Gestire i job in batch senza impazzire

"Il batch è partito ma non fa niente." Nove volte su dieci il job non è partito affatto: è accodato e aspetta. Capire cosa lo trattiene richiede di guardare tre cose in fila — la coda, il sottosistema che la serve, e quanti job quel sottosistema accetta insieme.

Dove si è fermato

Il primo comando è sempre lo stesso:

WRKSBMJOB

Mostra i job che hai sottomesso tu, con lo stato accanto. I due stati che contano:

• JOBQ — il job è in coda e non è ancora partito.
• ACTIVE — sta girando; se sembra non fare nulla, il problema è dentro il programma.

Se lo stato è JOBQ, si guarda la coda:

WRKJOBQ JOBQ(QGPL/QBATCH)

La colonna con il numero di job e, soprattutto, lo stato della coda: RLS (rilasciata) oppure HLD (trattenuta). Una coda trattenuta è la causa più banale e più frequente: qualcuno l'ha messa in hold e non l'ha rilasciata.

Il sottosistema che serve la coda

Una coda da sola non esegue niente: serve un sottosistema attivo che la prenda in carico. Si controlla con:

WRKSBS

Se QBATCH non compare nell'elenco, i job in quella coda resteranno lì per sempre, anche se la coda è rilasciata. Si avvia con STRSBS SBSD(QSYS/QBATCH).

Quando invece il sottosistema c'è, ma i job escono uno alla volta mentre ne servirebbero tre in parallelo, il limite è MAXACT nella voce della coda:

DSPSBSD SBSD(QSYS/QBATCH)

Opzione 6, Job queue entries: la colonna Max Active dice quanti job di quella coda possono girare contemporaneamente. 1 è il valore predefinito di molte installazioni, ed è spesso una scelta voluta — i batch che scrivono sugli stessi file, messi in parallelo, si bloccano a vicenda. Prima di alzarlo conviene sapere perché era a 1.

Sottomettere in modo che si capisca

Un SBMJOB scritto bene si ritrova; uno scritto in fretta no. Vale la pena dare sempre un nome parlante:

SBMJOB CMD(CALL PGM(MIALIB/CHIUSURA) PARM('202607'))
       JOB(CHIUS202607)
       JOBQ(QGPL/QBATCH)
       JOBD(MIALIB/JOBDBATCH)
       LOG(4 00 *SECLVL)

LOG(4 00 *SECLVL) merita una parola: chiede al sistema di registrare tutto, messaggi di secondo livello compresi. Il job log diventa più pesante, ma quando il batch fallisce alle tre di notte è l'unica cosa che permette di capire cosa è successo senza doverlo rilanciare.

Il JOBD decide molte cose che poi non si possono cambiare a job avviato: lista librerie, coda di destinazione, coda di stampa. Un errore frequente è sottomettere un batch che in interattivo funziona e in batch no: quasi sempre è la lista librerie della JOBD, che è diversa da quella della sessione.

Programmare un'esecuzione

Per far partire un batch a un orario preciso non serve uno scheduler esterno:

SBMJOB CMD(CALL PGM(MIALIB/NOTTURNO))
       JOB(NOTTURNO)
       SCDDATE(*CURRENT)
       SCDTIME('22:30:00')

Il job resta in coda con stato SCD finché non arriva l'ora. Per esecuzioni ricorrenti c'è invece lo scheduler integrato, WRKJOBSCDE, che gestisce le ripetizioni e tiene traccia dell'ultima esecuzione riuscita.

Quando un batch va fermato

ENDJOB ha due modalità e la differenza è sostanziale:

ENDJOB JOB(123456/UTENTE/CHIUSURA) OPTION(*CNTRLD) DELAY(60)

*CNTRLD avvisa il programma e gli concede i secondi indicati per chiudere ordinatamente: un RPG scritto bene se ne accorge e chiude i file. *IMMED tronca tutto sul posto. Con *IMMED su un programma che stava scrivendo, si può restare con aggiornamenti a metà — e se il file non è sotto giornale, non c'è modo di sapere fin dove era arrivato.

Vale la pena aggiungere SPLFILE(*YES): conserva gli spool già prodotti dal job, che spesso sono l'unica traccia di cosa aveva fatto prima di essere fermato.

Tre abitudini che risparmiano tempo

• Un nome per ogni batch, coerente e riconoscibile. Cercare fra venti job chiamati QDFTJOBD non è un lavoro.
• Code separate per lavori diversi. Mettere i report lunghi in una coda propria evita che blocchino le chiusure.
• Controllare WRKJOBQ prima di rilanciare. Un batch lanciato due volte perché "non partiva" è un problema molto più serio di un batch fermo.

Su quali versioni funziona

Tutti i comandi usati in questo articolo — SBMJOB, WRKSBMJOB, WRKJOBQ, WRKSBS, ENDJOB, DSPSBSD, ADDJOBSCDE, WRKJOBSCDE — sono comandi CL storici, presenti da molte release e non legati a un Technology Refresh. Su una macchina in 7.3, 7.4, 7.5 o 7.6 funzionano tutti allo stesso modo.

Quello che cambia fra le release non è il comando ma i parametri disponibili: nuove opzioni vengono aggiunte nel tempo. Se un parametro mostrato qui non compare premendo F4 sul comando, quasi sempre è perché la tua release è precedente a quella in cui è stato introdotto. La pagina di ciascun comando nella documentazione IBM è specifica per release, e basta cambiare il numero di versione nell'indirizzo per confrontarle.

In alternativa ai comandi, dalle release più recenti gli stessi dati si leggono anche in SQL con le IBM i Services (QSYS2.ACTIVE_JOB_INFO, QSYS2.JOB_QUEUE_INFO). È utile quando serve filtrare o esportare: una schermata 5250 non si può interrogare, una vista SQL sì. La disponibilità di ciascun servizio dipende dalla release e dal livello di PTF.

Fonti

• IBM i CL commands — IBM Documentation
• ACTIVE_JOB_INFO table function — IBM Documentation 7.5
• IBM i Technology Updates (novità per release e TR)