Il leggendario CGIDEV2

Il leggendario CGIDEV2
di Giovanni Battista Perotti
Per oltre un decennio CGIDEV2 ha insegnato a migliaia di programmatori RPG come fare del buon WEB a bassissimo costo riutilizzando
l’esperienza esistente. Inoltre, tramite i suoi sorgenti RPG-ILE, CGIDEV2 è diventato per tutti una scuola di programmazione ILE, insegnando
come si realizzano prototipi, procedure e programmi di servizio.
Questo è il primo di una serie di articoli con i quali mi rivolgo ad una tuttora vasta area di programmatori RPG che non hanno ancora sperimentato
l’ebbrezza di mandare in onda su Internet un loro programma. CGIDEV2 sarà per loro una esperienza entusiasmante, consentirà l’ingresso in un
mondo dove ogni giorno si fa una nuova scoperta.
Scrivere un programma per il WEB richiede non solo l’utilizzo di qualche istruzione nuova, ma richiede un piccolo aggiornamento culturale, in
quanto qui valgono leggi e regolamenti con le quali un programmatore tradizionale AS/400 (iSeries, System i, chiamatelo come volete) non ha
familiarità.
In questo primo articolo illustrerò alcuni elementi della panoramica WEB, che vanno al di là di CGIDEV2, ma la cui conoscenza è indispensabile per
poter capire poi come CGIDEV2 ad essi si appoggi. Questo può risultare inizialmente tedioso, ma è indispensabile premettere alcune nozioni cui in
seguito si dovrà necessariamente fare riferimento.
1- Il servente HTTP ed APACHE
Il TCP/IP (Transmission Control Protocol / Internet Protocol), è un insieme di protocolli di comunicazione utilizzati nella rete Internet ed in altre reti
(p.es. LAN). I protocolli più noti a livello applicativo sono il TELNET (Terminal NETwork, che consente una comunicazione bidirezionale di testi),
l’FTP (File Trasfer Protocol, utilizzato per trasferire file), l’SMTP (Simple Mail Transfer Protocol, che si occupa della trasmissione della posta
elettronica), il POP (Post Office Protocol, che consente di ricevere posta elettronica), l’HTTP (HyperText Transfer Protocol).
L’HTTP serve per comunicare tra WEB browser (web-client) e siti WEB (web-server) attraverso meccanismi standard di domanda-risposta tipici
dell’ambiente client-server.
La risorsa da accedere presso il web-server è generalmente una pagina statica, una pagina dinamica (cioè creata sul momento da un programma),
oppure una immagine, un PDF, ecc.. La risorsa viene richiesta dal client per il tramite di una cosiddetta URL (Uniform Resource Locator), che
specifica dove la risorsa è localizzata. La sintassi dell’URL http è:
http://indirizzo_servente:numero_porta/path?query_string#àncora
dove:
•
•
esempio:
•
•
•
l’indirizzo_servente è l’indirizzo IP del sistema web-server che ospita la risorsa (es. 89.234.101.99) oppure il nome del dominio con cui il webserver è registrato (es. www.easy400.net) .
il numero_porta (facoltativo) è il numero dell’interfaccia utilizzata sul web-server per colloquiare con uno specifico servente (istanza) http. Se
il numero_porta non è specificato, si intende la porta numero 80.
il path viene utilizzato per raggiungere una specifica risorsa (es. mmailp/xsearch.pgm )
la query_string contiene dati da passare alla applicazione web, per esempio un programma CGI (es: search=download )
l’ àncora (facoltativa) viene utilizzata per specificare una località all’interno della pagina trasmessa.
http://www.easy400.net/mmailp/xsearch.pgm?search=download
Il software utilizzato dal web-server per rispondere alle richieste http dei client, dipende dalla piattaforma.
Sull’AS/400 è stato inizialmente utilizzato, con il rilascio V4R2, un software proprietario IBM. Quando, con il rilascio V5R1, fu deciso di adottare
come web-server il software Apache, il precedente software proprietario fu denominato Original per distinguerlo da Apache. Apache è diventato
poi, con il rilascio V5R3, l’unico web-server per l’AS/400. Solo in tempi relativamente recenti è stato affiancato dal PHP.
Per utilizzare CGIDEV2, oggi ci si serve del software web-server di Apache.
Apache è, dal 2009, il software web-server più diffuso (oltre 100 milioni di siti).
Si tratta di un software open-source gestito dalla Apache Software Foundation.
L’HTTP consente di avere, per così dire, più fronti di servizio, chiamati istanze.
Ciascuna istanza occupa una porta diversa e viene definita tramite apposite istruzioni denominate direttive. Le direttive di una istanza sono
generalmente raccolte in un file di flusso IFS.
Le istanze http sono documentate nel file QUSRSYS/QATMHINSTC. Si tratta di un file multimembro, un membro per ciascuna istanza http.
Ciascun membro contiene un record, nel quale sta scritto quale sia il software web-server, quale sia il file di flusso contenente le direttive
dell’istanza e se la istanza debba partire automaticamente quando viene eseguito il comando STRTCPSVR SERVER(*HTTP). Per esempio, il
membro APACHEDFT del file QUSRSYS/QATMHINSTC contiene questo record:
dal quale si desume che
•
•
-apache -d /www/apachedft -f conf/httpd.conf –AutoStartY
il software web-server da utilizzare è Apache
il file di flusso contenente le direttive è /www/apachedft/conf/httpd.conf
•
la istanza viene avviata automaticamente all’avvio dell’http.
Per avviare manualmente una istanza http, si utilizza il comando
STRTCPSVR SERVER(*HTTP) HTTPSVR(nome_della_istanza)
Scrivere direttive http Apache non è un compito semplice, anche perché una direttiva sbagliata comporta o il fallimento dell’avvio di una
istanza o il suo mancato funzionamento per alcune pagine che si intendeva servire.
Per questo motivo sull’AS/400 esiste una istanza particolare denominata *ADMIN, la quale serve per amministrare il WEB ed in particolare per
definire le direttive di una istanza http. Questa istanza si avvia con il comando STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN) e la si
utilizza dal PC con un browser WEB tramite la URL http://indirizzo_IP_AS400:2001/ . All’avvio viene richiesto di specificare il nome e la
password di un profilo utente con autorità speciale *SECADM.
Purtroppo questo strumento è molto complesso e generalmente si commettono con esso molti più errori di quanto non avvenga possedendo un
esempio di direttive e provando a modificarlo opportunamente. Per questo motivo, in CGIDEV2 le direttive Apache sono già preparate nel file di
flusso /cgidev/conf/httpd.conf . La istanza http che consente l’utilizzo di CGIDEV2 si chiama CGIDEV2APA ed ha un suo membro di
controllo che va copiato nel file QUSRSYS/QATMHINSTC. A ciò si perviene con il comando
CPYF FROMFILE(CGIDEV2/QATMHINSTC) TOFILE(QUSRSYS/QATMHINSTC)
FROMMBR(CGIDEV2APA) TOMBR(CGIDEV2APA) MBROPT(*REPLACE) CRTFILE(*YES)
La istanza CGIDEV2APA lavora sulla porta 8014 e si avvia con il comando
STRTCPSVR SERVER(*http) HTTPSVR(CGIDEV2APA)
.
.
Alle pagine WEB di documentazione di CGIDEV2 si può quindi accedere localmente con l’URL
http://indirizzo_IP_AS400:8014/cgidev2/start
.
Commenti a spiegazione delle direttive Apache utilizzate per CGIDEV2 si possono reperire alla pagina
http://www.easy400.net/eapch/myexper.htm#MyDir
Le direttive Apache sono documentate nell’ “IBM i and System i Information Center” http://publib.boulder.ibm.com/iseries/ dove occorre fare una
ricerca per "Directives for HTTP server".
La documentazione dell’Apache http server è alla pagina http://httpd.apache.org/docs/2.0/ .
Ritorneremo comunque più tardi sull’argomento, quando si tratterà di sviluppare un primo programma WEB con CGIDEV2.
2- Il protocollo CGI
CGIDEV2 utilizza il protocollo CGI. Ma che cosa è il CGI?
Il Common Gateway Interface (CGI) è uno standard (RFC3875, 1983) per i serventi HTTP. Esso stabilisce il modo in cui una richiesta deve
essere trasmessa dal client (Standard Input) ed il modo in cui la risposta deve essere trasmessa al client (Standard Output).
Il CGI è uno dei primi protocolli utilizzati nel World Wide Web (WWW) per creare pagine web dinamiche ed è stato la base per la sua crescita
esplosiva dal 1995 al 2000 (si pensi per esempio ai siti Amazon ed eBay).
Il grande vantaggio del CGI è la sua semplicità: non richiede sovrastrutture software ed è quindi uno dei metodi più agili e con le prestazioni
migliori.
Il CGI non è un linguaggio di programmazione. Il CGI definisce unicamente il modo in cui la richiesta deve essere trasferita al web-server per
essere passata ad un programma ed il modo in cui la risposta del programma (praticamente un buffer) deve essere restituita al web-client. Su
AS/400 il programma CGI può essere scritto in REXX, C++, C-ILE, RPG-ILE, o COBOL-ILE. Il programma riceve dal browser del client, tramite una
URL, una richiesta specificata dal valore di opportuni parametri e quindi prepara una pagina di risposta in funzione della richiesta fatta (pagina
dinamica) che viene rispedita al browser del client. Il browser, tramite opportune testate inserite all’inizio della pagina, capisce come deve
interpretare la presentazione della stessa.
In genere la pagina di risposta è una pagina scritta in HTML (HyperText Markup Language), ma potrebbe anche essere in XML o essere addirittura
un file, per esempio un PDF.
Come fa un programma CGI a ricevere l’input dal web-client?
Esistono due modi in cui il client può trasmettere una richiesta CGI al web-server: il metodo GET ed il metodo POST.
Quando viene usato il metodo GET, la stringa di input deve essere reperita con l’API QtmhGetEnv (Get Environment Variable) specificando la
variabile d’ambiente QUERY_STRING.
Quando viene usato il metodo POST la stringa di input deve essere reperita con l’API QtmhRdStIn (Read Standard Input).
Successivamente, il programma deve recuperare dalla stringa di input i valori delle singole variabili di input. Questa operazione si chiama parsing e
può essere fatta utilizzando l’API QzhbCGIParse.
Già da qui si capisce che leggere l’input dal browser non è una operazione semplice per un programma CGI.
Questo non è nulla rispetto alla creazione della risposta (in genere una pagina HTML, ma potrebbe essere anche qualcosa di diverso).
La risposta non è altro che un buffer (una stringa) che va inviata al browser tramite l’API QtmhWrStOut (write to Stdout).
Il fatto è che, per esempio nel caso di una pagina HTML, il programma CGI dovrebbe scrivere nel buffer via via l’HTML necessario, intercalandolo
con i valori delle variabili di output. In altre parole sarebbe come se un programma interattivo, anziché utilizzare le DDS, scrivesse direttamente i
dati (testate e valori dei campi) nel buffer da inviare al terminale 5250.
Completamente impensabile. Ed è questo il motivo per cui ben pochi sono riusciti, e con gran fatica, a scrivere programmi CGI sull’AS/400 prima
della comparsa sulle scene di CGIDEV2.
3- Il paradigma CGI
Il programma CGI non ha memoria (ambiente “stateless”) - I serventi World-Wide-Web trattano ogni richiesta come una transazione
indipendente da ogni precedente richiesta. Questo semplifica la struttura del servente, in quanto non deve allocare memoria per tener conto delle
conversazioni in corso, né deve impegnarsi a liberarla se un client a metà conversazione decide di desistere. In altre parole, non esiste la EXFMT
(invia ed attendi la risposta). Nel mondo CGI il programma risponde ad una singola richiesta, dopo di che il programma non ricorda più nulla né
della richiesta né della risposta data. Questo comporta che, per mantenere il dialogo, una successiva richiesta può dover inviare al programma,
non solo i dati della nuova richiesta, ma anche alcuni dati relativi alla richiesta precedente.
Questo problema viene comunemente risolto spedendo, nella risposta al browser, delle variabili di input nascoste (hidden) contenenti i valori di cui
il programma CGI necessita per riprendere la elaborazione di una successiva richiesta.
A dire il vero, il supporto CGI su AS/400 consente di realizzare anche programmi CGI persistenti.
Un programma CGI persistente viene mantenuto attivo (con tutte le sue variabili impostate ed il posizionamento sui file intatto) in attesa di una
successiva richiesta da parte dello stesso client che lo aveva chiamato. In pratica il job della istanza http resta fermo in attesa di una successiva
chiamata. Ma ci sarà una successiva chiamata, e se sì, dopo quanto tempo?
Dato che ciò non è prevedibile, va posto un ragionevole limite al numero di job in attesa e va inoltre specificato un tempo di timeout, superato il
quale il job deve chiudere.
Tali limiti, unitamente alla complicazione della sovrastruttura necessaria per realizzare lo stato di persistenza, rendono poco attraente questo
metodo, del quale un programmatore CGI, abituato a gestire la non-persistenza, non sente affatto bisogno.
4- Che cosa è CGIDEV2
CGIDEV2 è una raccolta di procedure ILE che semplificano all’estremo la scrittura di programmi CGI in COBOL-ILE o in RPG-ILE.
Una prima stesura, denominata CGIDEV, venne creata da Mel Rothman, dell’IBM di Rochester (MN), nel 1996.
Nel 1999 Rothman rilasciò una nuova versione denominata CGIDEV2, potenziata in termini di semplicità e potenza di prestazioni. Rothman
continuò ad aggiungere nuove funzioni a CGIDEV2, sino al 2004, quando lasciò IBM.
CGIDEV2 si presenta come uno strumentario completo per il programmatore RPG che voglia fare del WEB. CGIDEV2 è compatibile con
qualunque nuovo rilascio di OS/400. L’unico requisito è almeno una modesta conoscenza dell’ RPG ILE da parte dello sviluppatore. Si impara in
fretta, due/tre giorni di applicazione sono sufficienti per realizzare i primi programmi e la velocità di sviluppo cresce molto velocemente.
Ovviamente, per poter presentare delle pagine WEB occorre conoscere l’HTML, ma questa non è una impresa, l’HTML è immensamente più
semplice delle DDS.
Nella evoluzione delle conoscenze verranno poi il Cascading Style Sheet (CSS), il Javascript, l’HTML DOM ed AJAX. Tutto questo si impara
facilmente dai tutorial http://www.w3schools.com/ .
I programmi CGI scritti in RPG_ILE non sono più difficili dei normali programmi 5250, hanno prestazioni eccellenti e si manutenzionano con la
stessa facilità dei programmi tradizionali.
La diffusione di CGIDEV2 su scala mondiale è dovuta all’opera di Giovanni Battista Perotti.
Perotti scoprì CGIDEV nel 1997, quando era in IBM Italia. Il suo primo sito internazionale inteso a diffondere CGIDEV fu messo in onda nel Luglio
del 1997. Nel Novembre del 1999 AS/400 News U.S. diffuse per via elettronica un articolo dove si annunciava che tramite CGIDEV si potevano
creare in RPG splendidi siti WEB. In un sol giorno CGIDEV fu installato da oltre 300 sviluppatori di AS/400. Nel Marzo del 2000 Perotti ottenne il
consenso dall’IBM di Rochester di poter distribuire CGIDEV2 gratuitamente e completo di sorgenti.
Quando, nel Giugno del 2005, Perotti uscì, per anzianità, da IBM chiese ad IBM di ereditare la proprietà di CGIDEV2 per poterne curare la ulteriore
crescita e diffusione. Quando IBM rifiutò, Perotti fece pervenire ai responsabili IBM di Rochester centinaia di lettere di protesta da clienti ed IBM fu
costretta a dichiarare che avrebbe preso in carico ufficialmente il prodotto, per curarne la manutenzione, la evoluzione ed un eventuale annuncio
open-source.
In realtà IBM ha fatto ben poco o nulla di quanto promesso. Ad oggi le installazioni di CGIDEV2 sono oltre 4700 e continuano a crescere
unicamente grazie all’opera di Perotti, che ne diffonde la conoscenza tramite il suo sito http://www.easy400.net , il suo forum internazionale
http://tech.groups.yahoo.com/group/Easy400Group/ ed il suo forum italiano di nuovo conio http://groups.google.com/group/cgidev2-italia .
5- I paradigmi CGIDEV2
In particolare CGIDEV2, mentre non risolve il problema (stateless) della perdita di memoria del programma CGI, peraltro facilmente superabile,
risolve invece brillantemente i problemi della lettura dell’input e della scrittura dell’output.
Mentre la lettura dell’input avviene tramite alcune semplici procedure ILE che saranno illustrate più avanti, la creazione dell’output merita qualche
spiegazione introduttiva.
Come si sa, la separazione tra presentazione dei dati e valori dei dati è fondamentale per la produttività di un programma.
In un programma interattivo o batch, ciò avviene tramite un file unità esterno (file display o file di stampa) il quale definisce come i dati debbano
essere presentati per il tramite di costanti (titoli, testate, messaggi) e di variabili di input o di output. Il tutto organizzato in uno o più tracciati record.
Le DDS servono a questo scopo. Il programma si occupa unicamente del processo logico dei dati, di assegnare valori alle variabili di input o di
output e di emettere nell’ordine opportuno i tracciati record del file display o stampa, in modo da produrre la risposta appropriata per il caso in
esecuzione.
Con CGIDEV2, per emettere una pagina HTML si fa esattamente la stessa cosa.
Si produce un file HTML costituito da tracciati record che qui si chiamano “sezioni” (section). Una sezione può contenere testo HTML e variabili di
input o di output da valorizzare. Il programma CGI in partenza carica in memoria, tramite procedure di CGIDEV2, il file HTML esterno. Via via che
l’elaborazione procede, il programma CGI assegna valori alle variabili di input e di output ed emette ordinatamente le “sezioni” necessarie per
comporre la risposta. Alla fine comanda la spedizione del buffer di output e va a fine programma.
Il grande vantaggio delle applicazioni WEB, rispetto alle applicazioni tradizionali 5250, sta nella estrema flessibilità dell’HTML rispetto alle DDS.
In termini di presentazione, efficacia, completezza, eleganza, dotazione di accessori, non esiste ovviamente confronto. Si pensi unicamente ai
cambiamenti che si possono produrre con semplici variazioni del CSS. Non va poi tralasciato il fatto che non esiste controllo di livello tra
programma e file HTML esterno. L’unico controllo di livello lo fa CGIDEV2 che, quando il CGI gli chiede di caricare in memoria un file HTML
esterno, evita di farlo se il file è già in memoria e non è stato variato.
6- Installare CGIDEV2
Dopo aver compreso un poco che cosa sia CGIDEV2 e come si collochi nel protocollo CGI dell’HTTP, veniamo alla sua installazione.
CGIDEV2 si scarica dal sito http://www.easy400.net .
La pagina presenta una colonna di navigazione sul lato sinistro.
Si tratta di premere il link denominato “Download”.
La prima volta che lo si preme viene richiesto di registrarsi.
Una volta effettuata la registrazione si accede alla pagina di scarico.
Nella tabella dei software, si prema CGIDEV2 per raggiungere le istruzioni relative.
Si scelga una delle tre versioni disponibili (V5R2, V5R1, V4R5) per far comparire la finestrella di download, quindi si prema il bottone Submit.
Si riceva il file cgidev2.zip in una cartella del PC, quindi lo si espanda ad ottenere due file : un readme.txt ed un cgidev2.sav . Quest’ultimo è un file
di salvataggio che contiene la libreria CGIDEV2.
Occorre ora trasportare il file di salvataggio sul System i. Si proceda così:
a. Sul System i si esegua il comando
CRTSAVF SAVF(QGPL/CGIDEV2)
b.
Sul PC si apra una finestra DOS per trasferire il file di salvataggio sul System i. Ci si posizioni sulla cartella contenente il file di
salvataggio cgidev2.sav, quindi si immettano i comandi seguenti:
ftp indirizzo_IP_del_System_i
utente
password
binary
quote site namefmt 1
cd /qsys.lib/qgpl.lib
put cgidev2.sav cgidev2.savf
quit
c.
d.
Sul System i si immetta il comando
RSTLIB SAVLIB(CGIDEV2) DEV(*SAVF) SAVF(QGPL/CGIDEV2)
per ripristinare la libreria CGIDEV2.
CGIDEV2 viene consegnato con i soli sorgenti dei programmi. Per completare la installazione è necessario eseguire una procedura
REXX che ricrea i programmi. Si immetta il comando
SBMJOB JOB(CGIDEV2) CMD(STRREXPRC SRCMBR(INSTALL1) SRCFILE(CGIDEV2/QREXSRC))
e.
f.
Una volta completato questo lavoro, per ripristinare le cartelle IFS /cgidev e /cgidevexthtml, si immetta il comando
STRREXPRC SRCMBR(INSTALL2) SRCFILE(CGIDEV2/QREXSRC)
Alla fine, per creare la istanza HTTP CGIDEV2APA che consente di leggere localmente la documentazione di CGIDEV2 e di eseguirne
alcune dimostrazioni, si esegua il comando
CPYF FROMFILE(CGIDEV2/QATMHINSTC) TOFILE(QUSRSYS/QATMHINSTC)
FROMMBR(CGIDEV2APA) TOMBR(CGIDEV2APA) MBROPT(*REPLACE) CRTFILE(*YES)
g.
.
La istanza HTTP CGIDEV2APA si avvia con il comando
STRTCPSVR SERVER(*http) HTTPSVR(CGIDEV2APA)
Successivamente si immetta il comando
WRKACTJOB SBS(QHTTPSVR) JOB(CGIDEV2APA)
per constatare che la istanza sia effettivamente partita. Se la partenza ha avuto successo, si vedranno attivi vari job di nome
CGIDEV2APA. La istanza lavora sulla porta 8014, quindi per accedere alla prima pagina di CGIDEV2 si utilizzi la URL
http://indirizzo_IP_as400:8014/cgidev2/start
7- La documentazione dettagliata di CGIDEV2
La documentazione dettagliata di CGIDEV2 è disponibile sul sito Easy400 a partire dalla pagina http://www.easy400.net/cgidev2/start . La lingua
ufficiale l’inglese, ma la maggior parte delle pagine ha anche una versione in italiano (premere sulla bandierina). Lo stesso materiale è disponibile
localmente attraverso la istanza http CGIDEV2APA.
Main functions
• Read input from client browser
• Map input string into program variables
• Multiple occurrencies of an input variable
• Use an externally defined HTML script to write HTML output
Other functions
• Handling cookies
• Message handling
• Maintain and retrieve page counts
• Retrieve environment variables
• Other environment variables functions
• Timing functions
• Check IFS object
• Uploading PC files
• CGI DEBUG file
• Debugging functions
o
o
In alto, nella prima pagina, basta premere il bottone
cgi tutorial per arrivare alla pagina
http://www.easy400.net/cgidev2o/tutorial.htm . A
circa metà di questa pagina compare un riquadro
contenente l’indice del tutorial (vedi la figura a lato).
Esiste anche un indice analitico. Premendo il
bottone index si arriva alla pagina dell’indice
analitico
http://www.easy400.net/cgidev2o/index.htm .
Sono inoltre disponibili delle dimostrazioni, con
evidenziazione del codice HTML ed RPG, dalle quali è facile
imparare alcune delle tecniche basilari. Si prema il bottone
basic demos per giungere alla pagina
http://www.easy400.net/cgidev2o/demos.htm .
Coding facilities
• Data conversion functions
• Execute a command
• Override a database file
Dynastatic pages
• Write HTML to a stream file
Program state support
• Using user spaces
• Create a random string
Persistent CGI support
• Get a random integer
• Assign a Session ID (“handle”)
8- Come si fa il debugging dei programmi CGI
Tutti i lavori nel sottositema QHTTPSVR sono lavori batch. Come tutti i lavori batch, se incontrano un errore si fermano e mandano un messaggio
alla coda messaggi dell’operatore. Questo per una lavoro WEB non va bene. E’ inutile far aspettare l’utente finale per ore o giorni. Occorre che gli
arrivi un messaggio di errore, che l’errore venga registrato nel log del lavoro e che il lavoro termini (il sistema ne avvierà subito un altro). Per
ottenere questo bisogna immettere il comando
chgjobd qhttpsvr/qzhbhttp log(4 00 *seclvl) inqmsgrpy(*dft) .
Per visualizzare i lavori di una istanza http (per esempio quelli della istanza CGIDEV2APA) si utilizza il comando
WRKACTJOB SBS(QHTTPSVR) JOB(cgidev2apa)
Gestione lavori attivi
CPU %:
Opz
__
__
__
__
__
__
__
__
11.9
Sottosis/Lav
CGIDEV2APA
CGIDEV2APA
CGIDEV2APA
CGIDEV2APA
CGIDEV2APA
CGIDEV2APA
CGIDEV2APA
CGIDEV2APA
30/04/10 16:07:54
Tempo trascorso:
00:00:23
Lavori attivi:
401
Utente
corrente
Tipo CPU % Funzione
Stato
QTMHHTTP
BCH
.0 PGM-QZHBMAIN
SIGW
QTMHHTTP
BCI
.0 PGM-QZSRLOG
SIGW
QTMHHTTP
BCI
.0 PGM-QZSRHTTP
SIGW
QTMHHTP1
BCI
.3 PGM-QZSRCGI
TIMW Í
QTMHHTP1
BCI
.0 PGM-QZSRCGI
TIMW
QTMHHTTP
BCI
.0 PGM-QZSRHTTP
DEQW
QTMHHTP1
BCI
.0 PGM-QZSRCGI
TIMW
QTMHHTP1
BCI
.0 PGM-QZSRCGI
TIMW
I lavori dell’istanza che eseguono I programmi CGI sono quelli contrasegnati dal PGM-QZSRCGI. Dato che ne esiste più di uno, non è dato sapere
a priori quale di essi eseguirà la prossima richiesta da un web-client. In genere la richiesta in arrivo viene sempre assegnata allo stesso lavoro.
Solo se quel lavoro è impegnato la richiesta viene passata ad un altro lavoro.
Per sapere quale lavoro prenderà controllo, è sufficiente riazzerare il conteggio CPU% (F10), far immettere una richiesta dal web-client, tornare alla
schermata wrkactjob e fare F5. Il lavoro PGM-QZSRCGI che ha preso controllo avrà speso del tempo di CPU. Se il sistema è molto veloce, non
sempre è possibile rilevare quale lavoro abbia speso tempo CPU; in questo caso occorre congelare i lavori PGM-QZSRCGI, immettere la richiesta
dal web-client, quindi scongelare i lavori uno alla volta, controllando ogni volta se il browser ha ricevuto la risposta.
Una volta che si è individuato il lavoro PGM-QZSRCGI addetto a rispondere per primo, se ne visualizzano i dati con la opzione 5:
Gestione lavoro
Lavoro:
CGIDEV2APA
Utente:
QTMHHTP1
Numero:
Sistema:
033875
xxxxxxxx
Selezionare una delle seguenti:
1.
2.
3.
4.
Visualizzazione attributi di stato del lavoro
Visualizzazione attributi di definizione del lavoro
Visualizzazione attributi di esecuzione del lavoro, se attivo
Gestione dei file di spool
10.
11.
12.
13.
14.
15.
16.
Visualizz. registrazione lavoro, se attivo, in coda lavori o sospeso
Visualizzazione dell'elenco richiami, se attivo
Gestione dei vincoli, se attivi
Visualizzazione della lista delle librerie, se attivo
Visualizzazione file aperti, se attivi
Visualizzazione sostituzioni di file, se attive
Visualizzazione stato controllo convalida, se attivo
Segue...
Scelta o comando
===> __________________________________________________________________________
______________________________________________________________________________
F3=Fine
F4=Richiesta
F9=Duplicaz.
F12=Ann.
Supponiamo che il programma CGI da sottoporre a debug sia il programma PGM1 nella libreria CGI1.
Ovviamente bisognerà che i moduli di tale programma siano stati creati con il parametro DBGVIEW(*SRC) o DBGVIEW(*LIST) .
Per mettere in debug il programma bisognerà immettere i comandi seguenti:
• STRSRVJOB 033875/QTMHHTP1/CGIDEV2APA
• STRDBG CGI1/PGM1 UPDPROD(*YES)
Dopo di che si provvederà ad assegnare almeno un breakpoint e si farà partire la richiesta dal web-browser per il programma CGI1.
Una volta trovato l’errore, si tratterà di correggere e ricreare il programma, quindi eventualmente eseguire un nuovo debug, immettendo i comandi
• ENDDBG
• STRDBG CGI1/PGM1 UPDPROD(*YES)
Se il problema da correggere non è semplice, si reitera in continuazione tra comandi enddbg e strdbg e, se necessario, endsrvjob e strsrvjob.
Questa iterazione comporta tempo ed attenzione ed è alquanto defatigante. Per questo motivo in CGIDEV2 è stato creato un comando (che alla
installazione viene duplicato nella libreria QGPL), EDBG (Enhanced DEBUG) il quale provvede da solo a lanciare i comandi di end/strsrvjob e di
end/strdbg. Il comando richiede che siano specificati solo due parametri: il nome (qualificato) del programma ed il numero del lavoro batch da
servire. Nel caso illustrato basterà quindi ripetere ogni volta il comando
EDBG CGI1/PGM1 033875
9- Creare una prima libreria per i programmi CGI
Non ostante che ciò possa apparir comodo, non è conveniente creare propri programmi nella libreria CGIDEV2. E’ meglio abituarsi ad utilizzare
proprie librerie. In questo esempio vogliamo creare la libreria CGI1 e fare in modo da averla pronta per i nostri prossimi programmi CGI.
a.
b.
Creiamo la libreria: CRTLIB LIB(CGI1) TEXT('Miei primi programmi CGI') AUT(*USE)
Ora popoliamo la libreria CGI1 con alcuni strumenti di CGIDEV2 che ci serviranno:
CGIDEV2/SETCGILIB SRCLIB(CGI1)
Questo comando (vedi http://www.easy400.net/cgidev2o/cgisetup.mbr#setcgilib )
•
•
Duplica nella libreria il service program CGISRVPGM2 di CGIDEV2
•
Crea nella libreria i file origine QRPGLESRC, QCLSRC, QDDSSRC, QCMDSRC, QPNLSRC, HTMLSRC (quest’ultimo file origine
può essere utilizzato per membri contenenti HTML, anche se è largamente preferibile utilizzare per questo scopo file di flusso nella
cartella /cgi1/html )
•
Crea nella libreria la *BNDDIR TEMPLATE2, che serve per risolvere le chiamate delle procedure CGIDEV2 verso il service program
CGISRVPGM2 nella stessa libreria
Nel file QRPGLESRC aggiunge i membri HSPECS, HSPECSBND, PROTOTYPEB, VARIABLES3, PROLOG3 che saranno utilizzati
via /COPY nei programmi CGI
•
•
Crea una cartella IFS con lo stesso nome della libreria e vi aggiunge tre sottocartelle:
o Una sottocartella /nome_libreria/css dove si possono mettere i file .css che saranno utilizzati dalla applicazione
o Una sottocartella /nome_libreria/html dove si possono mettere i file .html (pagine statiche o html esterni per i
CGI) che saranno utilizzati dalla applicazione
o Una sottocartella /nome_libreria/graphics dove si possono mettere gli oggetti grafici (icone, immagini, ecc.)
utilizzati dalla applicazione.
Alla fine invia questa schermata
Add HTTP Directives
for CGI object library CGI1
Type of directives . . . .
_
1=Original, 2=Apache
F3=End
Si immetta 2 e si prema Invio per avere un elenco delle istanze HTTP disponibili:
Add HTTP Directives
for CGI object library CGI1
Type option, press Enter
1=HTTP instance to be updated
instance
………
configuration file
_ APACHEDFT /www/apachedft/conf/httpd.
_ CGIDEV2APA /cgidev/conf/httpd.conf
………
Si immetta 1 per CGIDEV2APA e si dia Invio. In questo modo alle direttive di CGIDEV2APA vengono aggiunte alcune direttive che
consentono la esecuzione di programmi CGI nella libreria CGI1. Le nuove direttive vengono automaticamente visualizzate da un
comando dspf ‘/cgidev/conf/httpd.conf’ . Andando alla fine del file di direttive, si vede che le direttive aggiunte sono:
#---CGI1 directives
AliasMatch /cgi1h/(.*)\.htm /QSYS.LIB/CGI1.LIB/HTMLSRC.FILE/$1.mbr
Alias /cgi1h/
/QSYS.LIB/CGI1.LIB/HTMLSRC.FILE/
Alias /cgi1/
/cgi1/
ScriptAliasMatch /cgi1p/(.*).pgm /qsys.lib/cgi1.lib/$1.pgm
<Directory /QSYS.LIB/CGI1.LIB>
AllowOverride None
Options None
order allow,deny
allow from all
</Directory>
<Directory /cgi1>
AllowOverride None
Options None
order allow,deny
allow from all
</Directory>
• La prima di queste righe è un commento
• La seconda riga (AliasMatch /cgi1h/(.*)\.htm …) intende significare che quando in una URL si incontra la
dizione /cgi1h/ seguita da qualcosa e poi da .htm, si intende che quel qualcosa sia un membro del file CGI1/HTMLSRC
• La terza riga (Alias /cgi1h/ …) intende significare che quando in una URL si incontra la dizione /cgi1h/ ci si intende
riferire al file /CGI1/HTMLSRC
• La quarta riga (Alias /cgi1/ …) intende significare che quando in una URL si incontra la dizione /cgi1/ si intende riferirsi
proprio alla cartella IFS /cgi1/
• La quinta riga (ScriptAliasMatch /cgi1p/(.*).pgm …) intende significare che quando in una URL si incontra la
dizione /cgi1p seguita da qualcosa e quindi dalla dizione .pgm, si tratta di un programma CGI nella libreria CGI1.
Pertanto, per eseguire il programma PGM1 nella libreria CGI1 basterà utilizzare la URL
http://indirizzo_IP_as400/cgi1p/pgm1.pgm
• Il gruppo di direttive che va da <Directory /QSYS.LIB/CGI1.LIB> a </Directory> significa che la libreria
CGI1 è accessibile a qualunque richiesta http
• Il gruppo di direttive che va da <Directory /cgi1> a </Directory> significa che la cartella CGI1 è accessibile a
qualunque richiesta http
c.
Per far ripartire la istanza http CGIDEV2APA in modo tale che tenga conto delle nuove direttive, occorre immettere il comando
STRTCPSVR SERVER(*HTTP) RESTART(*HTTP) HTTPSVR(CGIDEV2APA)
Nei prossimi articoli incominceremo a scrivere con CGIDEV2 alcuni programmi CGI.
Se sei interessato, devi però prepararti, imparando un poco di HTML e di CSS.
Su questi argomenti esistono fior di siti. Io raccomando (ma sono in lingua inglese) quelli di W3Sschools
• http://www.w3schools.com/ per l’elenco dei corsi
• http://www.w3schools.com/html/default.asp per il corso di HTML
• http://www.w3schools.com/css/default.asp per il corso di CSS
Si tratta di corsi molto semplici ed anche divertenti, ti fanno respirare ed aprire gli occhi su un altro mondo.
Non perdere l’occasione di imparare!
Se hai domande, puoi contattarmi liberamente, scrivendo al mio indirizzo e-mail esposto nella prima pagina del sito
www.easy400.net