Su IBM i ogni cosa che gira è un job. Non un processo: un job, che ha un nome fatto di tre parti, una descrizione da cui prende le impostazioni, un registro proprio e un sottosistema che lo ospita.
Il nome completo si scrive numero/utente/nome (per esempio 123456/MROSSI/CHIUSURA) ed
è l'identificatore da usare ovunque serva indicare un job preciso. Gli schermi lo mostrano
in tre colonne separate: vanno unite con le barre.
I tipi di job
- Interattivo: una sessione a terminale, oggi quasi sempre un emulatore. Nasce quando qualcuno si collega e muore quando esce.
- Batch: un lavoro sottomesso a una coda, che parte quando c'è posto. È la forma in cui gira tutta l'elaborazione seria.
- Autostart: parte da solo quando parte il sottosistema che lo contiene: è così che si avviano i servizi.
- Prestart: job già pronti e in attesa, per non pagare il costo dell'avvio a ogni richiesta. Sono quelli che servono le connessioni ODBC, JDBC e i server di rete.
- Di sistema: quelli del sistema operativo, che non si toccano.
I sottosistemi
Un sottosistema è un ambiente di esecuzione: un pezzo di memoria, un insieme di regole su chi può entrarci, e i job che ci girano dentro. Il sistema ne ha diversi già pronti, e i nomi ricorrono ovunque:
| Sottosistema | Chi ci gira |
|---|---|
QBASE o QCTL |
il sottosistema di controllo: parte all'IPL, ed è quello da cui l'operatore governa il sistema dalla console. Lo indica il valore di sistema QCTLSBSD; quello di serie è QBASE |
QINTER |
le sessioni interattive |
QBATCH |
i lavori batch |
QSYSWRK |
i demoni dei server, tranne quelli del file server e del database server. Parte sempre all'IPL |
QUSRWRK |
i job dei server host: database, accesso, comandi remoti, code dati, stampa di rete |
QSERVER |
il demone del file server, i suoi job già pronti, e il demone del database server. Se non è attivo, le connessioni a quei server falliscono |
QHTTPSVR |
i server web |
Vederli, e vedere chi c'è dentro:
WRKSBS
WRKSBSJOB SBS(QBATCH)
WRKACTJOB SBS(QINTER)
La descrizione di sottosistema (oggetto *SBSD) contiene le regole: quali code di lavori
serve e con che priorità, quanti job può tenere attivi contemporaneamente, e in quale
porzione di memoria li fa girare.
Nota
in molte installazioni l'applicativo ha un sottosistema proprio, creato anni fa da chi ha fatto l'impianto. Separare i lavori dell'applicativo da QBATCH non è una complicazione inutile: significa poter fermare l'applicativo senza fermare tutto il resto, e poter dare a quei lavori memoria e priorità decise separatamente.
Le code di lavori
Un job batch non parte quando lo si sottomette: entra in una coda di lavori (*JOBQ) e
aspetta. Un sottosistema pesca dalle code che ha in elenco, fino al numero massimo di job
attivi che gli è stato consentito.
SBMJOB CMD(CALL PGM(PRODLIB/CHIUSURA)) JOB(CHIUSURA) JOBQ(QBATCH)
WRKJOBQ JOBQ(QBATCH)
La coda è la leva più semplice per governare la sequenza: una coda servita da un solo job alla volta esegue in fila, il che è esattamente quello che serve per lavori che non devono sovrapporsi; una chiusura contabile, una riorganizzazione di archivio.
Avvertenza
una coda sospesa (HLDJOBQ, spesso durante una manutenzione) accetta
i lavori e non ne fa partire nessuno. Non è un errore, non compare come guasto: i lavori
si accumulano educatamente e la mattina dopo nessuno è girato. Vale lo stesso per un
singolo lavoro sospeso in coda e per un sottosistema non avviato. Chi indaga su un batch
che "non è partito" guarda WRKJOBQ prima ancora del programma.
La memoria
La memoria è divisa in pool, e ogni sottosistema fa girare i propri job in un pool.
WRKSYSSTS mostra i pool con due numeri che valgono più di tutti gli altri: il tasso di
faulting e il wait.
Un pool che pagina molto è un pool troppo piccolo per il lavoro che ci si è messo dentro, e la conseguenza si vede come lentezza generale invece che come errore.
Consiglio
il sistema può regolare da solo i pool e i livelli di attività, con il valore di
sistema QPFRADJ, e di serie lo fa: all'avvio e poi periodicamente. Dimensionarli a mano ha
senso in casi particolari, e va rifatto ogni volta che il carico cambia.
Le priorità
Ogni job ha una priorità di esecuzione, che arriva dalla classe (*CLS) associata al
sottosistema, e che si può cambiare al volo:
CHGJOB JOB(123456/MROSSI/CHIUSURA) RUNPTY(30)
La priorità va da 1 (la più alta) a 99 (la più bassa), e una classe creata con CRTCLS senza
dire niente usa 50. IBM avverte che il numero è relativo: una priorità 25 non vale il doppio di
una 50.
Consiglio
prima di alzare la priorità di un batch pesante conviene ricordare che compete per il processore con tutti gli altri job attivi, sessioni comprese: quello che guadagna lui lo perdono gli altri. Spesso è più utile abbassare la priorità di un lavoro che sta dando fastidio.
Guardare, fermare, riprendere
WRKACTJOB
WRKJOB JOB(123456/MROSSI/CHIUSURA)
HLDJOB JOB(123456/MROSSI/CHIUSURA)
RLSJOB JOB(123456/MROSSI/CHIUSURA)
ENDJOB JOB(123456/MROSSI/CHIUSURA) OPTION(*CNTRLD) DELAY(60)
Avvertenza
ENDJOB con OPTION(*IMMED) chiude il job senza lasciare al programma il
tempo di concludere: il sistema fa la sua pulizia, il programma no (a meno che gestisca il
segnale SIGTERM). IBM scrive che può dare risultati indesiderati se i dati sono stati
aggiornati a metà, e che va usato solo dopo aver provato senza successo una chiusura
controllata. *CNTRLD lascia al programma il tempo indicato in DELAY per chiudere da sé.
Commenti
Nessun commento ancora. Sii il primo a commentare!
Devi avere un account per commentare. Accedi · Registrati