Il leggendario CGIDEV2 di Giovanni Battista Perotti

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: 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. esempio: 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: -apache -d /www/apachedft -f conf/httpd.conf AutoStartY dal quale si desume che 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. Sul System i si immetta il comando RSTLIB SAVLIB(CGIDEV2) DEV(*SAVF) SAVF(QGPL/CGIDEV2) per ripristinare la libreria CGIDEV2. d. 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. Una volta completato questo lavoro, per ripristinare le cartelle IFS /cgidev e /cgidevexthtml, si immetta il comando STRREXPRC SRCMBR(INSTALL2) SRCFILE(CGIDEV2/QREXSRC) f. 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 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). o 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 30/04/10 16:07:54 CPU %: 11.9 Tempo trascorso: 00:00:23 Lavori attivi: 401 Utente Opz Sottosis/Lav corrente Tipo CPU % Funzione Stato CGIDEV2APA QTMHHTTP BCH.0 PGM-QZHBMAIN SIGW CGIDEV2APA QTMHHTTP BCI.0 PGM-QZSRLOG SIGW CGIDEV2APA QTMHHTTP BCI.0 PGM-QZSRHTTP SIGW CGIDEV2APA QTMHHTP1 BCI.3 PGM-QZSRCGI TIMW CGIDEV2APA QTMHHTP1 BCI.0 PGM-QZSRCGI TIMW CGIDEV2APA QTMHHTTP BCI.0 PGM-QZSRHTTP DEQW CGIDEV2APA QTMHHTP1 BCI.0 PGM-QZSRCGI TIMW CGIDEV2APA 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 Sistema: xxxxxxxx Lavoro: CGIDEV2APA Utente: QTMHHTP1 Numero: 033875 Selezionare una delle seguenti: 1. Visualizzazione attributi di stato del lavoro 2. Visualizzazione attributi di definizione del lavoro 3. Visualizzazione attributi di esecuzione del lavoro, se attivo 4. Gestione dei file di spool 10. Visualizz. registrazione lavoro, se attivo, in coda lavori o sospeso 11. Visualizzazione dell'elenco richiami, se attivo 12. Gestione dei vincoli, se attivi 13. Visualizzazione della lista delle librerie, se attivo 14. Visualizzazione file aperti, se attivi 15. Visualizzazione sostituzioni di file, se attive 16. 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. Creiamo la libreria: CRTLIB LIB(CGI1) TEXT('Miei primi programmi CGI') AUT(*USE) b. 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 la *BNDDIR TEMPLATE2, che serve per risolvere le chiamate delle procedure CGIDEV2 verso il service program CGISRVPGM2 nella stessa libreria 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 ) 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