5. Consigli per il debug dei CGI

In campo didattico, il debug viene sempre per ultimo, anche se l'argomento di per sè è ai primi posti nell'interesse di un programmatore. Questo è un buon motivo per dedicare una pagina speciale a questo argomento.

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.

7. Consigli per la migrazione da Versione 1

Se avevi già sviluppato dei CGI con la Versione 1, mi immagino che, dopo aver saputo dell'enorme miglioramento di prestazioni apportato dalla Versione 2, non starai più nella pelle dalla voglia di provare.
Il lavoro di migrazione è facile, ma per renderlo ancora più facile abbiamo preparato una pagina ad hoc: leggila.

8. 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.

9. 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.