Circolare numero 94 del 6-4-1991

Manuale per la gestione del sistema elaborativo IBM/AS400 per lo sviluppo applicazioni nelle sedi regionali

La circolare trasmette il manuale di riferimento per l’uso degli AS/400 installati presso le sedi regionali e ne richiama l’adozione uniforme da parte del personale coinvolto nello sviluppo applicativo. Il documento è finalizzato a garantire omogeneità tecnica, corrette procedure di sviluppo, catalogazione e distribuzione del software, nonché una gestione coordinata tra sedi regionali e centro nazionale.

Finalità della circolare e destinatari

La comunicazione accompagna il manuale per lo sviluppo delle applicazioni in ambiente AS/400 e sottolinea la necessità che i dirigenti responsabili della sviluppo presso le sedi regionali ne diffondano copia a tutto il personale con funzioni di analisi e programmazione. Il contenuto del manuale è qualificato come essenziale per la corretta applicazione degli standard di sviluppo.

Contesto tecnico e organizzativo del sistema AS/400

Il manuale descrive il passaggio dagli elaboratori IBM-8100 agli AS/400, indicando che questi ultimi consentono sia l’esecuzione di procedure già esistenti, previa trasformazione dei programmi, sia lo sviluppo di nuove applicazioni in COBOL-AS400. Viene illustrata la logica del "prototipo" AS/400 definito presso il Servizio E.A.D. e trasferito alle sedi regionali come ambiente logico coerente con le esigenze dell’Istituto.

L’AS/400 regionale è concepito come un "centro satellite" autonomo ma integrato con il sistema centrale. Il collegamento tra i sistemi regionali e gli elaboratori centrali è affidato al Netview Distribution Manager, mentre sul sistema SVA-HOST opera il prodotto TRANSFORMER per generare moduli precompilati da destinare all’AS/400. Il testo richiama anche la distribuzione, tramite il sistema DM, dei programmi trasformati DPCX e dei nuovi programmi COBOL nativi verso le sedi periferiche.

Ruoli, responsabilità e coordinamento locale

Presso l’Ufficio prove programmi è stato istituito il Settore AS400, cui compete:

• la guida funzionale per l’individuazione e l’installazione del software di base;
• la progettazione, realizzazione e gestione del prototipo di struttura operativa;
• il trasferimento della struttura progettata alle sedi regionali;
• l’assistenza e il coordinamento dei mondi AS400 di sviluppo.

Ogni sede regionale deve nominare un responsabile del sistema locale, comunicandone il nominativo ai programmi dell’E.A.D. Tale figura coordina le attività degli addetti, costituisce il punto di riferimento operativo della sede e collabora con il responsabile AS400 dell’E.A.D. per gestione, mantenimento della struttura e installazione del software.

Hardware e software di base

Il manuale rinvia agli allegati per la configurazione hardware "tipo" dell’AS400 regionale. Per la parte software, il Settore AS400 individua i componenti del sistema operativo da installare, cura l’approvvigionamento e guida l’installazione del software, affiancando il responsabile locale per il trasferimento graduale di conoscenze tecniche.

È evidenziata la necessità assoluta che tutte le sedi regionali risultino allineate quanto a presenza e livello dei componenti software. Il manuale raccomanda attenzione e puntualità sia a livello centrale sia locale, anche in ragione della possibile evoluzione nel tempo delle integrazioni e variazioni ai componenti richiesti.

Struttura di sviluppo: progetti, utenti e librerie

Nell’ambito delle aree DM e PN sono individuati progetti o gruppi di lavoro, ciascuno identificato da un codice alfanumerico di due caratteri. Parallelamente, ogni utente abilitato agli AS/400 regionali riceve un identificativo di due caratteri alfanumerici, così da consentire il collegamento tra oggetti memorizzati e utenti e facilitare la gestione degli spazi.

La nomenclatura degli utenti segue uno schema che associa area, gruppo di lavoro e progressivo utente. I gruppi sono inizialmente disattivati e il QSYSOPR deve attivarli con le utility previste. Solo dopo l’attivazione gli utenti possono effettuare il signon, inizialmente con password uguale al profilo utente, da modificare subito per ragioni di sicurezza tramite il comando CHGPWD.

Le librerie sono organizzate in modo diverso per DPCX e COBOL, sia in ambiente regionale sia centrale. Il manuale elenca le librerie sorgenti, oggetto, di archivio e di transito, distinguendo i livelli di sviluppo, catalogazione e produzione. Per la nomenclatura degli oggetti si stabilisce che:

• il nome degli oggetti AS/400 non può superare 10 caratteri;
• gli oggetti creati dall’utente non devono iniziare con "Q" o "K", riservate agli oggetti di sistema;
• nel COBOL il nome applicativo è normalmente gestito su 7 caratteri, con l’ottavo usato solo per indicare il rilascio corrente o nuovo;
• per i programmi DPCX e per i flussi di catalogazione centralizzata vengono utilizzati meccanismi analoghi di distinzione tra sorgente, precompilato ed eseguibile.

Configurazione regionale e centrale

L’AS/400 regionale è suddiviso in due macro-ambienti: ambiente di sviluppo e ambiente di sede. Il primo ospita il parco dati, i test dei programmi COBOL/SQL e i test dei programmi DPCX; il secondo contiene l’ambiente di sede con profili, librerie, programmi e autorizzazioni provenienti da HOST. Il manuale precisa che questa configurazione si intende duplicata per entrambe le aree funzionali, Riscossioni Contributi e Prestazioni.

Sul piano centrale, presso la D.C.I., sono installati due sistemi AS/400, uno per ciascuna area, con funzioni di sistemi centrali verso i quali confluisce il software applicativo sviluppato sul territorio. Le motivazioni organizzative della scelta sono esplicitate nel manuale e si basano sull’esigenza di mantenere un unico livello accertato di software e due archivi centrali nazionali: uno per i programmi simbolici e uno per i programmi eseguibili.

Programmazione DPCX: test e catalogazione

Per il DPCX il manuale descrive un flusso di sviluppo ancora collegato al mondo 8100. La fase di test avviene tramite il comando SVAP sul sistema HOST-SVA e consente di produrre, attraverso il TRANSFORMER, un modulo precompilato destinato all’AS/400 regionale. Questo modulo viene poi compilato in ambiente AS/400 e reso disponibile per il collaudo con i dati dell’ambiente di prova.

La catalogazione DPCX prevede invece la compilazione sul sistema HOST-SVA, l’archiviazione del modulo, la trasformazione in precompilato e il trasferimento del programma all’AS/400 centrale, dove si svolge la compilazione definitiva e l’inserimento in archivio. In caso di esito negativo della compilazione, il programma viene eliminato dal file di transito; in caso di esito positivo, viene registrato nella libreria YDXCAT dedicata alla conservazione dei programmi catalogati.

Il manuale precisa che, pur essendo il processo generalmente automatizzato, alcune istruzioni DPCX non sono direttamente trasformabili; per questo motivo resta talvolta necessario un test anche in ambiente AS/400, oltre a quello tradizionale su 8100.

Programmazione COBOL: compilazione e gestione delle versioni

La compilazione COBOL avviene interamente sull’AS/400 di sviluppo regionale o E.A.D. e produce un modulo oggetto a partire dal sorgente. La procedura consente la compilazione di programmi COBOL, COBOL/SQL e CLP. Il programma da compilare viene richiesto tramite pannello e, se composto da 7 caratteri, viene automaticamente completato con un ottavo carattere di versione.

L’utente deve indicare se il rilascio è corrente o nuovo, poiché la compilazione produce il modulo oggetto nella libreria corrispondente alla versione scelta. Il manuale chiarisce che, in tale contesto, l’ottavo carattere non va inteso come versione nel senso tradizionale, ma come distinzione tra procedura corrente e nuova, utile soprattutto nelle fasi di test su sedi pilota.

Catalogazione COBOL: precatalogazione, trasferimento e archiviazione

La catalogazione COBOL è articolata in tre momenti:

• precatalogazione sull’AS/400 regionale;
• trasferimento del pacchetto all’AS/400 centrale tramite l’NDM di HOST1;
• catalogazione vera e propria sull’AS/400 centrale, a cura degli uffici competenti.

La precatalogazione consiste nella preparazione di un insieme di oggetti o pacchetto da inviare al centro come lavoro finito. L’utente operante in questa fase accede con un profilo del tipo gruppo + PCAT e utilizza il menu MPCAT1, che consente la gestione di programmi e componenti correlati oppure di altri oggetti come modulo base, message file, printer file e DDS.

Per i programmi e i componenti correlati è previsto il menu MPCAT2; per gli altri oggetti, il menu MPCAT3. Il sistema genera save file dedicati, con nomi strutturati secondo codifiche specifiche che incorporano gruppo, sede, giorno e progressivo. Il manuale descrive anche le utility di visualizzazione, accettazione, cancellazione e scambio di oggetti fra centri di sviluppo tramite i menu MPCAT4 e MPCAT5.

Sul sistema centrale il catalogatore accede con utenza di gruppo e password corrispondente al codice utenza. Il menu principale MCAT01 consente di:

• catalogare programmi nativi e componenti correlati;
• catalogare modulo base, file messaggi, archivi e printer file;
• catalogare programmi a seguito di modifiche ai componenti;
• accedere alle funzioni utente;
• visualizzare i file di spool;
• usare i programmi di utilità.

Nella fase centrale è possibile visualizzare i save file in attesa, escludere oggetti singoli dalla catalogazione, annullare l’intero save file, forzare la sovrascrittura di oggetti già presenti oppure rinunciare in caso di duplicato. Il manuale prevede inoltre il richiamo di altri programmi da ricompilare quando una mappa o un componente modificato impone una ricostruzione di dipendenze.

Trasferimento oggetti tra sedi e centro: procedura COB400

La procedura COB400, richiamabile via TSO sul sistema centrale di sviluppo, è il canale operativo per il trasferimento di oggetti tra sedi regionali e centro. Le opzioni consentono:

• l’invio di programmi e DDS da catalogare;
• l’invio di oggetti diversi da modulo base, DDS, printer file e message file;
• il prelievo di programmi source dal centro;
• l’invio di oggetti al centro per il successivo prelievo da un centro di sviluppo;
• il prelievo di oggetti ricevuti tramite il sistema centrale.

Il manuale specifica che, per i programmi richiesti in manutenzione, viene mantenuto un flag che impedisce richieste concorrenti da altre sedi; la disponibilità viene ripristinata solo dopo la catalogazione. La procedura COB400 predispone i piani di trasmissione da affidare all’NDM, che effettua la distribuzione o il recapito dei save file.

Manutenzione, nuovi programmi e gestione degli oggetti catalogati

Per i programmi già catalogati, la manutenzione comporta il richiamo dal centro all’archivio dei simbolici verso la sede regionale. La richiesta deve specificare la motivazione, cioè se il programma è richiesto per visione o per modifica. Il manuale sottolinea che la richiesta viene registrata al centro e che solo in tal modo il programma potrà essere reinserito negli archivi dei catalogati dopo la manutenzione.

L’inserimento di nuovi programmi in archivio è subordinato alla predisposizione della corrispondente "entrata" da parte dei responsabili degli uffici. Sono previste funzioni specifiche per operare sui pacchetti, sulle registrazioni di prelievo e sulla creazione delle entrate necessarie.

Funzioni operative del QSYSOPR

Il menu MNUOPR mette a disposizione del QSYSOPR le principali funzioni operative di sistema. In particolare, il manuale disciplina:

• applicazione delle FIX, con procedura di verifica delle correzioni precedenti e chiusura dei sottosistemi;
• reset delle password, differenziato per utenti DM e PN, di S.A.P. o di programmazione, fino al singolo utente;
• ripristino delle autorità, per ambiente, per libreria o per oggetto;
• invio di messaggi agli utenti, visualizzati al signon;
• salvataggi su nastro;
• salvataggio e ripristino di archivi e librerie da disco;
• ulteriori funzioni legate alla gestione dei gruppi di lavoro e del giornale.

Il menu MNUOP2 consente, tra l’altro, di avviare il giornale per i dataset di DMADSNEW2, attivare o disattivare gruppi di lavoro e cambiare o cancellare i ricevitori di giornale. Il manuale distingue chiaramente le operazioni svolte nei Centri di Sviluppo da quelle tipiche delle SAP, soprattutto per quanto riguarda la cancellazione dei dati di giornale senza salvataggio.

Gestione degli ASP e dei dumps

Nel manuale l’ASP è definito come porzione del parco dischi dedicata soprattutto al salvataggio dei giornali e dei ricevitori. Si raccomanda di avviare il giornale solo quando necessario, per non appesantire il sistema e per evitare il rapido riempimento dell’ASP. Vengono richiamate le procedure giornaliere e settimanali di salvataggio, con funzioni di cambio ricevitore, creazione dei file di salvataggio, svuotamento del ricevitore e salvataggio dei dati su nastro.

Per i dumps viene illustrato un metodo di rotazione dei nastri che consente di disporre di tre versioni settimanali e di una gestione del mese con supporti riutilizzabili. Il manuale raccomanda espressamente di eseguire i dumps con regolarità, al fine di prevenire perdite di dati non ripristinabili.

Allegati e schermate operative

Il manuale comprende numerosi allegati: configurazioni hardware tipo, elenco del software di base, tabella dei progetti, codifica dei nomi dei programmi e degli oggetti, schema dei dumps, nonché le maschere di menu per le procedure di precatalogazione, catalogazione, funzioni utente, utilità di sistema e trasferimento oggetti. Tali allegati costituiscono parte integrante delle istruzioni operative e rendono immediatamente applicabili le procedure descritte nel corpo del manuale.