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 |
|---|---|
QCTL |
il sottosistema di controllo, il primo a partire |
QINTER |
le sessioni interattive |
QBATCH |
i lavori batch |
QSYSWRK |
i lavori di servizio del sistema |
QUSRWRK |
i lavori che il sistema esegue per conto degli utenti |
QSERVER |
i server per l'accesso ai file e al database |
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
su quasi tutti i sistemi moderni conviene lasciare fare al sistema, con
QPFRADJ impostato in modo che regoli i pool da solo, invece di dimensionarli a mano.
L'ottimizzazione manuale ha senso in casi particolari e va rifatta ogni volta che il
carico cambia; quella automatica segue il carico da sé.
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)
I valori bassi hanno più priorità. I job interattivi girano tipicamente a 20, i batch a 50.
Avvertenza
alzare la priorità di un batch pesante fino al livello degli interattivi non lo fa finire prima in modo significativo, ma fa rallentare le sessioni di tutti. Nella pratica la priorità serve più spesso ad abbassare quella di un lavoro che sta dando fastidio che ad alzare quella di uno urgente.
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 dargli modo di
concludere quello che stava facendo. Se il lavoro aveva una transazione aperta sotto
controllo di commit, la transazione viene annullata — che è il comportamento giusto — ma
se il programma gestisce a modo suo lo stato dell'elaborazione, si resta a metà, e
rimettere le cose a posto è lavoro manuale. *CNTRLD con un'attesa ragionevole va provato
per primo.
Commenti
Nessun commento ancora. Sii il primo a commentare!
Devi avere un account per commentare. Accedi · Registrati