6. Significato dei codici di errore

In certi casi alcune delle procedure del service program possono restituire dei "return code" diversi da zero. Solitamente tali codici di errore vengono anche riportati nel file CGIDEBUG. Ma quale è il significato di questi codici? Si può tentare di decifrarli attraverso le pagine dell' iSeries Information Center. Per esempio:

1. si vada alla pagina V4R5
2. si effettui una ricerca per "errno xxxx", dove xxxx è il codice di errore in questione.

5. Consigli per il debugging

La soluzione degli errori (debugging) è al primo posto nell'interesse degli sviluppatori. Ecco perchè abbiamo dedicato a questo argomento un' intera pagina.

7. Consigli per avere prestazioni ottimali

Seguendo questi consigli riuscirai ad avere il meglio, in termini di prestazioni, dai tuoi CGI:

1. usa un activation group con nome (un activation group diverso per ogni CGI, vedi la FAQ numero 26
2. effettua il return senza accendere l'indicatore LR

   Nota. Ritornare con LR impostato ad *off dà al programma un altro enorme vantaggio. La prossima volta che il programma sarà invocato ed entrerà nella procedura gethtml per caricare l'html esterno, in effetti non effettuerà il caricamento, perchè il service program si accorge che ciò è già stato fatto. Il service program effettua il ricaricamento solo se si accorge che il sorgente html esterno è stato variato. Questo comportamento del service program è responsabile di buona parte dei miglioramenti apportati con la Versione 2.

3. fai in modo che il programma apra i file solo la prima volta che viene chiamato, ma non li chiuda mai
4. ogni volta che il programma viene richiamato, deve
   • ri-inizializzare le variabili
   • riposizionare i file usando SETLL, o SETGT, o qualunque altro modo sia appropriato
5. Quando i programmi sono stati completamente collaudati, usa CALLP SetNoDebug(*ON) per disattivare tutte le attività di debugging.

   Nota.SetNoDebug imposta una variabile globale nel service program. Questo significa che tutti i programmi CGI che girano nello stesso "activation group con nome" si comportano conseguentemente all'ultima richiesta di SetNoDebug ricevuta.

8. A proposito dei CGI persistenti

Sin qui, sottacendo la cosa, abbiamo sempre indirettamente parlato di CGI non persistenti. Tradizionalmemnte i programmi CGI sono non persistenti, nel senso che un CGI, la prossima volta che viene invocato non si ricorda (o meglio, è opportuno che non si ricordi- dato che chi lo chiama può benissimo essere un client diverso da precedente) quali valori erano stati lasciati nelle variabili e quale era il posizionamento dei file.
Naturalmente questo fatto ha importanza notevole nella progettazione dei programmi, in quanto le variabili che sono importanti per le ri-esecuzione del programma vanno salvate nascostamente nello script html inviato al client, dimodochè il client le ritrasmetta nella chiamata successiva (in altre parole. il client funziona da "memoria" per il server).
Va detto però che dalla V43R3 sull'HTTP è stato fornito supporto per i CGI persistenti.
I CGI persistenti effettuano anch'essi return senza accendare l'indicatore LR , ma godono della proprietà di poter essere richiamati solo dallo stesso client che li aveva chiamati in precedenza. Pertanto un CGI persistente, una volta richiamato, sa che le variabili contengono valori appropriati e che i file sono posizionati al punto giusto.
Un CGI persistente, per fare in modo da poter essere richiamato solo dal client originale, stacca -per così dire- uno scontrino in duplice copia: una copia la consegna al servente http (che funge da magazziniere), l'altra copia la consegna al client (il cliente). In definitiva, quando il client deciderà di ricontattare quel CGI, lo farà presentando al magazziniere (l'http) lo scontrino assegnatogli. L'http provvederà quindi a richiamare quella copia di programma ferma in memoria, che aveva emesso quello scontrino.
In termini tecnici, anzichè di scontrino, si parla di "identificativo di sessione" o "handle" (manico della valigia).
L'altro problema è che un CGI in attesa di chiamata tiene fermo un job http servente. Questo comporta due aspetti:

• solo una frazione dei job http serventi può essere dedicata a CGI persistenti
• se un CGI persistente non viene più richiamato dopo un tempo predefinito, l'http uccide il job che lo contiene e fa ripartire un nuovo job servente. In questo caso, il client che si trovasse successivamente a richiedere quel CGI persistente, non potrebbe essere servito.

Ciò posto, voglio ora dire la mia opinione sui CGI persistenti. Io sconsiglio di usarli, per i motivi seguenti:

• il CGI persistente non è -contrariamente all'intuito- necessariamente più "performante" di uno non persistente
• le difficoltà di organizzare un buon sistema di "scontrin-aggio" e di "timeoout" controllato sono tali da scoraggiare chiunque vi si appresti senza una precedente lunga dimestichezza con i CGI non persistenti
• resta insoluto il caso dell'utente il quale, essendo stato interrotto nel suo lavoro da -diciamo- una lunga telefonata, lo perde perchè il suo CGI persistente è andato in timeout.

L'unico caso in cui io ritengo che i CGI persistenti possano essere di aiuto è -forse- quello in cui sia necessario utilizzare tecniche di COMMIT.
Dato tuttavia che utilizzare i CGI persistenti è legittimo, abbiamo preparato una pagina che aiuta nel compito.

9. Comandi ZIP e UNZIP

La libreria CGIDEV2 contiene i comandi ZIP e UNZIP. Questi comandi consentono di comprimere e decomprimere file di flusso IFS utilizzando file standard di tipo .zip.
Le richieste dei comandi ZIP ed UNZIP vengono trasformate in comandi QSHELL, i quali vengono eseguiti in modo batch.
Il risultato di questi comandi può essere facoltativamente visualizzato.

10. Nuovi rilasci di CGIDEV2

1. Firma del *srvpgm program CGIDEV2/CGISRVPGM2

Occasionalmente un nuovo rilascio della libreria CGIDEV2 può comprendere nuove procedure per il *srvpgm CGIDEV2/CGISRVPGM2.

A partire da 25 Marzo 2009, il *srvpgm CGIDEV2/CGISRVPGM2 è dotato di firma zero.

Se hai già la libreria CGIDEV2 e sei in procinto di installarne una nuova versione, occorre che tu prima controlli la data di rilascio della versione esistente. Per farlo, devi immettere il comando CGIDEV2/RELEASED.

1. Se il CGIDEV2 esistente ha una data di rilascio uguale o superiore al 25 Marzo 2009, i programmi esistenti che si legano al *srvpgm CGIDEV2/CGISRVPGM2 non avranno problemi con il nuovo rilascio di CGIDEV2, in quanto il nuovo *srvpgm CGIDEV2/CGISRVPGM2 non provocherà un conflitto di firma.
2. Se invece il CGIDEV2 esistente ha una data inferiore al 25 Marzo 2009, dopo la installazione del nuovo rilascio di CGIDEV2 sarà necessario lanciare il comando CGIDEV2/REBIND nome_libreria per ogni libreria contenente programmi legati al *srvpgm CGIDEV2/CGISRVPGM2.
   Il comando CGIDEV2/REBIND ri-lega tutti i *srvpgm ed i *pgm CBLLE/RPGLE della libreria specificata.
3. Se avevi duplicato il *srvpgm CGIDEV2/CGISRVPGM2 in varie librerie di programmi CGI (per renderle indipendenti dal *srvpgm CGIDEV2/CGISRVPGM2 ed essere quindi libero di installare in qualunque momento nuove versioni di CGIDEV2) e se desideri sostituire alcuni di quei *srvpgm CGISRVPGM2 duplicati con la versione disponibile nella nuova libreria CGIDEV2, allora ti conviene usare il comando CGIDEV2/DUPSRVPGM.
   Questo comando:
   1. trova le librerie che contengono il *srvpgm CGISRVPGM2
   2. di consente di scegliere le librerie da trattare
   3. per ogni libreria scelta
      • sostituisce il *srvpgm CGISRVPGM2 di quella libreria con una copia del *srvpgm CGIDEV2/CGISRVPGM2
      • ri-lega tutti i *srvpgm di quella libreria
      • ri-lega tutti i *pgm CBLLE e RPGLE di quella libreria.



2. Activity group del *srvpgm CGIDEV2/CGISRVPGM2

Durante la installazione di CGIDEV2, il *srvpgm CGIDEV2/CGISRVPGM2 viene creato con activity group CGIDEV2.
Prima di installare un nuovo rilascio di CGIDEV2, devi controllare che l'activity group del *srvpgm CGIDEV2/CGISRVPGM2 non sia invece *CALLER. Questo controllo si fa eseguendo il comando
DSPSRVPGM SRVPGM(CGIDEV2/CGISRVPGM2) DETAIL(*BASIC) .

Se l' activity group del tuo *srvpgm CGIDEV2/CGISRVPGM2 attuale è *CALLER, allora dopo la installazione del nuovo rilascio di CGIDEV2, DEVI eseguire il comando
UPDSRVPGM SRVPGM(CGIDEV2/CGISRVPGM) MODULE(*NONE) ACTGRP(*CALLER) .
Se non lo fai, potresti avere problemi con qualcuno dei tuoi programmi CGI.