Cosa occorre conoscere su CICS

La programmazione per CICS è molto simile alla programmazione per qualsiasi altro ambiente, ma ci sono alcune funzioni di base di CICS da comprendere e alcune aree in cui i programmi per IBM Z si comportano in modo diverso rispetto ad altre piattaforme.

Nuovo in CICS? Introduzione a CICS - un corso IBM Redbooks mostra cos' è e cosa fa.

Aprire una sezione di seguito per ottenere un breve riepilogo e collegamenti a ulteriori informazioni.

Introduzione a CICS - un corso IBM Redbooks

Funzioni CICS

Servizi CICS®

Tramite l'API, CICS fornisce servizi a un'applicazione: servizi quali la gestione dei dati, le comunicazioni e i servizi diagnostici. Un punto terminologico: i gestori servizi CICS di solito hanno la parola controllo nel loro titolo: ad esempio, controllo del programma.

Per saperne di più:
Risorse CICS

Le risorse utilizzate da CICS o dalle relative applicazioni, come file, programmi e così via, agiscono come oggetti metadati. Innanzitutto, si definiscono le risorse in un catalogo. In CICS, i cataloghi risorse sono dataset VSAM. Vengono utilizzati dataset diversi in base al metodo utilizzato per definire le risorse. Un dataset viene denominato CICS system definition data set (CSD), noto anche come CICS system definition file (CSD)e contiene le definizioni delle risorse di qualsiasi risorsa definita in CICS tramite i seguenti metodi: la transazione CEDA, CICS Explorer, il programma di utilità batch di aggiornamento CSD DFHCSDUPo i comandi API CSD. Un altro data set è denominato EYUDREP e contiene le definizioni delle risorse di qualsiasi risorsa definita in CICS tramite CICSPlex SM Business Application Services (BAS).

In fase di runtime, si installa un'istanza della definizione della risorsa per gestirla. Quando viene installata una definizione di risorsa, le informazioni relative alla risorsa vengono utilizzate per creare le strutture di dati che rappresentano la risorsa nello spazio di indirizzi CICS .

In Java, le risorse CICS sono rappresentate da istanze della classe Java appropriata. Per utilizzare, ad esempio, una TSQ (temporary storage queue) CICS , creare prima un'istanza di un oggetto TSQ. Quindi, assegnare un nome che corrisponda al nome del TSQ che si desidera utilizzare e utilizzare i relativi metodi per manipolare la coda.

I nomi delle risorse sono riportati nella documentazione CICS in maiuscolo: ad esempio, una risorsa che definisce un server JVM è denominata JVMSERVER.

Per saperne di più:
Bundle e parti di bundle CICS

Una risorsa che verrà utilizzata con programmi Java è un bundle CICS. Un bundle CICS è un meccanismo di impacchettamento e distribuzione per le risorse CICS (consultare How it works: Java in CICS). Agisce come un contenitore per le risorse correlate che sono raggruppate e gestite insieme. I bundle CICS sono in grado di fornire il controllo delle versioni per gli aggiornamenti delle risorse e possono dichiarare dipendenze su altre risorse esterne al bundle. Il bundle viene distribuito in zFS. Quando si installa (distribuisci) un bundle, CICS legge il manifest nella directory del bundle e crea dinamicamente le risorse CICS . CICS controlla inoltre che tutte le dipendenze richieste, ad esempio programmi o file esterni al bundle, siano presenti nella regione CICS .

Le risorse all'interno di un bundle CICS sono denominate CICS parti bundle.

È facile confondere i bundle di CICS con i bundle OSGi. I bundle OSGi sono componenti del sistema OSGi Java. La parte bundle OSGi CICS fa riferimento a un bundle OSGi e consente a CICS di distribuire tale bundle OSGi in un server OSGi JVM quando il bundle CICS è abilitato. Gli ambienti OSGi al di fuori di CICS non conoscono il concetto di bundle " CICS ", quindi i bundle OSGi in circolazione vengono generalmente distribuiti direttamente sul framework OSGi. L'approccio " CICS " offre tuttavia alcuni vantaggi, come la possibilità di controllare il ciclo di vita sia dei bundle OSGi che delle risorse " CICS " all'interno dello stesso meccanismo di packaging.

Come se quella potenziale confusione non fosse sufficiente, Liberty ha anche un meccanismo di contenimento per i bundle OSGi, chiamato Enterprise Bundle Archive, o EBA. Tuttavia, gli EBA non sono solo un modo per distribuire più bundle OSGi, ma anche un modo per distribuire insiemi di bundle OSGi come un singolo sottosistema isolato (si pensi a un mini contenitore OSGi per ogni applicazione). CICS va fino in fondo e fornisce una parte bundle CICS EBA per la distribuzione di EBA in CICS Liberty. In ultima analisi, il bundle OSGi si trova all'interno di un EBA e l'EBA si trova all'interno di un bundle CICS .

Per saperne di più:
Transazioni CICS e unità di lavoro

In CICS, una transazione consiste in un elemento di elaborazione che può essere eseguito da uno o più programmi applicativi. Le transazioni possono essere definite dagli utenti di CICS e vengono indicate come transazioni utente nella documentazione CICS . CICS fornisce anche le transazioni per controllare le operazioni CICS , denominate transazioniCICS. Ogni transazione è identificata dal relativo identificativo transazione (TRANSID). Le transazioni CICS hanno identificatori di transazione che iniziano con C e sono lunghe 4 caratteri, ad esempio CEMT.

In molti altri contesti IT, una transazione descrive un'unità di recupero: in genere, un'operazione completa che è recuperabile. Può essere eseguito il commit o il rollback (backout) come una totalità, come risultato di un comando programmato o di un malfunzionamento del sistema. CICS richiama questa unità di recupero come unità di lavoro. In molti casi, l'ambito di una transazione CICS è anche una singola unità di lavoro, ma non è necessario. Gli sviluppatori hanno flessibilità per consentire a CICS di gestire l'integrità nell'ambito della transazione CICS o per utilizzare esplicitamente le chiamate API per elaborare le unità di lavoro. Non esiste alcuna API per avviare esplicitamente una nuova unità di lavoro. Una nuova unità di lavoro viene considerata attiva al termine della precedente. La fine di un'unità di lavoro è chiamata syncpoint (punto di sincronizzazione), quindi il comando utilizzato nei programmi COBOL per confermare tutte le modifiche alle risorse recuperabili dall'ultimo syncpoint è EXEC CICS SYNCPOINT.

In Java, è possibile utilizzare i metodi JCICS commit e rollback nella classe Task per completare l'unità di lavoro corrente e aggiornare le risorse in linea con tale lavoro.

Altre risorse:
Attività e thread CICS

Quando CICS riceve una richiesta di esecuzione di una transazione, avvia una nuova attività associata a questa istanza di questo tipo di transazione. Si può pensare ad esso come analogo ad un filo. CICS Le attività vengono eseguite in parallelo come thread nello stesso processo server di JVM. L' JVM e è condiviso da tutte le attività di CICS, che potrebbero eseguire più applicazioni contemporaneamente. Vengono condivisi anche i dati statici e le classi statiche. Quindi, per utilizzare un server JVM in CICS, un'applicazione Java deve essere thread-safe.

Un TCB (task control block) è un'unità di lavoro distribuibile in z/OS. Il dispatcher z/OS distribuisce i TCB. Il dispatcher CICS distribuisce le attività CICS da eseguire sui TCB. Quando CICS è stato sviluppato per la prima volta, tutte le attività CICS che eseguivano applicazioni utente venivano eseguite su un TCB denominato quasi - rientrante TCB (QR TCB). Al giorno d'oggi, un OTE (open transaction environment) consente al codice dell'applicazione thread - safe di essere eseguito sul proprio TCB all'interno dello spazio di indirizzi CICS senza interferenze da altre transazioni. I programmi Java vengono eseguiti in OTE. Sebbene l'OTE offra le applicazioni da eseguire su una classe di TCB denominata TCB aperto o sul TCB quasi rientrante (QR TCB), le applicazioni Java vengono eseguite solo su un TCB aperto mentre eseguono il codice Java. Se l'applicazione Java esegue un comando CICS non thread - safe, viene eseguita in una regione CICS che utilizza l'isolamento della transazione o esegue un'uscita utente correlata al task non thread - safe, passa al TCB QR.

In OTE, CICS gestisce i TCB aperti in lotti separati. Ogni pool contiene un tipo (o modalità) diverso di TCB aperto. Ogni modalità ha un identificativo di due caratteri per indicarne lo scopo specifico e viene gestito da CICS in modo diverso. La modalità di TCB utilizzata dalle applicazioni Java è T8. Ogni thread nel processo server JVM viene eseguito in un TCB ( T8 ).

Un'attività di CICS non è limitata all'esecuzione su un singolo TCB. Durante il ciclo di vita di un'attività, il dispatcher CICS può eseguire più operazioni di modifica modalità TCB per fornire all'applicazione utente l'ambiente corretto. Queste modifiche non sono evidenti per l'applicazione utente al runtime, ma comportano una piccola penalizzazione delle prestazioni.

Per saperne di più:
Collegamento tra programmi

La chiamata da un programma CICS ad un altro è nota come link (o LINK, dal nome del suo comando EXEC CICS ). CICS LINK passa il controllo al programma di destinazione e ne attende il completamento. Il programma iniziale viene temporaneamente sospeso e viene avviato il programma collegato. Quando il programma collegato ritorna, il controllo viene restituito al programma originale. Il programma avviato fa ancora parte della stessa unità di lavoro, quindi qualsiasi lavoro eseguito per le risorse recuperabili da entrambi i programmi viene ripristinato se l'attività non viene completata correttamente. In altre parole, un LINK CICS funziona proprio come una chiamata di sottoroutine, tranne per il fatto che i programmi richiamati e richiamati non sono collegati in modo statico. Un link differisce da una chiamata di metodo Java in quanto il programma di destinazione può essere implementato in qualsiasi linguaggio supportato da CICS e può risiedere anche su un diverso sistema CICS . Tuttavia, una chiamata al metodo Java è molto più leggera di un comando LINK.

Il trasferimento del controllo ad un altro programma viene eseguito con il comando XCTL (trasferimento controllo). Il programma che emette XCTL non riceve il controllo al termine del programma di destinazione. Piuttosto, il programma che è su di un livello nella gerarchia di chiamate fa.

Gli equivalenti Java per EXEC CICS LINK e EXEC CICS XCTL sono i metodi Program.link() e Program.xctl(). Si crea un'istanza della classe Program, si richiama il metodo setName() per fornire il nome del programma a cui si desidera trasferire il controllo e si richiama link() o xctl().

Per saperne di più:
Trasmissione di dati tra programmi

Ci sono due modi principali per trasmettere i dati tra i programmi: attraverso un'area di comunicazione (in CICS, denominata COMMAREA) o attraverso canali e contenitori.

Una COMMAREA è una parte di memoria, che contiene una struttura dati definita da un programma. Più comunemente, questa struttura di dati è un copybook COBOL. In CICS, un COMMAREA è solo una sequenza di byte, CICS non tenta di formattare la struttura dei dati, ma facilita semplicemente il trasferimento dei dati tra i programmi. La COMMAREA ha una dimensione massima di 32 KB. I programmi richiamati e richiamati devono avere esattamente la stessa definizione del layout COMMAREA per abilitare l'intercomunicazione corretta. La struttura dei dati è descritta da un'interfaccia, in cui i campi sono definiti da una struttura specifica del linguaggio, come un copybook dell' COBOL. Affinché un'applicazione Java comunichi con un'applicazione scritta in un altro linguaggio, si utilizza una schiera di byte per rappresentare la COMMAREA e per conservare i dati da trasferire. Gli strumenti che generano le classi Java rendono più semplice la creazione dell'array di byte richiesto.

I canali e i contenitori affrontano le limitazioni con COMMAREA. Un canale è un'area denominata di memoria gestita da CICSassociata a un task. All'interno di un canale, è possibile memorizzare più parti di dati sotto forma di contenitori denominati. I contenitori vengono classificati come contenenti dati CHAR, dove CICS gestisce qualsiasi conversione di codepage richiesta; oppure come contenenti dati BIT, dove non avviene alcuna conversione. È possibile passare più contenitori tra programmi all'interno di un canale in modo da poter confrontare un canale con un elenco di parametri.

Per saperne di più:

Utilizzo di z/OS

Gestione delle interruzioni e delle eccezioni

Cos' è una fine anomala? Un'interruzione CICS è una fine anomala. È possibile considerarla come un'eccezione non verificata o un'eccezione di runtime in Java. L'errore si verifica attraverso il programma e, se non si gestisce esplicitamente l'errore, il programma avrà esito negativo. È possibile impostare un gestore di abend per rilevare queste eccezioni.

Nei linguaggi tradizionali, CICS indica l'esito positivo o negativo di un comando CICS restituendo un codice condizione al programma applicativo (di solito denominato valore RESP perché si utilizza la parola chiave RESP per richiamarlo). Per ogni valore RESP che può verificarsi in CICS, esiste una classe di eccezione Java corrispondente.

Per saperne di più:
Codifica caratteri e EBCDIC

Una delle considerazioni più importanti nella conversione di un programma distribuito per l'esecuzione in z/OS è la codifica EBCDIC. Non si tratta tanto di una cosa CICS quanto di una cosa generale della piattaforma z/OS , ma è importante comprendere. Senza comprendere come funziona la codifica per i dati trasmessi tra i programmi CICS e l'output che si desidera che gli utenti finali ricevano, è possibile ottenere dati inutilizzabili.

CICS funziona sempre in EBCDIC (consulta Wikipedia per una definizione di EBCDIC), ma l' JVM e può utilizzare una tabella codici diversa da CICS per la codifica dei caratteri. Le JVM OSGi solitamente funzionano in EBCDIC, mentre le JVM Liberty cercano di funzionare in ASCII ( UTF-8 ). Le stringhe Java sono Unicode, ma i dati caratteri dell' COBOL e e gli array di byte Java vengono codificati quando vengono passati alle stringhe o restituiti da esse. Per impostazione predefinita, l'API JCICS utilizza la tabella codici specificata nel parametro di inizializzazione del sistema LOCALCCSID per la regione dell' CICS, anziché l' JVM sottostante. Se le due tabelle codici sono diverse, il programma deve gestirle oppure è necessario chiedere a un amministratore di sistema CICS di modificare la codifica dei caratteri JCICS aggiornando una proprietà di sistema JVM nel profilo JVM.

Per saperne di più:
zFS

z/OS File System (zFS) è il tipo principale di file system di z/OS UNIX ed è ampiamente utilizzato con CICS. zFS fa parte dell'elemento di base Distributed File Service di z/OS. Come altri sistemi UNIX, zFS è un file system gerarchico, contenente file e directory accessibili tramite interfacce di programmazione delle applicazioni (API) z/OS UNIX.

Per saperne di più:

Dove si trova il prossimo?

Introduzione Questa pagina Scelte di progettazione per Java in CICS
Cosa occorre conoscere su CICS Esplora API Java Prova Java nella nostra sandbox
Prova Java nel tuo ambiente Partecipa Domande frequenti