Spesso non si è neanche a conoscenza dell’ esistenza delle Api su System I e altrettanto spesso sembra troppo difficile utilizzarle.
Il primo approccio può sembrare ostico , ma superato il primo scoglio il loro utilizzo diventa facile. Andando sull’ Information Center dell’ Ibm sotto la voce Programming si trovano tutte le api divise per categoria.
Per ogni api si trova una descrizione , i parametri di input e come viene ritornato l’output (in alcuni casi l’Api richiede uno user space). Il problema principale nel caso si usi Rpg come linguaggio è trovare il giusto tipo di dati , infatti un campo 4b dell’api non significa un campo 4b 0 in Rpg, ma un campo numerico lungo 4 byte , convertibile in Rpg come 10 i 0 ossia un campo intero di 10 cifre.
In questo redbook ci sono esempi di accesso alle api e se scaricate le varie utility e service program da tools400.de (ne ho parlato qui) troverete ottimi esempi e anche aiuti per l’utilizzo delle api.
Perche sbattersi tanto?
Facciamo un paio di esempi pratici.
Primo esempio : accesso alle informazioni dei lavori
Qualche tempo fa mi fu chiesto di creare una procedura che monitorasse i lavori batch in stato Msgw e Lckw e mandasse una mail con i dati del lavoro.
La mia prima proposta era di assumere una stagista giovane che monitorasse i lavori, stranamente la soluzione fu immediatamente cestinata.
Come “analisi” mi fu detto : fai una stampa dei lavori attivi, la metti su un file te lo leggi e poi nel caso mandi la mail.
La cosa mi provocò un brivido lungo tutta la spina dorsale. Sapevo che c’era una soluzione migliore e più elegante e l’ho trovata nell’api QUSLJOB . L’utilizzo dell’api prevede l’output su di uno userpace , per fortuna il srvpgm Qbasics1 (sempre tools400.de) contiene dei wrapper per le api dello user space.
Il flusso logico diventava quindi:
- Creazione dello user space
- Chiamata dell’Api QUSLJOB
- Lettura dello user space per i lavori
- Invio della mail in caso di lavori nello stato LCKW o MSGW
- Goto 1
I vantaggi rispetto al metodo del file di spool , ed in genere per l’utilizzo delle Api:
- Maggiore velocità
- Maggiore flessibilità
- Stabilità dei parametri rispetto all’ouput del comando
Sull’ ultimo punto è importante riflettere , facilmente l’output del comando WRKACTJOB può cambiare , mentre per le Api c’è una maggiore attenzione alla retro compatibilità ed eventuali parametri aggiuntivi saranno aggiunti alla fine oppure in altri formati. Sicuramente QUSLJOB non è l’api giusta per cominciare.
Il tempo che ho risparmiato nello scrivere il programma attraverso questo metodo l’ho utilizzato per migliorarlo , ad esempio per evitare di mandare un alert più volte per lo stesso lavoro.
Secondo esempio : reperire lo stato del controllo di sincronia.
Mi sono trovato ad inserire in un trigger la chiamata ad una procedura esterna che doveva aggiornare un file. Il problema principale era quello dello stato del commit , la procedura esterna doveva essere coerente nell’ambito in cui veniva chiamata , ossia se il controllo di sincronia era attivo doveva effettuare gli aggiornamenti sotto commit altrimenti doveva farli senza.
Il trigger tra i parametri in ingresso ha già l’informazione dello stato del controllo di sincronia , ma non volevo dipendere da un parametro passato.
Mi fu detto che reperire queste informazione era impossibile , ma invece ecco venire in aiuto QTNRCMTI.
Quest’api torna le informazioni sullo stato del controllo di sincronia ossia se è a livello di activation group oppure di lavoro , il lock del commit (*Chg *All ecc.) e altre informazioni.
Con poche specifiche ho risolto il problema elegantemente rendendo la procedura indipendente dal controllo di sincronia.
Semplifichiamo la vita ai programmatori : il wrapping
Quando si prende dimestichezza con le Api , il loro uso sarà sempre più frequente, le difficoltà iniziali sono state superate , ma nel caso delle Api è meglio semplificare la vita a chi dovrà utilizzarle.
Per esempio nel caso del reperimento del controllo di sincronia , l’informazione che interessa maggiormente è se questo è attivo oppure no , allora perchè non creare una semplice procedura esterna che torni un valore booleano come true o false ? Sicuramente il proliferare di chiamate a QTNRCMTI nei programmi non ha molto senso e rende i sorgenti più complessi , molto meglio una chiamata ad una procedura wrapper tipo IsCommitActive() , le cose semplici sono quelle più utilizzate.
Se per esempio ci fosse bisogno di utilizzare QUSLJOB in molti programmi sarebbe meglio creare una procedura che crei la lista sullo user space in base ai parametri passati ed una che iteri attraverso lo user space ad esempio così:
JobListInit(par1:par2:…);
dow JobListGetNext(out:..);
…
enddo;
Molto semplice ed eviterà che sviluppatori troppi pigri utilizzino l’obbrobriosa tecnica dell’output su spool , il suo trasferimento su file ecc… ecc…
Note:
Mi scuso in anticipo nel caso di errori o mancanze , non ho un System I a casa. Nel caso foste abbonati a System I News , potete trovare ottimi articoli sulle api.
Sottofondo musicale : ZZ Top – Fandango!
