Il Language Environment è l’ambiente di run-time pre-requisito per le applicazioni generate dal compilatore Cobol Enterprise di IBM.
Ma LE non può essere considerato un run-time per il solo linguaggio Cobol, poichè si configura come il livello unico di run-time per applicazioni multi-linguaggio ovvero organizzate in componenti cooperanti sviluppate in differenti linguaggi.
Per questo LE contiene sia librerie di run-time comuni e dedicate ai singoli compilatori LE-compatibili che librerie di compatibilità dedicate ai singoli linguaggi e relativi compilatori precedenti LE, destinati inevitabilmente come tool a cedere il passo a quelli predisposti per la visione multi-linguaggio.

La migrazione a Cobol Enterprise, che è lo step 2 del nostro percorso, quello successivo alla migrazione a LE, si collega a questa strategia di utilizzo del solo run-time LE per tutte le applicazioni Cobol anche integrate con parti in C e C++; che permette di eliminare, di conseguenza, il mantenimento in produzione di scenari applicativi basati su livelli precedenti di Cobol e relativo run-time la cui compatibilità con LE potrebbe essere non garantita.
Si ricordi a questo proposito che tutti i vari dialetti Cobol, incluso l'Enterprise della versione 3.1, 3.2, 3.3, risultano ritirati e non supportati.

Essenzialmente la migrazione a LE consiste in tre operazioni, due di tipo conservativo ovvero la sostituzione delle precedenti librerie con quelle di LE e l'eliminazione delle incompatibilità tra i run-times, ed una di tipo innovativo, ovvero l'utilizzo dei servizi forniti da LE ed il conseguente svecchiamento del codice.
Naturalmente la premessa di tutto è la disponibilità di un catalogo delle applicazioni, con relativi livelli e versioni, e la costruzione dell'ambiente batch e della regione CICS aggiornati a LE per l'esecuzione pratica della migrazione Guidati dal criterio che il run-time deve essere di un livello più recente dell'applicazione che lo utilizza, sia per le componenti linkate staticamente che per quelle richiamate a run time in modo dinamico, si procede con la sostituzione delle librerie senza modificare e compilare i sorgenti ma con l'eliminazione dei riferimenti alle precedenti librerie, e con l'esecuzione di test funzionali di non regressione mirati al programma.
Le incompatibilità determinano invece la variazione del codice, ma la casistica è quasi sempre reperibile dalla documentazione e dai vari siti (si veda ad esempio, la generazione e gestione dei casi di Abend).
In questi casi è del tutto ovvio l'utilizzo del Compilatore Enterprise, e questo anticipa l'esecuzione minima dello Step 2.

Nella migrazione a LE, molto rilevante è l'introduzione dei servizi servizi richiamabili direttamente da programma messi a disposizione da LE, per esempio:

- Manipolazione di bit,
- Gestione delle condizioni dei servizi chiamabili,
- Data e ora, tra cui le conversioni dal formato Lilian,
- Allocazione dinamica della memoria heap del processo,
- Attivazione e sospensione a tempo del processo,
- Inizio e stop di processo,
- Funzioni matematiche e trigonometriche,
- Servizi di tipo localizzazione e supporto al linguaggio nazionale.

Dato un programma Cobol, per esempio, una CALL CEELOCT permette di disporre della data ed ora locale in tre formati, ovvero Lilian-giorni (numero di giorni dal 14 Ottobre 1582), Lilian-secondi (numero di secondi dalle 00:00:00 del 14 Ottobre), e Gregoriano (stringa di caratteri della forma YYYYMMDDHHMISS999.
Questi valori sono compatibili con gli altri servizi data e ora di LE, come pure con le funzioni intrinseche del Cobol, di cui parliamo più avanti.

Abbiamo a disposizione il file CEEIGZCT per dichiarare i codici simbolici di Language Environnment utili per tutt i servizi, e lo istanziamo con il verbo Copy:

copy CEEIGZCT
call "CEExxxx" using parm1, parm2, ... parmn, fc

E utilizziamo Call statiche o dinamiche, ben sapendo che la scelta statica migliora le prestazioni del codice perché il modulo di load non viene caricato a run-time al momento della esecuzione della Call.

In sintesi, i razionali dell’utilizzo dei servizi di Language Environment sono due:
- riducono il costo della manutenzione a carico del programmatore applicativo poiché < ..are architected as low maintenance stubs ..>;
- partecipano alla modernizzazione dell'applicazione poiché sono contigui e compatibili con i compilatori Enterprise,

Corollario implementativo

L’iniziativa dello Step 1 si basa sulla ispezione del codice Cobol e sull'introduzione delle modifiche necessarie per la migrazione a LE e per implementare le chiamate ai servizi di Language Environment in sostituzione di codice sviluppato ad hoc.
Nel modello proposto la migrazione a LE è concettualmente precedente e separata da quella a Cobol Enterprise.
Poiché in alcuni casi si rende necessaria la ricompilazione Cobol ( e relativo testing) altre opinioni prevedono che la stessa ispezione possa essere l’occasione per eseguire contemporaneamente altre due operazioni di svecchiamento del codice, l’utilizzo delle funzioni intrinseche del Cobol e la migrazione completa al compilatore Enterprise.
Ma questo non è esattamente il nostro punto di vista, il testing di non regressione fa la differenza.