t l tivoli workload -...
TRANSCRIPT
Tivoli® IBM Tivoli Workload
Scheduler
Manuale di riferimento
Versione 8.2 (ultima modifica dicembre 2004)
SC32-1274-02
���
Tivoli® IBM Tivoli Workload
Scheduler
Manuale di riferimento
Versione 8.2 (ultima modifica dicembre 2004)
SC32-1274-02
���
Nota
Prima di utilizzare queste informazioni e il prodotto ad esse relativo, leggere le informazioni riportate in “Informazioni
particolari” a pagina 343.
Terza edizione (dicembre 2004)
Questa edizione si applica alla versione 8, rilascio 2, livello di modifica 0 di IBM Tivoli Workload Scheduler
(numero programma 5698-WSH) e a tutti i successivi rilasci e modificazioni, se non diversamente indicato nelle
nuove edizioni.
Questa edizione sostituisce la versione SC32–1274–01.
© Copyright International Business Machines Corporation 1999, 2004. Tutti i diritti riservati.
Indice
Figure . . . . . . . . . . . . . . . vii
Tabelle . . . . . . . . . . . . . . . ix
Informazioni sul manuale . . . . . . . xi
Novità . . . . . . . . . . . . . . . . xi
A chi è rivolto questo manuale . . . . . . . . xi
Contenuto del manuale . . . . . . . . . . xi
Pubblicazioni . . . . . . . . . . . . . . xii
Libreria IBM Tivoli Workload Scheduler . . . . xii
Pubblicazioni correlate . . . . . . . . . xv
Accesso alle pubblicazioni in linea . . . . . xvi
Richiesta pubblicazioni . . . . . . . . . xvi
Feedback sulle pubblicazioni . . . . . . . xvii
Accesso facilitato . . . . . . . . . . . . xvii
Preparazione tecnica Tivoli . . . . . . . . . xvii
Informazioni di supporto . . . . . . . . . xvii
Convenzioni utilizzate in questo manuale . . . . xvii
Convenzioni tipografiche . . . . . . . . xvii
Variabili e percorsi specifici del sistema
operativo . . . . . . . . . . . . . xviii
Sintassi dei comandi . . . . . . . . . . xviii
Capitolo 1. Inizio rapido . . . . . . . . 1
Creazione di un piano . . . . . . . . . . . 2
Gestione dei lavori e dei flussi di lavoro . . . . . 5
Capitolo 2. Ciclo di produzione . . . . . 9
Processi e interfacce principali del prodotto . . . . 9
Interfacce utente . . . . . . . . . . . . 9
Comandi di preproduzione e postproduzione . . 10
Comandi di sicurezza . . . . . . . . . . 10
Processi di produzione . . . . . . . . . 10
Struttura ad albero dei processi sulle piattaforme
UNIX . . . . . . . . . . . . . . . 11
Struttura ad albero dei processi sulle piattaforme
Windows . . . . . . . . . . . . . . 13
Automazione del ciclo di produzione . . . . . . 15
Personalizzazione del flusso di lavoro finale . . 15
Aggiunta del flusso di lavoro finale . . . . . 16
Avvio di un ciclo di produzione . . . . . . 16
Gestione dell’ambiente di produzione . . . . . 17
Selezione dell’Avvio del giorno di IBM Tivoli
Workload Scheduler . . . . . . . . . . 17
Modifica dell’avvio del giorno . . . . . . . 17
Creazione di un piano per date passate e future 17
Utilizzo dei report . . . . . . . . . . . 18
Avvio dei lavori . . . . . . . . . . . . . 18
Variabili di ambiente del lavoro . . . . . . 19
Script di configurazione standard - jobmanrc . . 19
Script di configurazione locale -
$HOME/.jobmanrc . . . . . . . . . . . 21
Comandi di elaborazione della produzione . . . . 22
Comando schedulr . . . . . . . . . . . 23
Comando compiler . . . . . . . . . . . 25
Comando stageman . . . . . . . . . . 27
Comando logman . . . . . . . . . . . 30
Comando wmaeutil . . . . . . . . . . . 32
Capitolo 3. Riferimento al Composer 35
Gestione degli oggetti di pianificazione . . . . . 35
Definizioni delle workstation . . . . . . . 37
Definizioni delle classi workstation . . . . . 43
Definizioni dominio . . . . . . . . . . 44
Definizioni lavoro . . . . . . . . . . . 46
Definizioni utente . . . . . . . . . . . 52
Definizioni calendario . . . . . . . . . . 54
Definizioni parametro . . . . . . . . . . 55
Definizioni prompt . . . . . . . . . . . 57
Definizioni risorsa . . . . . . . . . . . 59
Programma Composer . . . . . . . . . . . 60
Esecuzione del composer . . . . . . . . . 60
Sintassi dei comandi . . . . . . . . . . 62
Descrizioni comandi . . . . . . . . . . . 63
add . . . . . . . . . . . . . . . . 65
build . . . . . . . . . . . . . . . 66
continue . . . . . . . . . . . . . . 67
create . . . . . . . . . . . . . . . 68
delete . . . . . . . . . . . . . . . 70
display, list, print . . . . . . . . . . . 72
edit . . . . . . . . . . . . . . . . 75
exit . . . . . . . . . . . . . . . . 76
modify . . . . . . . . . . . . . . . 77
new . . . . . . . . . . . . . . . . 79
redo . . . . . . . . . . . . . . . . 80
replace . . . . . . . . . . . . . . . 82
system, comando . . . . . . . . . . . 83
validate . . . . . . . . . . . . . . . 84
version . . . . . . . . . . . . . . . 85
Capitolo 4. Linguaggio di pianificazione 87
Sintassi per i flussi di lavoro . . . . . . . . . 87
Parole chiave . . . . . . . . . . . . . 88
Dipendenze . . . . . . . . . . . . . 89
Sensibilità al maiuscolo/minuscolo . . . . . 89
Descrizioni parola chiave . . . . . . . . . . 89
at . . . . . . . . . . . . . . . . . 90
carryforward . . . . . . . . . . . . . 92
comments . . . . . . . . . . . . . . 93
confirmed . . . . . . . . . . . . . . 94
tempo limite . . . . . . . . . . . . . 95
end . . . . . . . . . . . . . . . . 96
every . . . . . . . . . . . . . . . 97
except . . . . . . . . . . . . . . . 98
follows . . . . . . . . . . . . . . 100
freedays . . . . . . . . . . . . . . 101
job statement . . . . . . . . . . . . 103
keyjob . . . . . . . . . . . . . . . 108
keysched . . . . . . . . . . . . . . 109
© Copyright IBM Corp. 1999, 2004 iii
limit . . . . . . . . . . . . . . . 110
needs . . . . . . . . . . . . . . . 111
il . . . . . . . . . . . . . . . . 112
opens . . . . . . . . . . . . . . . 115
priority . . . . . . . . . . . . . . 117
prompt . . . . . . . . . . . . . . 118
schedule . . . . . . . . . . . . . . 119
until . . . . . . . . . . . . . . . 120
Capitolo 5. Riferimento a Conman . . 123
Esecuzione di conman . . . . . . . . . . 123
Esempi . . . . . . . . . . . . . . 123
Caratteri di controllo . . . . . . . . . . 123
Esecuzione dei comandi di sistema . . . . . 123
Prompt dell’utente . . . . . . . . . . . 124
Output terminale . . . . . . . . . . . 124
Output non in linea . . . . . . . . . . 124
Selezione del prompt del comando conman . . 125
Sintassi dei comandi . . . . . . . . . . . 125
Caratteri jolly . . . . . . . . . . . . 126
Delimitatori e caratteri speciali . . . . . . 126
Elenco di comandi . . . . . . . . . . . 127
Selezione dei lavori nei comandi . . . . . . . 129
Sintesi . . . . . . . . . . . . . . . 129
Argomenti . . . . . . . . . . . . . 129
Selezione dei flussi di lavoro nei comandi . . . . 137
Sintesi . . . . . . . . . . . . . . . 137
Argomenti . . . . . . . . . . . . . 137
Descrizioni comandi . . . . . . . . . . . 143
Elaborazione del comando Conman . . . . . 143
adddep job . . . . . . . . . . . . . 144
adddep sched . . . . . . . . . . . . 146
altpass . . . . . . . . . . . . . . . 148
altpri . . . . . . . . . . . . . . . 149
cancel job . . . . . . . . . . . . . . 150
cancel sched . . . . . . . . . . . . . 152
confirm . . . . . . . . . . . . . . 154
console . . . . . . . . . . . . . . 155
continue . . . . . . . . . . . . . . 156
lavoro deldep . . . . . . . . . . . . 157
deldep sched . . . . . . . . . . . . 159
display . . . . . . . . . . . . . . 161
exit . . . . . . . . . . . . . . . . 162
fence . . . . . . . . . . . . . . . 163
help . . . . . . . . . . . . . . . 164
kill . . . . . . . . . . . . . . . . 165
limit cpu . . . . . . . . . . . . . . 166
limit sched . . . . . . . . . . . . . 167
link . . . . . . . . . . . . . . . . 168
listsym . . . . . . . . . . . . . . 170
recall . . . . . . . . . . . . . . . 171
redo . . . . . . . . . . . . . . . 172
release job . . . . . . . . . . . . . 174
release sched . . . . . . . . . . . . 176
reply . . . . . . . . . . . . . . . 178
rerun . . . . . . . . . . . . . . . 179
resource . . . . . . . . . . . . . . 182
setsym . . . . . . . . . . . . . . 183
showcpus . . . . . . . . . . . . . 184
showdomain . . . . . . . . . . . . 188
showfiles . . . . . . . . . . . . . . 189
showjobs . . . . . . . . . . . . . . 191
showprompts . . . . . . . . . . . . 199
showresources . . . . . . . . . . . . 201
showschedules . . . . . . . . . . . . 203
shutdown . . . . . . . . . . . . . 206
avvio . . . . . . . . . . . . . . . 207
status . . . . . . . . . . . . . . . 209
stop . . . . . . . . . . . . . . . 210
stop ;progressive . . . . . . . . . . . 212
submit docommand . . . . . . . . . . 213
submit file . . . . . . . . . . . . . 215
submit job . . . . . . . . . . . . . 217
submit sched . . . . . . . . . . . . 219
switchmgr . . . . . . . . . . . . . 221
system . . . . . . . . . . . . . . 222
tellop . . . . . . . . . . . . . . . 223
unlink . . . . . . . . . . . . . . . 224
version . . . . . . . . . . . . . . 226
Capitolo 6. Comandi di utilità . . . . 227
Descrizioni comandi . . . . . . . . . . . 227
Comandi at e batch . . . . . . . . . . 229
caxtract . . . . . . . . . . . . . . 233
cpuinfo . . . . . . . . . . . . . . 234
datecalc . . . . . . . . . . . . . . 236
dbexpand . . . . . . . . . . . . . 240
delete . . . . . . . . . . . . . . . 241
evtsize . . . . . . . . . . . . . . . 242
jbxtract . . . . . . . . . . . . . . 244
jobinfo . . . . . . . . . . . . . . . 246
jobstdl . . . . . . . . . . . . . . . 248
maestro . . . . . . . . . . . . . . 250
makecal . . . . . . . . . . . . . . 251
metronome.pl . . . . . . . . . . . . 253
morestdl . . . . . . . . . . . . . . 254
parms . . . . . . . . . . . . . . . 256
paxtract . . . . . . . . . . . . . . 257
prxtract . . . . . . . . . . . . . . 258
r11xtr . . . . . . . . . . . . . . . 259
rilascia . . . . . . . . . . . . . . 260
rextract . . . . . . . . . . . . . . 262
rmstdlist . . . . . . . . . . . . . . 263
showexec . . . . . . . . . . . . . . 264
StartUp . . . . . . . . . . . . . . 265
version . . . . . . . . . . . . . . 266
wmaeutil . . . . . . . . . . . . . . 268
xrxtrct . . . . . . . . . . . . . . . 270
Comandi non supportati . . . . . . . . 275
Capitolo 7. Comandi report . . . . . 277
Comandi report . . . . . . . . . . . . 277
Output del comando . . . . . . . . . . 277
Comandi rep1 - rep4b . . . . . . . . . 279
Comando rep7 . . . . . . . . . . . . 280
Comando rep8 . . . . . . . . . . . . 281
Comando rep11 . . . . . . . . . . . 282
Comando reptr . . . . . . . . . . . . 283
Comando xref . . . . . . . . . . . . 285
Report di esempio . . . . . . . . . . . 286
iv IBM Tivoli Workload Scheduler - Manuale di riferimento
Capitolo 8. Riferimento Agent esteso 289
Cosa sono gli Agent estesi? . . . . . . . . . 289
Definizione della workstation . . . . . . . 289
Interfaccia del metodo di accesso . . . . . . . 289
Sintassi della riga comandi del metodo . . . . 289
Messaggi di risposta del metodo . . . . . . 292
File di opzioni del metodo . . . . . . . . 292
Esecuzione del metodo . . . . . . . . . . 293
Attività LJ (Launch job) . . . . . . . . . 293
Attività MJ (Manage job) . . . . . . . . 294
Attività CF (Check file) . . . . . . . . . 294
Attività GS (Get status) . . . . . . . . . 295
Comando cpuinfo . . . . . . . . . . . 296
Risoluzione dei problemi . . . . . . . . . 296
Messaggi di errore dell’elenco standard del
lavoro . . . . . . . . . . . . . . . 296
Metodo non eseguibile . . . . . . . . . 296
Messaggi Gestore console . . . . . . . . 296
Messaggi del composer e del compiler . . . . 297
Messaggi Jobman . . . . . . . . . . . 297
Capitolo 9. Riferimento Agent di rete 299
Panoramica . . . . . . . . . . . . . . 299
Configurazione della workstation dell’agent di rete 299
Esempio della riga comandi dell’agent di rete 301
File delle opzioni . . . . . . . . . . . 301
Dipendenze Internetwork . . . . . . . . . 302
Creazione di una dipendenza internetwork in
un flusso di lavoro . . . . . . . . . . 302
Dipendenze Internetwork e Conman . . . . 303
Capitolo 10. Impostazione delle
definizioni di sicurezza utente . . . . 307
Centralizzazione della sicurezza . . . . . . . 307
Gestione dei file Security . . . . . . . . . 308
Creazione del file Security . . . . . . . . 308
Modifica del file Security . . . . . . . . 308
Sintassi del file Security . . . . . . . . . . 309
Definizioni utente . . . . . . . . . . . 309
File Security di esempio . . . . . . . . . . 319
dumpsec . . . . . . . . . . . . . . . 323
makesec . . . . . . . . . . . . . . . 324
Appendice A. Informazioni di
supporto . . . . . . . . . . . . . 327
Ricerca basi della conoscenza . . . . . . . . 327
Ricerca nel centro informazioni sulla rete o sul
sistema locale . . . . . . . . . . . . 327
Ricerca nel centro informazioni sul sito Web di
supporto IBM . . . . . . . . . . . . 327
Ricerca in Internet . . . . . . . . . . . 327
Come ottenere le correzioni . . . . . . . . 328
Come contattare l’assistenza software IBM . . . . 328
Determinazione dell’impatto aziendale del
problema . . . . . . . . . . . . . . 329
Descrizione del problema e raccolta delle
informazioni di background . . . . . . . 329
Notifica del problema all’assistenza IBM . . . 329
Appendice B. Gestione dei fusi orari 331
Attivazione della funzione fuso orario . . . . . 331
Esecuzione di un flusso di lavoro senza
l’abilitazione del fuso orario quando il gestore
dominio master è in anticipo su FTA . . . . 332
Esecuzione di un flusso di lavoro con
l’abilitazione del fuso orario quando il master è
in anticipo su FTA . . . . . . . . . . . 332
Esecuzione di un flusso di lavoro senza
l’abilitazione del fuso orario quando il gestore
dominio master è in ritardo su FTA . . . . . 332
Esecuzione di un flusso di lavoro con
l’abilitazione del fuso orario quando il gestore
dominio master è in ritardo su FTA . . . . . 333
Inoltro ad hoc di un flusso di lavoro
specificando una dipendenza at . . . . . . 333
Inoltro di un flusso di lavoro specificando una
dipendenza at con l’ora legale . . . . . . . 334
Elenco dei fusi orari . . . . . . . . . . . 334
Appendice C. Funzione di controllo 337
Abilitazione della funzione di controllo . . . . . 337
Formato del file di log di controllo . . . . . . 338
Intestazione del file di log di controllo . . . . . 341
Voci log di controllo di esempio . . . . . . . 342
Informazioni particolari . . . . . . . 343
Marchi . . . . . . . . . . . . . . . 344
Glossario . . . . . . . . . . . . . 345
Indice analitico . . . . . . . . . . . 351
Indice v
Figure
1. Struttura ad albero dei processi su UNIX 12
2. Struttura ad albero dei processi su Windows 14
3. Collegamenti di rete . . . . . . . . . 169
4. Workstation avviate in rete . . . . . . . 208
5. Workstation arrestate in rete . . . . . . 211
6. Workstation di rete non collegate . . . . . 225
7. Reti locali e remote . . . . . . . . . 301
8. Zone morte . . . . . . . . . . . . 331
© Copyright IBM Corp. 1999, 2004 vii
Tabelle
1. Sintassi comando . . . . . . . . . . xviii
2. Variabili di ambiente del lavoro . . . . . . 19
3. Variabili di jobmanrc . . . . . . . . . 19
4. Elenco di parole chiave riservate . . . . . 36
5. Valori per i sistemi operativi supportati 38
6. Topo di comunicazione a seconda del valore di
securitylevel. . . . . . . . . . . . . 40
7. Operatore di comparazione . . . . . . . 47
8. Operatori logici . . . . . . . . . . . 48
9. Operatore di comparazione . . . . . . . 104
10. Operatori logici . . . . . . . . . . . 105
11. Attributi dell’oggetto . . . . . . . . . 311
12. Azioni . . . . . . . . . . . . . . 312
13. Azioni (continuo) . . . . . . . . . . 312
© Copyright IBM Corp. 1999, 2004 ix
Informazioni sul manuale
IBM Tivoli Workload Scheduler semplifica la gestione dei sistemi su ambienti
distribuiti integrando le funzioni di gestione dei sistemi. IBM Tivoli Workload
Scheduler pianifica, controlla e automatizza l’elaborazione dell’intero carico di
produzione di un’azienda. Il Manuale di riferimento IBM Tivoli Workload Scheduler
fornisce informazioni dettagliate sulla CLI (command line interface), sul linguaggio
di pianificazione e sui comandi di utilità per IBM Tivoli Workload Scheduler.
Novità
Questa edizione è un aggiornamento della Guida di riferimento di IBM Tivoli
Workload Scheduler, versione 8.2, precedentemente modificata nell’aprile 2004.
Di seguito sono riportate le principali modifiche apportate alla guida:
v Una nuova sezione ″Vedere anche″ con la descrizione di diversi comandi.
v Più esempi per i comandi.
v Una nuova sezione che descrive le interfacce e i processi inclusi nel Capitolo 2,
consultare “Processi e interfacce principali del prodotto” a pagina 9.
v Un nuovo capitolo denominato ″Inizio rapido″, aggiunto per i nuovi utenti.
v Più informazioni sul file Security, fare riferimento al Capitolo 10, “Impostazione
delle definizioni di sicurezza utente”, a pagina 307.
v Una nuova appendice che fornisce i dettagli su come contattare l’assistenza IBM,
consultare l’Appendice A, “Informazioni di supporto”, a pagina 327.
v Una nuova appendice che descrive la funzione Fuso orario, consultare
l’Appendice B, “Gestione dei fusi orari”, a pagina 331.
v Le informazioni contenute in questa guida sono state aggiornate in base ai due
APAR IY58702 e IY53459.
A chi è rivolto questo manuale
Questo manuale è rivolto agli amministratori e agli utenti avanzati di IBM Tivoli
Workload Scheduler.
Contenuto del manuale
La Parte I contiene i capitoli seguenti:
v Capitolo 1, “Inizio rapido”, a pagina 1
Descrive la procedura di base che un nuovo utente deve seguire per utilizzare
IBM Tivoli Workload Scheduler per la prima volta.
v Capitolo 2, “Ciclo di produzione”, a pagina 9
Descrive il modo in cui IBM Tivoli Workload Scheduler determina, al termine di
ogni giorno, le pianificazioni da eseguire il giorno successivo in base alle
informazioni memorizzate nel database e ai risultati dell’elaborazione del giorno
di produzione corrente.
v Capitolo 3, “Riferimento al Composer”, a pagina 35
© Copyright IBM Corp. 1999, 2004 xi
Descrive gli oggetti di pianificazione che possono essere definiti nel database
IBM Tivoli Workload Scheduler e fornisce informazioni sull’utilizzo e sulla
sintassi dei comandi del programma composer impiegati per gestire questi
oggetti nel database.
v Capitolo 4, “Linguaggio di pianificazione”, a pagina 87
Descrive il modo in cui creare un flusso di lavoro, in base agli oggetti di
pianificazione definiti nel database IBM Tivoli Workload Scheduler, utilizzando il
comando composer.
v Capitolo 5, “Riferimento a Conman”, a pagina 123
Descrive la CLI (command line interface) conman. Questa interfaccia viene
utilizzata per monitorare e gestire i lavori e i flussi di lavoro durante un giorno
di produzione.
v Capitolo 6, “Comandi di utilità”, a pagina 227
Descrive i comandi di utilità IBM Tivoli Workload Scheduler per la gestione
dell’ambiente.
v Capitolo 7, “Comandi report”, a pagina 277
Descrive come stampare diversi tipi di report.
v Capitolo 8, “Riferimento Agent esteso”, a pagina 289
Descrive il modo in cui creare e utilizzare gli agent estesi per estendere le
funzioni di pianificazione dei lavori di IBM Tivoli Workload Scheduler ad altri
sistemi e applicazioni, quali i sistemi UNIX locali o remoti, Peoplesoft, SAP R/3,
z/OS, OPC, Oracle CCM e VMS.
v Capitolo 9, “Riferimento Agent di rete”, a pagina 299
Descrive come creare e utilizzare una workstation dell’agent di rete per gestire le
dipendenze internetwork.
v Capitolo 10, “Impostazione delle definizioni di sicurezza utente”, a pagina 307
Descrive come gestire il file Security.
v Appendice A, “Informazioni di supporto”, a pagina 327
Descrive le diverse opzioni per ottenere il supporto sui prodotti IBM.
v Appendice B, “Gestione dei fusi orari”, a pagina 331
Elenca i fusi orari supportati da IBM Tivoli Workload Scheduler.
v Appendice C, “Funzione di controllo”, a pagina 337
Descrive il modo in cui abilitare e utilizzare l’opzione di controllo per tracciare
le modifiche apportate al database e al piano.
Pubblicazioni
Questa sezione elenca le pubblicazioni nella libreria Tivoli Workload Scheduler e tutti
i documenti correlati. Inoltre, descrive il modo in cui accedere online alle
pubblicazioni Tivoli e come ordinare le pubblicazioni Tivoli.
Libreria IBM Tivoli Workload Scheduler
IBM Tivoli Workload Scheduler comprende diversi singoli prodotti, disponibili su
una varietà di piattaforme, e una libreria così suddivisa:
Libreria di IBM Tivoli Workload Scheduling
Questa libreria contiene tutte le pubblicazioni delle piattaforme e dei
prodotti incrociati per IBM Tivoli Workload Scheduler.
xii IBM Tivoli Workload Scheduler - Manuale di riferimento
Libreria distribuita di IBM Tivoli Workload Scheduler
Questa libreria contiene tutte le pubblicazioni che fanno riferimento
all’utilizzo di IBM Tivoli Workload Scheduler sulle piattaforme diverse da
z/OS.
Libreria di IBM Tivoli Workload Scheduler per z/OS
Questa libreria contiene tutte le pubblicazioni che si applicano solo a IBM
Tivoli Workload Scheduler per z/OS.
Libreria di IBM Tivoli Workload Scheduler per le applicazioni
Questa libreria contiene tutte le pubblicazioni che si applicano a IBM Tivoli
Workload Scheduler per le applicazioni.
Libreria di IBM Tivoli Workload Scheduler per Virtualized Data Centers
Questa libreria contiene tutte le pubblicazioni che si applicano solo a IBM
Tivoli Workload Scheduler per Virtualized Data Centers.
Libreria di IBM Tivoli Workload Scheduling
Le seguenti pubblicazioni sono disponibili nella libreria di IBM Tivoli Workload
Scheduling. Comprende molte pubblicazioni comuni a tutti i prodotti, piattaforme
e componenti.
v IBM Tivoli Workload Scheduler: General Information, SC32-1256
Fornisce informazioni generiche su tutti i prodotti IBM Tivoli Workload
Scheduler. Indica, inoltre, come utilizzare questi prodotti insieme per fornire
soluzioni aziendali relative alla gestione del carico di lavoro.
v IBM Tivoli Workload Scheduler: Job Scheduling Console - Guida per l’utente,
SC32-1257
Descrive il modo in cui gestire IBM Tivoli Workload Scheduler, a prescindere
dalla piattaforma, utilizzando una GUI comune denominata Job Scheduling
Console.
v IBM Tivoli Workload Scheduler: Job Scheduling Console Release Notes, SC32-1258
Fornisce le ultime informazioni su Job Scheduling Console.
v IBM Tivoli Workload Scheduler: Warehouse Enablement Pack versione 1.1.0
Implementation Guide for Tivoli Enterprise Data Warehouse, versione 1.1,
Fornisce informazioni sull’abilitazione di IBM Tivoli Workload Scheduler per
Tivoli Data Warehouse.
Nota: Questa guida è disponibile solo sul CD del prodotto. Non è possibile
consultare questa guida in linea come per gli altri manuali (consultare
“Accesso alle pubblicazioni in linea” a pagina xvi).
Libreria distribuita di IBM IBM Tivoli Workload Scheduler
Le seguenti pubblicazioni sono disponibili nella libreria distribuita IBM IBM Tivoli
Workload Scheduler. Sono incluse le pubblicazioni che fanno riferimento
all’utilizzo del prodotto su tutte le piattaforme ad eccezione di z/OS.
v IBM Tivoli Workload Scheduler: Release Notes, SC32-1277
Fornisce le ultime informazioni per IBM Tivoli Workload Scheduler sulle
piattaforme diverse da z/OS.
v IBM Tivoli Workload Scheduler: Guida alla pianificazione e all’installazione, SC32-1273
Descrive come pianificare e installare IBM IBM Tivoli Workload Scheduler sulle
piattaforme diverse da z/OS e come integrare IBM Tivoli Workload Scheduler
con NetView, Tivoli Data Warehouse e IBM IBM Tivoli Business Systems
Manager.
v IBM Tivoli Workload Scheduler: Manuale di riferimento, SC32-1274
Informazioni sul manuale xiii
Descrive la riga comandi IBM Tivoli Workload Scheduler utilizzata sulle
piattaforme diverse da z/OS e il funzionamento degli agent estesi e di rete.
v IBM Tivoli Workload Scheduler: Administration and Troubleshooting, SC32-1275
Fornisce informazioni sulla gestione di IBM Tivoli Workload Scheduler sulle
piattaforme diverse da z/OS e sulla risoluzione dei problemi. Include una guida
per i messaggi generati dai componenti principali di IBM Tivoli Workload
Scheduler.
v IBM Tivoli Workload Scheduler: Limited Fault-tolerant Agent for OS/400, SC32-1280
Descrive come installare, configurare e utilizzare gli FTA limitati IBM Tivoli
Workload Scheduler sui sistemi AS/400.
v IBM Tivoli Workload Scheduler: Plus Module User’s Guide, SC32-1276
Descrive come impostare e utilizzare il modulo IBM Tivoli Workload Scheduler
Plus.
Visitare il sito http://www.ibm.com/software/tivoli/products/scheduler/ per
un’introduzione al prodotto.
Libreria di IBM IBM Tivoli Workload Scheduler per z/OS
I seguenti documenti sono disponibili nella libreria Tivoli Workload Scheduler per
z/OS:
v IBM Tivoli Workload Scheduler per z/OS: Getting Started, SC32-1262
Descrive come definire i dati sull’installazione di IBM Tivoli Workload Scheduler
per z/OS e come creare e modificare i piani.
v IBM Tivoli Workload Scheduler per z/OS: Installation Guide
Descrive come installare Tivoli Workload Scheduler per z/OS.
v IBM Tivoli Workload Scheduler per z/OS: Customization and Tuning, SC32-1265
Descrive come personalizzare Tivoli Workload Scheduler per z/OS.
v IBM Tivoli Workload Scheduler per z/OS: Managing the Workload, SC32-1263
Spiega come pianificare il carico di lavoro e controllare il piano corrente.
v IBM Tivoli Workload Scheduler per z/OS: Quick Reference, SC32-1268
Fornisce una guida rapido e facile da consultare sull’utilizzo di Tivoli Workload
Scheduler per z/OS.
v IBM Tivoli Workload Scheduler per z/OS: Diagnosis Guide and Reference, SC32-1261
Fornisce informazioni per l’individuazione e la risoluzione dei problemi che
potrebbero verificarsi durante l’utilizzo di Tivoli Workload Scheduler per z/OS.
v IBM Tivoli Workload Scheduler per z/OS: Messages and Codes, SC32-1267
Descrive i messaggi e i codici in Tivoli Workload Scheduler per z/OS.
v IBM Tivoli Workload Scheduler per z/OS: Programming Interfaces, SC32-1266
Fornisce informazioni sulla scrittura delle applicazioni di Tivoli Workload
Scheduler per z/OS.
v IBM Tivoli Workload Scheduler per z/OS: Licensed Program Specifications, GI11-4208
Fornisce informazioni sulla pianificazione di Tivoli Workload Scheduler per
z/OS.
v IBM Tivoli Workload Scheduler per z/OS: Memo per il programma 5697-WSZ,
GI11-4209
Fornisce un riepilogo delle modifiche del rilascio corrente del prodotto.
v IBM Tivoli Workload Scheduler per z/OS: Program Directory per il programma
5697-WSZ, GI11-4203
xiv IBM Tivoli Workload Scheduler - Manuale di riferimento
Fornita con il supporto di installazione di Tivoli Workload Scheduler per z/OS
(programma 5697-WSZ), descrive tutto il materiale relativo all’installazione e
fornisce istruzioni di installazione specifiche per il numero di funzione o il
livello di rilascio del prodotto.
v IBM Tivoli Workload Scheduler per z/OS: Program Directory per il programma
5698-WSZ, GI11-4207
Fornita con il supporto di installazione di Tivoli Workload Scheduler per z/OS
(programma 5698-WSC), descrive tutto il materiale relativo all’installazione e
fornisce istruzioni di installazione specifiche per il numero di funzione o il
livello di rilascio del prodotto.
Visitare il sito http://www.ibm.com/software/tivoli/products/scheduler-zos/ per
un’introduzione sul prodotto.
Libreria di IBM IBM Tivoli Workload Scheduler for Applications
I seguenti manuali sono disponibili nella libreria IBM IBM Tivoli Workload
Scheduler for Applications:
v IBM Tivoli Workload Scheduler, Applications: Release Notes, SC32-1279
Fornisce le ultime informazioni sugli agent estesi IBM Tivoli Workload
Scheduler.
v IBM Tivoli Workload Scheduler, Applications: User’s Guide, SC32-1278
Descrive come installare, utilizzare e risolvere i problemi relativi agli agent estesi
di IBM Tivoli Workload Scheduler.
Visitare il sito http://www.ibm.com/software/tivoli/products/scheduler-apps/
per un’introduzione sul prodotto.
Libreria di IBM IBM Tivoli Workload Scheduler per Virtualized
Data Centers
I seguenti manuali sono disponibili nella libreria IBM IBM Tivoli Workload
Scheduler per Virtualized Data Centers:
v IBM Tivoli Workload Scheduler per Virtualized Data Centers: Release Notes, SC32-1453
Fornisce le ultime informazioni su IBM Tivoli Workload Scheduler per
Virtualized Data Centers.
v IBM Tivoli Workload Scheduler per Virtualized Data Centers: User’s Guide, SC32-1454
Descrive come estendere le funzioni di pianificazione di IBM Tivoli Workload
Scheduler per l’ottimizzazione del carico di lavoro e della griglia abilitando il
controllo dei lavori di IBM LoadLeveler e IBM Grid Toolbox.
Vedere http://www.ibm.com/software/info/ecatalog/it_IT/
products/Y614224T20392S50.html per un’introduzione al prodotto.
Pubblicazioni correlate
Anche i seguenti documenti forniscono delle informazioni utili:
v IBM Redbooks: High Availability Scenarios with IBM Tivoli Workload Scheduler and
IBM Tivoli Framework
Questo Redbook IBM mostra come progettare e creare ambienti altamente
disponibili di IBM Tivoli Workload Scheduler e IBM Tivoli Management
Framework (server TMR, endpoint e nodi gestiti). Presenta la funzione HACMP
(High Availability Cluster Multiprocessing) per MSCS (Cluster Service) AIX e
Microsoft Windows.
Questo Redbook è disponibile sul sito web Redbooks all’indirizzo
http://www.redbooks.ibm.com/abstracts/sg246632.html
Informazioni sul manuale xv
v IBM Redbooks: Customizing IBM Tivoli Workload Scheduler for z/OS V8.2 to Improve
Performance
Questo Redbook IBM fornisce le tecniche per l’ottimizzazione delle prestazioni
di Tivoli Workload Scheduler per z/OS (come la pianificazione end-to-end).
Questo Redbook è disponibile sul sito web Redbooks all’indirizzo
http://www.redbooks.ibm.com/abstracts/sg246352.html
v IBM Redbooks: End-to-End Scheduling with IBM Tivoli Workload Scheduler Version 8.2
Questo Redbook IBM fornisce la pianificazione end-to-end utilizzando Tivoli
Workload Scheduler versione 8.2, entrambi i componenti Distribuito
(precedentemente noto come Maestro e Mainframe (noto come OPC).
Questo Redbook è disponibile sul sito web Redbooks all’indirizzo
http://www.redbooks.ibm.com/abstracts/sg246624.html
Tivoli Software Glossary include le definizioni di molti termini tecnici correlati con il
software Tivoli. Tivoli Software Glossary è disponibile sul seguente sito Web della
libreria software Tivoli:
http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm
Accesso alle pubblicazioni in linea
Il CD del prodotto contiene le pubblicazioni della libreria del prodotto. Il formato
delle pubblicazioni è PDF, HTML o entrambi. Per accedere alle pubblicazioni
mediante un browser Web, aprire il file infocenter.html. Il file si trova nella
directory delle pubblicazioni appropriata sul CD del prodotto.
IBM invia le pubblicazioni relative a questo e altri prodotti Tivoli, non appena sono
disponibili e in qualsiasi momento vengano aggiornate, al sito Web del centro
informazioni Tivoli. Accedere al centro informazioni del software Tivoli visitando
la libreria del software Tivoli all’indirizzo Web:
http://www.ibm.com/software/tivoli/library/
Scorrere l’elenco e selezionare il collegamento Product manuals. Nella finestra
Tivoli Technical Product Documents Alphabetical Listing, fare clic sul prodotto
appropriato di Tivoli Workload Scheduler per accedere alle librerie del prodotto
nel centro informazioni del software Tivoli. Tutte le pubblicazioni nella libreria IBM
Tivoli Workload Scheduler, nella libreria distribuita e nella libreria z/OS possono
essere ricercate sotto la voce IBM Tivoli Workload Scheduler.
Nota: Se si stampano i documenti PDF su un tipo di carta non in formato lettera,
impostare l’opzione nella finestra File → Print che consente al programma
Adobe Reader di stampare le pagine in formato lettera su carta locale.
Richiesta pubblicazioni
E’ possibile richiedere molte pubblicazioni Tivoli in linea nel seguente sito web:
http://www.elink.ibmlink.ibm.com/public/applications/
publications/cgibin/pbi.cgi
E’ possibile inoltre effettuare l’ordine telefonicamente chiamando uno dei seguenti
numeri:
v Negli Stati Uniti: 800-879-2755
v In Canada: 800-426-4968
xvi IBM Tivoli Workload Scheduler - Manuale di riferimento
In altri paesi, per un elenco di numeri telefonici, consultare il seguente sito web:
http://www.ibm.com/software/tivoli/order-lit/
Feedback sulle pubblicazioni
In caso di commenti o suggerimenti sui prodotti e sulla documentazione Tivoli,
completare il seguente feedback sul sito Web:
http://www.ibm.com/software/sysmgmt/products/support
Accesso facilitato
Le funzioni di accessibilità aiutano gli utenti disabili ad utilizzare i prodotti
software correttamente. Con questo prodotto, è possibile utilizzare le tecnologie
assistenziali per ascoltare e navigare. E’ inoltre possibile utilizzare la tastiera al
posto del mouse per eseguire tutte le funzioni della GUI.
Per ulteriori informazioni, consultare l’appendice sull’accesso facilitato del manuale
IBM Tivoli Job Scheduling Console - Guida per l’utente.
Preparazione tecnica Tivoli
Per informazioni sulla preparazione tecnica Tivoli, visitare il seguente sito Web
IBM Tivoli Education:
http://www.ibm.com/software/tivoli/education
Informazioni di supporto
Se si verifica un problema al software IBM, si desidera risolverlo velocemente. IBM
fornisce i seguenti modi per ottenere il supporto necessario:
v Ricercando le basi della conoscenza: è possibile effettuare la ricerca in un’ampia
raccolta di problemi noti e risoluzioni, note tecniche e altre informazioni.
v Ricercando le correzioni: è possibile trovare le ultime correzioni già disponibili
per il prodotto.
v Contattando l’assistenza IBM: se non si è in grado da soli di risolvere il
problema ed occorre rivolgersi al personale specializzato IBM, è possibile
utilizzare diversi modi per contattare l’assistenza IBM.
Per ulteriori informazioni su questi tre metodi di risoluzione dei problemi,
consultare Appendice A, “Informazioni di supporto”, a pagina 327.
Convenzioni utilizzate in questo manuale
Questo manuale utilizza diverse convenzioni per termini e azioni speciali, per i
comandi e i percorsi che dipendono dal sistema operativo e per la grafica di
margine.
Convenzioni tipografiche
Nella presente pubblicazione sono utilizzate le seguenti convenzioni tipografiche:
Grassetto
v Comandi scritti in minuscolo e con caratteri misti difficilmente
distinguibili dal resto del testo
Informazioni sul manuale xvii
v Controlli dell’interfaccia (caselle di spunta, pulsanti, pulsanti di scelta,
campi, cartelle, icone, caselle di elenco, contenitori, scelte di menu, nomi
di menu, separatori e così via), etichette (ad esempio Suggerimento:, e
Considerazioni del sistema operativo:)
v Parole chiave e parametri nel testo
Corsivo
v Parole definite nel testo
v Enfasi delle parole
v Nuovi termini nel testo (eccetto in un elenco di definizioni)
v Variabili e valori da fornire
Monospace
v Esempi di codici
v Nomi file, parole chiave di programmazione e altri elementi difficili da
distinguere dal resto del testo
v Testo dei messaggi e richieste indirizzate all’utente
v Testo che l’utente deve immettere
v Valori per gli argomenti o le opzioni dei comandi
Variabili e percorsi specifici del sistema operativo
Questo manuale utilizza la convenzione UNIX per specificare le variabili di
ambiente e per la notazione della directory.
Quando si utilizza la riga comandi Windows, sostituire $variable con %variable%
per le variabili d’ambiente e sostituire ogni barra (/) con una barra retroversa (\)
nei percorsi delle directory. I nomi delle variabili di ambiente non sono sempre gli
stessi in Windows e UNIX. Ad esempio, %TEMP% in Windows corrisponde a $tmp
in UNIX.
Nota: Se si utilizza la shell bash in un sistema Windows, è possibile utilizzare le
convenzioni UNIX.
Sintassi dei comandi
Questa guida utilizza la seguente sintassi quando descrive i comandi:
Tabella 1. Sintassi comando
Convenzione di
sintassi
Descrizione
Parentesi quadre
([ ])
L’informazione racchiusa tra parentesi ([ ]) è facoltativa. Tutto ciò che
non è racchiuso tra parentesi deve essere specificato.
Parentesi graffe ({
})
Le parentesi graffe ({ }) identificano una serie di opzioni che si
escludono reciprocamente quando viene richiesta un’opzione.
Sottolineatura ( _
)
Un segno di sottolineatura (_) collega più parole in una variabile.
Barra verticale ( |
)
Le opzioni che si escludono reciprocamente sono separate da una barra
verticale ( | ). È possibile immettere una delle opzioni separate dalla
barra verticale, ma non è possibile immettere più opzioni quando si
utilizza il comando una sola volta. La barra verticale può essere
utilizzata per separare le opzioni obbligatorie e facoltative.
xviii IBM Tivoli Workload Scheduler - Manuale di riferimento
Tabella 1. Sintassi comando (Continua)
Convenzione di
sintassi
Descrizione
Grassetto Il testo in grassetto indica le informazioni letterali che devono essere
immesse sulla riga comandi esattamente come riportato. Si applica ai
nomi dei comandi e alle opzioni non variabili.
Corsivo Il testo in corsivo è variabile e deve essere sostituito da qualunque cosa
lo rappresenti.
Informazioni sul manuale xix
Capitolo 1. Inizio rapido
Il prodotto IBM Tivoli Workload Scheduler fornisce la possibilità di gestire
l’ambiente di produzione e automatizzare molte attività dell’operatore. IBM Tivoli
Workload Scheduler consente di preparare i lavori per l’esecuzione, risolvere le
interdipendenze, avviare e controllare l’andamento di ciascun lavoro. Poiché i
lavori iniziano una volta soddisfatte le relative dipendenze, vengono ridotti i tempi
di inattività ottimizzando positivamente le prestazioni. I lavori non vengono mai
eseguiti fuori sequenza, e, se un lavoro non ha esito positivo, IBM Tivoli Workload
Scheduler gestisce il processo di recupero con un intervento minimo o addirittura
nullo dell’operatore.
La sezione “Creazione di un piano” a pagina 2 fornisce all’utente un percorso
guidato costituito da informazioni e operazioni di base necessarie per
implementare IBM Tivoli Workload Scheduler nel proprio ambiente, utilizzando
l’interfaccia CLI. Per eseguire le stesse attività, è anche possibile utilizzare Job
Scheduling Console. Per ulteriori informazioni, consultare il manuale Guida per
l’utente di Job Scheduling Console.
Esistono due concetti di base per eseguire la pianificazione dei lavori con IBM
Tivoli Workload Scheduler:
database
Risiede su Gestore dominio master e contiene tutte le definizioni per gli
oggetti di pianificazione, quali i lavori, i flussi di lavoro, le risorse e le
workstation. Contiene inoltre le statistiche sull’esecuzione dei lavori e dei
flussi di lavoro, le informazioni sull’ID utente che ha creato un oggetto e la
data dell’ultima modifica dell’oggetto. Il programma utilizzato per gestire
gli oggetti nel database è composer. Per ulteriori informazioni, consultare il
Capitolo 3, “Riferimento al Composer”, a pagina 35.
piano Il piano contiene tutte le attività di pianificazione dei lavori impostate per
un giorno. In IBM Tivoli Workload Scheduler, il piano viene creato su
Gestore dominio master ogni 24 ore ed è costituito da tutti i lavori, i flussi
di lavoro e gli oggetti dipendenza che vengono pianificati per essere
eseguiti in tale giorno. Alla fine del giorno di produzione, i flussi di lavoro
non completati correttamente, ancora in esecuzione o in attesa di
esecuzione possono essere proseguiti e inseriti nel piano del giorno
successivo. Per ulteriori informazioni sulle modalità di creazione del piano,
consultare il Capitolo 2, “Ciclo di produzione”, a pagina 9. Il programma
utilizzato per interagire con il piano durante il giorno di elaborazione
corrente è conman. Per ulteriori informazioni, consultare il Capitolo 5,
“Riferimento a Conman”, a pagina 123.
Una volta installato l’ambiente di pianificazione seguendo le istruzioni riportate nel
manuale IBM Tivoli Workload Scheduler Planning and Installation Guide, è possibile
creare un piano da eseguire giornalmente con le informazioni necessarie a seconda
del proprio ambiente. Per ulteriori informazioni, consultare la sezione “Creazione
di un piano” a pagina 2.
© Copyright IBM Corp. 1999, 2004 1
Creazione di un piano
Per creare un piano da eseguire giornalmente, completare i seguenti passi:
1.
Collegamento a una shell su Gestore dominio master
Collegarsi a una shell utilizzando l’ID specificato durante
l’installazione ed eseguire tutte le operazioni descritte nei passi
riportati di seguito. 2.
Avvio dei processi IBM Tivoli Workload Scheduler
Eseguire questo passo dalla riga comandi dell’utente immettendo il
comando Startup per avviare il processo di gestione della rete dello
scheduler. Per ulteriori informazioni sul comando Startup, consultare
“StartUp” a pagina 265. 3.
Aggiunta delle definizioni al database per descrivere la topologia del
proprio ambiente di pianificazione
Questo passo può essere suddiviso nel seguente modo:
a.
Definizione delle workstation nel proprio ambiente
Di solito, una workstation è una macchina fisica su cui
vengono eseguiti i lavori e i flussi di lavoro, tuttavia, nel
caso degli agent estesi (XA), le workstation sono
definizioni logiche che devono essere ospitate da una
workstation fisica. Definire una workstation per ciascuna
macchina appartenente all’ambiente di pianificazione ad
eccezione di Gestore dominio master, che viene definito
automaticamente durante l’installazione di IBM Tivoli
Workload Scheduler. Per ulteriori informazioni, consultare
il “Definizioni delle workstation” a pagina 37.b.
Definizione dei domini
Utilizzare questo passo se si desidera creare un albero
gerarchico del percorso che attraversa i domini. IBM Tivoli
Workload Scheduler scorre questo albero verso il basso,
durante la distribuzione del piano all’inizio del giorno di
produzione, e verso l’alto quando vengono inviate a
Gestore dominio master le informazioni sui lavori e sui
flussi di lavoro eseguiti sulle workstation di destinazione.
Per ulteriori informazioni, consultare “Definizioni
dominio” a pagina 44. 4.
Definizione degli utenti autorizzati ad eseguire i lavori sulle workstation
Windows
Solo sulle workstation Windows, definire gli utenti autorizzati ad
eseguire i lavori specificando il nome utente e la password. Per
ulteriori informazioni, consultare “Definizioni utente” a pagina 52. 5.
Definizione delle dipendenze
Le dipendenze sono condizioni da soddisfare prima dell’avvio di un
lavoro. Possono essere definite per il flusso di lavoro, per un lavoro
2 IBM Tivoli Workload Scheduler - Manuale di riferimento
all’interno del flusso o per entrambi. Il numero massimo di
dipendenze consentite per un lavoro o flusso di lavoro è 40. Per
ulteriori informazioni, consultare Capitolo 4, “Linguaggio di
pianificazione”, a pagina 87. Di seguito sono riportate alcune delle
dipendenze che è possibile impostare:
a.
Dipendenze Ora
Impostare una dipendenza Ora per specificare l’ora di
inizio e fine in base alla quale un lavoro o un flusso di
lavoro deve essere avviato o completato. È inoltre possibile
indicare i giorni in cui il flusso di lavoro non deve essere
eseguito. Per ulteriori informazioni, consultare “Parole
chiave” a pagina 88.b.
Dipendenze File aperto
Utilizzare le dipendenze File aperto per specificare i file
che devono essere disponibili prima dell’avvio di un
lavoro o di un flusso di lavoro. Per ulteriori informazioni,
consultare “opens” a pagina 115.c.
Dipendenze Follow
Impostare una dipendenza Follow per definire gli altri
lavori o flussi di lavoro che devono essere completati
correttamente prima dell’avvio di un nuovo lavoro o flusso
di lavoro. Per ulteriori informazioni, consultare “follows” a
pagina 100.d.
Risorse
Utilizzare le risorse per specificare gli oggetti fisici o logici
appartenenti a una workstation richiesti per eseguire un
lavoro su questa workstation. Poiché la disponibilità delle
risorse viene controllata prima di eseguire i lavori su una
determinata workstation, è possibile utilizzare le risorse
come dipendenze per semplificare la gestione dei lavori e
dei flussi di lavoro. Ad esempio, è possibile definire una
risorsa TAPES assegnandole il valore 2, che identifica le
due unità nastro del sistema, e definire i lavori che
richiedono quelle stesse unità nastro come dipendenza. I
lavori con questa dipendenza non possono essere eseguiti
contemporaneamente, perché ogni volta che un lavoro
viene eseguito, viene utilizzata la risorsa TAPES. Per
ulteriori informazioni, consultare “Definizioni risorsa” a
pagina 59.e.
Prompt
Utilizzare un prompt quando si desidera associare un
nome univoco a un messaggio di testo che richiede una
risposta da un operatore. I prompt vengono utilizzati come
dipendenze per impedire ai lavori di iniziare fin quando
non ricevono una risposta affermativa. Per ulteriori
informazioni, consultare “Definizioni prompt” a pagina 57.f.
Capitolo 1. Inizio rapido 3
Limite Impostare il limite per indicare il numero di lavori che
possono essere eseguiti contemporaneamente in un flusso
di lavoro. Per ulteriori informazioni, consultare il “limit” a
pagina 110.g.
Priorità
Utilizzare questa dipendenza per impostare la priorità di
un lavoro o di un flusso di lavoro. Per ulteriori
informazioni, consultare “priority” a pagina 117. 6.
Definizione dei lavori
Un lavoro è un’operazione che viene eseguita sulle workstation, ad
esempio un file eseguibile, un programma o un comando pianificato e
avviato da IBM Tivoli Workload Scheduler come parte
dell’elaborazione di un flusso di lavoro. Generalmente include tutti i
programmi di computer, i collegamenti, i file e le istruzioni necessari
per il sistema operativo. Non include date e orari pianificati per
l’esecuzione, perché questi vengono definiti come argomenti della
definizione dei flussi di lavoro. Per ulteriori informazioni, consultare
“Definizioni lavoro” a pagina 46. 7.
Definizione dei flussi di lavoro
Un flusso di lavoro è una sequenza ordinata di lavori da eseguire
rispettando le dipendenze impostate. I lavori possono essere
raggruppati in un flusso se vengono eseguiti tutti nello stesso giorno o
se condividono una funzione comune o le stesse dipendenze. Per
ulteriori informazioni, consultare Capitolo 4, “Linguaggio di
pianificazione”, a pagina 87. 8.
Definizione dei calendari
Un calendario indica i giorni in cui eseguire i lavori. Utilizzarlo per
includere o escludere i giorni in un ciclo di esecuzione giornaliero.
Questa definizione può essere assegnata a uno o più flussi di lavoro.
Per ulteriori informazioni, consultare “Definizioni calendario” a
pagina 54. 9.
Definizione dei parametri che rappresentano le variabili nei lavori e nei
flussi di lavoro
Una definizione parametro indica un’associazione tra un nome e un
valore, questo valore è quello di una variabile utilizzata in un lavoro o
in un flusso di lavoro per un argomento specifico. I nomi dei
parametri vengono sostituiti con i valori corrispondenti nelle
definizioni del lavoro e del flusso di lavoro alla fine di un giorno di
elaborazione, quando viene creato il piano di produzione per il giorno
successivo. Per ulteriori informazioni, consultare “Definizioni
parametro” a pagina 55.10.
Creazione automatica del piano alla fine del giorno di produzione corrente
Aggiungere il flusso di lavoro finale al database per eseguire
l’elaborazione di pre e postproduzione in modo da assicurarsi la
4 IBM Tivoli Workload Scheduler - Manuale di riferimento
creazione automatica del piano alla fine di ciascun giorno di
produzione. Per ulteriori informazioni, consultare “Automazione del
ciclo di produzione” a pagina 15.11.
Generazione del piano
Eseguire il comando Jnextday per creare il piano. Questo comando
avvia l’elaborazione delle informazioni sulla pianificazione
memorizzate nel database e crea il piano per il giorno di produzione
successivo. Se si automatizza la creazione del piano come descritto nel
passo 10, basterà soltanto eseguire il comando Jnextday.
Questo piano viene memorizzato in un file denominato Symphony che
viene distribuito da Gestore dominio master ai domini secondari
all’ora di avvio impostata per il giorno (per default, alle 6:00 AM).
Una volta avviato il nuovo giorno di produzione, le modifiche
apportate agli oggetti memorizzati nel database non avranno effetto
sull’elaborazione del giorno di produzione corrente, ad eccezione dei
lavori e dei flussi di lavoro o dei file inoltrati utilizzando conman sbj o
conman sbs. Per ulteriori informazioni, consultare Capitolo 2, “Ciclo di
produzione”, a pagina 9.
Una volta completati questi passi, il proprio ambiente di pianificazione è pronto ad
eseguire l’elaborazione batch di una sequenza ordinata di lavori e flussi di lavoro
in base alle risorse definite su una serie di workstation. Per impostazione
predefinita, la prima volta che si esegue il comando Jnextday, il numero di lavori
che possono essere elaborati contemporaneamente su una workstation è zero,
pertanto aumentare questo valore modificando il limite cpu in modo da consentire
l’esecuzione dei lavori su questa workstation; per ulteriori dettagli, consultare
“limit cpu” a pagina 166. Questa elaborazione batch si basa su un ciclo di 24 ore e
viene generata di nuovo alla fine di ciascun giorno di produzione da Gestore
dominio master.
Gestione dei lavori e dei flussi di lavoro
Se si desidera apportare delle modifiche mentre il piano del giorno di produzione
è in esecuzione, utilizzare il programma conman. È possibile definire o modificare
un lavoro e aggiungerlo al piano utilizzando il comando conman sbj, solo se il
lavoro verrà eseguito su una workstation che ha già ricevuto il piano. Fare
riferimento al Capitolo 5, “Riferimento a Conman”, a pagina 123 per ulteriori
dettagli sul programma conman. Di seguito sono riportate le azioni che è possibile
eseguire con il comando conman:
Aggiungere o eliminare le dipendenze
Utilizzare questo comando per eliminare o aggiungere le dipendenze a un
flusso di lavoro o a un lavoro in un flusso. Per ulteriori informazioni
sull’aggiunta delle dipendenze, consultare “Elaborazione del comando
Conman” a pagina 143, mentre per la loro eliminazione fare riferimento a
“lavoro deldep” a pagina 157.
Modificare il limite
Eseguire questa operazione per modificare il limite del numero di lavori
che possono essere eseguiti contemporaneamente su una workstation o il
limite di lavori per un flusso di lavoro. Per ulteriori informazioni,
consultare “limit cpu” a pagina 166.
Capitolo 1. Inizio rapido 5
Modificare la priorità
Utilizzare questa opzione per modificare la priorità per un lavoro o un
flusso di lavoro. Per ulteriori informazioni, consultare “altpri” a pagina
149.
Modificare il delimitatore
Il delimitatore è un valore che può essere impostato sulle workstation.
Impostare il delimitatore dei lavori su una workstation per impedire che i
lavori con una priorità inferiore o uguale al valore impostato per il
delimitatore vengano eseguiti su questa workstation. Per ulteriori
informazioni, consultare “fence” a pagina 163.
Rilasciare un lavoro o un flusso di lavoro
Eseguire questa operazione per rilasciare alcune o tutte le dipendenze da
un lavoro o flusso di lavoro. Per ulteriori informazioni, consultare “release
job” a pagina 174.
Annullare un lavoro o un flusso di lavoro
Eseguire questa operazione se si desidera annullare un lavoro o un flusso
di lavoro immediatamente o dopo aver risolto le dipendenze. Per ulteriori
informazioni, consultare “cancel job” a pagina 150.
Arrestare l’esecuzione del lavoro o ripetere un lavoro
Eseguire questa operazione se si desidera arrestare l’esecuzione del lavoro
utilizzando il comando kill. Per ulteriori informazioni fare riferimento a
“kill” a pagina 165. Utilizzare il comando rerun job per eseguire
nuovamente il lavoro. Per ulteriori informazioni fare riferimento a “rerun”
a pagina 179.
Nota: Un lavoro eseguito nuovamente viene inserito nello stesso flusso di
lavoro del lavoro originale ed eredita le dipendenze del lavoro
originale.
Collegare o scollegare le workstation nel proprio ambiente di pianificazione
Eseguire questa operazione per collegare o scollegare una workstation dalla
rete di pianificazione. IBM Tivoli Workload Scheduler utilizza una
tecnologia per garantire la coerenza dei dati e la tolleranza all’errore sulla
rete che, quando ci si scollega da una workstation, consente di
memorizzare tutti i messaggi nel file dei messaggi e di inviarli appena
viene stabilito di nuovo il collegamento. Questo comando non influisce
sugli altri processi in esecuzione sul sistema. Per ulteriori informazioni sul
collegamento delle workstation, consultare “link” a pagina 168 e, per lo
scollegamento, “unlink” a pagina 224.
Arrestare, avviare o chiudere i processi IBM Tivoli Workload Scheduler
Eseguire questa operazione per agire sui processi di produzione, ad
esempio sui processi IBM Tivoli Workload Scheduler, ad eccezione del
processo di gestione della rete. La chiusura dell’operazione arresta tutti i
processi IBM Tivoli Workload Scheduler, incluso il processo di gestione
della rete. Per ulteriori informazioni, consultare “stop” a pagina 210,
“avvio” a pagina 207 e “shutdown” a pagina 206.
Inoltrare un comando
Eseguire questa operazione per inoltrare un comando su una workstation
come un lavoro dello scheduler. Se non si specifica il nome lavoro nelle
opzioni di inoltro, viene utilizzata una stringa che inizia con il nome del
comando, mentre per il flusso di lavoro viene utilizzato JOBS. Gli eventi
che riportano il risultato dell’esecuzione vengono registrati nel database.
Per ulteriori informazioni, consultare “submit docommand” a pagina 213.
6 IBM Tivoli Workload Scheduler - Manuale di riferimento
Inoltrare un lavoro
Eseguire questa operazione per inoltrare il comando di esecuzione di un
lavoro definito nel database all’interno di un flusso di lavoro durante il
giorno di produzione corrente su una workstation che ha ricevuto il piano.
Se non si specifica un flusso di lavoro nelle opzioni di inoltro, viene
utilizzato JOBS. Questo comando può essere eseguito solo su Gestore
dominio master. Gli eventi che riportano il risultato dell’esecuzione
vengono registrati nel database. Per ulteriori informazioni, consultare
“submit job” a pagina 217.
Inoltrare un flusso di lavoro
Eseguire questa operazione per inoltrare il comando di esecuzione di un
flusso di lavoro definito nel database durante il giorno di produzione
corrente su una workstation che ha ricevuto il piano. Questo comando può
essere eseguito solo su Gestore dominio master. Gli eventi che riportano il
risultato dell’esecuzione vengono registrati nel database. Per ulteriori
informazioni, consultare “submit sched” a pagina 219.
Inoltrare un file
Eseguire questa operazione per inoltrare un file script come un lavoro
all’interno di un flusso di lavoro durante il giorno di produzione corrente
su una workstation che ha ricevuto il piano. Se non si specifica il nome
lavoro nelle opzioni di inoltro, viene utilizzato il nome del file, mentre per
il flusso di lavoro viene utilizzato JOBS. Gli eventi che riportano il risultato
dell’esecuzione vengono registrati nel database. Per ulteriori informazioni,
consultare “submit file” a pagina 215.
Capitolo 1. Inizio rapido 7
Capitolo 2. Ciclo di produzione
Il piano di IBM Tivoli Workload Scheduler è un elenco attività che indica i lavori
da eseguire e le dipendenze da soddisfare prima di avviare ciascun lavoro. Il piano
copre un periodo di 24 ore. Questo periodo viene indicato come giorno di
produzione. Il piano inizia all’ora definita dall’opzione globale start, impostata per
default su 6:00.
Un nuovo piano viene creato all’inizio del giorno di produzione e posizionato in
un file di controllo della produzione denominato Symphony. Dopo aver creato il
piano, una copia di questo file viene inviata a tutte le workstation secondarie. I
gestori dominio dipendenti distribuiscono la loro copia a tutti gli FTA, ai relativi
domini e a tutti i gestori dominio ad essi subordinati. Ciò consente agli FTA (Fault
Tolerant Agent) sulla rete di continuare l’elaborazione anche se la connessione di
rete ai relativi gestori dominio non è attiva.
In ogni FTA di destinazione, i processi di IBM Tivoli Workload Scheduler accedono
alla copia del file Symphony, leggono le istruzioni sull’elaborazione dei lavori e
indicano al sistema operativo di avviare i lavori richiesti. Il sistema operativo
esegue il lavoro e notifica l’esito dell’esecuzione a IBM Tivoli Workload Scheduler.
Queste informazioni vengono memorizzate nel file Symphony per indicare lo stato
del lavoro. In questo modo, il file Symphony viene continuamente aggiornato sullo
stato dei lavori: il lavoro da eseguire, il lavoro in corso e il lavoro completato. Se
FTA non è in modalità Stato completo, può controllare solo l’elaborazione dei
propri lavori. Se è in modalità Stato completo, può controllare anche l’elaborazione
del relativo dominio e dei domini secondari.
Ogni FTA riceve lo stesso file Symphony e aggiorna le parti del file a cui è
correlato, mentre il gestore dominio master (e il relativo backup) dispone di una
copia del file Symphony contenente questi aggiornamenti.
Per passare al giorno successivo, viene eseguita l’impostazione di preproduzione
per il nuovo giorno e il collegamento e la registrazione di post-produzione per il
giorno appena terminato. Questo capitolo descrive le procedure e i comandi che
vengono utilizzati per eseguire tali attività.
Processi e interfacce principali del prodotto
Questa sezione descrive le interfacce principali e i processi utilizzati da IBM Tivoli
Workload Scheduler.
Interfacce utente
Viene fornita una combinazione di interfacce GUI e CLI per eseguire IBM Tivoli
Workload Scheduler. CLI consente di eseguire alcune funzioni avanzate non
disponibili nella GUI (Job Scheduling Console). Le interfacce utente sono:
Composer
Un programma della riga comandi utilizzato per definire gli oggetti di
pianificazione e stabilire le pianificazioni.
Conman
Un programma della riga comandi utilizzato per controllare l’ambiente di
produzione di IBM Tivoli Workload Scheduler.
© Copyright IBM Corp. 1999, 2004 9
Job Scheduling Console
Un’interfaccia grafica interattiva utilizzata per creare, modificare ed
eliminare gli oggetti nel database del prodotto e nel piano.
Comandi di preproduzione e postproduzione
I comandi riportati di seguito vengono utilizzati per impostare il giorno di
produzione di IBM Tivoli Workload Scheduler. Per automatizzare il processo, i
comandi vengono organizzati normalmente in una pianificazione che viene
eseguita all’inizio di ogni giorno.
schedulr
Il comando che seleziona le pianificazioni per l’esecuzione.
compiler
Il comando che compila il file di controllo della produzione.
stageman
Il comando che riporta le pianificazioni non completate e installa il file di
controllo della produzione.
logman
Il comando che registra le statistiche sui lavori.
Comandi di sicurezza
I comandi riportati di seguito vengono utilizzati per definire e mantenere i
privilegi dell’utente.
dumpsec
Il comando che crea una copia modificabile del file di sicurezza del
prodotto.
makesec
Il comando che compila e installa il file di sicurezza del prodotto.
Processi di produzione
Di seguito sono riportati i processi di produzione di IBM Tivoli Workload
Scheduler:
Netman
Il processo che riceve le richieste di servizio e richiama i programmi
appropriati.
Mailman
Il processo che instrada i messaggi alle workstation locali o remote.
Batchman
Il processo che comunica direttamente con il piano e lo aggiorna.
Jobman (Windows e UNIX), Jobmon (Windows), joblnch.exe (Windows)
I processi che controllano l’esecuzione dei lavori. Sono responsabili
dell’avvio e dell’andamento dei lavori che utilizzano gli script jobmanrc e
.jobmanrc. Per informazioni su questi script, consultare “Avvio dei lavori”
a pagina 18.
Writer Il processo, generato da Netman, che stabilisce il collegamento tra le
workstation nella rete di IBM Tivoli Workload Scheduler.
10 IBM Tivoli Workload Scheduler - Manuale di riferimento
Struttura ad albero dei processi sulle piattaforme UNIX
La Figura 1 mostra la struttura ad albero dei processi di IBM Tivoli Workload
Scheduler sulle piattaforme UNIX:
Capitolo 2. Ciclo di produzione 11
netman
mailman
batchman
jobman
jobmanrc jobmanrcjobmanrc
.jobmanrc .jobmanrc .jobmanrc
job file job filejob file
job monitor
writer
serverA(mailman)
job monitor job monitor(jobman)(jobman)(jobman)
Figura 1. Struttura ad albero dei processi su UNIX
12 IBM Tivoli Workload Scheduler - Manuale di riferimento
Struttura ad albero dei processi sulle piattaforme Windows
La Figura 2 mostra la struttura ad albero dei processi di IBM Tivoli Workload
Scheduler sulle piattaforme Windows:
Capitolo 2. Ciclo di produzione 13
netman
mailman
batchman
jobman
job file job filejob file
writer
serverA(mailman.exe)
.exe
.exe
.exe
.exe
.exe
jobmon.exe
joblnch.exe joblnch.exe joblnch.exe
jobmanrc.cmd jobmanrc.cmd jobmanrc.cmd
Figura 2. Struttura ad albero dei processi su Windows
14 IBM Tivoli Workload Scheduler - Manuale di riferimento
Automazione del ciclo di produzione
L’elaborazione di preproduzione e postproduzione può essere completamente
automatizzata aggiungendo al database il flusso di lavoro finale fornito dal
prodotto oppure uno equivalente fornito dall’utente. Una copia del flusso di lavoro
fornito si trova nel file Sfinal, e precisamente nella directory TWShome/Sfinal. Una
copia dello script di lavoro si trova nella directory TWShome/Jnextday. E’ possibile
trovarlo utile per stampare le copie che aiutano a capire il processo di rotazione.
Il flusso di lavoro finale viene messo in produzione ogni giorno e risulta
nell’esecuzione di un lavoro denominato Jnextday prima dell’inizio di un nuovo
giorno. Il lavoro esegue le attività riportate di seguito:
1. Esegue il comando schedulr per selezionare i flussi di lavoro per il piano di
produzione del nuovo giorno. Per ulteriori informazioni, consultare “Comando
schedulr” a pagina 23.
2. Esegue il comando compiler per compilare il piano di produzione. Per ulteriori
informazioni, consultare “Comando compiler” a pagina 25.
3. Esegue il comando reptr per stampare i report di preproduzione. Per ulteriori
informazioni, consultare “Comando reptr” a pagina 283.
4. Arresta lo scheduler.
5. Esegue il comando stageman per proseguire i flussi di lavoro non completi,
registrare il vecchio piano di produzione e installare il nuovo. Per ulteriori
informazioni, consultare “Comando stageman” a pagina 27.
6. Esegue il comando wmaeutil per arrestare tutte le istanze del connettore e
riavviarle per aggiornare il file symphony. Per ulteriori informazioni, consultare
“Comando wmaeutil” a pagina 32.
7. Avvia lo scheduler per il nuovo giorno.
8. Esegue il comando reptr per stampare i report di postproduzione per il giorno
precedente. Per ulteriori informazioni, consultare “Comando reptr” a pagina
283.
9. Esegue il comando logman per registrare le statistiche sul lavoro per il giorno
precedente. Per ulteriori informazioni, consultare “Comando logman” a pagina
30.
Personalizzazione del flusso di lavoro finale
Prima di utilizzare il flusso di lavoro finale, è possibile modificarlo per adattarlo
alle proprie necessità oppure crearne uno differente.
Quando si crea il proprio flusso di lavoro, adattarlo in base a quello fornito con il
prodotto. Se si decide di effettuare questa operazione, tenere presente quanto
segue:
v Se si desidera modificare il modo in cui stageman crea i nomi dei file di log,
tener presente che reptr e logman devono utilizzare gli stessi nomi.
v Se si desidera stampare i report di preproduzione prima di un nuovo giorno, è
possibile suddividere il lavoro Jnextday in due lavori. Il primo lavoro eseguirà
schedulr, compiler e reptr. Il secondo lavoro arresta lo scheduler, esegue
stageman, avvia lo scheduler ed esegue reptr e logman. Il primo lavoro può
essere pianificato per essere eseguito in qualsiasi ora prima della fine del giorno,
mentre il secondo lavoro viene pianificato per essere eseguito poco prima della
fine del giorno.
Capitolo 2. Ciclo di produzione 15
Aggiunta del flusso di lavoro finale
Una volta installato un gestore dominio master, indipendentemente dal metodo di
installazione utilizzato, è necessario aggiungere il flusso di lavoro finale al database
ed eseguire Jnextday. Il flusso di lavoro viene messo in produzione ogni giorno e
determina l’esecuzione di un lavoro definito Jnextday prima dell’inizio di un
nuovo giorno. L’installazione crea un file Sfinal sulla workstation contenente la
definizione di flusso di lavoro finale. È possibile utilizzare il file Sfinal o crearne e
personalizzarne uno nuovo. Per informazioni sulla personalizzazione dei flussi di
lavoro finali, consultare il manuale IBM Tivoli Workload Scheduler - Guida alla
pianificazione e all’installazione, versione 8.2.
Quanto segue è un esempio di configurazione di gestore dominio master dopo
l’installazione:
1. Collegarsi come Utente TWS.
2. Eseguire lo script tws_env per impostare l’ambiente IBM Tivoli Workload
Scheduler come segue:
v UNIX: sulle shell C avviare source/tws_home/tws_env.sh
v UNIX: sulle shell Korn avviare ./tws_home/tws_env.sh
v Da una riga comandi di Windows immettere \tws_home\tws_env.cmd
Dove tws_home rappresenta la directory di installazione del prodotto.
3. Eseguire il comando composer.
4. Aggiungere la definizione di flusso di lavoro finale al database eseguendo il
comando:
composer add Sfinal
Se non è stato utilizzato il file Sfinal con il prodotto, ma ne è stato creato uno
nuovo, utilizzare il nome di questo file invece di Sfinal.
Avvio di un ciclo di produzione
Per avviare un ciclo di produzione, completare i seguenti passi:
1. Collegarsi come utente TWS al gestore dominio master.
2. Alla richiesta comandi, eseguire il lavoro Jnextday immettendo il seguente
comando:
Jnextday
In questo modo si esegue l’elaborazione di preproduzione e si avviano i
processi di produzione dello scheduler.
Nota: Non aggiornare o creare il database Tivoli Workload Scheduler mentre è
in esecuzione Jnextday per evitare il rischio di danneggiare il database.
3. Quando il lavoro Jnextday viene completato, verificare lo stato di IBM Tivoli
Workload Scheduler:
conman status
Se IBM Tivoli Workload Scheduler è stato avviato correttamente, lo stato è
Batchman=LIVES.
4. Aumentare il limite per consentire l’esecuzione dei lavori. Il limite di lavori
predefinito dopo l’installazione è zero. Ciò indica che non verranno eseguiti i
lavori, quindi sarà necessario aumentare il limite:
conman "limit;10"
16 IBM Tivoli Workload Scheduler - Manuale di riferimento
Gestione dell’ambiente di produzione
Questa sezione fornisce informazioni sulla modifica dell’avvio del giorno per IBM
Tivoli Workload Scheduler e sulla creazione di un piano per l’elaborazione dei
giorni futuri e passati.
Selezione dell’Avvio del giorno di IBM Tivoli Workload
Scheduler
Esistono tre opzioni comuni per l’avvio del giorno di produzione:
v Prima mattina
v Tardo pomeriggio
v Mezzanotte
Esistono poche implicazioni di pianificazione:
Ora di avvio e Ultima ora di avvio
Le ore di avvio (parola chiave at) vengono sempre specificate in relazione
con l’ora di avvio del giorno di produzione dello scheduler. Potrebbe
risultare necessario aggiungere “+ 1 giorno” ai flussi di lavoro i cui lavori
vengono eseguiti attraverso giorni di produzione. Inoltre, assicurarsi che
l’ultima ora di avvio (parola chiave until) sia successiva all’ora di avvio.
Parola chiave On
I giorni calendario e produzione potrebbero non essere gli stessi. Se il
giorno di produzione comincia alle 06:00 a.m. (l’impostazione di default),
05:59 a.m. sarà l’ultimo minuto del giorno di produzione. Un flusso di
lavoro che deve essere eseguito LUNEDI’ alle 05:30, verrà selezionato
Lunedì e verrà eseguito Martedì alle 5:30 a.m.
Parola chiave Carryforward
Se si posiziona l’avvio del giorno vicino alla mezzanotte in modo da
corrispondere al giorno del calendario ciò porterà alla produzione di un
gran numero di Flussi di lavoro rinviati. Ciò potrebbe aumentare la
complessità della gestione del centro dati.
Tempo limite
Le notifiche vengono inviate quando i lavori e i flussi di lavoro hanno
raggiunto il tempo limite, ma non sono stati ancora avviati o non sono stati
ancora completati. Un daedline specifica l’ora entro la quale un lavoro o un
flusso di lavoro deve essere completato.
Modifica dell’avvio del giorno
L’avvio del giorno per IBM Tivoli Workload Scheduler si riferisce al momento in
cui viene eseguito il flusso di lavoro finale e i processi dello scheduler vengono
arrestati e riavviati. Per specificare l’avvio del giorno per lo scheduler:
1. Modificare l’opzione start nel file globalopts. Questa è l’ora di avvio del giorno
di elaborazione in formato 24 ore: hhmm (0000-2359). L’ora di avvio predefinita
è 6:00 a.m.
2. Modificare l’ora di avvio (parola chiave at) del flusso di lavoro finale in modo
che venga eseguito un minuto prima della fine del giorno.
Creazione di un piano per date passate e future
E’ possibile creare un piano che esegua l’elaborazione normalmente pianificata per
un giorno passato o futuro. Questa procedura ricrea realmente tutti i giorni di
Capitolo 2. Ciclo di produzione 17
elaborazione specificati. Se, a causa di un’emergenza, viene perso un giorno di
elaborazione, potrebbe essere necessario utilizzare questa procedura.
1. Scollegare e arrestare tutte le workstation nella propria rete dello scheduler.
Questa procedura arresta tutte le elaborazioni nella rete.
2. Eseguire il comando schedulr con l’opzione della data per creare un file
prodsked:
schedulr -date ddmmyyyy
Con l’opzione data è possibile specificare di creare un piano basato su un
giorno di elaborazione futuro o passato.
3. Eseguire il comando compiler per creare un file Symnew:
compiler (-date ddmmyyyy)
E’ possibile utilizzare l’opzione data con il compiler per specificare la data
odierna o la data del giorno in cui si tenta di effettuare la nuova creazione.
Questa opzione potrebbe risultare necessaria se ci sono flussi di lavoro che
contengono parametri di input sensibili alla data. Il parametro scheddate ha
eliminato la data specificata con il comando compiler.
4. Eseguire il gestore console per arrestare i processi dello scheduler:
conman stop @!@;wait
Se è stata definita almeno una workstation come behindfirewall in una rete IBM
Tivoli Workload Scheduler Versione 8.2, è necessario immettere il seguente
comando:
conman stop ;progressive
5. Eseguire stageman per creare il nuovo file Symphony:
stageman
6. Eseguire il gestore console per avviare i processi dello scheduler:
conman start
Utilizzo dei report
Utilizzare i report che sono utili per gestire il ciclo di produzione. Per ulteriori
informazioni, consultare Capitolo 7, “Comandi report”, a pagina 277 e “Comando
reptr” a pagina 283.
Avvio dei lavori
I lavori vengono avviati sotto la direzione del processo di controllo della
produzione Batchman. Batchman risolve tutte le dipendenze dei lavori per
garantire l’ordine corretto di esecuzione e invia un messaggio di avvio lavoro al
processo Jobman.
Jobman genera un processo di controllo dei lavori che inizia impostando un
gruppo di variabili di ambiente per poi eseguire lo script di configurazione
standard (tws_home/jobmanrc). Se l’utente è autorizzato ad utilizzare uno script di
configurazione locale e lo script esiste come $HOME/.jobmanrc, viene eseguito
anche lo script di configurazione locale. Il lavoro potrà quindi essere eseguito dallo
script di configurazione standard o da uno locale.
Ogni processo avviato da Jobman, inclusi gli script di configurazione e i lavori,
assume il nome utente registrato con il logon del flusso di lavoro. In caso di lavori
inoltrati, questi assumono il nome dell’utente che li ha inoltrati. Per eseguire i
lavori con l’ambiente dell’utente, aggiungere l’ambiente .profile dell’utente allo
script di configurazione locale.
18 IBM Tivoli Workload Scheduler - Manuale di riferimento
Variabili di ambiente del lavoro
Le variabili elencate nella tabella riportata di seguito vengono impostate ed
esportate da Jobman.
Tabella 2. Variabili di ambiente del lavoro
Nome variabile Valore
HOME La directory del nome dell’utente di login.
LOGNAME Il nome dell’utente di login.
PATH Per Windows: %SYSTEMROOT\SYSTEM32.
Per UNIX: /bin:/usr/bin
TZ Il fuso orario.
UNISON_SHELL La shell di login dell’utente.
UNISON_CPU Il nome di questa CPU.
UNISON_HOST Il nome della CPU master/host.
UNISON_JOB Il nome del lavoro completo: cpu#sched.job
UNISON_JOBNUM Il numero del lavoro (ppid).
UNISON_MASTER Il nome della CPU master.
UNISON_RUN Il numero di esecuzione della produzione
corrente di Tivoli Workload Scheduler.
UNISON_SCHED Il nome della pianificazione.
UNISON_SCHED_DATE La data di produzione di Tivoli Workload
Scheduler (yymmdd).
UNISON_SCHED_EPOCH La data di produzione di Tivoli Workload
Scheduler, espressa in formato EPOCH.
UNISON_SYM Il numero del record Symphony.
UNISON_EXEC_PATH Il percorso completo jobmanrc.
TIVOLI_JOB_DATE La data pianificata per un lavoro.
Script di configurazione standard - jobmanrc
Una maschera script di configurazione standard denominata
tws_home/config/jobmanrc viene fornita con IBM Tivoli Workload Scheduler. Viene
installata automaticamente come tws_home/jobmanrc. Questo script può essere
utilizzato dall’amministratore di sistema per stabilire un ambiente desiderato prima
dell’esecuzione di ogni lavoro. Se si desidera modificare lo script, apportare le
modifiche nella copia attiva (tws_home/jobmanrc), senza modificare il file di
maschera. Il file contiene variabili configurabili e commenti utili per comprendere
la metodologia. La Tabella 3 descrive le variabili jobmanrc.
Tabella 3. Variabili di jobmanrc
Nome variabile Valore
UNISON_JCL Il nome del percorso del file script del
lavoro.
UNISON_STDLIST Il nome del percorso del file di elenco
standard del lavoro.
Capitolo 2. Ciclo di produzione 19
Tabella 3. Variabili di jobmanrc (Continua)
Nome variabile Valore
UNISON_EXIT (Impostabile) Se impostato su yes, il lavoro
viene terminato immediatamente se qualsiasi
comando restituisce un codice di uscita
diverso da zero. Se impostato su no, il
lavoro continua l’esecuzione se un comando
restituisce un codice di uscita diverso da
zero. Qualsiasi altra impostazione viene
interpretata come no.
LOCAL_RC_OK (Impostabile) Se impostato su yes, viene
eseguito lo script di configurazione locale
dell’utente, inoltrando $UNISON_JCL come
primo argomento. All’utente potrebbe essere
consentita o negata questa opzione.
Consultare “Script di configurazione locale -
$HOME/.jobmanrc” a pagina 21 per
ulteriori informazioni. Se impostata su no, la
presenza di uno script di configurazione
locale viene ignorata e viene eseguito
$UNISON_JCL. Qualsiasi altra impostazione
viene interpretata come no.
MAIL_ON_ABEND (Impostabile) Se impostato su yes, viene
inviato un messaggio alla mailbox
dell’utente di login se il lavoro termina con
un codice di uscita non zero. Ciò può essere
inoltre impostato su uno o più nomi utente,
separati da spazi e un messaggio viene
inviato a ogni utente. Ad esempio, ″root mis
sam mary″. Se impostato su no, nessun
messaggio viene inviato se il lavoro termina
in modo anomalo. I messaggi che terminano
in modo anomalo hanno il seguente formato:
cpu#sched.job
jcl-file non riuscito con exit-code
Riesaminare standard-list-filename
SHELL_TYPE (Configurabile) Se impostato su standard, la
prima riga del file jcl viene letta per
determinare quale shell utilizzare per
eseguire il lavoro. Se la prima riga non inizia
con #!, viene utilizzato /bin/sh per eseguire
lo script di configurazione locale o
$UNISON_JCL. I comandi vengono emessi
sul file di elenco standard del lavoro. Se
impostato su utente, lo script di
configurazione locale o $UNISON_JCL viene
eseguito dalla shell di login dell’utente
($UNISON_SHELL). I comandi vengono
emessi sul file di elenco standard del lavoro.
Se impostato su script, lo script di
configurazione locale o $UNISON_JCL viene
eseguito direttamente e i comandi non
vengono emessi, a meno che lo script di
configurazione locale o $UNISON_JCL non
contenga un comando set -x. Qualsiasi altra
impostazione viene interpretata come
standard.
20 IBM Tivoli Workload Scheduler - Manuale di riferimento
Tabella 3. Variabili di jobmanrc (Continua)
Nome variabile Valore
USE_EXEC (Impostabile) Se impostato su yes, il lavoro
o lo script di configurazione locale
dell’utente viene eseguito utilizzando il
comando exec, quindi eliminando un
processo aggiuntivo. Questa opzione viene
sovrascritta se MAIL_ON_ABEND viene
impostato su yes. Qualsiasi altra
impostazione viene interpretata come no, nei
casi in cui il lavoro o lo script di
configurazione locale vengono eseguiti da
un altro processo shell.
Script di configurazione locale - $HOME/.jobmanrc
Lo script di configurazione locale consente agli utenti di stabilire un ambiente
desiderato per l’esecuzione dei propri lavori. Lo script può essere eseguito solo
rispettando le seguenti condizioni:
1. Lo script di configurazione standard, jobmanrc, deve essere installato e la
variabile di ambiente LOCAL_RC_OK deve essere impostata su yes (consultare
Tabella 3).
2. Se il file tws_home/localrc.allow esiste, il nome utente deve essere visualizzato
nel file. Se il file allow non esiste, il nome dell’utente non appare nel file,
tws_home/localrc.deny. Se nessuno di questi file esiste, l’utente può utilizzare
uno script di configurazione locale.
3. Lo script di configurazione locale deve essere installato nella directory home
dell’utente ($HOME/.jobmanrc) e deve disporre dell’autorizzazione
all’esecuzione.
Se si desidera utilizzare uno script di configurazione locale, in parte, è necessario
eseguire il file di script del lavoro ($UNISON_JCL). Lo script di configurazione
standard fornito da Tivoli, jobmanrc, esegue lo script di configurazione locale come
segue:
$EXECIT $USE_SHELL $HOME/.jobmanrc "$UNISON_JCL" $IS_COMMAND
Il valore di USE_SHELL viene impostato sul valore della variabile jobmanrc
SHELL_TYPE (consultare Tabella 3 a pagina 19). IS_COMMAND viene impostato
su yes se il lavoro è stato pianificato per l’esecuzione o inoltrato utilizzando la
struttura docommand. EXECIT viene impostato su exec se la variabile USE_EXEC
è impostata su yes (consultare Tabella 3 a pagina 19), altrimenti è null.
Il seguente esempio mostra come eseguire il file script di un lavoro o un comando
nello script di configurazione locale:
#!/bin/ksh
PATH=tws_home:tws_home/bin:$PATH
export PATH
/bin/sh -c "$UNISON_JCL"
Quanto segue è un esempio di un file .jobmanrc che effettua un’elaborazione in
base al codice di uscita del lavoro dell’utente:
#!/bin/sh
#
PATH=tws_home:tws_home/bin:$PATH
Capitolo 2. Ciclo di produzione 21
export PATH
/bin/sh -c "$UNISON_JCL"
#or use eval "$UNISON_JCL" and the quotes are required
RETVAL=$?
if [ $RETVAL -eq 1 ]
then
echo "Exit code 1 - Non Fatal Error"
exit 0
elif [ $RETVAL -gt 1 -a $RETVAL -lt 100 ]
then
conman "tellop This is a database error - page the dba"
elif [ $RETVAL -ge 100 ]
then
conman "tellop Job aborted. Please page the admin"
fi
Comandi di elaborazione della produzione
I comandi di elaborazione di pre e postproduzione eseguiti dal lavoro Jnextday
vengono descritti nelle seguenti sezioni.
22 IBM Tivoli Workload Scheduler - Manuale di riferimento
Comando schedulr
Il comando schedulr seleziona i flussi di lavoro per una data specifica dal file
database mastsked e li copia su un nuovo file pianificato di produzione
denominato prodsked.
E’ necessario disporre dell’accesso build ai file database scheduler.
Synopsis
schedulr -v|-u
schedulr [-date date|-autodate] [-scheds {in-file|-}] [-prodsked {out-file|-}]
Arguments
-u Visualizza le informazioni sull’utilizzo del comando e termina.
-v Visualizza la versione del comando e termina.
-date Seleziona i flussi di lavoro per una data specifica. La data deve essere
immessa come mm/dd/[yy]yy.
-autodate
Selezionare i flussi di lavoro per la data di sistema corrente.
-scheds
Oltre a quelli selezionati da -date o -autodate, se presenti, seleziona i flussi
di lavoro denominati in-file. I nomi devono apparire nel file come
[workstation#]jobstream, con un nome per riga. Se viene immesso un trattino
al posto di un nome file, schedulr richiede i nomi del flusso di lavoro per
stdin.
-prodsked
Indirizza l’output schedulr su out-file. Se viene immesso un trattino al
posto di un nome file, l’output viene indirizzato su stdout. Se viene
omesso l’argomento, l’output viene scritto su un file denominato prodsked.
Description
Se -autodate e -date vengono omessi, schedulr richiede una data. Se si risponde
alla richiesta premendo il tasto Invio, i flussi di lavoro vengono selezionati solo da
in-file.
Examples
Selezionare i flussi di lavoro per la data corrente, più i flussi di lavoro denominati
nel file myskeds:
schedulr -autodate -scheds myskeds
Selezionare i flussi di lavoro per Febbraio 15, 2001, non richiedere ulteriori nomi
flusso di lavoro e scrivere l’output sul file myprodsked:
schedulr -date 2/15/01 -prodsked myprodsked
Selezionare i flussi di lavoro per Febbraio 15, 2001 e richiedere ulteriori flussi di
lavoro:
schedulr -date 2/15/2001 -scheds -
Effettuare il prompt per la data di produzione e ulteriori flussi di lavoro (tenere
presente che “schedule” è uguale a “job stream”):
Capitolo 2. Ciclo di produzione 23
schedulr
Enter schedule date: 4/14/01
Enter a list of extra schedules
Schedule name: site1#sked2
Schedule name: <Return>
<list of job streams selected>
End of Program
24 IBM Tivoli Workload Scheduler - Manuale di riferimento
Comando compiler
Il comando compiler compila il file di pianificazione produzione e crea un file
piano di produzione ad interim.
Synopsis
compiler -v|-u
compiler [-date date] [-input in-file] [-output out-file]
Arguments
-u Visualizza le informazioni sull’utilizzo del comando e termina.
-v Visualizza la versione del comando e termina.
-date La data di produzione che deve essere registrata nel file piano di
produzione ad interim. La data deve essere immessa come mm/gg/[aa]aa.
-input Il nome del file che contiene la pianificazione di produzione. Se questa
opzione viene omessa, il nome di default è prodsked.
-output
Indirizzare l’output compiler su out-file. Se l’argomento viene omesso,
l’output viene scritto su un file denominato Symnew.
Description
Se si omette l’argomento -date, aSymnew viene fornita la stessa data di quella
registrata nel file pianificazione di produzione creato da schedulr. Se non è
presente una data in un file pianificazione di produzione, viene utilizzata la data
di sistema corrente. La data in Symnew è la data in cui lo scheduler inizierà
l’esecuzione del piano di produzione. La capacità di immettere una data differente
può essere utilizzata per impostare l’elaborazione per date future o passate.
Messaggi per gli oggetti mancanti: I seguenti messaggi vengono prodotti dal
compiler per indicare gli oggetti di pianificazione mancanti. Solitamente, i
messaggi vengono rilevati nel file di elenco standard per il lavoro Jnextday.
job. 5 ... Undefined parameter in "schedule"; not replaced.
Un parametro richiamato in un flusso di lavoro non esiste nel database dello
scheduler. Non si verifica alcuna sostituzione e viene utilizzata la stringa
parametro.
AWSBIC102W ... Job name is not found in database. Added a dummy job
in FAIL state.
Un lavoro denominato in un flusso di lavoro non esiste nel database dello
scheduler. Un lavoro dummy con lo stesso nome viene posizionato nella
pianificazione di produzione con una priorità di zero e uno stato di FAIL.
AWSBIC103W ... Prompt name not found. Added prompt name in Symphony.
Un prompt richiamato in un flusso di lavoro non esiste nel database scheduler.
Viene utilizzato un prompt dummy contenente il seguente testo: Nome prompt
non rilevato nel database. Questo è un testo fittizio. Si desidera continuare (S/N).
AWSBIC104W ...Resource name for cpu name not found in database.
Added resource name with 0 units.
Capitolo 2. Ciclo di produzione 25
Una risorsa definita in un flusso di lavoro non esiste nel database dello scheduler.
Una risorsa dummy con zero unità disponibili viene utilizzata al posto di:
AWSBIC106W ... Cpu name does not exist in cpu database.
Ignoring schedule name.
Viene definito un flusso di lavoro da eseguire su una cpu che non esiste. Il flusso
di lavoro viene ignorato e non posizionato nella pianificazione della produzione.
Examples
Compilare prodsked in Symnew:
compiler
Compilare prodsked in Symnew, e immettere una data di produzione di 15
maggio, 2002:
compiler -date 5/15/02
Compilare il file mysked in un file definito mysym:
compiler -input mysked -output mysym
26 IBM Tivoli Workload Scheduler - Manuale di riferimento
Comando stageman
Il comando stageman prosegue i flussi di lavoro, registra il vecchio piano di
produzione e installa il nuovo piano di produzione. Il nuovo piano di produzione
viene definito Symphony. Viene creata inoltre una copia di Symphony, definita
Sinfonia. Sinfonia viene inviata ai gestori dominio e agli agent come parte del
processo di inizializzazione per il nuovo giorno.
E’ necessario disporre dell’accesso build al file Symphony.
Synopsis
stageman -v
stageman [-carryforward {yes|no|all}] [-log log-file|-nolog] [symnew]
Arguments
-v Visualizza la versione del comando e termina.
-carryforward
Definisce il tipo da portare avanti:
no Non prosegue alcun flusso di lavoro.
yes Prosegue solo i flussi di lavoro non completi che hanno abilitato
Carry Forward.
all Ignora l’abilitazione di Carry Forward nei flussi di lavoro e
proseguire tutti i flussi di lavoro incompleti.
-log Registra il vecchio piano di produzione e fornire al file di log questo nome.
Per ulteriori informazioni, consultare “Nomi dei file di log” a pagina 28.
-nolog Non registra il vecchio piano di produzione.
symnew
Il nome del piano di produzione ad interim creato dal compiler. Se
omesso, viene utilizzato il file Symnew.
Description
Se si omette -carryforward, il valore di default per carry forward viene
determinato dall’opzione globale carryforward.
Solo su UNIX, stageman determina anche i file eseguibili che possono essere
cancellati per i lavori inoltrati con i comandi at e batch. Questi sono i lavori che
non sono stati proseguiti. I file vengono cancellati nel momento in cui si avvia lo
scheduler per il nuovo giorno.
Se i processi dello scheduler sono ancora in esecuzione e accedono al file
Symphony, stageman visualizza il messaggio:
Impossibile ottenere l’accesso esclusivo al file Symphony.
Shutdown batchman and mailman.
Per continuare, arrestare lo scheduler ed eseguire nuovamente stageman. Se
stageman si interrompe per un motivo qualunque, è necessario eseguire
nuovamente sia compiler sia stageman.
Agli utenti che accedono al piano tramite la CLI durante la commutazione di
Symphony viene inviato il messaggio:
Capitolo 2. Ciclo di produzione 27
Current Symphony file is old. Switching to new Symphony.
Schedule mm/dd/yy (nnnn) on cpu, Symphony switched.
Alcuni comandi utente eseguiti durante la commutazione potrebbero non effettuare
l’esecuzione in modalità appropriata perché i lavori e i flussi di lavoro di
destinazione non sono stati proseguiti.
Nomi dei file di log: I file di log del piano di produzione vengono memorizzati
nella directory TWShome/schedlog. La convenzione di definizione di default
utilizzata da stageman, quando vengono omessi -log e -nolog, è come la seguente:
TWShome/schedlog/Myyyymmddhhtt
dove yyyymmddhhtt è l’anno, il mese, il giorno, l’ora e il minuto in cui è stato
creato il file di log.
La precedente convenzione di denominazione viene codificata nello script Jnextday
fornito da Tivoli. Se si desidera, è possibile modificare la convenzione di
denominazione nel momento in cui si automatizza il ciclo di produzione. Per
ulteriori informazioni consultare “Automazione del ciclo di produzione” a pagina
15.
Nota: Monitorare lo spazio su disco nella directory schedlog e rimuovere i file di
log più vecchi su una base regolare.
Flussi di lavoro preseguiti: L’opzione carry forward rimane abilitata sui flussi di
lavoro che sono stati proseguiti, in questo modo potrebbero essere proseguiti
nuovamente. Se un flusso di lavoro che ha avuto esito negativo viene proseguito e
termina in uno stato diverso da SUCC, potrebbe essere proseguito indefinitamente,
a meno che non scada l’ora Until o non venga annullata.
I flussi di lavoro proseguiti mantengono la loro data di produzione originale.
Qualsiasi lavoro all’interno dei flussi di lavoro che utilizza datecalc, utilizzerà
questa data di produzione nel momento in cui usa la parola chiave ″scheddate″.
Per ulteriori informazioni, consultare “datecalc” a pagina 236.
Per proseguire il lavoro in modalità appropriata in una rete, il file del piano di
produzione del gestore dominio master, Symphony, deve essere aggiornato con lo
stato dell’ultimo flusso di lavoro dai suoi agent e gestori dominio subordinati. E’
possibile effettuare ciò inserendo quando segue ad un prompt dei comandi sul
gestore dominio master prima di eseguire stageman:
conman "link @"
Nomi dei flussi di lavoro: I flussi di lavoro proseguiti vengono ridenominati come
segue:
CFyyjjjnnxxxxxxxxx
dove yy corrisponde alle ultime due lettere dell’anno, jjj è la data giuliana, nn è un
numero di sequenza (00-99, AA-ZZ) e xxxxxxxxx è una stringa alfabetica casuale.
Prompt Carry Forward: Affinché vi sia continuità durante i flussi di lavoro
proseguiti, stageman crea prompt speciali nel nuovo piano di produzione
sull’account per le dipendenze Follows scollegate. Questi prompt vengono emessi
dopo l’inizio del nuovo giorno di elaborazione, quando lo scheduler controlla se il
lavoro o il flusso di lavoro è pronto per l’avvio e si risponde ad esse come prompt
standard. Quanto segue è un esempio di un prompt Carry Forward:
28 IBM Tivoli Workload Scheduler - Manuale di riferimento
INACT 12 (SYS1#CF9123AA) follows SYS1#SKED3 satisfied?
Questo prompt indica che è stato proseguito un flusso di lavoro come CF9123AA e
che segue un flusso di lavoro definito sked3 che non è stato proseguito. Lo stato
del prompt– INACT in questo caso– definisce lo stato della dipendenza Follows
corrispondente. Gli stati possibili sono:
INACT
Il prompt non è stato emesso e la dipendenza non è stata soddisfatta.
ASKED
Il prompt è stato emesso ed è in attesa di risposta. La dipendenza non è
stata soddisfatta.
NO E’ stata ricevuta una risposta negativa o è stato stabilito prima che si
verificasse Carry Forward che il flusso di lavoro (sked3) non è stato
completato con esito positivo. La dipendenza non è stata soddisfatta.
YES E’ stata ricevuta una risposta positiva o è stato stabilito prima che si
verificasse Carry Forward che il flusso di lavoro (sked3) è stato completato
con esito positivo. La dipendenza viene soddisfatta.
Nota: Viene generato un prompt se la pianificazione viene proseguita e presenta
una dipendenza follows su un’altra pianificazione incompleta. Nel caso
delle dipendenze Internetwork, viene generato un prompt anche quando
vengono proseguite entrambe le pianificazioni. Questo perché, nel caso delle
dipendenze Internetwork, non esiste alcun meccanismo disponibile per
mantenerle connesse. Non viene fornito alcun modo al successore per sapere
se la pianificazione dall’altra parte è stata proseguita o meno, e la
dipendenza di collegamento viene interrotta in ogni caso. Per ulteriori
informazioni, consultare Capitolo 9, “Riferimento Agent di rete”, a pagina
299.
Examples
Proseguire tutti i flussi di lavoro non completi (a prescindere dallo stato
dell’opzione Carry Forward), registrare il vecchio file Symphony e creare il nuovo
file Symphony:
DATE=’datecalc today pic YYYYMMDDHHTT’
stageman -carryforward all -log schedlog/M$DATE
Proseguire i flussi di lavoro non completi come definito dall’opzione globale
carryforward, non registrare il vecchio fileSymphony e creare un nuovo file di
controllo della produzione definito mysym:
stageman -nolog mysym
Capitolo 2. Ciclo di produzione 29
Comando logman
Il comando logman registra le statistiche del lavoro da un file di log del piano di
produzione.
Synopsis
logman -v|-u
logman [-smooth percent] [-minmax {elapsed|cpu}] log-file
Arguments
-u Visualizza le informazioni sull’utilizzo del comando e termina.
-v Visualizza la versione del comando e termina.
-smooth
Utilizza un fattore importante che favorisce il lavoro più recente durante il
calcolo del tempo di esecuzione normale (medio) per un lavoro. Ciò viene
espresso come percentuale. Ad esempio, -smooth 40 applicherà un fattore
importante del 40% all’esecuzione del lavoro più recente e del 60% alla
media esistente. Il valore di default è zero.
-minmax
Definisce le modalità di registrazione e documentazione dei tempi di
esecuzione minimi e massimi.
elapsed
Imposta i tempi di esecuzione minimi e massimi sul tempo
trascorso.
cpu Imposta i tempi di esecuzione minimi e massimi sull’ora della
CPU.
log-file Il nome del file del piano di produzione o del file di log da cui vengono
estratte le statistiche del lavoro.
Description
I lavori che sono stati già registrati non possono essere registrati nuovamente.
Durante il tentativo di effettuare la registrazione verrà visualizzato il messaggio di
errore 0 lavori registrati.
Ora trascorsa confrontata con l’ora della CPU: L’ora trascorsa, espressa in minuti,
è influenzata dall’attività di sistema. Essa include sia la quantità di tempo
impiegata dal lavoro della CPU sia gli intervalli che il lavoro ha dovuto attendere
prima che gli altri processi rilasciassero la CPU. Nei periodi di elevata attività del
sistema, ad esempio, un lavoro può impiegare parecchio tempo e può utilizzare
non utilizzare più l’ora della CPU nei periodi di bassa attività del sistema. D’altro
canto, il tempo della CPU, espresso in secondi, è una misura reale dell’effettivo
utilizzo di un lavoro della CPU e non include intervalli nel momento in cui il
lavoro è in attesa.
Se si esegue logman con l’argomento -minmaxelapsed, i tempi di esecuzione
minimi e massimi si basano unicamente sul tempo trascorso del lavoro. I valori
vengono aggiornati solo se l’ultima esecuzione del lavoro ha un tempo trascorso
superiore al massimo esistente o inferiore al minimo esistente. I tempi della CPU,
in questo caso, non indicheranno necessariamente gli estremi minimi e massimi.
Se si esegue logman con l’argomento -minmaxCPU, i tempi di esecuzione minimi
e massimi e le date si basano unicamente sul tempo della CPU del lavoro. I valori
30 IBM Tivoli Workload Scheduler - Manuale di riferimento
vengono aggiornati solo se l’ultima esecuzione del lavoro ha un tempo della CPU
superiore al massimo esistente o inferiore al minimo esistente. I tempi trascorsi, in
questo caso, non indicheranno necessariamente i loro estremi minimi e massimi.
Se si esegue logman senza l’argomento -minmax, i valori del tempo trascorso e del
tempo della CPU vengono aggiornati indipendentemente per indicare i loro
estremi minimi e massimi, ma le date di esecuzione corrispondono solo ai valori
del tempo trascorso. In questo caso, non viene mantenuto nessun record delle date
di esecuzione per i tempi minimi e massimi della CPU.
Examples
Registrare le statistiche del lavoro dal file di log M199903170935:
logman schedlog/M199903170935
Registrare le statistiche del lavoro dal file di log M$DATE in base al tempo
trascorso, dando all’esecuzione del lavoro più recente un peso pari al 40% durante
il calcolo dei tempi di esecuzione normale (medio):
logman -smooth 40 -minmax elapsed schedlog/M$DATE
La variabile $DATE contiene la data e la registrazione data/ora utilizzata da
stageman per creare il nome del file di log. Per ulteriori informazioni, consultare
“Comando stageman” a pagina 27.
Capitolo 2. Ciclo di produzione 31
Comando wmaeutil
Il comando wmaeutil viene utilizzato per arrestare il server connettore per il piano,
per il database e per il sistema. Il comando makesec non verrà eseguito con esito
positivo su piattaforme Windows fino a che non vengono arrestati i connettori.
Nota: se si crea nuovamente un file piano manualmente (non utilizzando
Jnextday), è necessario arrestare i connettori eseguendo il comando wmaeutil e
aggiornare le viste in Job Scheduling Console per visualizzare il nuovo giorno di
produzione. Altrimenti, le viste in Job Scheduling Console rimarranno sul giorno
di produzione precedente.
Synopsis
UNIX:
wmaeutil.sh instance_name [-stop DB | PL | EG | “*”] [-version DB | PL | EG |
“*”] [-dbinfo DB | PL] [-sethome] [-gethome] [ALL -stop]
Windows:
wmaeutil.cmd instance_name [-stop DB | PL | EG | “*”] [-version DB | PL | EG
| “*”] [-dbinfo DB | PL] [-sethome] [-gethome] [ALL -stop]
Arguments
instance_name
Il nome dell’istanza dello scheduler. Si riferisce al nome dell’istanza
immesso durante l’installazione del motore dello scheduler e l’installazione
del connettore.
-stop DB | PL | EG | *
Questa opzione può essere utilizzata per arrestare il server connettore
specificato. L’asterisco (*) può essere utilizzato per arrestare tutti e tre i
server connettori.
-version DB | PL | EG | *
Questa opzione viene utilizzata per ottenere il numero della versione del
server connettore per il piano, il database, il motore e deve essere installata
sul sistema. L’asterisco (*) può essere utilizzato per ricevere delle versioni
per tutti e tre i server connettori contemporaneamente.
-dbinfo DB | PL
Questa opzione viene utilizzata per stabilire se il database dello scheduler
e il piano a cui questo connettore è collegato è espanso o meno. Con IBM
Tivoli Workload Scheduler, Versione 8.2, i database e i piani sono sempre
estesi, ma questa opzione esiste per motivi di compatibilità con le versioni
precedenti.
-sethome
Questa opzione viene utilizzata per impostare l’attributo TWShome degli
oggetti dello scheduler (Engine, Database e Plan) nel database oggetto di
Tivoli. Questo valore attributo collega i connettori per l’istanza dell’oggetto
specificato al prodotto scheduler core. Esso considera il nome completo
della directory home dello scheduler come argomento. Anche la stringa del
nome percorso deve essere racchiusa tra apici per impedire qualsiasi
interpretazione della shell.
32 IBM Tivoli Workload Scheduler - Manuale di riferimento
-gethome
Questa opzione non richiede tutti gli argomenti e stampa il valore
dell’attributo TWSHome per le istanze degli oggetti Engine, Database e
Plan nel database dell’oggetto.
ALL -stop
Questa opzione arresta i server connettore per tutte le istanze connettore
dello scheduler sull’installazione dello scheduler corrente, arresta i server
connettore per tutte le istanze il cui attributo TWSHome corrisponde alla
directory home dell’installazione corrente dello scheduler.
Usage Notes
Impostazione delle variabili di ambiente: Prima che wmaeutil possa essere
eseguito con esito positivo, è necessario avviare il file seguente per impostare
l’ambiente framework.
Per Windows:
c: \> %SystemRoot%\system32\drivers\etc\Tivoli\setup_env.cmd
Per UNIX:
$. /etc/Tivoli/setup_env.sh
E’ possibile aggiornare il proprio profilo UNIX per eseguire questo file, in modo da
evitare la riesecuzione manuale del comando.
Considerazioni Makesec: Il comando wmaeutil.sh deve essere eseguito prima del
comando makesec. Il comando makesec non verrà eseguito con esito positivo su
piattaforme Windows fino a che non vengono arrestati i connettori. E’ necessario
inoltre arrestare i connettori quando si utilizza il comando makesec su UNIX.
Nome istanza di IBM Tivoli Workload Scheduler: Se non si ricorda il nome
dell’istanza immesso al momento dell’installazione, seguire queste istruzioni:
1. L’origine delle variabili di ambiente Tivoli:
. /etc/Tivoli/setup_env.sh (for UNIX)
C:\winnt\system32\drivers\etc\Tivoli\setup_env.cmd (per Windows)
2. Eseguire il comando wlookup per ottenere il nome dell’istanza dello scheduler:
wlookup -ar MaestroEngine
maestro2 1697429415.1.596#Maestro::Engine#
dove maestro2 è il nome istanza dello scheduler.
Examples
Arrestare i connettori per il database, il piano e il motore per una istanza
denominata maestro:
wmaeutil.sh maestro -stop ALL
Arrestare i connettori per il database per una istanza denominata tws:
wmaeutil.sh tws -stop ALL DB
Arrestare le versioni del connettore per il database, il piano e il motore per una
istanza denominata maestro2:
wmaeutil.sh maestro2 -version *
Capitolo 2. Ciclo di produzione 33
Capitolo 3. Riferimento al Composer
Il programma Composer viene utilizzato per gestire gli oggetti di pianificazione nel
database IBM Tivoli Workload Scheduler. Gli oggetti di pianificazione sono
workstation, classi di workstation, domini, lavori, flussi di lavoro, risorse, prompt,
calendari e parametri. Questo capitolo contiene informazioni sui seguenti
argomenti:
v Gestione degli oggetti di pianificazione
v Programma Composer
v Descrizioni dei comandi
Gestione degli oggetti di pianificazione
Gli oggetti di pianificazione vengono gestiti con il programma Composer e vengono
archiviati nel database dello scheduler. Questo programma utilizza dei file di
modifica per aggiornare il database di pianificazione; per ulteriori informazioni sul
formato dei file di modifica utilizzati per un oggetto specifico, fare riferimento alla
definizione di tale oggetto riportata nell’ultima parte di questa sezione. Ad
esempio, per aggiungere un nuovo oggetto è necessario immettere la definizione in
un file di modifica e, con il programma composer, sarà possibile creare o modificare
questo oggetto specificando il file di modifica che contiene la definizione, poi il
programma composer controllerà la sintassi nel file di modifica e, se corretta,
aggiungerà la definizione al database.
A seconda del tipo di oggetto che si desidera gestire con il programma composer, è
possibile gestire un particolare oggetto singolarmente nel database o accedere
all’elenco di oggetti dello stesso tipo definiti nel database e modificare la voce che
rappresenta tale oggetto.
E’ possibile accedere alle voci del database per i flussi di lavoro, i lavori, gli utenti,
le workstation, i domini e le classi della workstation e gestirle individualmente. Ad
esempio, per modificare una definizione di lavoro esistente, occorre utilizzare il
programma composer con l’opzione create per copiare la definizione di questo
lavoro dal database in un file di modifica, poi sarà necessario modificare questo
file utilizzando il programma composer con l’opzione modify per modificare la
definizione del lavoro ed infine il programma composer controllerà la sintassi del
file di modifica e, se corretta, copierà la definizione del lavoro nel database,
sostituendo quella esistente.
Le voci del database per i calendari, i parametri, i prompt e le risorse vengono
gestite come elenchi completi. Ad esempio, per modificare una risorsa esistente è
necessario utilizzare il programma composer con l’opzione modify resources per
copiare l’intero elenco di risorse dal database in un file che può essere modificato e
salvato direttamente dall’interfaccia del composer; dopo aver salvato il file di
modifica, il programma composer controlla se la sintassi nel file è corretta e, quindi,
copia il nuovo elenco nel database, sostituendo quello esistente.
Il programma di composizione non emette avvisi specifici se le parole chiave di
specificazione vengono utilizzate come nomi degli oggetti di pianificazione.
Tuttavia, l’utilizzo di parole chiave può generare errori. Quando si definiscono
oggetti di pianificazione, evitare l’uso delle seguenti parole chiave:
© Copyright IBM Corp. 1999, 2004 35
Tabella 4. Elenco di parole chiave riservate
abendprompt end i18n_priority on schedule
after every in onuntil scriptname
at everyday interactive op server
autodocoff except isuserjob opens stop
autodocon extraneous jobfilename order streamlogon
behindfirewall fdignore keyjob os su
carryforward fdnext keysched priority timezone_tzid
confirmed fdprev maestro prompt token_in
cpuname filename needs qualifier until
dateval follows netdelim quoted_string weekday(s)
day(s) freedays nextjob recovery workday(s)
day_of_week go node request
deadline hi notempty rerun
docommand i18n_id number sa
36 IBM Tivoli Workload Scheduler - Manuale di riferimento
Definizioni delle workstation
Una workstation è un oggetto di pianificazione che esegue i lavori. Normalmente,
una workstation è un singolo computer sul quale vengono eseguiti lavori e flussi
di lavoro. Per ogni computer che esegue lavori nella rete IBM Tivoli Workload
Scheduler viene richiesta una definizione di workstation. Le definizioni
workstation principali fanno riferimento alle workstation fisiche. Comunque, nel
caso degli agent estesi, le workstation sono definizioni logiche che devono trovarsi
su una workstation fisica. E’ possibile includere più definizioni della workstation
nello stesso file di testo, insieme alle definizioni della classe della workstation e del
dominio. Ogni definizione workstation presenta il seguente formato:
Sintesi
#[ comment]
cpuname wkstation [description ″text″]
os os-type
node hostname [tcpaddr port]
[secureaddr port][timezone|tz tzname]
[domain domainname]
[for maestro [host host-wkstation [access method]]
[type fta | s-agent | x-agent]
[ignore]
[autolink on | off]
[behindfirewall on | off]
[securitylevel enabled | on | force]
[fullstatus on | off]
[resolvedep on | off]
[server serverid]]
end
[cpuname ...]
[cpuclass ...]
[domain ...]
Argomenti
# comment
Indica che tutto ciò che si trova dopo il segno cancelletto è un commento.
cpuname wkstation
Specifica il nome della workstation. Il nome deve cominciare con una
lettera e può contenere caratteri alfanumerici, trattini e caratteri di
sottolineatura. Può contenere fino a 16 caratteri. Per un elenco di parole da
evitare nella specificazione del nome cpi, consultare Tabella 4 a pagina 36.
Nota: i nomi della workstation devono essere univoci e non possono
essere uguali ai nomi della classe della workstation e a quelli del
dominio.
description “text”
Fornisce una descrizione della workstation. Il testo deve essere racchiuso
tra doppi apici.
os os_type
Specifica il sistema operativo della workstation. I valori validi sono UNIX,
WNT e OTHER dove
Capitolo 3. Riferimento al Composer 37
Tabella 5. Valori per i sistemi operativi supportati
Utilizzare questi valori... Per questi sistemi operativi...
UNIX HP-UX, Sun Solaris, AIX, Linux per Intel,
Linux per S/390 e z/Series, Linux per
ISeries e PSeries, Irix, OSF, Dynix, Compaq
WNT Windows NT, Windows 2000, Windows 2000
NET Server, Windows XP Professional
OTHER Utilizzato in connessione con gli agent
estesi.
Nota: Per un elenco aggiornato delle piattaforme supportate, fare
riferimento alle Note sulla versione IBM Tivoli Workload Scheduler.
node hostname
Specifica il nome host o l’indirizzo IP della workstation. Sono consentiti
anche nomi domini completi.
tcpaddr port
Specifica il numero della porta TCP che lo scheduler utilizza per le
comunicazioni sulla workstation. Il valore di default è 31111.
secureaddr
Definisce la porta utilizzata per attendere le connessioni SSL in entrata.
Questo valore deve corrispondere a quello definito nell’opzione locale nm
SSL port della workstation. Deve essere diverso dall’opzione locale nm
port che definisce la porta utilizzata per le normali comunicazioni. Se il
livello di sicurezza è specificato ma questo attributo manca, viene
utilizzato il valore di default 31113. Per informazioni sull’autenticazione
SSL, fare riferimento a Manuale per la pianificazione e installazione di IBM
Tivoli Workload Scheduler,.
timezone|tz tzname
Specifica il fuso orario della workstation. Consultare Appendice B,
“Gestione dei fusi orari”, a pagina 331 per nomi validi del fuso orario. Per
assicurare il verificarsi delle ore di pianificazione, questo fuso orario deve
essere uguale al fuso orario del sistema operativo del computer.
domain domainname
Specifica il nome del dominio scheduler della workstation. Il valore di
default per gli FTA e gli agent standard è il dominio master, generalmente
denominato MASTERDM. Il valore di default per il Gestore dominio è il
dominio in cui viene definito come gestore. Il valore di default per un
agent esteso (XA) è il dominio della workstation host.
host host-wkstation
Specifica il nome della workstation host dell’agent. È necessario per gli
agent estesi (XA). L’host è la workstation con la quale l’agent esteso
comunica e dove si trova il relativo metodo di accesso. Tenere presente che
l’host non può essere un altro agent esteso.
access method
Specifica un metodo di accesso per gli agent estesi e di rete. Questo deve
essere il nome di un file che si trova nella directory Metodi/TWShome
sulla workstation host dell’agent.
type Specifica il tipo di workstation. Immettere uno dei seguenti:
38 IBM Tivoli Workload Scheduler - Manuale di riferimento
fta Agent tollerante l’errore (FTA), che include gestori dominio e
gestori dominio di backup.
s-agent
Agent standard (SA).
x-agent
Agent esteso (XA).
ignore Specifica che lo scheduler ignorerà questa definizione della workstation.
autolink
Specifica se consentire all’avvio il collegamento tra le workstation. Per gli
FTA e gli agent standard, immettere on affinché il Gestore dominio
consenta il collegamento all’agent nel momento in cui viene avviato il
Gestore dominio. Per il Gestore dominio, immettere on affinché gli agent
abilitino i collegamenti al Gestore dominio nel momento in cui vengono
avviati.
Il collegamento automatico è utile principalmente durante la sequenza di
avvio all’inizio di ogni giorno. In quel momento, viene creato e compilato
un nuovo piano di produzione sul gestore dominio master e tutte le
workstation vengono arrestate e riavviate. Per ogni agent con autolink
attivo, il Gestore dominio invia automaticamente una copia del nuovo
piano di produzione e avvia l’agent. Se autolink è attivo anche sul Gestore
dominio, l’agent, a sua volta, apre un nuovo collegamento al Gestore
dominio. Se il valore di autolink è off per un agent, viene inizializzato
quando si esegue un comando Conman link sul gestore dominio dell’agent
o sul gestore dominio master.
behindfirewall
Se questo attributo è impostato su ON, è presente un firewall tra la
workstation e il gestore dominio master. È consentita solo una connessione
diretta tra la workstation e il relativo dominio. Per tutte le workstation con
behindfirewall impostato su ON, i comandi start wkstation, stop wkstation
e showjobs vengono inviati dopo la gerarchia di dominio, invece di fare in
modo che il gestore dominio o master apra una connessione diretta con la
workstation.
fullstatus
Specifica se l’agent viene aggiornato con stato parziale o completo. Questo
si riferisce solo agli agent tolleranti l’errore. Immettere on affinché l’agent
funzioni in modalità Full status. In questa modalità, l’agent viene
aggiornato circa lo stato dei lavori e dei flussi di lavoro in esecuzione su
tutte le altre workstation nel dominio e in domini subordinati.
Se il valore fullstatus è off, l’agent viene informato solo sullo stato dei
lavori e dei flussi di lavoro sulle altre workstation che influenzano i propri
lavori e flussi di lavoro. Ciò potrebbe migliorare le prestazioni riducendo
l’attività di rete.
Per mantenere un piano di produzione dell’agent allo stesso livello del
gestore dominio, impostare fullstatus e resolvedep su attivo. Impostare
sempre queste modalità su attivo per i gestori domini di backup.
securitylevel
Specifica il tipo di autenticazione SSL della workstation. Deve avere uno
dei seguenti valori:
enabled
La workstation utilizza l’autenticazione SSL solo se la workstation
Capitolo 3. Riferimento al Composer 39
di dominio master o un altro agent tollerante l’errore al di sotto di
questo nella gerarchia di domini la richiede.
on La workstation utilizza l’autenticazione SSL quando si collega al
gestore dominio. Il gestore dominio utilizza l’autenticazione SSL
quando si collega al gestore dominio parent. L’agent tollerante
l’errore rifiuta qualsiasi connessione in arrivo dal gestore dominio
tranne le connessioni SSL.
force La workstation utilizza l’autenticazione SSL per tutte le connessioni
e accetta le connessioni sia dai gestori dominio parent che dai
gestori subordinati. Rifiuta tutte le connessioni in entrata non SSL.
Se questo attributo viene omesso, la workstation non è configurata per le
connessioni SSL. In questo caso, sarà ignorato qualsiasi valore di
secureaddr. È anche necessario impostare l’opzione locale nm ssl port su 0
per assicurarsi che la porta non sia aperta da netman. Per informazioni
sull’autenticazione SSL, fare riferimento a Manuale per la pianificazione e
installazione di IBM Tivoli Workload Scheduler,. La tabella seguente descrive il
tipo di comunicazioni utilizzato per ciascun tipo di impostazione
securitylevel.
Tabella 6. Topo di comunicazione a seconda del valore di securitylevel.
Agent tollerante l’errore
(Gestore dominio)
Gestore dominio (Parent
Domain Manager)
Tipo di connessione
- - TCP/IP
Enabled - TCP/IP
On - Nessuna connessione
Force - Nessuna connessione
- On TCP/IP
Enabled On TCP/IP
On On SSL
Force On SSL
- Enabled TCP/IP
Enabled Enabled TCP/IP
On Enabled SSL
Force Enabled SSL
- Force Nessuna connessione
Enabled Force SSL
On Force SSL
Force Force SSL
resolvedep
Specifica se un agent terrà traccia di tutte le dipendenze o solo delle
proprie. Questo si riferisce solo agli agent tolleranti l’errore. Immettere on
affinché l’agent operi in modalità Risolvi tutte le dipendenze. In questa
modalità, l’agent tiene traccia delle dipendenze per tutti i i lavori e i flussi
di lavoro, inclusi quelli in esecuzione sulle altre workstation. Tenere
presente che anche il valore di fullstatus deve essere attivo in modo che
l’agent sia informato sull’attività sulle altre workstation. Se il valore di
resolvedep è off, l’agent tiene traccia delle dipendenze solo dei lavori e dei
flussi di lavoro propri. Ciò riduce il sovraccarico dell’elaborazione.
40 IBM Tivoli Workload Scheduler - Manuale di riferimento
Per mantenere un piano di produzione dell’agent allo stesso livello del
gestore dominio, impostare fullstatus e resolvedep su on. Impostare
sempre queste modalità su on per i gestori dominio di backup.
server serverid
Specifica un server Mailman sul gestore dominio per gestire le
comunicazioni con l’agent. Questo si riferisce solo a FTA e agent standard.
Non utilizzare questa opzione per i gestori dominio. L’utilizzo di server
può ridurre il tempo necessario per inizializzare gli agent e per migliorare
la tempestività dei messaggi.
L’ID è una lettera singola o un numero (dalla A alla Z e da 0 a 9). Gli ID
sono univoci per ogni gestore dominio, in questo modo è possibile
utilizzare gli stessi ID in altri domini senza creare conflitti. Se in un
dominio sono richiesti più di 36 ID server, è possibile dividere il dominio
in due o più domini.
Se non viene specificato un ID server, le comunicazioni con l’agent
vengono gestite dal processo principale Mailman sul gestore dominio.
Quando viene avviato, il gestore dominio crea un server separato per ogni
ID server univoco. Se viene utilizzato lo stesso ID per più agent, viene
creato un singolo server che gestisce le comunicazioni. E’ necessario
definire server supplementari per impedire ad un singolo server di gestire
più di otto agent.
Esempi
Nel seguente esempio viene creato un gestore dominio master definito hdq-1 e un
FTA definito hdq-2 nel dominio master. Tenere presente che, in questo esempio, un
argomento domain è facoltativo, perché il dominio master viene impostato su
masterdm.
cpuname hdq-1 description “Headquarters master DM”
os unix
tz pst
node sultan.ibm.com
domain masterdm
for maestro type fta
autolink on
fullstatus on
resolvedep on
end
cpuname hdq-2
os wnt
tz pst
node opera.ibm.com
domain masterdm
for maestro type fta
autolink on
end
Il seguente esempio crea un dominio definito distr-a con un gestore dominio
definito distr-a1 ed un agent standard denominato distr-a2:
domain distr-a
manager distr-a1
parent masterdm
end
cpuname distr-a1 description “District A domain mgr”
os wnt
tz est
node pewter.ibm.com
domain distr-a
Capitolo 3. Riferimento al Composer 41
for maestro type fta
autolink on
fullstatus on
resolvedep on
end
cpuname distr-a2
os wnt
node quatro.ibm.com
tz est
domain distr-a
for maestro type s-agent
end
Il seguente esempio crea una workstation con autenticazione SSL. La definizione di
sicurezza di securitylevel specifica che la connessione tra la stazione di lavoro e il
gestore dominio può essere solo di tipo SSL. La porta 32222 è riservata all’attesa di
connessioni SSL in entrata.
cpuname ENNETI3
os WNT
node apollo
tcpaddr 30112
secureaddr 32222
for maestro
autolink off
fullstatus on
securitylevel on
end
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
le sezioni relative alla creazione di una workstation z/OS o distribuita del manuale
Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
42 IBM Tivoli Workload Scheduler - Manuale di riferimento
Definizioni delle classi workstation
Una classe workstation è un gruppo di workstation per cui è possibile scrivere i
flussi di lavoro comuni. E’ possibile includere più definizioni della classe
workstation nello stesso file di testo, insieme alle definizioni della workstation e
alle definizioni relative al dominio. Ogni definizione della classe workstation
presenta il seguente formato:
Sintesi
# comment
cpuclass wkstationclass
members {wkstation | @} [...]
end
[cpuname ...]
[cpuclass ...]
[domain ...]
Argomenti
# comment
Indica che tutto ciò che si trova dopo il segno cancelletto è un commento.
cpuclass wkstationclass
Specifica il nome della classe workstation. Il nome deve cominciare con
una lettera e può contenere caratteri alfanumerici, trattini e caratteri di
sottolineatura. Può contenere fino a 16 caratteri.
Nota: Non è possibile utilizzare gli stessi nomi per le workstation, le classi
workstation e per i domini.
members wkstation
Specifica un elenco di nomi di workstation, separati da spazi, che sono
membri della classe. Il carattere jolly rappresentato dal segno at (@) include
tutte le workstation.
Esempi
Quanto segue definisce una classe workstation denominata backup:
cpuclass backup
members
main
site1
site2
end
Nel seguente esempio viene definita una classe workstation denominata allcpus
che contiene ogni workstation:
cpuclass allcpus
members
@
end
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione di una classe workstation nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 43
Definizioni dominio
Un dominio è un gruppo di workstation composto da uno o più agent e un gestore
dominio. Il gestore dominio funziona come hub di gestione per gli agent nel
dominio. E’ possibile includere più definizioni dominio nello stesso file di testo,
insieme alle definizioni della workstation e alle definizioni della classe workstation.
Ogni definizione di dominio presenta il seguente formato:
Sintesi
# comment
domain domainname[description “text”]
manager wkstation
[parent domainname]
end
[cpuname ...]
[cpuclass ...]
[domain ...]
Argomenti
# comment
Indica che tutto ciò che si trova dopo il segno cancelletto è un commento.
domain domainname
Il nome del dominio. Il nome deve cominciare con una lettera e può
contenere caratteri alfanumerici, trattini e caratteri di sottolineatura. Può
contenere fino a 16 caratteri. Non è possibile utilizzare gli stessi nomi per
le workstation, le classi workstation e per i domini.
description “text”
Fornisce una descrizione del dominio. Il testo deve essere racchiuso tra
doppi apici.
managerwkstation
Specifica il nome della workstation, ossia il gestore dominio. Questa
workstation deve appartenere al dominio da definire. Il gestore dominio
deve essere un agent tollerante l’errore con fullstatus e resolvedep
impostati su attivo.
parent domainname
Il nome del dominio parent a cui è collegato il gestore dominio. Il valore di
default e il dominio master, che non richiede una definizione dominio. Il
dominio master viene definito dalle opzioni globalimaster e master
domain.
Esempi
Quanto segue definisce un dominio denominato east, con il dominio master come
parent e due domini subordinati denominati northeast e southeast:
domain east description “The Eastern domain”
manager cyclops
end
domain northeast description “The Northeastern domain”
manager boxcar parent east
end
domain southeast description “The Southeastern domain”
manager sedan parent east
end
44 IBM Tivoli Workload Scheduler - Manuale di riferimento
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione di un dominio nel manuale Guida per l’utente di
IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 45
Definizioni lavoro
Un lavoro è un file eseguibile, un programma o un comando che viene pianificato
ed avviato da IBM Tivoli Workload Scheduler. È possibile scrivere le definizioni
lavoro nei file di modifica e quindi aggiungerli al database dello scheduler con il
programma composer. E’ possibile includere più definizioni lavoro in un singolo
file di modifica.
Nota: Un lavoro non ha dipendenze, queste devono essere aggiunte a un lavoro in
un flusso. Il linguaggio di pianificazione utilizzato per scrivere i flussi di
lavoro consente inoltre di aggiungere e modificare le definizioni lavoro.
Consultare il seguente capitolo per ulteriori informazioni sull’utilizzo del
linguaggio di pianificazione per scrivere i flussi di lavoro.Ogni definizione di lavoro presenta il seguente formato:
Sintesi
$jobs
[wkstation#]jobname
scriptname filename |
docommand “command”streamlogon username
[description “text”]
[interactive]
[rccondsucc ″Success Condition″]
[recovery
{stop | continue | rerun}
[after [wkstation#]jobname]
[abendprompt “text”] ]
[ [wkstation#]jobname... ]
Argomenti
wkstation#
Specifica il nome della workstation o della classe workstation su cui è in
esecuzione il lavoro. Il valore di default è la workstation su cui è in
esecuzione il Composer. Il segno del cancelletto (#) è un delimitatore
necessario. Se si specifica una classe workstation, è necessario che
corrisponda alla classe workstation di ogni flusso di lavoro in cui viene
incluso il lavoro.
jobname
Specifica il nome del lavoro. Il nome deve cominciare con una lettera e può
contenere caratteri alfanumerici, trattini e caratteri di sottolineatura. Può
contenere fino a 40 caratteri.
scriptname filename
Specifica il nome del file che esegue il lavoro. Utilizzare scriptname per i
lavori UNIX e Windows. Per un file eseguibile, immettere il nome del file e
tutte le opzioni e gli argomenti. La lunghezza di filename più quella di
Success Condition (della parola chiave rccondsucc) non deve superare i 4095
caratteri. E’ possibile inoltre utilizzare i parametri IBM Tivoli Workload
Scheduler. Per ulteriori informazioni, consultare “Utilizzo dei parametri
nelle definizioni lavoro” a pagina 50.
Per i lavori Windows, includere le estensioni dei file. Sono consentiti nomi
UNC (Universal Naming Convention). Non specificare file su unità
definite.
46 IBM Tivoli Workload Scheduler - Manuale di riferimento
Se vengono inseriti spazi o caratteri speciali diversi da barre (/) e barre
retroverse (\), l’intera stringa deve essere racchiusa tra apici (″).
Se il nome del file contiene spazi, immettere il nome in un altro file che
non ha spazi nel proprio nome e utilizzare il nome del secondo file per
questo argomento.
docommand command
Specifica un comando che esegue il lavoro. Immettere un comando valido e
tutte le opzioni e gli argomenti racchiusi tra apici (″). La lunghezza di
command più quella di Success Condition (della parola chiave rccondsucc)
non deve superare i 4095 caratteri. Un comando viene eseguito
direttamente e, a differenza di scriptname, non viene eseguito lo script di
configurazione jobmanrc. Altrimenti, il comando viene considerato come
un lavoro e vengono applicate tutte le regole ad esso relative. E’ possibile
inoltre immettere i parametriIBM Tivoli Workload Scheduler. Per ulteriori
informazioni, consultare “Utilizzo dei parametri nelle definizioni lavoro” a
pagina 50.
streamlogon username
Il nome dell’utente sotto cui viene eseguito il lavoro. Il nome può
contenere fino a 47 caratteri. Se il nome contiene caratteri speciali, deve
essere racchiuso tra apici (″). Specificare un utente che può effettuare il log
on alla workstation su cui viene eseguito il lavoro. E’ possibile inoltre
immettere i parametriIBM Tivoli Workload Scheduler. Per ulteriori
informazioni, consultare “Utilizzo dei parametri nelle definizioni lavoro” a
pagina 50.
Per i lavori Windows, l’utente deve disporre inoltre di una definizione
utente. Consultare “Definizioni utente” a pagina 52 per i requisiti
dell’utente.
description “text”
Fornisce una descrizione del lavoro. Il testo deve essere racchiuso tra doppi
apici.
interactive
Per i lavori Windows, includere questa parola chiave per indicare che il
lavoro viene eseguito interattivamente sul desktop Windows NT.
rccondsucc ″Success Condition″
Un’espressione che determina il codice di ritorno (RC) richiesto per
considerare un lavoro riuscito. La lunghezza massima di questo parametro
è di 256 caratteri. Questa espressione può contenere una combinazione di
espressioni di comparazione e booleana:
Espressione di comparazione
Specifica i codici di ritorno del lavoro. La sintassi é:
(RC operatore operando)
RC La parola chiave RC.
operatore
Operatore di comparazione. Può avere i seguenti valori:
Tabella 7. Operatore di comparazione
Esempio Operatore Descrizione
RC<a < Minore di
RC<=a <= Minore di o uguale a
Capitolo 3. Riferimento al Composer 47
Tabella 7. Operatore di comparazione (Continua)
RC>a > Maggiore di
RC>=a >= Maggiore di o uguale a
RC=a = Uguale a
RC!=a != Non uguale a
RC<>a <> Non uguale a
operando
Un numero intero compreso tra -2147483647 e 2147483647.
Ad esempio, è possibile definire un lavoro riuscito come lavoro che
termina con codice di ritorno minore o uguale a 3 come segue:
rccondsucc "(RC <= 3)"
Espressione booleana
Specifica una combinazione logica di espressioni di comparazione.
La sintassi é:
espressione_comparazione operatore espressione_comparazione
espressione_comparazione
L’espressione viene valutata da sinistra a destra. È
possibile utilizzare le parentesi per assegnare una priorità
alla valutazione dell’espressione.
operatore
Operatore logico. Può avere i seguenti valori:
Tabella 8. Operatori logici
Esempio Operatore Risultato
expr_a and expr_b And TRUE se sia expr_a che
expr_b sono TRUE.
expr_a o expr_b Or TRUE se o expr_a o expr_b è
TRUE.
Not expr_a Not TRUE se expr_a non è TRUE.
Ad esempio, è possibile definire un lavoro riuscito come lavoro che
termina con codice di ritorno minore o uguale a 3 o non uguale a 5
e minore di 10 come segue:
rccondsucc "(RC=3) OR ((RC>=5) AND (RC<10))"
recovery
Opzioni di ripristino del lavoro. Il valore di default è stop senza alcun
lavoro di ripristino e nessun prompt di ripristino. Immettere una delle
opzioni di ripristino, stop, continue o rerun. Questa può essere seguita da
un lavoro di ripristino, un prompt di ripristino o da entrambi.
arresta
Se il lavoro viene interrotto in modo anomalo, non continuare con
il lavoro successivo.
continue
Se il lavoro viene interrotto in modo anomalo, continuare con il
lavoro successivo.
rerun Se il lavoro viene interrotto in modo anomalo, rieseguirlo.
48 IBM Tivoli Workload Scheduler - Manuale di riferimento
after [wkstation#]jobname
Specifica il nome di un lavoro di ripristino da eseguire se il lavoro
parent viene interrotto in modo anomalo. I lavori di ripristino
vengono interrotti solo una volta per ogni istanza del lavoro parent
interrotta in modo anomalo.
E’ possibile specificare una workstation del lavoro di ripristino se è
diversa dalla workstation del lavoro parent. Il valore di default è la
workstation del lavoro parent. Non tutti i lavori possono avere
lavori di ripristino in esecuzione su una workstation differente.
Seguire queste istruzioni:
v Se una workstation è un XA (agent esteso), deve trovarsi su un
DM o su un FTA con un valore on per fullstatus.
v La workstation del lavoro di ripristino deve trovarsi nello steso
dominio della workstation del lavoro parent.
v Se la workstation del lavoro di ripristino è un agent tollerante
l’errore, è necessario disporre di on per fullstatus.
abendprompt “text”
Specifica il testo di un prompt di ripristino, racchiuso tra apici, che
viene visualizzato se il lavoro viene interrotto in modo anomalo. Il
testo può contenere fino a 64 caratteri. Se il testo inizia con i due
punti (:), il prompt viene visualizzato ma non è necessaria alcuna
risposta per continuare l’elaborazione. Se il testo inizia con un
punto esclamativo (!), il prompt non viene visualizzato, ma è
necessaria una risposta per proseguire.
La seguente tabella riepiloga tutte le combinazioni possibili delle opzioni e
delle operazioni di ripristino. La tabella si basa sul seguente criterio da un
flusso di lavoro definito sked1:
v Il flusso di lavoro sked1 dispone di due lavori, job1 e job2.
v Se selezionato per job1, il lavoro di ripristino è jobr.
v job2 dipende da job1 e non sarà avviato fino a che job1 non è completo.
Arresta Continua Riesegui
Prompt di richiesta:
No Lavoro di
ripristino: No
E’ necessario
l’intervento.
Eseguire job2. Rieseguire job1. Se
job1 viene interrotto
in modalità anomala,
emettere il prompt
dello scheduler. Se la
risposta è SI’, ripetere
il passo precedente.
Se job1 ha avuto esito
positivo, eseguire
job2.
Prompt di richiesta:
Sì Lavoro di
ripristino: No
Emettere il
prompt di
ripristino. E’
necessario
l’intervento.
Emettere il
prompt di
ripristino. Se la
risposta è sì,
eseguire job2.
Emettere il prompt di
ripristino. Se la
risposta è yes,
rieseguire job1. Se
job1 termina in
modalità anomala,
ripetere il passo
precedente. Se job1
ha avuto esito
positivo, eseguire
job2.
Capitolo 3. Riferimento al Composer 49
Arresta Continua Riesegui
Prompt di ripristino:
No Lavoro di
ripristino: Yes
Eseguire jobr. Se
termina in
modalità
anomala, è
necessario
l’intervento. Se
ha avuto esito
positivo,
eseguire job2.
Eseguire jobr.
Eseguire job2.
Eseguire jobr. Se jobr
termina in modalità
anomala, è necessario
l’intervento. Se jobr
ha esito positivo,
rieseguire job1. Se
job1 viene interrotto
in modalità anomala,
emettere il prompt
dello scheduler. Se la
risposta è SI’, ripetere
il passo precedente.
Se job1 ha avuto esito
positivo, eseguire
job2.
Prompt di ripristino:
SI Lavoro di
ripristino: SI
Emettere il
prompt di
ripristino. Se la
risposta è sì,
eseguire jobr. Se
termina in
modalità
anomala, è
necessario
l’intervento. Se
ha avuto esito
positivo,
eseguire job2.
Emettere il
prompt di
ripristino. Se la
risposta è sì,
eseguire jobr.
Eseguire job2.
Emettere il prompt di
ripristino. Se la
risposta è sì, eseguire
jobr. Se jobr termina
in modalità anomala,
è necessario
l’intervento. Se jobr
ha esito positivo,
rieseguire job1. Se
job1 termina in
modalità anomala,
ripetere il passo
precedente. Se job1
ha avuto esito
positivo, eseguire
job2.
Note:
1. ″L’intervento è necessario″ indica che job2 non viene rilasciato dalla sua
dipendenza su job1 e deve essere rilasciato dall’operatore.
2. L’opzione di ripristino continue sostituisce lo stato Fine anomala, in
questo modo la pianificazione che contiene il lavoro terminato in modo
anomalo potrebbe essere contrassegnata come riuscita. Ciò impedirà la
prosecuzione della pianificazione il giorno successivo.
3. Se si seleziona l’opzione Riesegui senza fornire un prompt di ripristino,
lo scheduler crea il proprio prompt.
4. Per fare riferimento ad un lavoro di ripristino in Conman, è necessario
utilizzare il nome del lavoro originale (Job1 nello scenario precedente,
non jobr). I lavori di ripristino vengono eseguiti solo per abend.
Utilizzo dei parametri nelle definizioni lavoro: I parametri, nelle definizioni
lavoro, hanno i seguenti utilizzi e limitazioni:
v I parametri sono consentiti nei valori streamlogon, scriptname e docommand.
v Un parametro può essere utilizzato come stringa intera o come parte di essa.
v Più parametri sono consentiti in una variabile singola.
v Racchiudere i nomi parametri tra segni di omissione (^) e la stringa intera tra
apici.
50 IBM Tivoli Workload Scheduler - Manuale di riferimento
v Assicurarsi che i segni di omissione non siano preceduti da una barra retroversa
nella stringa. Se ciò si verifica, spostare la barra retroversa nella definizione del
parametro tra i segni di omissione. Ad esempio, invece di immettere la seguente
definizione di parametri:
$PARM
MYDIR "scripts"
job01 scriptname "c:\pippo\home\^MYDIR^\test.cmd"
immettere:
$PARM
MYDIR "\scripts"
job01 scriptname "c:\pippo\home^MYDIR^\test.cmd"
Nell’esempio riportato di seguito viene utilizzato un parametro denominato mis
nel valore streamlogon. Per ulteriori esempi, consultare “Definizioni parametro” a
pagina 55.
Esempi
Quanto segue è un file che contiene definizioni lavoro:
$jobs
cpu1#gl1
scriptname "/usr/acct/scripts/gl1"
streamlogon acct
description "general ledger job1"
bkup
scriptname "/usr/mis/scripts/bkup"
streamlogon "^mis^"
recovery continue after recjob1
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione di una definizione di lavoro nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 51
Definizioni utente
I nomi dell’utente utilizzati come valore streamlogon per le definizioni lavoro di
Windows devono avere le definizioni dell’utente. Ciò non è necessario per gli
utenti che eseguono i lavori su altre piattaforme. Ogni definizione utente presenta
il seguente formato:
Sintesi
# comment
username[wkstation#]username
password “password”
end
[username ...]
Argomenti
# comment
Indica che tutto ciò che si trova dopo il segno cancelletto è un commento.
username [wkstation#]username
Specifica il nome di un utente Windows.
wkstation
Specifica la workstation su cui all’utente è consentito avviare i
lavori. E’ necessario il segno del cancelletto. Il valore di default è il
vuoto, indicando tutte le workstation.
username
Specifica il nome dell’utente nel seguente formato:
[domain\]user
dove domain è il dominio Windows dell’utente e user è il nome
dell’utente.
Il nome dominio può contenere fino a 16 caratteri (incluse le barre
retroverse) e il nome dell’utente può contenere fino a 31 caratteri.
Tenere presente che i nomi utente di Windows sono sensibili al
maiuscolo/minuscolo. Inoltre, l’utente deve essere capace di
collegarsi alla workstation su cui verranno inviati i lavori dallo
scheduler e deve avere il diritto di Effettuare il log on come batch.
Se il nome non è univoco in Windows, verrà considerato come
utente locale, un utente dominio o un utente dominio trusted in
questo ordine.
password
Specifica la password dell’utente. La password può contenere fino a 29
caratteri e deve essere racchiusa tra apici. Per non indicare alcuna
password, utilizzare due apici consecutivi senza spazi (″″). Una volta
compilata la definizione dell’utente, non è possibile leggere la password.
Gli utenti con privilegi di sicurezza appropriati possono modificare o
cancellare un utente, ma le informazioni sulla password non vengono mai
visualizzate.
Utilizzo delle definizioni utente Tivoli Workload Scheduler: In Windows, le
definizioni utente vengono specificate utilizzando il composer nel formato
[wkstation#]username. Il nome della workstation è facoltativo; la sua assenza indica
tutte le workstation in esecuzione su Widows nella rete Tivoli Workload Scheduler.
52 IBM Tivoli Workload Scheduler - Manuale di riferimento
Quando si definisce o si inoltra un lavoro con il composer, è necessario specificare
una workstation ed un logon utente valido per la workstation. Il logon in questi
casi è solo un nome utente username— valido per Windows— senza il nome della
workstation. Ad esempio, nella seguente definizione del lavoro:
$JOB
wkstation job01 docommand "dir"
streamlogon username
il valore per streamlogon è username e non wkstation#username.
Tuttavia, quando si esegue il comando altpass, è necessario utilizzare la
definizione utente nel formato
wkstation#username
Per questo comando, è possibile omettere il nome della workstation solo nel caso
in cui viene modificata la password della workstation dalla postazione in cui viene
eseguito il comando.
Utente dominio trusted: Se lo scheduler deve avviare i lavori per un utente
dominio trusted, prestare particolare attenzione alla definizione degli account
dell’utente. Presumendo che lo scheduler sia installato in Domain1 per l’account
utente maestro e che l’account utente sue in Domain2 debba avviare un lavoro, è
necessario che quanto segue sia true:
v Deve esistere fiducia reciproca tra Domain1 e Domain2.
v In Domain1 sui computer dove vengono avviati i lavori, sue deve avere il
diritto di Effettuare il log on come batch.
v In Domain1, maestro deve essere un utente dominio.
v Sui programmi di controllo del dominio in Domain2, maestro deve avere il
diritto di Accedere a questo computer dalla rete.
Esempi
Il seguente esempio definisce quattro utenti:
username joe
password "okidoki"
end
#
username server#jane
password "okitay"
end
#
username dom1\jane
password "righto"
end
#
username jack
password ""
end
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione di un utente Windows nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 53
Definizioni calendario
I calendari sono elenchi di dati che possono essere utilizzati per pianificare i flussi
di lavoro. Le definizioni del calendario vengono immesse utilizzando il comando
di modifica del composer. Quando si immette il comando, il composer copia l’elenco
completo di definizioni calendario in un file di modifica e avvia un editor dove è
possibile modificare l’elenco. Ogni definizione calendario presenta il seguente
formato:
Sintesi
$calendar
calendarname [“description”]
date [...]
[calendarname ...]
Argomenti
calendarname
Specifica il nome del calendario. Il nome può contenere fino a otto caratteri
alfanumerici, che includono i trattini (-) e i caratteri di sottolineatura (_) e
deve cominciare con una lettera.
“description”
Fornisce una descrizione del calendario. E’ necessario che sia racchiuso tra
doppi apici. Può contenere caratteri alfanumerici purché inizi con una
lettera. Può contenere i seguenti caratteri: virgola (,), punto (.), trattino (-),
più (+), singolo apice (’), e uguale (=). Non può contenere doppi apici (″)
oltre a quelli che racchiudono la descrizione, due punti (:), punto e virgola
(;), ed E commerciale (&).
date [...]
Specifica una o più date, separate da spazi. Il formato è mm/gg/aa.
Esempi
Il seguente esempio definisce tre calendari definiti monthend, paydays e holidays:
$calendar
monthend "Month end dates 1st half ’99"
01/31/99 02/28/99 03/31/99 04/30/99 05/31/99 06/30/99
paydays
01/15/99 02/15/99
03/15/99 04/15/99
05/14/99 06/15/99
holidays
01/01/99 02/15/99 05/31/99
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione di un calendario del manuale Guida per l’utente di
IBM Tivoli Workload Scheduler Job Scheduling Console.
54 IBM Tivoli Workload Scheduler - Manuale di riferimento
Definizioni parametro
I parametri sono i valori che sostituiscono le variabili nelle definizioni del lavoro e
del flusso di lavoro quando viene creato il nuovo piano di produzione. Le
definizioni parametro vengono immesse utilizzando il comando di modifica del
composer. Quando si immette il comando, il composer copia l’elenco completo di
definizioni parametro in un file di modifica e avvia un editor dove è possibile
modificare l’elenco. Ogni definizione parametro presenta il seguente formato:
Sintesi
$parm
parametername “value”
[parametername ...]
Argomenti
parametername
Il nome del parametro. Il nome può contenere fino a otto caratteri
alfanumerici, che includono i trattini (-) e i caratteri di sottolineatura (_) e
deve cominciare con una lettera.
value Specifica il valore assegnato al parametro. Non devono essere inseriti nomi
di altri parametri.
Note sull’utilizzo
I parametri sono accessibili a tutti i lavori, i flussi di lavoro e i prompt. Se utilizzati
durante la pianificazione, i nomi di parametri vengono sostituiti dai relativi valori,
quando il piano di produzione viene compilato per un nuovo giorno di
elaborazione.
È possibile utilizzare più parametri in una variabile singola. Quando si utilizza un
parametro, racchiuderlo tra segni di omissione (^) e racchiudere l’intera stringa tra
doppi apici. Assicurarsi che i segni di omissione non siano preceduti da una barra
retroversa nella stringa. Se ciò si verifica, spostare la barra retroversa nella
definizione del parametro tra i segni di omissione. Ad esempio, invece di
immettere la seguente definizione di parametri:
$PARM
MYDIR "scripts"
job01 scriptname "c:\pippo\home\^MYDIR^\test.cmd"
immettere:
$PARM
MYDIR "\scripts"
job01 scriptname "c:\pippo\home^MYDIR^\test.cmd"
Esempi
I due parametri, glpath e gllogon, sono definiti nel modo seguente:
$parm
glpath "/glfiles/daily"
gllogon "gluser"
I parametri glpath and gllogon vengono utilizzati nel lavoro gljob2 del flusso di
lavoro glsched:
schedule glsched on weekdays
:
gljob2
scriptname "/usr/gl^glpath^"
Capitolo 3. Riferimento al Composer 55
streamlogon "^gllogon^"
opens "^glpath^/datafile"
prompt ":^glpath^ started by ^gllogon^"
end
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione di un parametro del manuale Guida per l’utente di
IBM Tivoli Workload Scheduler Job Scheduling Console.
56 IBM Tivoli Workload Scheduler - Manuale di riferimento
Definizioni prompt
E’ possibile utilizzare i prompt come dipendenze nei lavori e nei flussi di lavoro. Il
prompt viene definito da un nome univoco associato a un messaggio di testo e,
affinché venga avviato un lavoro dipendente o un flusso di lavoro, è necessario che
riceva una risposta affermativa. Le definizioni dei prompt vengono immesse
utilizzando il comando di modifica del composer. Quando si immette il comando, il
composer copia l’elenco completo di definizioni dei prompt in un file di modifica e
avvia un editor dove è possibile modificare l’elenco.
Esistono due tipi di prompt:
v ad hoc o locale
v predefinito o globale
Un prompt locale viene definito all’interno delle proprietà di un lavoro o flusso di
lavoro ed è univoco per quel lavoro o flusso di lavoro.
Un prompt globale viene definito nel database dello scheduler e può essere
utilizzato da un lavoro o da un flusso di lavoro.
Nota: Le definizioni di prompt predefinite o globali vengono preimpostate ogni
volta che viene eseguito il comando Jnextday.
Sintesi
$prompt
promptname “[: | !]text”
[promptname ...]
Argomenti
promptname
Specifica il nome del prompt. Il nome può contenere fino a otto caratteri
alfanumerici, che includono i trattini (-) e i caratteri di sottolineatura (_) e
deve cominciare con una lettera.
text
Fornisce il testo del prompt. Se il testo inizia con i due punti (:), il prompt
viene visualizzato ma non è necessaria alcuna risposta per continuare
l’elaborazione. Se il testo inizia con un punto esclamativo (!)il prompt non
viene visualizzato, ma è necessaria una risposta per continuare.
E’ possibile utilizzare uno o più parametri come parte o totalità della
stringa di testo di un prompt. Se si utilizza un parametro, la stringa
parametro deve essere racchiusa tra segni di omissione (^). Consultare
“Definizioni parametro” a pagina 55 per un esempio.
Nota: In un prompt locale, quando non si indica un parametro, i segni di
omissione (^) devono essere preceduti da una barra retroversa (\)
oppure causeranno errori nel prompt. Nei prompt globali, i segni di
omissione non devono essere preceduti da una barra retroversa.
E’ possibile includere una barra retroversa n (\n) nel testo per creare una
nuova riga.
Esempi
Il seguente esempio definisce tre prompt:
Capitolo 3. Riferimento al Composer 57
$prompt
prmt1 "ready for job4? (y/n)"
prmt2 ":job4 launched"
prmt3 "!continue?"
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione di un prompt nel manuale Guida per l’utente di
IBM Tivoli Workload Scheduler Job Scheduling Console.
58 IBM Tivoli Workload Scheduler - Manuale di riferimento
Definizioni risorsa
Le risorse rappresentano risorse di pianificazione logiche o fisiche che possono
essere utilizzate come dipendenze per i lavori e i flussi di lavoro. Le definizioni
delle risorse vengono immesse utilizzando il comando di modifica del composer.
Quando si immette il comando, il composer copia l’elenco completo di definizioni
delle risorse in un file di modifica e avvia un editor dove è possibile modificare
l’elenco. Ogni definizione risorsa presenta il seguente formato:
Sintesi
$resource
wkstation#resourcename units [“description” ]
[wkstation#resourcename ...]
Argomenti
wkstation
Specifica il nome della workstation o della classe workstation su cui viene
utilizzata la risorsa.
resourcename
Specifica il nome della risorsa. Il nome può contenere fino a otto caratteri
alfanumerici, che includono i trattini (-) e i caratteri di sottolineatura (_) e
deve cominciare con una lettera.
units Specifica il numero di unità di risorse disponibili. I valori possono essere
tra 0 e 1024.
“description”
Fornisce una descrizione della risorsa. E’ necessario che sia racchiuso tra
doppi apici.
Esempi
Il seguente esempio definisce quattro risorse:
$resource
ux1#tapes 3 "tape units"
ux1#jobslots 24 "job slots"
ux2#tapes 2 "tape units"
ux2#jobslots 16 "job slots"
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione di una risorsa distribuita nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 59
Programma Composer
Il programma Composer gestisce gli oggetti di pianificazione nel database dello
scheduler.
Esecuzione del composer
Per eseguire il programma, utilizzare il seguente comando:
composer [″command[&[command]][...]″]
Seguono alcuni esempi del comando:
v Esegue il composer e i prompt per un comando:
composer
v Esegue i comandi print e version e viene terminato:
composer "p parms&v"
v Esegue i comandi print e version ed effettua i prompt per un comando:
composer "p parms&v&"
v Legge i comandi da cmdfile:
composer < cmdfile
v Trasmette i comandi da cmdfile al Composer:
cat cmdfile | composer
Caratteri di controllo
È possibile immettere i seguenti caratteri di controllo in modalità interattiva per
interrompere il composer se le impostazioni stty sono state configurate a tale scopo.
Ctrl+c Il composer arresta l’esecuzione del comando corrente e restituisce un
prompt del comando.
Ctrl+d Dopo l’esecuzione del comando corrente il composer viene interrotto.
Output terminale
L’output sul computer viene controllato dalle variabili shell definite
MAESTROLINES e MAESTROCOLUMNS. Se non è stata impostata alcuna
variabile, vengono utilizzate le variabili shell standard LINES e COLUMNS. Alla
fine di ogni pagina dello schermo, il Composer effettua un prompt per continuare.
Se MAESTROLINES (o LINES) viene impostato su zero o su un numero negativo,
il Composer non si arresta alla fine di una pagina.
Output non in linea
L’opzione ;offline nei comandi Composer viene generalmente utilizzata per
stampare l’output di un comando. Quando la si include, le seguenti variabili
controllano l’output:
Variabili Windows:
$MAESTROLP
Specifica il file in cui viene scritto un output del comando. Il valore di
default è stdout.
$MAESTROLPLINES
Specifica il numero di righe per pagina. Il valore di default è 60.
$MAESTROLPCOLUMNS
Specifica il numero di caratteri per riga. Il valore di default è 132.
60 IBM Tivoli Workload Scheduler - Manuale di riferimento
Variabili UNIX: L’opzione ;offline nei comandi Composer viene generalmente
utilizzata per stampare l’output di un comando. Quando la si include, le seguenti
variabili shell controllano l’output:
$MAESTROLP
Specifica la destinazione di un output del comando. Impostarla su uno dei
seguenti:
> file Reindirizza l’output ad un file e sovrascrive il contenuto del file. Se
il file non esiste, viene creato.
>> file Reindirizza l’output su un file e accoda l’output alla fine del file.
Se il file non esiste, viene creato.
| comando
Associa l’output a un processo o comando di sistema. Il comando
di sistema viene eseguito che venga creato o meno l’output.
|| command
Associa l’output a un processo o comando di sistema. Se non esiste
alcun output, il comando di sistema non viene eseguito.
Il valore di default è | lp -tCONLIST, il quale indirizza l’output del
comando alla stampante e inserisce il titolo “CONLIST” nella pagina
banner di stampa.
$MAESTROLPLINES
Specifica il numero di righe per pagina. Il valore di default è 60.
$MAESTROLPCOLUMNS
Specifica il numero di caratteri per riga. Il valore di default è 132.
E’ necessario esportare le variabili prima di eseguire il Composer.
Editor del composer
Diversi comandi Composer aprono automaticamente un editor di testo. E’ possibile
selezionare l’editor che Composer desidera utilizzare.
Windows: In Windows, l’editor di default è l’editor MS-DOS ‘edit’. Questo editor,
tuttavia, segue la convenzione di denominazione 8.3 che può rappresentare un
limite nel momento in cui il composer la utilizza per modificare gli oggetti del
database. Se il nome dell’oggetto è più lungo di 8.3 caratteri, il comando MODIFY
del Composer incorrerà in un errore. Si consiglia di utilizzare un altro editor, come
Notepad. Per modificare l’editor, impostare la variabile EDITOR sul nome del
nuovo editor prima di eseguire il Composer.
UNIX: Diversi comandi Composer aprono automaticamente l’editor di testo. Il
tipo di editor viene stabilito dal valore delle due variabili shell. Se la variabile
VISUAL è impostata, definisce l’editor, altrimenti viene definita variabile EDITOR.
Se non è impostata nessuna delle variabili, viene aperto un editor vi.
Selezione del prompt del comando composer su UNIX
Il prompt del comando composer viene definito nel file TWShome/localopts. Il
prompt del comando di default è un trattino (-). Per selezionare un prompt
differente, modificare l’opzione del prompt del composer nel file localopts e
modificare il trattino. Il prompt può essere lunga fino a dieci caratteri, che non
includono il segno del cancelletto (#) desiderato:
#----------------------------------------------------------------------------
# Custom format attributes
#
date format = 1 # The possible values are 0-ymd, 1-mdy,
Capitolo 3. Riferimento al Composer 61
2-dmy, 3-NLS.
composer prompt = -
conman prompt = %
switch sym prompt = <n>%
#----------------------------------------------------------------------------
Sintassi dei comandi
I comandi Composer sono composti dai seguenti elementi:
argomenti di selezione commandname
dove:
commandname
Specifica il nome del comando.
selection
Specifica l’oggetto o la serie di oggetti da eseguire.
arguments
Specifica gli argomenti del comando.
Caratteri jolly
In alcuni comandi Composer sono consentiti i seguenti caratteri jolly:
@ Sostituisce uno o più caratteri alfanumerici.
? Sostituisce un carattere alfanumerico.
% Sostituisce un carattere numerico.
Delimitatori e caratteri speciali
I seguenti caratteri hanno significati speciali nei comandi Composer.
Carattere Descrizione
& Delimitatore comando. Consultare “Esecuzione del composer” a pagina
60.
; Delimitatore argomenti. Ad esempio:
;info;offline
= Delimitatore valori. Ad esempio:
sched=sked5
: ! Prefissi del comando che inviano il comando al sistema. Questi prefissi
sono facoltativi; se Composer non riconosce il comando, viene inoltrato
automaticamente al sistema. Ad esempio:
!ls o :ls
<< >> Parentesi di commento. I commenti possono essere posizionati su una
singola riga in qualunque posto di un flusso di lavoro. Ad esempio:
schedule foo <<comment>> on everyday
* Prefisso commento. Quando questo prefisso è il primo carattere su una
riga, l’intera riga è un commento. Quando il prefisso segue un comando,
la parte restante della riga è un commento. Ad esempio:
*comment
o
print& *comment
> Reindirizza l’output del comando ad un file e sovrascrive il contenuto
del file. Se il file non esiste, viene creato. Ad esempio:
display parms > parmlist
62 IBM Tivoli Workload Scheduler - Manuale di riferimento
Carattere Descrizione
>> Reindirizza l’output del comando ad un file e accoda l’output alla fine
del file. Se il file non esiste, viene creato. Ad esempio:
display parms >> parmlist
| Associa l’output del comando ad un processo o ad un comando di
sistema. Il comando di sistema viene eseguito che venga creato o meno
l’output. Ad esempio:
display parms | grep alparm
|| Associa l’output del comando ad un processo o ad un comando di
sistema. Se non esiste alcun output, il comando di sistema non viene
eseguito. Ad esempio:
display parms || grep alparm
Descrizioni comandi
Le seguenti pagine descrivono i comandi del Composer.
Comando Descrizione Pagina
add Aggiunge gli oggetti di pianificazione. “add” a
pagina 65
build Crea o crea nuovamente un file IBM Tivoli Workload
Scheduler.
“build” a
pagina 66
continue Ignora l’errore successivo. “continue” a
pagina 67
create Crea un file per la modifica. “create” a
pagina 68
delete Cancella gli oggetti di pianificazione. “delete” a
pagina 70
display Visualizza gli oggetti di pianificazione. “display, list,
print” a
pagina 72
edit Modifica un file. “edit” a
pagina 75
exit Termina il Composer. “exit” a
pagina 76
list Elenca gli oggetti di pianificazione. “display, list,
print” a
pagina 72
modify Modifica gli oggetti di pianificazione. “modify” a
pagina 77
new Modifica e aggiunge gli oggetti di pianificazione. “new” a
pagina 79
print Stampa gli oggetti di pianificazione. “display, list,
print” a
pagina 72
redo Modifica il comando precedente. “redo” a
pagina 80
replace Sostituisce gli oggetti di pianificazione. “replace” a
pagina 82
Capitolo 3. Riferimento al Composer 63
Comando Descrizione Pagina
validate Convalida un file. “validate” a
pagina 84
version Visualizza il banner del programma Composer. “version” a
pagina 85
system command Invia un comando di sistema al sistema. “system,
comando” a
pagina 83
E’ possibile immettere i nomi dei comandi e le parole chiave sia in caratteri
maiuscoli sia in caratteri minuscoli. Inoltre è possibile abbreviarli in modo da
poterli distinguere tra loro.
64 IBM Tivoli Workload Scheduler - Manuale di riferimento
add
Aggiunge i lavori, i flussi di lavoro, gli utenti, le workstation, le classi della
workstation e i domini. E’ necessario disporre dell’accesso add per i nuovi oggetti.
Se un oggetto già esiste, è necessario disporre dell’accesso modify all’oggetto.
Sintesi
add filename
Argomenti
filename
Specifica il nome di un file che contiene quanto segue:
v Definizioni lavoro. (La prima riga del file deve essere $jobs.)
v Definizioni flusso di lavoro.
v Qualsiasi combinazione di workstation, classi della workstation e di
definizioni dominio.
v Definizioni utente.
Note sull’utilizzo
La sintassi del file viene sempre controllata prima che sia scritta sul database.
Vengono riportati tutti gli errori e le avvertenze. Se sono presenti errori di sintassi,
l’utente deve modificare il file per apportare delle correzioni. Se esiste già un
oggetto, all’utente viene richiesto di sostituirlo o meno.
Esempi
Per aggiungere i lavori dal file myjobs, eseguire il comando:
add myjobs
Per aggiungere i flussi di lavoro dal file mysked, eseguire il comando:
a mysked
Per aggiungere le workstation, le classi della workstation e i domini dal file
cpus.src, eseguire il comando:
a cpus.src
Per aggiungere le definizioni utente dal file users_nt, eseguire il comando:
a users_nt
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa al controllo delle attività nel manuale Guida per l’utente di IBM
Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 65
build
Crea o crea nuovamente i file database dello scheduler. E’ necessario disporre
dell’accesso build al file.
Se si implementa il fix pack 8.2-TWS-FP04, è possibile utilizzare questo comando
mentre IBM Tivoli Workload Scheduler è in esecuzione. Se non è stato
implementato questo fix pack o uno successivo, si consiglia di arrestare tutti i
processi di IBM Tivoli Workload Scheduler prima di eseguire questo comando.
Synopsis
build filename
Arguments
database file name
Specifica uno dei seguenti nomi di file:
calendars
Il file che contiene le definizioni calendario.
cpudata
Il file che contiene la workstation, la classe workstation e le
definizioni del dominio.
jobs Il file che contiene le definizioni lavoro.
mastsked
Il file che contiene le definizioni del flusso di lavoro.
parms Il file che contiene le definizioni del parametro.
prompts
Il file che contiene le definizioni del prompt.
resources
Il file che contiene le definizioni della risorsa.
userdata
Il file che contiene le definizioni dell’utente.
Usage Notes
Se non esiste alcun file, ne viene creato uno. Se il file esiste, viene ricostruito. La
nuova creazione di un file database può essere utile quando il database viene
frammentato da numerose aggiunte e cancellazioni. La nuova creazione rimuoverà
i record non utilizzati e ottimizzerà le chiavi.
Esempi
Per creare nuovamente i file che contengono le definizioni del flusso di lavoro,
eseguire il comando:
build mastsked
Per creare nuovamente il file che contiene i calendari, eseguire il comando:
build calendars
Per creare nuovamente il file che contiene le workstation, eseguire il comando:
b cpudata
66 IBM Tivoli Workload Scheduler - Manuale di riferimento
continue
Specifica di ignorare il successivo errore del comando.
Synopsis
continue
Usage Notes
Questo comando è utile quando vengono immessi più comandi sulla riga comandi
o viene reindirizzato da un file. Esso istruisce il Composer su come continuare
l’esecuzione dei comandi anche se il comando successivo, che segue continue, è in
errore. Questo comando non è necessario quando si immettono i comandi
interattivamente, poiché il Composer non sarà interrotto in caso di errore.
Examples
Se si desidera che il Composer continui con il comando print quando il comando
delete determina un errore, eseguire il comando:
composer "continue&delete cpu=site4&print cpu=@"
Capitolo 3. Riferimento al Composer 67
create
Crea un file che contiene le definizioni oggetto. E’ necessario disporre dell’accesso
display agli oggetti copiati.
Sintesi
create filename from calendars | parms | prompts | resources
| cpu={wkstation | wkstationclass | domain} |
jobs=[wkstation#]jobname |
sched=[wkstation#]jstream |
users=[wkstation#]username
Argomenti
filename
Specifica un nome file.
calendars
Copia tutti i calendari nel file.
parms Copia tutti i parametri nel file.
prompts
Copia tutti i prompt nel file.
resources
Copia tutte le risorse nel file.
cpu Copia una workstation, una classe workstation o un dominio nel file.
wkstation
Il nome delle workstation. Sono consentiti caratteri jolly.
wkstationclass
Il nome della classe workstation. Sono consentiti caratteri jolly.
domain Il nome dominio. Sono consentiti caratteri jolly.
jobs Copia tutti i lavori nel file.
wkstation
Il nome della workstation o della classe workstation su cui è in
esecuzione il lavoro. Sono consentiti caratteri jolly. Il valore di
default è la workstation su cui è in esecuzione il Composer.
jobname
Il nome lavoro. Sono consentiti caratteri jolly.
sched Copia i flussi di lavoro nel file.
wkstation
Il nome della workstation o della classe workstation su cui è in
esecuzione il flusso di lavoro. Sono consentiti caratteri jolly. Il
valore di default è la workstation su cui è in esecuzione il
Composer.
jstream Il nome del flusso di lavoro. Sono consentiti caratteri jolly.
users Copia gli utenti nel file. Il campo della password non è stato copiato per
motivi di sicurezza.
68 IBM Tivoli Workload Scheduler - Manuale di riferimento
wkstation
Il nome della workstation su cui viene definito l’utente. Sono
consentiti caratteri jolly. Il valore di default è la workstation su cui
è in esecuzione il Composer.
username
Il nome utente. Sono consentiti caratteri jolly.
Nota: Si consiglia di creare regolarmente una copia di backup degli oggetti
memorizzati nel database.
Note sull’utilizzo
Dopo aver creato un file, è possibile utilizzare il comando edit per apportare delle
modifiche al file. Il comando add o replace può quindi essere utilizzato per
aggiungere o aggiornare la definizione.
Esempi
Per creare un file che contiene tutti i calendari, eseguire il comando:
create caltemp from calendars
Per creare un file che contiene tutti i flussi di lavoro, eseguire il comando:
cr stemp from sched=@
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa al controllo delle attività nel manuale Guida per l’utente di IBM
Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 69
delete
Cancella le definizioni oggetto dal database. E’ necessario disporre dell’accesso
delete agli oggetti che vengono cancellati.
Sintesi
delete cpu={wkstation | wkstationclass | domain} |
jobs=[wkstation#]jobname |
sched=[wkstation#]jstream |
users=[wkstation#]username
Argomenti
cpu Elimina workstation, classi di workstation o domini.
wkstation
Il nome delle workstation. Sono consentiti caratteri jolly.
wkstationclass
Il nome della classe workstation. Sono consentiti caratteri jolly.
domain Il nome dominio. Sono consentiti caratteri jolly.
jobs Elimina i lavori.
wkstation
Il nome della workstation o della classe workstation su cui è in
esecuzione il lavoro. Sono consentiti caratteri jolly. Il valore di
default è la workstation su cui è in esecuzione il Composer.
jobname
Il nome lavoro. Sono consentiti caratteri jolly.
sched Elimina i flussi di lavoro.
wkstation
Il nome della workstation o della classe workstation su cui è in
esecuzione il flusso di lavoro. Sono consentiti caratteri jolly. Il
valore di default è la workstation su cui è in esecuzione il
Composer.
jstream Il nome del flusso di lavoro. Sono consentiti caratteri jolly.
users Elimina gli utenti.
wkstation
Il nome della workstation su cui viene definito l’utente. Sono
consentiti caratteri jolly. Il valore di default è la workstation su cui
è in esecuzione il Composer.
username
Il nome utente. Sono consentiti caratteri jolly.
Note sull’utilizzo
Se si utilizzano caratteri jolly per specificare una serie di definizioni, il Composer
richiede informazioni prima della cancellazione di ogni definizione corrispondente.
Esempi
Per eliminare job3 che viene avviato sulla workstation site3, eseguire il comando:
delete jobs=site3#job3
70 IBM Tivoli Workload Scheduler - Manuale di riferimento
Per eliminare tutte le workstation con i nomi che cominciano con ux, eseguire il
comando:
de cpu=ux@
Per eliminare tutti i flussi di lavoro con i nomi che cominciano con test su tutte le
workstation, eseguire il comando:
de sched=@#test@
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa al controllo delle attività nel manuale Guida per l’utente di IBM
Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 71
display, list, print
Visualizza, elenca o stampa le definizioni oggetto. Per i comandi display e print, è
necessario disporre dell’accesso display all’oggetto. Il comando display visualizza il
contenuto dell’oggetto database, mentre list e print visualizzano il nome e gli
attributi dell’oggetto database.
Sintesi
display | list | print calendars | parms | prompts | resources
| cpu={wkstation | wkstationclass | domain} |
jobs=[wkstation#]jobname |
sched=[wkstation#]jstream |
users=[wkstation#]username
Argomenti
calendars
Visualizza tutti i calendari.
parms Visualizza tutti i parametri.
prompts
Visualizza tutti i prompt.
resources
Visualizza tutte le risorse.
cpu Visualizza una workstation, una classe workstation o un dominio.
wkstation
Il nome delle workstation. Sono consentiti caratteri jolly.
wkstationclass
Il nome della classe workstation. Sono consentiti caratteri jolly.
domain Il nome dominio. Sono consentiti caratteri jolly.
jobs Visualizza un lavoro.
wkstation
Il nome della workstation o della classe workstation su cui è in
esecuzione il lavoro. Sono consentiti caratteri jolly. Il valore di
default è la workstation su cui è in esecuzione il Composer.
jobname
Il nome lavoro. Sono consentiti caratteri jolly.
sched Visualizza un flusso di lavoro.
wkstation
Il nome della workstation o della classe workstation su cui è in
esecuzione il flusso di lavoro. Sono consentiti caratteri jolly. Il
valore di default è la workstation su cui è in esecuzione il
Composer.
jstream Il nome del flusso di lavoro. Sono consentiti caratteri jolly.
users Visualizza un utente. (Il campo della password non è stato copiato per
motivi di sicurezza.)
wkstation
Il nome della workstation su cui viene definito l’utente. Sono
consentiti caratteri jolly. Il valore di default è la workstation su cui
è in esecuzione il Composer.
72 IBM Tivoli Workload Scheduler - Manuale di riferimento
username
Il nome utente. Sono consentiti caratteri jolly.
Output del comando
Il comando list visualizza solo i nomi oggetto. L’output del comando print viene
controllato dalla variabile MAESTROLP. Per ulteriori informazioni, consultare
“Output non in linea” a pagina 60.
Formato calendari:
Calendar
Il nome calendario.
Descrizione
Una descrizione a modulo libero del calendario.
A questi campi fa seguito un elenco di date calendario.
Formato Cpu:
ID CPU
L’ID di una workstation, di una classe workstation o di un dominio.
Creatore
Il nome dell’utente che ha creato la definizione della workstation.
Ultimo aggiornamento
L’ultima data di aggiornamento della definizione della workstation.
A questi campi fa seguito la definizione della workstation o della classe
workstation.
Formato lavori:
ID CPU
Il nome della workstation su cui è in esecuzione il lavoro.
Lavoro
Il nome del lavoro.
Logon Il nome dell’utente di logon per il lavoro.
Ultima data di esecuzione
L’ultima data di esecuzione del lavoro.
A questi campi fa seguito la definizione lavoro.
Formato Parms:
Parametro
Il nome del parametro.
Valore Il valore del parametro.
Formato prompt:
Prompt
Il nome del prompt.
Messaggio
Il testo messaggio del prompt.
Formato risorse:
Capitolo 3. Riferimento al Composer 73
ID CPU
Il nome della workstation sulla quale è definita la risorsa.
Risorsa
Il nome della risorsa.
Num. disp
Il numero totale di unità di risorsa.
Descrizione
La descrizione a modulo libero della risorsa.
Formato pianificazione:
ID CPU
Il nome della workstation su cui è in esecuzione il flusso di lavoro.
Schedule
Il nome del flusso di lavoro.
Creatore
Il nome dell’utente che ha creato la definizione del flusso di lavoro.
Ultimo aggiornamento
L’ultima volta in cui è stata aggiornata la definizione del flusso di lavoro.
A questi campi fa seguito la definizione del flusso di lavoro.
Formato utenti:
ID CPU
Il nome della workstation su cui è consentita l’esecuzione dei lavori.
Utente
Il nome dell’utente.
Creatore
Il nome dell’utente che ha creato la definizione utente.
Ultimo aggiornamento
L’ultima volta in cui è stata aggiornata la definizione utente.
A questi campi fa seguito la definizione utente.
Esempi
Per visualizzare tutti i calendari, immettere il seguente comando:
display calendars
Per stampare tutti i flussi di lavoro che vengono avviati sulla workstation site2,
eseguire il comando:
di sched=site2#@;offline
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla gestione degli elenchi di oggetti nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
74 IBM Tivoli Workload Scheduler - Manuale di riferimento
edit
Modifica un file.
Sintesi
edit filename
Note sull’utilizzo
Viene avviato un editor e viene aperto il file specificato per la modifica. Per
ulteriori informazioni, consultare “Editor del composer” a pagina 61.
Esempi
Per aprire il file mytemp per la modifica, eseguire il comando:
edit mytemp
Per aprire il file resfile per la modifica, eseguire il comando:
ed resfile
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa al controllo delle attività nel manuale Guida per l’utente di IBM
Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 3. Riferimento al Composer 75
exit
Esce dal programma Composer.
Synopsis
exit
Usage Notes
Quando il programma Composer è in modalità di aiuto, questo comando riporta il
Composer in modalità di input del comando.
Examples
Per uscire dal programma Composer, eseguire il comando:
exit
o:
e
76 IBM Tivoli Workload Scheduler - Manuale di riferimento
modify
Modifica o aggiunge gli oggetti di pianificazione. E’ necessario disporre
dell’accesso modify all’oggetto o al file database interessato.
Sintesi
modify calendars | parms | prompts | resources |
cpu={wkstation | wkstationclass | domain} |
jobs=[wkstation#]jobname |
sched=[wkstation#]jstream |
users=[wkstation#]username
Argomenti
calendars
Modifica tutti i calendari.
parms Modifica tutti i parametri.
prompts
Modifica tutti i prompt.
resources
Modifica tutte le risorse.
cpu Modifica una workstation, una classe workstation o un dominio.
wkstation
Il nome delle workstation. Sono consentiti caratteri jolly.
wkstationclass
Il nome della classe workstation. Sono consentiti caratteri jolly.
domain Il nome dominio. Sono consentiti caratteri jolly.
jobs Modifica un lavoro.
wkstation
Il nome della workstation o della classe workstation su cui è in
esecuzione il lavoro. Sono consentiti caratteri jolly. Il valore di
default è la workstation su cui è in esecuzione il Composer.
jobname
Il nome lavoro. Sono consentiti caratteri jolly.
sched Modifica un flusso di lavoro.
wkstation
Il nome della workstation o della classe workstation su cui è in
esecuzione il flusso di lavoro. Sono consentiti caratteri jolly. Il
valore di default è la workstation su cui è in esecuzione il
Composer.
jstream Il nome del flusso di lavoro. Sono consentiti caratteri jolly.
users Modifica un utente.
wkstation
Il nome della workstation su cui viene definito l’utente. Sono
consentiti caratteri jolly. Il valore di default è la workstation su cui
è in esecuzione il Composer.
username
Il nome utente. Sono consentiti caratteri jolly.
Capitolo 3. Riferimento al Composer 77
Note sull’utilizzo
Il comando modify copia l’elenco di definizioni o di oggetti in un file temporaneo,
modifica il file e aggiunge il suo contenuto al file database appropriato. Ciò è
equivalente alla sequenza di comandi seguente:
create file from object-specification
edit file
add file
Se l’operazione di aggiunta ha esito positivo, il file di modifica viene eliminato. Per
ulteriori informazioni, fare riferimento alle descrizioni dei comandi create, edit e
add in questo capitolo.
Per le definizioni utente, se un campo della password rimane vuoto nel momento
in cui viene terminato l’editor, la vecchia password viene mantenuta. Per
specificare una password null utilizzare due doppi apici consecutivi (“”).
Esempi
Per modificare tutti i calendari, immettere il seguente comando:
modify calendars
Per modificare il flusso di lavoro sked9 che viene avviato sulla workstation site1,
eseguire il comando:
m sched=site1#sked9
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa al controllo delle attività nel manuale Guida per l’utente di IBM
Tivoli Workload Scheduler Job Scheduling Console.
78 IBM Tivoli Workload Scheduler - Manuale di riferimento
new
Aggiunge un nuovo oggetto di pianificazione. E’ necessario disporre dell’accesso
add per i nuovi oggetti nella workstation. Per gli oggetti esistenti, è necessario
disporre dell’accesso modify all’oggetto o al file database interessato.
Synopsis
new
Usage Notes
Il comando new crea un file temporaneo, modifica il file e aggiunge il contenuto
del file. Per i calendari, i parametri, le risorse e i prompt, utilizzare il comando
modify sulla pagina 77.
Examples
Per creare un file temporaneo, modificare il file e aggiungere il contenuto del file al
database, eseguire il comando:
new
o:
n
Capitolo 3. Riferimento al Composer 79
redo
Modifica ed esegue nuovamente il comando precedente.
Synopsis
redo
Contesto
Quando si esegue il comando redo, Composer visualizza il comando precedente, in
modo che possa essere modificato ed eseguito nuovamente. Utilizzare la barra
spaziatrice per spostare il cursore sotto il carattere da modificare e immettere le
seguenti direttive.
Direttive
d[dir] Cancella il carattere che precede la d. Questa operazione può
essere seguita da altre direttive.
itext Inserisce il testo prima del carattere che precede la i.
rtext Sostituisce uno o più caratteri con il testo, iniziando con il carattere
che precede la r. La sostituzione è implicita se non viene immessa
nessun altra direttiva.
>text Accoda il testo alla fine della riga.
>d[dir | text]
Cancella i caratteri alla fine della riga. Questa operazione può
essere seguita da un altra direttiva o un altro testo.
>rtext Sostituisce i caratteri alla fine della riga con il testo.
Esempi di direttive
ddd Cancella i tre caratteri che precedono la d.
iabc Inserisce l’abc prima del carattere che precede la i.
rabc Sostituisce i tre caratteri, cominciando da quello che precede la r
con abc.
abc Sostituisce i tre caratteri suabc con abc.
d diabc
Cancella il carattere che precede la prima d, ignora un carattere,
cancella il carattere che precede la seconda d e, al suo posto,
inserisce abc.
>abc Accoda abc alla fine della riga.
>ddabc
Cancella gli ultimi due caratteri nella riga e li sostituisce con abc.
>rabc Sostituisce gli ultimi tre caratteri nella riga con abc.
Examples
Per inserire un carattere, eseguire il comando:
redo
dislay site1#sa@
ip
display site1#sa@
Per sostituire un carattere, eseguire questo comando:
80 IBM Tivoli Workload Scheduler - Manuale di riferimento
replace
Sostituisce gli oggetti di pianificazione. E’ necessario disporre dell’accesso modify
agli oggetti o al file database interessato.
Synopsis
replace filename
Arguments
filename
Specifica il nome di un file che contiene uno dei seguenti:
v Definizioni lavoro. La prima riga del file deve essere $jobs.
v Definizioni flusso di lavoro.
v Qualsiasi combinazione di workstation, classi della workstation e di
definizioni dominio.
v Definizioni utente.
v Una serie completa di calendari, parametri o risorse.
Usage Notes
Il comando replace è simile al comando add, fatta eccezione del fatto che non
esiste alcun prompt che sostituisce gli oggetti esistenti. Per ulteriori informazioni,
fare riferimento a “add” a pagina 65.
Esempi
Per sostituire i lavori dal file myjobs, eseguire il comando:
replace myjobs
Per sostituire i flussi di lavoro dal file mysked, eseguire il comando:
rep mysked
Per sostituire tutte le risorse con quelle contenute nel file myres, eseguire il
comando:
rep myres
82 IBM Tivoli Workload Scheduler - Manuale di riferimento
system, comando
Esegue un comando di sistema.
Synopsis
[: | !] sys-command
Arguments
sys-command Specifica qualsiasi comando di sistema valido. Il prefisso
rappresentato dai due punti (:) o dal punto esclamativo (!) è
necessario solo quando il comando è scritto nello stesso modo del
comando Composer.
Examples
Per eseguire un comando ps su UNIX, immettere il comando:
ps -ef
Per eseguire un comando dir in Windows, immettere il comando:
dir \bin
Capitolo 3. Riferimento al Composer 83
validate
Convalida un file che contiene oggetti di pianificazione.
Synopsis
validate filename[;syntax]
Arguments
filename
Specifica il nome di un file che contiene calendari, workstation, domini,
lavori, parametri, prompt, risorse o flussi di lavoro. Immettere prodsked
per convalidare il file di pianificazione della produzione creato durante
l’elaborazione precedente al giorno di produzione.
syntax Controlla il file per errori di sintassi.
Usage Notes
Il comando validate esegue gli stessi controlli di sintassi o la stessa convalida
eseguiti nel momento in cui si aggiungono o si modificano oggetti. E’ possibile
inoltre utilizzarlo per convalidare il file di pianificazione della produzione,
prodsked, creato durante l’elaborazione anteriore al giorno di produzione.
Prodsked contiene i flussi di lavoro da eseguire in un giorno particolare e può
essere modificato con un editor. In questo modo possono essere inserite delle
modifiche ad hoc prima che inizi il giorno di elaborazione. In questi casi deve
essere utilizzato Validate per verificare che la pianificazione della produzione sia
ancora valida.
Per i flussi di lavoro, se viene omessa l’opzione della sintassi, la convalida e la
registrazione includono quanto segue:
v Verificare i nomi lavoro rispetto al file lavoro master.
v Esaminare le dipendenze per verificare che gli oggetti esistano. Ad esempio,
viene registrata una dipendenza needs su una risorsa non esistente. Ciò
controllerà anche i riferimenti a calendari non esistenti.
v Controllare le dipendenze circolari. Ad esempio, se job1 segue job2 e job2 segue
job1 esiste una dipendenza circolare.
L’output del comando validate può essere reindirizzato ad un file nel modo
seguente:
composer "validate filename" > outfile
Per includere messaggi di errore nel file di output, utilizzare quanto segue:
composer "validate filename" > outfile 2>&1
Esempi
Per controllare la sintassi di un file che contiene le definizioni della workstation,
eseguire il comando:
validate mycpus;syntax
Per convalidare di nuovo tutti i flussi di lavoro, eseguire il comando:
create allskeds from sched=@#@
validate allskeds
E’ possibile effettuare ciò per verificare l’integrità dei riferimenti su altri oggetti di
pianificazione dopo aver apportato delle modifiche.
84 IBM Tivoli Workload Scheduler - Manuale di riferimento
version
Visualizza il banner del programma Composer.
Synopsis
version
Examples
Per visualizzare il banner del programma Composer, eseguire il comando:
version
o:
v
Capitolo 3. Riferimento al Composer 85
Capitolo 4. Linguaggio di pianificazione
Questo capitolo descrive il modo in cui creare un flusso di lavoro, in base agli
oggetti di pianificazione definiti nel database, utilizzando il programma Composer.
I flussi di lavoro creati utilizzando la GUI non si riferiscono alle parole chiave
elencate in questo capitolo, ma tutti i flussi di lavoro nello scheduler vengono
salvati utilizzando la stessa sintassi e le stesse parole chiave del linguaggio di
pianificazione. Questo capitolo contiene informazioni sui seguenti argomenti:
v Sintassi per i flussi di lavoro
v Descrizioni delle parole chiave
Sintassi per i flussi di lavoro
La sintassi mostra la struttura di un flusso di lavoro, con parole chiave in
grassetto. Un flusso di lavoro comincia con una parola chiave schedule seguita da
attributi e dipendenze. Il delimitatore con la virgola presenta i lavori che
comprendono il flusso di lavoro. Ogni lavoro ha attributi propri o dipendenze.
schedule [cpu#]sched
[freedays Calendar_Name [-sa] [-su] ]
on {date| day | calendar | request}[,...] [fdignore | fdnext | fdprev]
[on {date| day | calendar | request}[,...] [fdignore | fdnext | fdprev]]
[,...]
[deadline time [timezone|tz tzname][+n day[s] [,...]
[except{date| day | calendar}[,...] [fdignore | fdnext | fdprev] ]
[,...]
[at time[timezone|tz tzname][+ n day [s] ] ] [,...]
[carryforward]
[follows { [cpu#] sched [. job] [,...] } ]
[keysched]
[limit number]
[needs resource]
[opens file]
[priority number]
[prompt name|text]
[until time [timezone|tz tzname][+n day[s]] [onuntil action]
:
job-statement
[at time[timezone|tz tzname][+ n day [s] ] ] [,...]
[confirmed]
[deadline time [timezone|tz tzname][+n day[s] [,...]
[every rate]
[follows job|jstream]
[keyjob]
[needs resource]
[opens file]
[priority number]
[prompt name|text]
[until time [timezone|tz tzname][+n day[s]] [onuntil action]
[job-statement...]
end
© Copyright IBM Corp. 1999, 2004 87
Non tentare di scrivere flussi di lavoro su una sola riga, perché verranno rifiutati
dal comando schedulr dopo averli accettati apparentemente dal composer. Ad
esempio, scrivendo la seguente pianificazione su una sola riga:
SCHEDULE cbdbu01#NN_CBCID1001YS31 ON CBZZ0001 PRIORITY 10 FOLLOWS
cbdbu02#NN_CBTND10011501:cbdbu01#JN_CBCID1001YS1GA1 PRIORITY 10 OPENS
"/st01/st01if/in/CUBCIFYS1GA1001.dat.ok"
viene restituito un errore quando la pianificazione verrà elaborata da schedulr. In
questo caso, eseguire una delle operazioni riportate di seguito:
v Utilizzare composer per:
1. Creare un filename da schedule=cbdbu01#NN_CBCID1001YS31 (o tutte le
pianificazioni definite in questo modo).
2. Eseguire composer add filename
v Suddividere la pianificazione nel seguente modo:
SCHEDULE cbdbu01#NN_CBCID1001YS31 ON CBZZ0001 PRIORITY 10 FOLLOWS
cbdbu02#NN_CBTND10011501:cbdbu01#JN_CBCID1001YS1GA1 PRIORITY 10 OPENS
"/st01/st01if/in/CUBCIFYS1GA1001.dat.ok"
Parole chiave
Nella seguente tabella è riportata una breve descrizione delle parole chiave
necessarie per la pianificazione.
Parola chiave Descrizione Pagina
at Definisce l’ora del giorno in cui comincia
l’esecuzione del lavoro o del flusso di lavoro.
“at” a pagina
90
carryforward Consente la prosecuzione del lavoro se questo non
viene completato.
“carryforward”
a pagina 92
comments Include i commenti in una definizione del flusso di
lavoro
“comments” a
pagina 93
confirmed Specifica che è necessaria la conferma del
completamento di questo lavoro.
“confirmed” a
pagina 94
deadline Specifica l’ora entro la quale un lavoro o un flusso
di lavori deve essere completato.
“tempo limite”
a pagina 95
end Indica la fine di un flusso di lavoro. “end” a pagina
96
every Avvia il lavoro ripetutamente a intervalli specificati. “every” a
pagina 97
except Specifica le date che sono eccezioni alle date in cui
il flusso di lavoro viene selezionato per
l’esecuzione.
“except” a
pagina 98
follows Specifica di non avviare questo lavoro o flusso di
lavoro fino al completamento di altri lavori o flussi
di lavoro.
“follows” a
pagina 100
freedays Specifica un calendario di giorni liberi per il calcolo
dei giorni lavorativi per il flusso di lavoro. Può
inoltre impostare i sabati e le domeniche come
giorni lavorativi.
“freedays” a
pagina 101
job statement Definisce un lavoro e le sue dipendenze. “job statement”
a pagina 103
88 IBM Tivoli Workload Scheduler - Manuale di riferimento
Parola chiave Descrizione Pagina
keyjob Contrassegna un lavoro come chiave o critico sia
nel database, che nel piano giornaliero per il
controllo delle applicazioni, ad esempio IBM Tivoli
Business Systems Manager o Tivoli Enterprise
Console.
“keyjob” a
pagina 108
keysched Contrassegna un flusso di lavoro come chiave o
critico sia nel database, che nel piano giornaliero
per il controllo delle applicazioni, ad esempio IBM
Tivoli Business Systems Manager o Tivoli Enterprise
Console.
“keysched” a
pagina 109
limit Imposta un limite sul numero di lavori che possono
essere avviati contemporaneamente dal flusso di
lavoro.
“limit” a
pagina 110
needs Definisce il numero di unità di una risorsa richiesto
dal lavoro o dal flusso di lavoro prima che possa
essere avviato.
“needs” a
pagina 111
on Definisce le date in cui il flusso di lavoro viene
selezionato per l’esecuzione.
“il” a pagina
112
opens Definisce i file che devono essere accessibili prima
dell’avvio del lavoro o del flusso di lavoro.
“opens” a
pagina 115
priority Definisce la priorità di un lavoro o di un flusso di
lavoro.
“priority” a
pagina 117
prompt Definisce i prompt a cui è necessario rispondere
prima di avviare un lavoro o un flusso di lavoro.
“prompt” a
pagina 118
schedule Assegna un nome al flusso di lavoro. “schedule” a
pagina 119
until Definisce un’ora del giorno dopo la quale il lavoro
o il flusso di lavoro non viene avviato.
“until” a
pagina 120
Dipendenze
Una dipendenza è una condizione che deve essere soddisfatta prima dell’avvio di
un lavoro o di un flusso di lavoro. Per i flussi di lavoro, le dipendenze hanno
come parole chiave follows, needs, opens e prompt. Il numero massimo di
dipendenze consentite per un lavoro o per un flusso di lavoro è 40.
Nota: l’unica dipendenza selezionata immediatamente prima dell’esecuzione di un
flusso di lavoro è NEEDS. Una dipendenza OPENS viene risolta
automaticamente prima dell’esecuzione di un lavoro.
Sensibilità al maiuscolo/minuscolo
Ad eccezione dei nomi del percorso, dei nomi utente e dei comandi UNIX, che
sono sensibili al maiuscolo e al minuscolo, è possibile utilizzare indifferentemente
caratteri maiuscoli o minuscoli per la pianificazione.
Descrizioni parola chiave
Le pagine seguenti descrivono la sintassi per le parole chiave del linguaggio di
pianificazione.
Capitolo 4. Linguaggio di pianificazione 89
at
Definisce la prima ora di avvio di un lavoro o di un flusso di lavoro.
Synopsis
at time [timezone|tz tzname][+n day[s]] [,...]
Arguments
time Specifica l’ora del giorno. I valori possibili rientrano in un intervallo
compreso tra 0000 e 2359.
tzname Specifica il fuso orario da utilizzare durante il calcolo dell’ora di avvio.
Consultare Appendice B, “Gestione dei fusi orari”, a pagina 331 per i nomi
del fuso orario. Il valore di default è il fuso orario della workstation su cui
viene avviato il lavoro o l’esecuzione del lavoro.
Nota: se vengono specificate un’ora at e un’ora until, il fuso orario deve
essere uguale.
n Specifica uno scostamento in giorni dalla data e dall’ora di avvio
pianificate.
Usage Notes
Se non viene specificata un’ora at per un lavoro o un flusso di lavoro, la relativa
ora di avvio è determinata dalle dipendenze e dalle priorità.
Il valore dell’ora nell’opzione at è considerato nel modo seguente:
se tale valore è minore dell’ora corrente, viene considerato come se fosse del
giorno seguente.
Se il valore dell’ora è maggiore dell’ora corrente, viene considerato come se
fosse del giorno corrente.
Se si specifica un valore dell’ora maggiore di 2400, viene diviso per 2400 per
ottenere il numero di giorni. Se si specificano dei giorni, questi vengono
aggiunti al valore ottenuto dividendo per 2400.
Esempi
Gli esempi seguenti suppongono che il giorno di elaborazione IBM Tivoli
Workload Scheduler comincia alle 6:00 a.m..
v Il flusso di lavoro seguente, impostato su martedì, viene avviato sempre dopo le
3:00 a.m. del mercoledì. I due lavori vengono avviati appena possibile dopo tale
ora.
schedule sked7 on tu at 0300:
job1
job2
end
v Il fuso orario della workstation sfran è definito come pst (Pacific Standard Time)
e il fuso orario della workstation nycity è definito come est (Eastern Standard
Time). L’esecuzione di questo flusso di lavoro è fissata per Venerdì. Viene
avviato su una workstation sfran alle 10:00 a.m. pst di sabato. job1 viene
avviato su sfran appena possibile dopo tale ora. job2 viene avviato su sfran alle
2:00 p.m. est (11:00 a.m. pst) di sabato. job3 viene avviato sulla workstation
nycity alle 4:00 p.m. est (1:00 p.m. pst) di sabato.
90 IBM Tivoli Workload Scheduler - Manuale di riferimento
sfran#schedule sked8 on fr at 1000 + 1 day :
job1
job2 at 1400 tz est
nycity#job3 at 1600
end
Capitolo 4. Linguaggio di pianificazione 91
carryforward
Consente la prosecuzione di un lavoro nel giorno di produzione successivo, se non
viene completato prima della fine del piano di produzione corrente.
Synopsis
carryforward
Esempi
L’esecuzione del seguente flusso di lavoro viene proseguita se i relativi lavori non
sono stati completati prima dell’inizio dell’elaborazione anteriore alla produzione
di un nuovo giorno.
schedule sked43 on th
carryforward
:
job12
job13
job13a
end
92 IBM Tivoli Workload Scheduler - Manuale di riferimento
comments
Include i commenti in una definizione del flusso di lavoro
Synopsis
*text | <<text>>
Arguments
*text Inserisce una riga di commento. Il primo carattere nella riga deve essere un
asterisco.
<<text>>
Inserisce un testo di commento in una riga. Il testo deve essere racchiuso
tra doppi segni di maggiore e minore.
Esempi
L’esempio seguente include entrambi i tipi di commento:
****************************************
* The weekly cleanup jobs
****************************************
*
schedule wkend on fr at 1830
carryforward
:
job1 <<final totals and reports>>
job2 <<update database >>
end
Capitolo 4. Linguaggio di pianificazione 93
confirmed
Specifica che il completamento di un lavoro deve essere confermato eseguendo un
comando Conman confirm. Per ulteriori informazioni, consultare “confirm” a
pagina 154.
Synopsis
confirmed
Esempi
Nel flusso di lavoro seguente, la conferma del completamento di job1 deve essere
ricevuta prima dell’avvio di job2 e job3.
schedule test1 on fr:
job1 confirmed
job2 follows job1
job3 follows job1
end
94 IBM Tivoli Workload Scheduler - Manuale di riferimento
tempo limite
Specifica l’ora entro la quale un lavoro o un flusso di lavoro deve essere
completato. I lavori o i flussi di lavoro non ancora avviati o ancora in esecuzione
una volta raggiunto il tempo limite vengono considerati ritardatari nella
pianificazione. Quando un lavoro o un flusso di lavoro è ritardatario, vengono
effettuate le seguenti azioni:
v Il lavoro è mostrato come ritardatario in Conman nella console di pianificazione
lavori.
v Un evento viene inviato a Tivoli Enterprise Console e IBM Tivoli Business
Systems Manager.
v Un messaggio viene emesso in stdlist e nei log della console.
Synopsis
deadline time [timezone|tz tzname][+n day[s] [,...]
Arguments
time Specifica l’ora del giorno. I valori possibili rientrano in un intervallo
compreso tra 0000 e 2359.
tzname Specifica il fuso orario da utilizzare durante il calcolo del tempo limita.
Consultare Appendice B, “Gestione dei fusi orari”, a pagina 331 per i nomi
del fuso orario. Il valore di default è il fuso orario della workstation su cui
viene avviato il lavoro o l’esecuzione del lavoro.
n Specifica uno scostamento in giorni dall’ora di tempo limite.
Esempi
Il seguente esempio avvia il flusso di lavoro x sked7 ogni giorno e il lavoro jobc
che deve essere iniziato alle 14:30 ed essere completato 16:00.
schedule sked7 on everyday :
jobc at 1430 deadline 1600
end
Capitolo 4. Linguaggio di pianificazione 95
end
Indica la fine di un flusso di lavoro.
Synopsis
end
Esempi
schedule test1 on monthend
:
job1
job2
job3
end << end of job stream >>
96 IBM Tivoli Workload Scheduler - Manuale di riferimento
every
Definisce l’intervallo di ripetizione per un lavoro. Il lavoro viene avviato
ripetutamente all’intervallo specificato. Se il lavoro ha una dipendenza non
soddisfatta, l’interazione viene iniziata quando la dipendenza viene soddisfatta.
Synopsis
every rate
Arguments
rate L’intervallo di ripetizione espresso in ore e minuti, nel formato: hhmm.
(L’intervallo può essere maggiore di 24 ore.)
Usage Notes
Se un lavoro every termina in modo anomalo, l’iterazione continua. Se viene
utilizzata l’opzione every con la dipendenza AT, i lavori vengono avviati nelle ore
stabilite. Se una riesecuzione viene ritardata (a causa di una dipendenza o per un
altro motivo), IBM Tivoli Workload Scheduler eseguirà il riallineamento in base
all’ora AT. In questo caso una o più iterazioni potrebbero non rispettare l’ordine
EVERY. Se l’opzione EVERY viene utilizzata senza la dipendenza AT, i lavori
ripetuti verranno pianificati rispettando l’ordine EVERY specificato, a partire
dall’ora in cui il lavoro viene effettivamente avviato. Se, e solo se, viene utilizzata
l’opzione every con la dipendenza AT, possono esserci delle iterazioni che non
rispettano l’ordine EVERY. Per tutti gli altri casi, l’ordine EVERY viene sempre
rispettato.
Esempi
L’esempio seguente avvia il lavoro testjob ogni ora:
testjob every 100
L’esempio seguente avvia il lavoro testjob1 ogni 15 minuti, tra le 6:00 p.m. e le
8:00 p.m.:
testjob1 at 1800 every 15 until 2000
Il lavoro verrà eseguito alle 18:00, 18:15, 18:30 e così via. Se il lavoro viene inoltrato
adhoc alle 18:33, le ripetizioni si verificheranno alle 18:33, 18:34, 18:45 e così via.
Il seguente esempio non avvia l’interazione testjob2 del lavoro finché il lavoro
testjob1 non è stato completato correttamente:
testjob2 every 15 follows testjob1
Capitolo 4. Linguaggio di pianificazione 97
except
Definisce le date che sono eccezioni per le date on di un flusso di lavoro. Per
ulteriori informazioni, consultare “il” a pagina 112.
Synopsis
except {date| day | calendar } [fdignore | fdnext | fdprev][,...]
[except {date| day | calendar }] [fdignore | fdnext | fdprev][,...]]
Arguments
date Una data nel formato: mm/dd/yy.
day Un giorno della settimana. Specificare uno o più dei seguenti:
lu Lunedì
ma Martedì
me Mercoledì
gio Giovedì
ve Venerdì
sa Sabato
dom Domenica
weekdays
Tutti i giorni tranne il sabato e la domenica.
workdays
Può essere uno dei seguenti:
v Se è stato specificato un calendario di giorni liberi, i giorni
lavorativi sono tutti i giorni esclusi il sabato e la domenica (a meno
che non sia specificato -sa o -su con la parola chiave freedays) e
tranne tutte le date specificate nel calendario dei giorni liberi.
v Se non è stato specificato un calendario dei giorni liberi, i giorni
lavorativi sono tutti, tranne il sabato e la domenica e tutti i giorni
festivi.freedays
I giorni contrassegnati nel calendario dei giorni liberi, se specificati.
calendar
Le date specificate su un calendario con questo nome. Il nome del
calendario deve essere seguito da uno scostamento nel formato seguente:
{+ | -}n {day[s] | weekday[s] | workday[s]}
Dove:
n Il numero di giorni, di giorni della settimana o dei giorni
lavorativi.
days Indica i giorni della settimana.
weekdays
Corrisponde a ogni giorno della settimana, eccetto sabato e
domenica.
workdays
Indica un qualunque giorno della settimana, tranne il sabato e la
domenica (a meno che non venga specificato diversamente con la
parola chiave freedays) e per le date indicate in uno specifico
calendario dei giorni liberi o nel calendario delle ferie.
freeday rule
Specifica una regola che deve essere applicata quando la data selezionata
per l’esclusione è un venerdì. Può essere uno dei seguenti:
98 IBM Tivoli Workload Scheduler - Manuale di riferimento
fdignore
Non esclude la data.
fdnext Esclude il giorno lavorativo più vicino al giorno libero.
fdprev
Esclude il giorno lavorativo che precede il giorno libero.
Usage Notes
E’ possibile definire più istanze della parola chiave except per lo stesso flusso di
lavoro. Ogni istanza è equivalente a un ciclo di esecuzione a cui è possibile
associare una regola dei giorni liberi.
Più istanze except devono essere consecutive in una definizione del flusso di
lavoro.
Ogni istanza della parola chiave può contenere ognuno dei valori consentiti dalla
sintassi except.
Esempi
L’esempio seguente seleziona un flusso di lavoro testskd2 in modo che venga
eseguito ogni giorno della settimana, tranne che nei giorni presenti sul calendario
denominato monthend e holidays:
schedule testskd2 on weekdays
except monthend,holidays
L’esempio seguente seleziona il flusso di lavoro testskd3 in modo che venga
eseguito ogni giorno della settimana, tranne il 15 maggio 1999 e il 23 maggio 1999:
schedule testskd3 on weekdays
except 05/15/99,05/23/99
L’esempio seguente seleziona un flusso di lavoro testskd4 in modo che venga
eseguito ogni giorno tranne i due giorni della settimana precedenti ogni data che
appare su un calendario denominato monthend:
schedule testskd4 on everyday
except monthend-2 weekdays
Selezionare il flusso di lavoro sked4 in modo che venga eseguito nei giorni di
lunedì e di martedì e due giorni della settimana precedenti ogni data elencata nel
calendario MONTHEND. Se la data di esecuzione è un giorno libero, eseguire il
flusso di lavoro il giorno lavorativo seguente più vicino. Non eseguire il flusso di
lavoro di venerdì.
schedule sked4
on mo
on tu, MONTHEND -2 weekdays fdnext
except we
Selezionare il flusso di lavoro testskd2 in modo che venga eseguito ogni giorno
della settimana, tranne i giorni indicati in MONTHEND. Se un giorno indicato in
MONTHEND è venerdì, escludere il giorno lavorativo più vicino precedente a
esso. In questo esempio, i giorni liberi sono i sabati e le domeniche e tutti i giorni
indicati sul calendario holidays di default.
schedule testskd2
on weekdays
except MONTHEND fdprev
Capitolo 4. Linguaggio di pianificazione 99
follows
Definisce gli altri lavori o flussi di lavoro che devono essere completati con esito
positivo prima dell’avvio di un lavoro o di un flusso di lavoro.
Synopsis
Utilizzare la sintassi seguente per i flussi di lavoro:
follows [netagent::][wkstation#]jstream[.jobname | @] [,...]
Utilizzare la seguente sintassi per i lavori:
follows [netagent::][wkstation#]jstream{.jobname | @} | jobname [,...]
Arguments
netagent
Il nome dell’agent di rete (NA) in cui è definita la dipendenza tra reti.
wkstation
La workstation su cui viene eseguito il lavoro o il flusso di lavoro da
completare. Il valore di default è la stessa workstation del lavoro
dipendente o del flusso di lavoro.
Se non viene specificata una wkstation con netagent, il valore di default è la
workstation a cui è collegato l’agent di rete (NA).
jstream Il nome del flusso di lavoro da completare. Per un lavoro, il valore di
default è lo stesso flusso di lavoro del lavoro dipendente.
jobname
Il nome del lavoro da completare. E’ possibile utilizzare un segno at (@)
per indicare che tutti i lavori nel flusso di lavoro vengano completati con
esito positivo.
Esempi
L’esempio seguente indica di non avviare il flusso di lavoro skedc fino a che il
flusso di lavoro sked4 sulla workstation site1 e il lavoro joba nel flusso di lavoro
sked5 sulla workstation site2 non siano stati completati con esito positivo:
schedule skedc on fr
follows site1#sked4,site2#sked5.joba
Non avviare sked6 fino a che jobx nel flusso di lavoro skedx sul cluster4 di rete
remoto non sia stato completato con esito positivo:
sked6 follows cluster4::site4#skedx.jobx
L’esempio seguente specifica di non avviare jobd fino a che joba nello stesso
flusso di lavoro e job3 nel flusso di lavoro skeda non siano stati completati con
esito positivo:
jobd follows joba,skeda.job3
L’esempio seguente specifica di non avviare jobe fino a che tutti i lavori nel flusso
di lavoro skedb sulla workstation unix1 non siano stati completati con esito
positivo:
jobe follows unix1#skedb.@
100 IBM Tivoli Workload Scheduler - Manuale di riferimento
freedays
Consente di specificare il nome del calendario dei giorni liberi (consultare il
Manuale per l’utente per una descrizione del calendario dei giorni liberi) che
elenca i giorni in cui il flusso di lavoro non deve essere eseguito. Tivoli Workload
Scheduler utilizza questo calendario come calendario di base per il calcolo dei
giorni lavorativi per il flusso di lavoro.
La parola chiave influisce solo sulla pianificazione dei flussi di lavoro per cui è
specificata.
Synopsis
freedays Calendar_Name [-sa] [-su]
Arguments
Calendar_Name
Il nome del calendario che deve essere utilizzato come calendario dei
giorni liberi per il flusso di lavoro. Se Calendar_Name non si trova nel
database, Tivoli Workload Scheduler invia un’avvertenza quando si salva il
flusso di lavoro. Se Calendar_Name non si trova nel database durante
l’esecuzione dello scheduler, Tivoli Workload Scheduler invia un messaggio
di errore e utilizza il calendario di default holidays al suo posto. Non
utilizzare i nomi dei giorni della settimana per i nomi dei calendari.
-sa Conta le domeniche come giorni lavorativi.
-su Conta le domeniche come giorni lavorativi.
Usage Notes
Se non si specifica un calendario dei giorni liberi nella definizione del flusso di
lavoro, la parola chiave workdays assume il seguente valore: workdays = tutti i giorni
escluso il sabato e la domenica (a meno che l’utente non abbia specificato -sa o -su
insieme ai giorni liberi) ed esclusi tutti i giorni indicati in Calendar_Name
Se non si specifica freedays nella definizione del flusso di lavoro: workdays = tutti i
giorni esclusi il sabato e la domenica e tutte le date del calendario holidays
Per default, il sabato e la domenica sono considerati giorni liberi, a meno che non sia
stato specificato diversamente aggiungendo -sa e/o -su dopo Calendar_Name.
Esempi
Selezionare il flusso di lavoro sked2 in modo che venga eseguito il 01/01/2001 e
tutti i giorni lavorativi fino a che questi non sono elencati nel calendario dei giorni
liberi denominato GERMHOL.
schedule sked2
freedays GERMHOL
on 01/01/2001, workdays
Selezionare il flusso di lavoro sked3 in modo che venga eseguito due giorni
lavorativi precedenti ogni data indicata nel calendario PAYCAL. I giorni lavorativi
sono tutti i giorni dal lunedì al sabato, a meno che non siano elencati nel
calendario dei giorni lavorativi denominato USAHOL.
schedule sked3
freedays USAHOL -sa
on PAYCAL -2 workdays
Capitolo 4. Linguaggio di pianificazione 101
Selezionare il flusso di lavoro sked3 per le date elencate nel calendario APDATES.
Se la data selezionata è un giorno libero, non eseguire il flusso di lavoro. In questo
esempio, le domeniche e tutti gli altri giorni elencati nel calendario GERMHOL
devono essere considerati giorni liberi. Tutti i giorni dal lunedì al sabato, tranne
quelli indicati nel calendario GERMHOL, sono giorni lavorativi.
schedule sked3
freedays GERMHOL -sa
on APDATES fdignore
Selezionare il flusso di lavoro testsked3 in modo che venga eseguito ogni giorno
della settimana, tranne il 15/5/2002 e il 23/5/2002. Se 5/23/2002 è un giorno
libero, non escluderlo. In questo esempio, i sabati, le domeniche e tutti i giorni
elencati in GERMHOL devono essere considerati giorni lavorativi. Tutti i giorni dal
lunedì al venerdì, tranne quelli indicati nel calendario GERMHOL, sono giorni
lavorativi.
schedule testskd3
freedays GERMHOL
on weekdays
except 5/15/2002 fdignore
except 5/23/2002
Selezionare il flusso di lavoro testsked4 in modo che venga eseguito ogni giorno
tranne i due giorni lavorativi precedenti ogni data elencata nel calendario
MONTHEND. Se la data da escludere è un giorno libero, non escluderlo, ma
escludere il giorno lavorativo più vicino. In questo esempio, i giorni liberi sono
tutti quelli elencati in USAHOL, mentre i giorni lavorativi sono tutti i giorni
compresi tra il lunedì e la domenica non presenti in USAHOL.
schedule testskd4
freedays USAHOL -sa -su
on everyday
except MONTHEND -2 weekdays fdnext
102 IBM Tivoli Workload Scheduler - Manuale di riferimento
job statement
Le istruzioni lavoro inseriscono i lavori in un flusso di lavoro e definiscono le
dipendenze del lavoro. In una istruzione lavoro, è possibile inoltre inserire gli
attributi lavoro e le opzioni di ripristino che aggiungono un nuovo lavoro o
modificano un lavoro esistente nel database. Per ulteriori informazioni, consultare
“Note sull’utilizzo”.
Synopsis
[wkstation#]jobname
[description “text”]
[scriptname filename | docommand “commandline”][streamlogon username]
[interactive]
[rccondsucc ″Success Condition″]
[recovery {stop | continue | rerun}
[after [wkstation#]jobname]
[abendprompt “text”] ]
[job-dependency [,...]]
Arguments
wkstation
Specifica il nome della workstation o della classe workstation su cui è in
esecuzione il lavoro. Il valore di default è la workstation su cui viene
eseguito il flusso di lavoro. Il segno del cancelletto (#) è un delimitatore
necessario. Se si specifica una classe workstation, è necessario che
corrisponda alla classe workstation di ogni flusso di lavoro in cui viene
incluso il lavoro.
jobname
Specifica il nome del lavoro. Il nome deve cominciare con una lettera e può
contenere caratteri alfanumerici, trattini e caratteri di sottolineatura. Può
contenere fino a 40 caratteri.
Nota: non utilizzare la parola recovery come nome lavoro. Questa parola è
riservata.
description
Una descrizione a modulo libero del lavoro, tra parentesi.
scriptname filename
Specifica il nome del file che esegue il lavoro. Utilizzare scriptname per i
lavori UNIX e Windows. Per un file eseguibile, immettere il nome del file e
tutte le opzioni e gli argomenti. La lunghezza di filename più quella di
Success Condition (della parola chiave rccondsucc) non deve superare i 4095
caratteri. E’ possibile inoltre utilizzare i parametri IBM Tivoli Workload
Scheduler. Per ulteriori informazioni, consultare “Utilizzo dei parametri
nelle definizioni lavoro” a pagina 106.
Per i lavori Windows, includere le estensioni dei file. Sono consentiti nomi
UNC (Universal Naming Convention). Non specificare file su unità
definite.
Se vengono inseriti spazi o caratteri speciali diversi da barre (/) e barre
retroverse (\), l’intera stringa deve essere racchiusa tra apici (″).
Se il nome del file contiene spazi, immettere il nome in un altro file che
non ha spazi nel proprio nome e utilizzare il nome del secondo file per
questo argomento.
Capitolo 4. Linguaggio di pianificazione 103
docommand command
Specifica un comando che esegue il lavoro. Immettere un comando valido e
tutte le opzioni e gli argomenti racchiusi tra apici (″). La lunghezza di
command più quella di Success Condition (della parola chiave rccondsucc)
non deve superare i 4095 caratteri. Un comando viene eseguito
direttamente e, a differenza di scriptname, non viene eseguito lo script di
configurazione jobmanrc. Altrimenti, il comando viene considerato come
un lavoro e vengono applicate tutte le regole ad esso relative. E’ possibile
inoltre immettere i parametriIBM Tivoli Workload Scheduler. Per ulteriori
informazioni, consultare “Utilizzo dei parametri nelle definizioni lavoro” a
pagina 106.
Per gli FTA in esecuzione su Windows, i lavori non avranno esito positivo
se il percorso del programma/script da eseguire contiene uno spazio. Ad
esempio, l’istruzione
CMD.EXE /C "C:\PROGRAM FILES\CCR\CCR_CONSOLIDATE.BAT"
non avrà esito positivo, riportando il messaggio:
The name specified is not recognized as an internal or external command,
operable program or batch file.
perché gli spazi non vengono gestiti in questo contesto.
streamlogon
Il nome dell’utente sotto cui viene eseguito il lavoro. Il nome può
contenere fino a 47 caratteri. Se il nome contiene caratteri speciali, deve
essere racchiuso tra apici (″). Specificare un utente che può effettuare il log
on alla workstation su cui viene eseguito il lavoro. E’ possibile inoltre
immettere i parametriIBM Tivoli Workload Scheduler. Consultare “Utilizzo
dei parametri nelle definizioni lavoro” a pagina 106.
Per i lavori Windows, l’utente deve disporre inoltre di una definizione
utente. Consultare “Definizioni utente” a pagina 52 per i requisiti
dell’utente.
interactive
Per i lavori Windows, includere questa parola chiave per indicare che il
lavoro viene eseguito interattivamente sul desktop Windows.
rccondsucc ″Success Condition″
Un’espressione che determina il codice di ritorno (RC) richiesto per
considerare un lavoro riuscito. La lunghezza massima di questo parametro
è di 256 caratteri. Questa espressione può contenere una combinazione di
espressioni di comparazione e booleana:
Espressione di comparazione
Specifica i codici di ritorno del lavoro. La sintassi é:
(RC operatore operando)
RC La parola chiave RC.
operatore
Operatore di comparazione. Può avere i seguenti valori:
Tabella 9. Operatore di comparazione
Esempio Operatore Descrizione
RC<a < Minore di
RC<=a <= Minore di o uguale a
104 IBM Tivoli Workload Scheduler - Manuale di riferimento
Tabella 9. Operatore di comparazione (Continua)
RC>a > Maggiore di
RC>=a >= Maggiore di o uguale a
RC=a = Uguale a
RC!=a != Non uguale a
RC<>a <> Non uguale a
operando
Un numero intero compreso tra -2147483647 e 2147483647.
Ad esempio, è possibile definire un lavoro riuscito come lavoro che
termina con codice di ritorno minore o uguale a 3 come segue:
rccondsucc "(RC <= 3)"
Espressione booleana
Specifica una combinazione logica di espressioni di comparazione.
La sintassi é:
espressione_comparazione operatore espressione_comparazione
espressione_comparazione
L’espressione viene valutata da sinistra a destra. È
possibile utilizzare le parentesi per assegnare una priorità
alla valutazione dell’espressione.
operatore
Operatore logico. Può avere i seguenti valori:
Tabella 10. Operatori logici
Esempio Operatore Risultato
expr_a and expr_b And TRUE se sia expr_a che
expr_b sono TRUE.
expr_a o expr_b Or TRUE se o expr_a o expr_b è
TRUE.
Not expr_a Not TRUE se expr_a non è TRUE.
Ad esempio, è possibile definire un lavoro riuscito come lavoro che
termina con codice di ritorno minore o uguale a 3 o non uguale a 5
e minore di 10 come segue:
rccondsucc "(RC=3) OR ((RC>=5) AND (RC<10))"
recovery
Le opzioni di ripristino del lavoro. Il valore di default è stop senza alcun
lavoro di ripristino e nessun prompt di ripristino. Immettere una delle
opzioni di ripristino, stop, continue o rerun. Questa può essere seguita da
un lavoro di ripristino, un prompt di ripristino o da entrambi.
stop Se il lavoro viene interrotto in modo anomalo, non continuare con
il lavoro successivo.
continue
Se il lavoro viene interrotto in modo anomalo, continuare con il
lavoro successivo.
rerun Se il lavoro viene interrotto in modo anomalo, rieseguirlo.
Capitolo 4. Linguaggio di pianificazione 105
after [wkstation#]jobname
Specifica il nome di un lavoro di ripristino da eseguire se il lavoro
parent viene interrotto in modo anomalo. I lavori di ripristino
vengono interrotti solo una volta per ogni istanza del lavoro parent
interrotta in modo anomalo.
E’ possibile specificare una workstation del lavoro di ripristino se è
diversa dalla workstation del lavoro parent. Il valore di default è la
workstation del lavoro parent. Non tutti i lavori possono avere
lavori di ripristino in esecuzione su una workstation differente.
Seguire queste istruzioni:
v Se una workstation è un XA (agent esteso), deve trovarsi su un
DM o su un FTA con un valore on per fullstatus.
v La workstation del lavoro di ripristino deve trovarsi nello stesso
dominio della workstation del lavoro parent.
v Se la workstation del lavoro di ripristino è un FTA, essa deve
avere un valore di on per fullstatus.
abendprompt “text”
Specifica il testo di un prompt di ripristino, racchiusa tra apici, che
viene visualizzato se il lavoro viene interrotto in modo anomalo. Il
testo può contenere fino a 64 caratteri. Se il testo inizia con i due
punti (:), il prompt viene visualizzato ma non è necessaria alcuna
risposta per continuare l’elaborazione. Se il testo inizia con un
punto esclamativo (!), il prompt non viene visualizzato, ma è
necessaria una risposta per proseguire.
job-dependency
Specifica gli argomenti e le parole chiave di pianificazione. Le parole
chiave valide per i lavori sono: at, confirmed, every, follows, needs,
opens, priority, prompt e until.
Utilizzo dei parametri nelle definizioni lavoro: I parametri, nelle definizioni
lavoro, hanno i seguenti utilizzi e limitazioni:
v I parametri sono consentiti nei valori streamlogon, scriptname e docommand.
v Un parametro può essere utilizzato come stringa intera o come parte di essa.
v Più parametri sono consentiti in una variabile singola.
v Racchiudere i nomi parametri tra segni di omissione (^) e la stringa intera tra
apici.
Consultare l’esempio riportato di seguito in cui viene utilizzato un parametro
denominato mis nel valore streamlogon. Per ulteriori esempi, consultare
“Definizioni parametro” a pagina 55.
Usage Notes
Un lavoro deve essere definito solo una volta nel database e può essere utilizzato
su più flussi di lavoro. Quando un flusso di lavoro viene aggiunto o modificato,
anche gli attributi o le opzioni di ripristino dei lavori vengono aggiunti o
modificati.
Quando si definiscono nuovamente i lavori, ricordare che:
v i lavori possono essere definiti indipendentemente (come descritto in
“Definizioni lavoro” a pagina 46) o come parti di flussi di lavoro. In entrambi i
casi, le modifiche vengono effettuate sul database e non influiscono sul piano di
produzione fino all’inizio di un nuovo giorno di elaborazione.
106 IBM Tivoli Workload Scheduler - Manuale di riferimento
v Quando si aggiunge o si sostituisce un flusso di lavoro, tutte le modifiche dei
lavori influiscono su tutti gli altri flussi di lavoro che utilizzano i lavori. Tenere
presente che il Report di riferimento incrociato può essere utilizzato per stabilire
i nomi dei flussi di lavoro in cui è incluso un particolare lavoro.
Esempi
L’esempio seguente definisce un flusso di lavoro con tre lavori precedentemente
definiti:
schedule bkup on fr at 20:00 :
cpu1#jbk1
cpu2#jbk2
needs 1 tape
cpu3#jbk3
follows jbk1
end
La definizione di flusso di lavoro che segue contiene le istruzioni su un lavoro che
aggiungono o modificano le definizioni dei due lavori nel database:
schedule sked4 on mo :
job1 scriptname “d:\apps\maestro\scripts\jcljob1”
streamlogon jack
recovery stop abendprompt “continue production”
site1#job2 scriptname “d:\apps\maestro\scripts\jcljob2”
streamlogon jack
follows job1
end
Capitolo 4. Linguaggio di pianificazione 107
keyjob
La parola chiave keyjob viene utilizzata per contrassegnare un lavoro come chiave
o critico sia nel database che nel piano giornaliero e per il controllo delle
applicazioni, ad esempio Tivoli Business Systems Manager. Per informazioni
sull’abilitazione del meccanismo degli indicatori chiave, consultare Manuale per la
pianificazione e installazione di IBM Tivoli Workload Scheduler.
Esempi
Il seguente esempio
SCHEDULE cpu1#sched1
ON everyday
KEYSCHED
AT 0100
cpu1#myjob1 KEYJOB
END
108 IBM Tivoli Workload Scheduler - Manuale di riferimento
keysched
La parola chiave keysched viene utilizzata per contrassegnare un flusso di lavoro
come chiave o critico sia nel database che nel piano giornaliero e per il controllo
delle applicazioni, ad esempio Tivoli Business Systems Manager. Per informazioni
sull’abilitazione del meccanismo degli indicatori chiave, consultare Manuale per la
pianificazione e installazione di IBM Tivoli Workload Scheduler.
Synopsis
keysched
Esempi
Il seguente esempio:
SCHEDULE cpu1#sched1
ON everyday
KEYSCHED
AT 0100
cpu1#myjob1 KEYJOB
END
Capitolo 4. Linguaggio di pianificazione 109
limit
Limita il numero di lavori che possono essere eseguiti contemporaneamente in un
flusso di lavoro.
Synopsis
limit joblimit
Arguments
joblimit Specifica il numero di lavori che possono essere eseguiti nello
stesso momento nella pianificazione. I valori possibili sono
compresi tra 0 e 1024. Se si specifica 0, si impedisce l’avvio di tutti
i lavori.
Esempi
L’esempio seguente limita a cinque il numero di lavori che possono essere eseguiti
contemporaneamente in un flusso di lavoro sked2:
schedule sked2 on fr
limit 5 :
110 IBM Tivoli Workload Scheduler - Manuale di riferimento
needs
Definisce le risorse che devono essere disponibili prima dell’avvio di un lavoro o
di un flusso di lavoro.
Synopsis
needs [n] [wkstation#]resourcename [,...]
Arguments
n Specifica il numero di unità di risorse richiesto. Valori possibili
sono compresi tra 0 e 32. Il valore di default è uno.
Nota: Il numero di lavori e pianificazioni che utilizzano una
risorsa contemporaneamente non può essere superiore a 32.
wkstation Specifica il nome della workstation su cui viene definita localmente
la risorsa. Il valore di default è la workstation o la classe di
workstation del lavoro dipendente o del flusso di lavoro. Le risorse
possono essere utilizzate come dipendenze solo dai lavori e dai
flussi di lavoro che vengono eseguiti sulla stessa workstation della
risorsa. Tuttavia, un agent standard e il relativo host possono
riferirsi alle stesse risorse.
resourcename Specifica il nome della risorsa.
Esempi
L’esempio seguente impedisce l’avvio del flusso di lavoro sked3 fino a che le tre
unità di cputime e le due unità di tapes non diventano disponibili:
schedule sked3 on fr
needs 3 cputime,2 tapes :
La risorsa jlimit è stata definita con due unità disponibili. L’esempio seguente non
consente l’esecuzione contemporanea di due o più lavori in un flusso di lavoro
sked4:
schedule sked4 on mo,we,fr :
joba needs 1 jlimit
jobb needs 1 jlimit
jobc needs 2 jlimit <<runs alone>>
jobd needs 1 jlimit
end
Capitolo 4. Linguaggio di pianificazione 111
il
Questa è una parola chiave necessaria per il flusso di lavoro che definisce il
momento e la frequenza con cui un flusso di lavoro viene scelto per l’esecuzione.
La parola chiave on deve seguire la parola chiave schedule. Per ulteriori
informazioni, consultare “except” a pagina 98.
Synopsis
on {date| day | calendar | request}[,...] [fdignore | fdnext | fdprev][,...]
[on {date| day | calendar | request}[,...] [fdignore | fdnext | fdprev]][,...]
Arguments
date Specifica una data nel formato, mm/gg/aa.
day Un giorno della settimana. E’ possibile specificare:
lu Lunedì
ma Martedì
me Mercoledì
gio Giovedì
ve Venerdì
sa Sabato
dom Domenica
weekdays
Tutti i giorni tranne il sabato e la domenica.
everyday
Ogni giorno della settimana
workdays
Può essere uno dei seguenti:
v Se è stato specificato un calendario di giorni liberi, i giorni
lavorativi sono tutti i giorni esclusi il sabato e la domenica (a meno
che non sia specificato -sa o -su con la parola chiave freedays) e
tranne tutte le date specificate nel calendario dei giorni liberi.
v Se non è stato specificato un calendario dei giorni liberi, i giorni
lavorativi sono tutti, tranne il sabato e la domenica e tutti i giorni
festivi.freedays
I giorni contrassegnati nel calendario dei giorni liberi, se specificati.
calendar
Le date specificate su un calendario con questo nome. Il nome del
calendario deve essere seguito da uno scostamento nel formato seguente:
{+ | -}n {day[s] | weekday[s] | workday[s]}
Dove:
n Il numero di giorni, di giorni della settimana o dei giorni
lavorativi.
days Indica i giorni della settimana.
weekdays
Indica i giorni della settimana, tranne il sabato e la domenica.
workdays
Indica un qualunque giorno della settimana, tranne il sabato e la
domenica (a meno che non venga specificato diversamente con la
parola chiave freedays) e per le date indicate in uno specifico
calendario dei giorni liberi o nel calendario delle ferie.
112 IBM Tivoli Workload Scheduler - Manuale di riferimento
request
Seleziona il flusso di lavoro solo quando richiesto. Viene utilizzata per i
flussi di lavoro selezionati in base al nome piuttosto che in base alla data.
Per impedire che un flusso di lavoro pianificato venga eseguito per
Jnextday, modificare la definizione in ON REQUEST.
Nota: Quando si tenta di eseguire un flusso di lavoro che contiene ″on
request″, considerare che:
v ″On request″ ha sempre priorità su ″at″.
v ″On request″ non ha mai priorità su ″on″.
freeday rule
Specifica una regola che deve essere applicata quando la data selezionata è
un venerdì. Può essere uno dei seguenti:
fdignore
Non eseguire il flusso di lavoro.
fdnext Eseguire il flusso di lavoro il giorno lavorativo più vicino
successivo al giorno libero.
fdprev
Eseguire il flusso di lavoro il giorno lavorativo più vicino
precedente al giorno libero.
Usage Notes
E’ possibile definire più istanze della parola chiave on per questo stesso flusso di
lavoro. Ogni istanza è equivalente a un ciclo di esecuzione a cui è possibile
associare una regola dei giorni liberi.
Più istanze on devono essere consecutive in una definizione di flusso di lavoro.
Ogni istanza della parola chiave può contenere ognuno dei valori consentiti dalla
sintassi on.
E’ necessario specificare la parola chiave on almeno una volta nella definizione di
un flusso di lavoro.
Esempi
L’esempio seguente seleziona il flusso di lavoro sked1 il lunedì e il mercoledì:
schedule sked1 on mo,we
L’esempio seguente seleziona il flusso di lavoro sked3 il 15 giugno 1999 e nelle
date elencate sul calendario apdates:
schedule sked3 on 6/15/99,apdates
L’esempio seguente seleziona il flusso di lavoro sked4 due volte alla settimana
prima di ogni data che appare sul calendario monthend:
schedule sked4 on monthend -2 weekdays
L’esempio seguente seleziona il flusso di lavoro testskd1 ogni giorno della
settimana, tranne il mercoledì:
schedule testskd1 on weekdays
except we
L’esempio seguente seleziona il flusso di lavoro testskd3 ogni giorno della
settimana, tranne il 15 maggio 1999 e il 24 maggio 1999:
Capitolo 4. Linguaggio di pianificazione 113
schedule testskd3 on weekdays
except 05/16/99,05/24/99
L’esempio seguente seleziona il flusso di lavoro testskd4 ogni giorno, tranne nei
due giorni precedenti ogni data che appare su un calendario denominato
monthend:
schedule testskd4 on everyday
except monthend -2 weekdays
Selezionare l’esecuzione mensile di un flusso di lavorosked1, ogni lunedì e venerdì
e il 29/12/2001. Se i lunedì e il 29/12/2001 sono giorni liberi, eseguire il flusso di
lavoro nel giorno lavorativo successivo più vicino. Se i venerdì sono giorni liberi,
eseguire il flusso di lavoro nel giorno lavorativo immediatamente precedente. In
questo esempio, i giorni liberi sono i sabato e le domeniche e tutte le date elencate
nel calendario di default HOLIDAYS. I giorni lavorativi sono tutti i giorni dal
lunedì al venerdì, a meno che non siano elencati nel calendario HOLIDAYS.
schedule sked1
on mo, 29/12/2001 fdnext
on fr fdprev
114 IBM Tivoli Workload Scheduler - Manuale di riferimento
opens
Specifica i file che devono essere disponibili prima dell’avvio di un lavoro o di un
flusso di lavoro.
Synopsis
opens [wkstation#]″filename″ [(qualifier)] [,...]
Arguments
wkstation
Specifica il nome della workstation o della classe di workstation su cui si
trovano i file. Il valore di default è la workstation o la classe di workstation
del lavoro dipendente o del flusso di lavoro. Se si utilizza una classe di
workstation, essa deve essere la stessa del flusso di lavoro che include
questa istruzione.
filename
Specifica il nome del file, racchiuso tra apici. E’ possibile utilizzare IBM
Tivoli Workload Scheduler come parte o come stringa intera del nome file.
Se si utilizza un parametro, questo deve essere racchiuso tra segni di
omissione (^).
Il nome file deve essere completo per tutti i tipi di workstation ad
eccezione degli agent estesi (XA), per i quali non è obbligatorio.
qualifier
Specifica una condizione di verifica valida. Su UNIX, il qualificativo viene
inoltrato al comando test, che viene eseguito come root in bin/sh.
Su Windows, la funzione di verifica viene eseguita come utente maestro. I
qualificativi validi sono:
-d %p True se il file esiste e si trova in una directory.
-e %p Vero se il file esiste.
-f %p True se il file esiste ed è un file regolare.
-r %p True se il file esiste ed è leggibile.
-s %p True se il file esiste e la sua dimensione è maggiore di zero.
-w %p True se il file esiste ed è scrivibile.
Su UNIX e Windows, l’espressione %p inserisce il nome del file.
Immettere (notempty) è come immettere (-s %p). Se non viene specificato
nessun qualificativo, il valore di default è (-f %p).
Usage Notes
La combinazione del percorso del file con i qualificatori non può superare i 120
caratteri e il nome del file non può superare i 28 caratteri.
Esempi
L’esempio seguente verifica che il file c:\users\fred\datafiles\file88 sulla
workstation nt5 sia disponibile per l’accesso alla lettura prima dell’avvio
ux2#sked6:
schedule ux2#sked6 on tu opens nt5#"c:\users\fred\datafiles\file88"
L’esempio seguente verifica l’esistenza delle tre directory, /john, /mary e /roger
prima dell’avvio del lavoro jobr2:
Capitolo 4. Linguaggio di pianificazione 115
jobr2 opens "/users"(-d %p/john -a -d %p/mary -a -d %p/roger)
L’esempio seguente verifica che cron abbia creato il file FIFO prima dell’avvio di
un lavoro job6:
job6 opens "/usr/lib/cron/FIFO"(-p %p)
L’esempio seguente verifica l’esistenza del file d:\work\john\execit1 sulla
workstation dev3 e verifica che tale file non sia vuoto prima di eseguire un lavoro
jobt2:
jobt2 opens dev3#"d:\work\john\execit1"(notempty)
L’esempio seguente controlla che il file c:\tech\checker\startf sulla workstation
nyc abbia una dimensione maggiore di zero e che sia scrivibile, prima di eseguire
il lavoro job77:
job77 opens nyc#"C:\tech\checker\startf"(-s %p -a -w %p)
Sicurezza per i comandi test(1): Su UNIX, una funzione di sicurezza speciale
impedisce l’uso non autorizzato di altri comandi nel qualificativo. Ad esempio, il
file riportato di seguito contiene un comando nel qualificativo:
/users/xpr/hp3000/send2(-n "’ls /users/xpr/hp3000/m*’" -o -r %p)
Se il qualificativo contiene un altro comando, i seguenti controlli non vengono
effettuati:
1. L’opzione locale jm no root deve essere impostata su no.
2. Nel file security, l’utente che documenta la pianificazione o l’aggiunta della
dipendenza Open File con un comando Conman adddep, è necessario inoltrare
l’accesso a un lavoro con gli attributi seguenti:
name=cmdstest.fileeq
logon=root
jcl=il percorso del file opens
cpu=la CPU su cui risiedono i file opens
Tenere presente che cmdstest e fileeq non esistono.
116 IBM Tivoli Workload Scheduler - Manuale di riferimento
priority
Imposta la priorità di un lavoro o di un flusso di lavoro.
Synopsis
priority number | hi | go
Arguments
number Specifica la priorità. I valori possibili sono compresi tra 0 e 99. Una
priorità zero impedisce l’avvio del lavoro o del flusso di lavoro.
hi L’equivalente di una priorità 100.
go L’equivalente di una priorità 101, la priorità più alta.
Esempi
L’esempio seguente illustra le relazioni tra il flusso di lavoro e l e priorità del
flusso di lavoro. I lavori vengono lanciati nel seguente ordine: job1, job2, joba,
jobb.
schedule sked1 on tu
priority 50
:
job1 priority 15
job2 priority 10
end
schedule sked2 on tu
priority 10
:
joba priority 60
jobb priority 50
end
Se le priorità del flusso di lavoro sono le stesse, i lavori vengono avviati nel
seguente ordine: joba, jobb, job1, job2.
Capitolo 4. Linguaggio di pianificazione 117
prompt
Specifica i prompt a cui è necessario rispondere affermativamente prima dell’avvio
di un lavoro o di un flusso di lavoro.
Synopsis
prompt promptname [,...]
prompt ″[: | !]text″ [...]
Arguments
promptname Specifica il nome del prompt nel database.
text Specifica un prompt literal come stringa di testo racchiusa tra
virgolette (″). Più stringhe separate de barre retroverse n (\n)
possono essere utilizzate per messaggi lunghi. Se la stringa inizia
con i due punti (:), il messaggio viene visualizzato ma non è
necessaria alcuna risposta. Se la stringa comincia con un punto
esclamativo (!), il messaggio non viene visualizzato ma richiede
una risposta. E’ possibile includere una barra retroversa n (\n) nel
testo per nuove righe.
E’ possibile utilizzare uno o più parametri come parte o come
stringa di testo completa. Per utilizzare un parametro, inserire il
nome tra segni di omissione (^).
Nota: In un prompt locale, quando non si indica un parametro, i
segni di omissione (^) devono essere preceduti da una barra
retroversa (\) oppure causeranno errori nella prompt. Nei
prompt globali, i segni di omissione non devono essere
preceduti da una barra retroversa.
Esempi
L’esempio seguente illustra i literal e le richieste denominate. Il primo prompt è un
prompt literal che utilizza un parametro dei nomi denominato sys1. Quando una
risposta affermativa singola viene ricevuta per la richiesta denominata apmsg,
verranno soddisfatte le dipendenze per job1 e job2.
schedule sked3 on tu,th
prompt "All ap users logged out of ^sys1^? (y/n)"
:
job1 prompt apmsg
job2 prompt apmsg
end
L’esempio seguente definisce un prompt literal che apparirà su più di una riga. E’
definito con una barra retroversa n (\n) alla fine di ogni riga:
schedule sked5 on fr
prompt "The jobs in this job stream consume \n
an enormous amount of cpu time.\n
Do you want to launch it now? (y/n)"
:
j1
j2 follows j1
end
118 IBM Tivoli Workload Scheduler - Manuale di riferimento
schedule
Specifica il nome del flusso di lavoro. Ad eccezione dei commenti, questa deve
essere la prima parola chiave in un flusso di lavoro e deve essere seguita da una
parola chiave on.
Synopsis
schedule [wkstation#]jstreamname on ...
Arguments
wkstation Specifica il nome della workstation su cui viene avviato il flusso di
lavoro. Il valore di default è la workstation su cui viene eseguito il
Composer per aggiungere il flusso di lavoro.
jstreamname
Specifica il nome del flusso di lavoro. Il nome deve iniziare con
una lettera e può contenere caratteri alfanumerici, trattini e
caratteri di sottolineatura. Può contenere fino a 16 caratteri.
on
Specifica la data e la frequenza con cui viene selezionato il flusso
di lavoro per l’esecuzione. Per ulteriori informazioni, consultare
“il” a pagina 112.
Esempi
L’esempio seguente denomina un flusso di lavorosked1 che viene eseguito su una
workstation su cui è n esecuzione il Composer:
schedule sked1 on tu
L’esempio seguente denomina un flusso di lavorosked-2 che viene eseguito su una
workstation su cui è in esecuzione il Composer:
schedule sked-2 on everyday except fr
L’esempio seguente denomina un flusso di lavoroskedux7 eseguito su una
workstation hpux3:
schedule hpux3#skedux7 on monthend
Capitolo 4. Linguaggio di pianificazione 119
until
Specifica l’ultima ora in cui eseguire un lavoro o un flusso di lavoro.
Synopsis
until time [timezone|tz tzname][+n day[s]] [onuntil action]
Arguments
time Specifica l’ora del giorno. I valori possibili rientrano in un intervallo
compreso tra 0000 e 2359.
tzname Specifica il fuso orario da utilizzare durante il calcolo dell’ora. Consultare
Appendice B, “Gestione dei fusi orari”, a pagina 331 per i nomi del fuso
orario. Il valore di default è il fuso orario della workstation su cui viene
avviato il lavoro o l’esecuzione del lavoro.
Nota: Se vengono specificate un’ora until e un’ora at, il fuso orario deve
essere uguale.
n Specifica uno scostamento in giorni dalla data e dall’ora pianificate.
onuntil action
Specifica l’azione da eseguire su un lavoro o su un flusso di lavoro di cui è
scaduta l’ora until ma che non è stato ancora avviato. Vengono di seguito
riportati i valori possibili del parametro action:
suppr Lo stato del flusso di lavoro finale è HOLD se contiene almeno un
lavoro every. Altrimenti, lo stato finale viene calcolato utilizzando
le normali regole e i lavori con l’opzione onuntil suppr vengono
considerati nello stato SUCC quando si verifica l’ora until, anche
se le dipendenze non sono state effettivamente rilasciate.
cont Il lavoro o flusso di lavoro viene eseguito quando tutte le
condizioni necessarie sono soddisfatte e viene scritto un messaggio
di notifica nel log quando l’ora di avvio scade.
canc Un lavoro o un flusso di lavoro viene annullato finché non scade il
tempo specificato. Qualsiasi lavoro o flusso di lavoro dipendente
dal completamento di un lavoro o flusso di lavoro annullato sarà
eseguito perché la dipendenza non esiste più.
Esempi
L’esempio seguente impedisce l’avvio di sked1 dopo le 5:00 p.m. di martedì:
schedule sked1 on tu until 1700 :
Il seguente esempio avvia sked1 at 5:00 p.m., quando scade il tempo del valore
″until″:
schedule sked1 until 1700 onuntil cont
L’esempio seguente avvia job1 tra l’1:00 p.m. e le 5:00 p.m. nei giorni della
settimana:
schedule sked2 on weekdays :
job1 at 1300 until 1700
end
L’esempio seguente avvia joba ogni 15 minuti tra le 10:30 p.m. e le 11:30 p.m. il
lunedì:
120 IBM Tivoli Workload Scheduler - Manuale di riferimento
schedule sked3 on mo :
joba at 2230 every 0015 until 2330
end
L’esempio seguente avvia un flusso di lavoro sked4 la domenica tra le 8:00 a.m. e
l’1:00 p.m. I lavori vengono avviati in questo intervallo:
schedule sked4 on fr at 0800 + 2 days
until 1300 + 2 days
:
job1
job2 at 0900 <<launched on sunday>>
job3 follows job2 at 1200 <<launched on sunday>>
end
Il seguente esempio avvia il flusso di lavoro sked8 nei fine settimana alle 4:00 del
pomeriggio e deve essere completato entro le 5 del pomeriggio. Se il flusso di
lavoro non viene completato entro le 5 del pomeriggio, viene considerato un flusso
di lavoro ritardatario. I lavori devono essere avviati come segue: job1 viene
eseguito alle 4 del pomeriggio, o al più tardi alle 4:20 del pomeriggio. Se entro
quest’ora job1 non è stato ancora avviato, viene scritto un messaggio di notifica nel
log e viene avviata l’esecuzione. job2 viene eseguito alle 4:30 del pomeriggio o al
più tardi alle 4:50 del pomeriggio. Se entro quest’ora job2 non è stato ancora
avviato, viene annullato.
schedule sked8 on weekdays at 1600 deadline 1700 :
job1 at 1600 until 1620 onuntil cont
job2 at 1630 until 1650 onuntil canc
end
Il seguente esempio avvia il flusso di lavoro sked01. Quando si verifica l’evento
until, viene eseguito il flusso di lavoro sked02, poiché lo stato del flusso di lavoro
sked01 è SUCC. Invece, il flusso di lavoro sked03 non viene eseguito perché ha
una dipendenza dell’ora puntuale sul lavoro job01 e questa dipendenza non è
stata rilasciata.
SCHEDULE sked01 on everyday:
job01 until 2035 onuntil suppr
end
SCHEDULE sked02 on everyday follows sked01.@
:
job02
end
SCHEDULE sked03 on everyday follows sked01.JTEST
:
job03
END
Capitolo 4. Linguaggio di pianificazione 121
Capitolo 5. Riferimento a Conman
L’ambiente di pianificazione della produzione IBM Tivoli Workload Scheduler
viene gestito con il programma Conman. Conman viene utilizzato per avviare e
arrestare l’elaborazione, alterare e visualizzare la pianificazione della produzione
(Symphony) e controllare il collegamento della workstation in una rete. Questo
capitolo contiene informazioni su quanto segue:
v Esecuzione di Conman
v Selezione e qualifica dei lavori e dei flussi di lavoro
v Sintassi e utilizzo dei comandi Conman
Esecuzione di conman
Per eseguire Conman, immettere il seguente comando:
conman [“command[&...][&]"]
Esempi
Nell’esempio riportato di seguito, Conman avvia e ed esegue il prompt di un
comando:
conman
Nel seguente esempio, Conman esegue i comandi sj e sp, quindi viene interrotto:
conman"sj&sp"
Nel seguente esempio, Conman esegue i comandi sj e sp ed effettua il prompt di
un comando:
conman"sj&sp&"
Nel seguente esempio, Conman legge i comandi dacfile:
conman < cfile
Nel seguente esempio, i comandi dacfile vengono associati a Conman:
cat cfile | conman
Caratteri di controllo
Per interrompere Conman, è possibile immettere i seguenti caratteri di controllo.
Control+c
Appena possibile Conman arresta l’esecuzione del comando corrente e
restituisce un prompt del comando.
Control+d
Dopo l’esecuzione del comando corrente Conman viene interrotto.
Esecuzione dei comandi di sistema
Quando viene immesso un comando di sistema utilizzando un pipe o un prefisso
del comando di sistema (: o !), esso viene eseguito da un processo child. L’ID
utente valido del processo child viene impostato sull’ID dell’utente che sta
eseguendo Conman per impedire la violazione della sicurezza.
© Copyright IBM Corp. 1999, 2004 123
Prompt dell’utente
Quando si utilizzano caratteri jolly per selezionare gli oggetti che devono essere
eseguiti da un comando, Conman esegue il prompt di conferma dell’avvenuta
ricerca di ogni oggetto corrispondente. Rispondendo di sì viene abilitata l’azione e
no l’oggetto viene ignorato senza eseguire l’azione.
Quando Conman viene eseguito in modalità interattiva, i prompt di conferma
vengono emessi sul proprio computer. Se si preme il tasto Invio in risposta ad un
prompt, la risposta viene interpretata come no. Il prompt può essere disabilitato
includendo l’opzione ;noask in un comando.
Sebbene non sia stata emesso alcun prompt di conferma quando Conman non è in
esecuzione in modalità interattiva, esso funziona come se la risposta fosse stata no
in ogni caso e nessun oggetto viene attivato. E’ importante, tuttavia, includere
l’opzione ;noask ai comandi quando Conman non è in esecuzione in modalità
interattiva.
Output terminale
L’output sul computer viene specificato dalle variabili shell definite
MAESTROLINES e MAESTROCOLUMNS. Se non è stata impostata alcuna
variabile, vengono utilizzate le variabili shell standard, LINES e COLUMNS. Le
variabili possono essere impostate nel seguente modo:
$MAESTROLINES
Specifica il numero di righe per schermo. Il valore di default è 24. Alla fine
di ogni pagina dello schermo, Conman effettua un prompt per continuare.
Se MAESTROLINES (o LINES) viene impostato su zero o su un numero
negativo, Conman non si arresta alla fine della pagina.
$MAESTROCOLUMNS
Specifica il numero di caratteri per riga. Il valore di default è 80.
$MAESTRO_OUTPUT_STYLE
Specifica il metodo di visualizzazione dei nomi oggetto. Se impostato su
LONG, vengono visualizzati i nomi per esteso. Se non viene impostato o
se si imposta su qualsiasi valore diverso da LONG, i nomi lunghi vengono
interrotti a otto caratteri seguiti da un segno più finale.
Output non in linea
L’opzione ;offline nei comandi Conman viene generalmente utilizzata per
stampare l’output di un comando. Quando la si include, le seguenti variabili shell
controllano l’output:
$MAESTROLP
Specifica la destinazione di un output del comando. Impostarla su uno dei
seguenti:
> file Reindirizza l’output ad un file e sovrascrive il contenuto del file. Se
il file non esiste, viene creato.
>> file Reindirizza l’output su un file e accoda l’output alla fine del file.
Se il file non esiste, viene creato.
| comando
Associa l’output ad un processo o comando di sistema. Il comando
di sistema viene eseguito che venga creato o meno l’output.
124 IBM Tivoli Workload Scheduler - Manuale di riferimento
|| command
Associa l’output ad un processo o comando di sistema. Se non
esiste alcun output, il comando di sistema non viene eseguito.
Il valore di default è | lp -tCONLIST, il quale associa l’output del
comando alla stampante e inserisce il titolo “CONLIST” nella pagina
banner di stampa.
$MAESTROLPLINES
Specifica il numero di righe per pagina. Il valore di default è 60.
$MAESTROLPCOLUMNS
Specifica il numero di caratteri per riga. Il valore di default è 132.
Le variabili devono essere esportate prima dell’esecuzione di Conman.
Selezione del prompt del comando conman
Il prompt del comando conman è, per default, un segno %. Viene definito nel file
TWShome/localopts. Il prompt del comando di default è un trattino (-). Per
selezionare un prompt differente, modificare l’opzione del prompt di conman nel
file localopts e modificare il trattino. Il prompt può essere lungo fino a dieci
caratteri, non è incluso il segno del cancelletto (#).
#----------------------------------------------------------------------------
# Custom format attributes
#
date format = 1 # The possible values are 0-ymd, 1-mdy,
2-dmy, 3-NLS.
composer prompt = -
conman prompt = %
switch sym prompt = <n>%
#----------------------------------------------------------------------------
Sintassi dei comandi
I comandi Conman sono composti dai seguenti elementi:
argomenti di selezione commandname
dove:
commandname
Specifica il nome del comando.
selection
Specifica l’oggetto o la serie di oggetti da eseguire.
arguments
Specifica gli argomenti del comando.
Quanto segue è un esempio di un comando Conman:
sj sked1.@+state=hold~priority=0;info;offline
dove:
sj La forma abbreviata del comandoshowjobs.
sked1.@+state=hold~priority=0
Seleziona tutti i lavori nel flusso di lavoro sked1 che si trovano in uno
stato congelato con una priorità diversa da zero.
Capitolo 5. Riferimento a Conman 125
;info;offline
Argomenti per il comando showjobs.
Caratteri jolly
Sono consentiti i seguenti caratteri jolly:
@ Sostituisce uno o più caratteri alfanumerici.
? Sostituisce un carattere alfanumerico.
% Sostituisce un carattere numerico.
Delimitatori e caratteri speciali
I seguenti caratteri hanno significati speciali nei comandi Conman:
Char. Descrizione
& Delimitatore comando. Consultare “Esecuzione di conman” a pagina 123.
+ Un delimitatore utilizzato per selezionare gli oggetti dei comandi. Aggiunge
un attributo necessario per l’oggetto. Ad esempio:
sked1.@+priority=0
~ Un delimitatore utilizzato per selezionare gli oggetti dei comandi. Aggiunge
un attributo necessario per l’oggetto. Ad esempio:
sked1.@~priority=0
; Delimitatore argomenti. Ad esempio:
;info;offline
, Delimitatore intervallo e ripetizione. Ad esempio:
state=hold,sked,pend
= Delimitatore valori. Ad esempio:
state=hold
: ! Prefissi del comando che inviano il comando al sistema. Questi prefissi sono
facoltativi; se Conman non riconosce il comando, lo invia automaticamente al
sistema. Ad esempio:
!ls o :ls
<<>> Parentesi di commento. Ad esempio:
sj @#@.@ <<comment>>
* Prefisso commento. Il prefisso deve essere il primo carattere su una riga
comandi o deve seguire un delimitatore comandi. Ad esempio:
*comment
o
sj& *comment
> Reindirizza l’output del comando ad un file e sovrascrive il contenuto del file.
Se il file non esiste, viene creato. Ad esempio:
sj> joblist
>> Reindirizza l’output del comando ad un file e accoda l’output alla fine del
file. Se il file non esiste, viene creato. Ad esempio:
sj>> joblist
| Associa l’output del comando ad un processo o ad un comando di sistema. Il
comando di sistema viene eseguito che venga creato o meno l’output. Ad
esempio:
sj| grep ABEND
126 IBM Tivoli Workload Scheduler - Manuale di riferimento
Char. Descrizione
|| Associa l’output del comando ad un processo o ad un comando di sistema. Se
non esiste alcun output, il comando di sistema non viene eseguito. Ad
esempio:
sj || grep ABEND
Elenco di comandi
La seguente tabella elenca la serie di comandi Conman. I nomi dei comandi
Command e le parole chiave possono essere immessi in caratteri maiuscoli e
minuscoli e possono essere abbreviati come i caratteri iniziali per distinguerli tra di
loro. Anche alcuni nomi del comando hanno forme brevi.
Comando
Forma
breve Descrizione Tipo1 Pagina
adddep adj | ads Aggiunge un lavoro o le
dipendenze del flusso di
lavoro.
M,F 144, 146
altpass Altera una password di
definizione dell’oggetto
dell’utente.
M,F 148
altpri ap Altera un lavoro o le priorità
del flusso di lavoro.
M,F 149
cancel cj | cs Annulla un lavoro o un flusso
di lavoro.
M,F 157, 152
confirm Conferma il completamento
del lavoro.
M,F 154
console Assegna la console IBM Tivoli
Workload Scheduler.
M,F,A 155
continue Ignora l’errore successivo. M,F,A 156
deldep ddj | dds Cancella il lavoro o le
dipendenze del flusso di
lavoro.
M,F 174, 159
display df | dj |
ds
Visualizza i file, i lavori e i
flussi di lavoro.
M,F,A2 161
exit Termina Conman. M,F,A 162
fence Imposta il contenitore lavoro
IBM Tivoli Workload
Scheduler.
M,F,A 163
help5 Visualizza le informazioni sul
comando.
M,F,A 164
kill Arresta un lavoro di
esecuzione.
M,F 165
limit lc | ls Modifica un limite della
workstation o del lavoro del
flusso lavori.
M,F,A3 166, 167
link lk Apre i collegamenti della
workstation.
M,F,A 168
listsym Visualizza un elenco di file di
log Symphony.
M,F 170
Capitolo 5. Riferimento a Conman 127
Comando
Forma
breve Descrizione Tipo1 Pagina
recall rc Visualizza i messaggi del
prompt.
M,F 171
redo Modifica il comando
precedente.
M,F,A 172
release rj | rs Effettua il release del lavoro o
le dipendenze del flusso di
lavoro.
M,F 150, 176
reply Risponde al messaggio di
prompt.
M,F 178
rerun rr Esegue nuovamente un lavoro. M,F 179
resource Modifica il numero di unità
delle risorse.
M,F 182
setsym Seleziona un file di log
Symphony.
M,F 183
showcpus sc Visualizza informazioni sul
collegamento e sulla
workstation.
M,F,A 184
showdomain Visualizza le informazioni sul
dominio.
M,F,A 188
showfiles sf Visualizza le informazioni sui
file.
M,F 189
showjobs sj Visualizza le informazioni sui
lavori.
M,F 191
showprompts sp Visualizza le informazioni sui
prompt.
M,F 199
showresources sr Visualizza le informazioni sulle
risorse.
M,F 201
showschedules ss Visualizza le informazioni sui
flussi di lavoro.
M,F 203
shutdown Arresta i processi di
produzione del IBM Tivoli
Workload Scheduler.
M,F,A 206
start Avvia i processi di produzione
del IBM Tivoli Workload
Scheduler.
M,F,A 207
status Visualizza lo stato di
produzione del IBM Tivoli
Workload Scheduler.
M,F,A 209
stop Arresta i processi di
produzione del IBM Tivoli
Workload Scheduler.
M,F,A 210
stop ;progressive Arresta i processi di
produzione del IBM Tivoli
Workload Scheduler
gerarchicamente.
212
submit sbd |
sbf |
sbj |
sbs
Inoltra un comando, un file, un
lavoro o un flusso di lavoro.
M,F,A4 213,
215,
217,
219
128 IBM Tivoli Workload Scheduler - Manuale di riferimento
Comando
Forma
breve Descrizione Tipo1 Pagina
switchmgr Commuta il Gestore dominio. M,F 221
sys-command Invia un comando al sistema. M,F,A 222
tellop to Invia un messaggio alla
console.
M,F,A 223
unlink Chiude i collegamenti della
workstation.
M,F,A 224
version v Visualizza il banner del
programma Conman.
M,F,A 226
1. Tipi di workstation: gestori dominio (M), agent tolleranti l’errore (F), agent
standard (A).
2. E’ possibile visualizzare solo i file su un agent standard.
3. E’ possibile modificare il limite solo dei lavori sua workstation di agent
standard.
4. E’ possibile utilizzare submit job (sbj) e submit sched (sbs) su un agent
standard solo se la directory mozart sul Gestore dominio master è accessibile
all’agent standard.
5. Non disponibile sulle piattaforme Windows supportate.
Selezione dei lavori nei comandi
Per i comandi che operano sui lavori, i lavori di destinazione vengono selezionati
tramite attributi e qualificativi. La sintassi di selezione del lavoro viene visualizzata
di seguito e viene descritta sulle seguenti pagine.
Sintesi
[wkstation#] {jobstream.job | jobnumber} [+ | ~jobqualifier[...]]
o:
netagent::[wkstation#] jobstream.job
Argomenti
wkstation
Quando utilizzato con jobstream.job, ciò specifica il nome della workstation
su cui è in esecuzione il flusso di lavoro. Quando utilizzato con jobnumber,
specifica la workstation su cui è in esecuzione il lavoro. Sono consentiti
caratteri jolly.
jobstream
Specifica il nome del flusso di lavoro in cui è in esecuzione il lavoro. Sono
consentiti caratteri jolly.
job Specifica il nome del lavoro. Sono consentiti caratteri jolly.
jobnumber
Specifica il numero del lavoro.
jobqualifier
Consultare la seguente sezione, “Qualificativi lavoro” a pagina 130.
Capitolo 5. Riferimento a Conman 129
netagent
Specifica il nome dell’agent di rete dello scheduler che viene interfacciato
con la rete dello scheduler remota che contiene il lavoro di destinazione. I
doppi due punti (::) rappresentano un delimitatore necessario. Sono
consentiti caratteri jolly. Per ulteriori informazioni fare riferimento a
Capitolo 9, “Riferimento Agent di rete”, a pagina 299.
Qualificativi lavoro
I qualificativi lavoro specificano gli attributi dei lavori che devono essere eseguiti
da un comando. Essi vengono preceduti dal prefisso + o~. + indica che i lavori con
l’attributo sono abilitati per il comando. ~ indica che i lavori con l’attributo sono
esclusi dal comando.
Le parole chiave dei qualificativi lavoro possono essere abbreviate in modo da
poterle distinguerle tra loro.
at[=time | lowtime | hightime | lowtime,hightime [absolute | abs]]
Seleziona o esclude i lavori in base all’ora di avvio programmata.
time
Specifica l’ora di avvio programmata espressa nel modo seguente:
hhmm[+n days | date] [timezone|tz tzname]
dove:
hhmm L’ora e i minuti.
+n days
La ricorrenza successiva di hhmm in n giorni.
date La ricorrenza successiva di hhmm su date, espressa come
mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del lavoro. Consultare Appendice B,
“Gestione dei fusi orari”, a pagina 331 per i nomi validi.
time è conforme alle seguenti regole:
v Quando hhmm indica un orario precedente a quello corrente, il
momento di avvio è domani; quando hhmm indica un orario
successivo a quello corrente, il momento di avvio è oggi.
v Quando hhmm è maggiore di 2400, viene diviso per 2400. Del
risultato, la parte intera rappresenta il numero di + days, mentre
la parte decimale rappresenta l’ora.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i lavori con ore di avvio
pianificate o con ore successive a quella pianificata.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
nello stesso formato di time. Vengono selezionati i lavori con ore di
avvio pianificate o con ore di avvio precedenti a quella stabilita.
absolute | abs
Specifica l’ora di avvio specificata per il giorno corrente. Questa
parola chiave può essere utilizzata solo con timezone|tz tzname e
hhmm. E’ conforme alle seguenti regole:
130 IBM Tivoli Workload Scheduler - Manuale di riferimento
v Quando hhmm indica un orario precedente a quello corrente, il
momento di avvio è immediato.
v Quando hhmm indica un orario successivo a quello corrente,
l’ora di avvio è quella specificata da hhmm del giorno corrente.
v Quando hhmm supera 2400, viene divisa per 2400 per ottenere
l’ora e il giorno. Del risultato della divisione, la parte intera
rappresenta il giorno (numero di + days), mentre quella decimale
corrisponde all’ora:
– Se l’ora calcolata è precedente a quella corrente, l’ora di avvio
è un giorno prima del giorno calcolato all’ora calcolata.
– Se l’ora calcolata è successiva a quella corrente, l’ora di avvio
il giorno calcolato all’ora calcolata.
Ad esempio, se l’ora corrente è 1200 e un giorno viene inviato
allehhmm=3500 (2400 + 1100), con parola chiave abs specificata,
il lavoro viene avviato alle 1100 del giorno successivo. Senza la
specificazione della parola chiave abs, il lavoro viene avviato alle
1100, due giorni dopo.
Se at viene utilizzato da solo, l’intervallo è open-ended e, se è stata
pianificata l’ora di avvio, i lavori vengono selezionati o esclusi.
confirmed
Seleziona o esclude i lavori che sono stati pianificati utilizzando la parola
chiave confirm.
deadline[=time | lowtime, | ,hightime | lowtime,hightime]
Specifica l’ora entro la quale un lavoro deve essere completato.
hhmm[+n days | date] [timezone|tz tzname]
hhmm L’ora e i minuti.
+n days
Uno scostamento in giorni dall’ora di tempo limite.
date La ricorrenza successiva di hhmm su date, espressa come mm/dd/yy.
timezone|tz tzname
Specifica il fuso orario da utilizzare durante il calcolo del tempo
limite. Consultare Appendice B, “Gestione dei fusi orari”, a pagina
331 per i nomi del fuso orario. Il valore di default è il fuso orario
della workstation su cui viene avviato il lavoro o l’esecuzione del
lavoro.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i lavori con tempo
limite impostato sull’ora pianificata o successivo ad essa.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
nello stesso formato di time. Vengono selezionati i lavori con tempo
limite impostato sull’ora pianificata o precedente ad essa.
every[=rate | lowrate, | ,highrate | lowrate,highrate]
Seleziona o esclude i lavori in base al fatto che abbiano o meno intervalli
di ripetizione.
rate Specifica l’intervallo di esecuzione pianificato, espresso in ore e
minuti (hhmm).
Capitolo 5. Riferimento a Conman 131
lowrate Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di rate. Vengono selezionati i lavori che hanno
intervalli di ripetizione uguali o superiori a questo intervallo.
highrate
Specifica il limite massimo di un intervallo di tempo, espresso
nello stesso formato di rate. Vengono selezionati i lavori che hanno
intervalli di ripetizione inferiori o uguali a questo intervallo.
Se every viene utilizzato da solo, l’intervallo è open-ended e, se è stata
pianificata l’ora di avvio, i lavori vengono selezionati o esclusi.
finished[=time | lowtime, | ,hightime | lowtime,hightime]
Seleziona o esclude i lavori se sono stati terminati o meno.
time Specifica l’ora esatta in cui sono stati terminati i lavori, espressa
come segue:
hhmm [date] [timezone|tz tzname]
hhmm L’ora e i minuti.
date La ricorrenza successiva di hhmm sulla data, espressa come
mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del lavoro. Consultare Appendice B,
“Gestione dei fusi orari”, a pagina 331 per i nomi validi.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i lavori terminati in
quell’ora o successivamente.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
nello stesso formato di time. Vengono selezionati i lavori che
terminano in quell’ora o successivamente.
Se finished viene utilizzato da solo, l’intervallo è open-ended e i lavori
vengono selezionati o esclusi se hanno terminato l’esecuzione.
follows[=[netagent::][[wkstation#] jobstream.]job[;nocheck][;wait=time]]
Seleziona o esclude i lavori in base al fatto che dispongano o meno di una
dipendenza follows.
netagent
Specifica il nome dell’agent di rete dello scheduler che viene
interfacciato con la rete dello scheduler remota che contiene il
lavoro prerequisito. Sono consentiti caratteri jolly. Per ulteriori
informazioni fare riferimento a Capitolo 9, “Riferimento Agent di
rete”, a pagina 299.
wkstation
Specifica il nome della workstation su cui è in esecuzione il lavoro
prerequisito. Sono consentiti caratteri jolly.
jobstream
Specifica il nome del flusso di lavoro in cui è in esecuzione il
lavoro prerequisito. Sono consentiti caratteri jolly. Se si
immettejobstream.@, viene specificato che il lavoro di destinazione
segue tutti i lavori nel flusso di lavoro.
job Specifica il nome del lavoro prerequisito. Quando viene immesso
132 IBM Tivoli Workload Scheduler - Manuale di riferimento
senza un jobstream, indica che il lavoro prerequisito si trova nello
stesso flusso di lavoro del lavoro di destinazione. Non specificare il
nome lavoro utilizzando caratteri speciali per una dipendenza
follows.
nocheck
È valido solo per i comandi sbd, sbj e sbs. Il comando non verifica
l’esistenza di lavori prerequisiti nella symphony. Quando Batchman
elabora il comando di invio, aggiunge gli argomenti del comando
alla symphony (ad esempio il lavoro da inviare) incluse le
dipendenze dal lavoro prerequisito esistente nella symphony. Per i
lavori prerequisiti che non esistono nel file symphony, Batchman
stampa un avviso in stdlist.
wait=time
È valido solo per i comandi sbd, sbj e sbs. Per l’intervallo di tempo
specificato, conman verifica ogni secondo l’esistenza dei lavori
prerequisiti nel file symphony. Conman continua la verifica finché
non vengono trovati i lavori prerequisiti o non viene raggiunto
l’intervallo specificato per la parola chiave wait. Una volta rilevati
tutti i lavori prerequisiti, Batchman elabora il comando submit. Se
anche un solo lavoro prerequisito non viene trovato nella
symphony e l’intervallo di tempo scade, Conman non elabora il
comando command e restituisce un messaggio di errore. Il numero
massimo di secondi è 1200.
Se si specifica nocheck insieme a wait, quando l’intervallo di
tempo scade, Batchman elabora il comando submit anche se il
lavoro prerequisito non è presente nella symphony. Il lavoro da
inviare e i lavori prerequisiti che esistono nella symphony vengono
aggiunti alla symphony.
Se follows viene utilizzato da solo, i lavori vengono selezionati o esclusi se
dispongono di dipendenze follows.
logon=username
Selezionare i lavori in base ai nomi utente sotto cui sono in esecuzione. Se
username contiene caratteri speciali, è necessario che sia racchiuso tra apici
(″). Sono consentiti caratteri jolly.
needs[=[wkstation#]resourcename]
Seleziona o esclude i lavori a seconda che dispongano o meno di una
dipendenza della risorsa.
wkstation
Specifica il nome della workstation su cui viene definita la risorsa.
Sono consentiti caratteri jolly.
resourcename
Specifica il nome della risorsa. Sono consentiti caratteri jolly.
Se needs viene utilizzato da solo, i lavori vengono selezionati o esclusi se
dispongono di una dipendenza della risorsa.
opens[=[wkstation#]filename[(qualifier)]]
Selezionare i lavori in base al fatto che abbiano o meno una dipendenza
file. Per dipendenza file si intende quando un lavoro o flusso di lavoro
dipende dall’esistenza di uno o più file prima di poter iniziare
l’esecuzione.
Capitolo 5. Riferimento a Conman 133
wkstation
Specifica il nome della workstation su cui si trovano i file. Sono
consentiti caratteri jolly.
filename
Specifica il nome del file. Il nome deve essere racchiuso tra apici (″)
se contiene caratteri diversi dai seguenti: alfanumerici, trattini (-),
barre (/), barre retroverse (\) e caratteri di sottolineatura (_). Sono
consentiti caratteri jolly.
qualifier
Una condizione di testo valida. Se omessa, i lavori vengono
selezionati o esclusi senza considerare un qualificativo.
Se opens viene utilizzato da solo, i lavori vengono selezionati o esclusi se
hanno una dipendenza file. Per dipendenza file si intende quando un
lavoro o flusso di lavoro dipende dall’esistenza di uno o più file prima di
poter iniziare l’esecuzione.
priority=pri | lowpri, | ,highpri | lowpri,highpri
Seleziona o esclude i lavori in base alle loro priorità.
pri Specifica il valore della priorità. E’ possibile immettere un valore
compreso tra 0 e 99, hi o go.
lowpri Specifica il limite inferiore di un intervallo di priorità. I lavori
vengono selezionati con le priorità uguali o maggiori di questo
valore.
highpri Specifica il limite superiore di un intervallo priorità. I lavori
vengono selezionati con priorità inferiori o uguali a questo valore.
prompt[=promptname | msgnum]
Seleziona o esclude i lavori in base al fatto che abbiano o meno una
dipendenza prompt.
promptname
Specifica il nome di un prompt globale. Sono consentiti caratteri
jolly.
msgnum
Specifica il numero di messaggi di un prompt locale.
Se prompt viene utilizzato da solo, i lavori vengono selezionati o esclusi se
hanno una dipendenza prompt.
recovery=recv-option
Seleziona o esclude i lavori in base alle opzioni di ripristino.
recv-option
Specifica l’opzione di ripristino lavoro come stop, continue o
rerun.
scriptname=filename
Seleziona o esclude i lavori in base ai nomi del file eseguibile.
filename
Specifica il nome di un file eseguibile. Il nome deve essere
racchiuso tra apici (″) se contiene caratteri diversi dai seguenti:
alfanumerici, trattini (-), barre (/), barre retroverse (\) e caratteri di
sottolineatura (_). Sono consentiti caratteri jolly.
started[=time | lowtime, | ,hightime | lowtime,hightime]
Seleziona o esclude i lavori in base al fatto che siano stati avviati o meno.
134 IBM Tivoli Workload Scheduler - Manuale di riferimento
time Specifica l’ora esatta in cui vengono avviati i lavori, espressa nel
modo seguente:
hhmm [date] [timezone|tz tzname]
hhmm L’ora e i minuti.
date La ricorrenza successiva di hhmm sulla data, espressa come
mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del lavoro. Consultare Appendice B,
“Gestione dei fusi orari”, a pagina 331 per i nomi validi.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i lavori avviati in
quell’ora o successivamente.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
nello stesso formato di time. Vengono selezionati i lavori avviati in
quell’ora o precedentemente.
Se started viene utilizzato da solo, l’intervallo è open-ended e i lavori
vengono selezionati o esclusi in base al fatto che siano stati avviati o meno.
state=state[,...]
Seleziona o esclude i lavori in base ai loro stati.
stato Specifica lo stato corrente del lavoro. Gli stati validi del lavoro
sono:
abend Il lavoro è terminato con un codice di uscita diverso da
zero.
abenp E’ stata ricevuta una conferma abend, ma il lavoro non è
stato completato.
add Il lavoro è stato inoltrato.
done Il lavoro è stato completato in uno stato sconosciuto.
error Solo per le dipendenze internetwork, si è verificato un
errore durante il controllo dello stato remoto.
exec Il lavoro è in esecuzione.
extrn Solo per le dipendenze internetwork, lo stato è sconosciuto.
Si è verificato un errore, è stata eseguita un’operazione di
nuova esecuzione sul lavoro nel flusso di lavoro esterno
oppure il lavoro remoto o il flusso di lavoro non esiste.
fail Non in grado di avviare il lavoro.
fence La priorità del lavoro si trova sotto il delimitatore.
hold Il lavoro è in attesa della risoluzione della dipendenza.
intro Il lavoro viene introdotto per l’avvio dal sistema.
pend Il lavoro è stato completato ed è in attesa di conferma.
ready Il lavoro è pronto per l’avvio e tutte le dipendenze sono
state risolte.
sched Non è arrivata l’ora at del lavoro.
Capitolo 5. Riferimento a Conman 135
succ Il lavoro è stato completato con un codice di uscita zero.
succp E’ stata ricevuta una conferma succ, ma il lavoro non è
stato completato.
wait Il lavoro si trova nello stato di attesa. (Solo XA-Extended
Agent)
until[=time | lowtime, | ,hightime | lowtime,hightime [absolute | abs]]
Seleziona o esclude i lavori in base all’ora finale pianificata.
time Specifica l’ora finale pianificata espressa nel modo seguente:
hhmm[+n days | date] [timezone|tz tzname]
hhmm L’ora e i minuti.
+n days
La ricorrenza successiva di hhmm in n giorni.
date La ricorrenza successiva di hhmm su date, espressa come
mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del lavoro. Consultare Appendice B,
“Gestione dei fusi orari”, a pagina 331 per i nomi validi.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i lavori con ora di
avvio uguale o successivaa quella specificata.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
nello stesso formato di time. Vengono selezionati i lavori con ore di
chiusura pianificate o con ore precedenti a quelle specificate.
absolute | abs
Specifica l’ora di avvio specificata per il giorno corrente. Questa
parola chiave può essere utilizzata solo con timezone|tz tzname e
hhmm. E’ conforme alle seguenti regole:
v Quando hhmm indica un orario precedente a quello corrente, il
momento di avvio è immediato.
v Quando hhmm indica un orario successivo a quello corrente,
l’ora di avvio è quella specificata da hhmm del giorno corrente.
v Quando hhmm supera 2400, viene divisa per 2400 per ottenere
l’ora e il giorno. Del risultato della divisione, la parte intera
rappresenta il giorno (numero di + days), mentre quella decimale
corrisponde all’ora:
– Se l’ora calcolata è precedente a quella corrente, l’ora di avvio
è un giorno prima del giorno calcolato all’ora calcolata.
– Se l’ora calcolata è successiva a quella corrente, l’ora di avvio
il giorno calcolato all’ora calcolata.
Ad esempio, se l’ora corrente è 1200 e un giorno viene inviato
allehhmm=3500 (2400 + 1100), con parola chiave abs specificata,
il lavoro viene avviato alle 1100 del giorno successivo. Senza la
specificazione della parola chiave abs, il lavoro viene avviato alle
1100, due giorni dopo.
Se until viene utilizzato da solo, l’intervallo è open-ended e, se è stata
pianificata l’ora di chiusura, i lavori vengono selezionati o esclusi.
136 IBM Tivoli Workload Scheduler - Manuale di riferimento
Selezione dei flussi di lavoro nei comandi
Per i comandi che operano sui flussi di lavoro, i flussi di lavoro di destinazione
vengono selezionati tramite gli attributi e i qualificativi. La sintassi di selezione del
flusso di lavoro viene visualizzata di seguito e viene descritta sulle seguenti
pagine.
Sintesi
[wkstation#] jobstream [+ | ~jobstreamqual[...]]
Argomenti
wkstation
Specifica il nome della workstation su cui è in esecuzione il flusso di
lavoro. Sono consentiti caratteri jolly.
jobstream
Specifica il nome del flusso di lavoro. Sono consentiti caratteri jolly.
jobstreamqual
Consultare “Qualificativi flusso di lavoro”.
Qualificatori del flusso di lavoro
at[=time | lowtime, | ,hightime | lowtime,hightime [absolute | abs]]
Seleziona o esclude i flussi di lavoro in base all’ora di avvio programmata.
time Specifica l’ora di avvio programmata espressa nel modo seguente:
hhmm[+n days | date] [timezone|tz tzname]
hhmm L’ora e i minuti.
+n days
La ricorrenza successiva di hhmm in n giorni.
date La ricorrenza successiva di hhmm su date, espressa come
mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del flusso di lavoro. Consultare
Appendice B, “Gestione dei fusi orari”, a pagina 331 per i
nomi validi.
absolute | abs
Specifica l’ora di avvio specificata per il giorno corrente.
Questa parola chiave può essere utilizzata solo con
timezone|tz tzname e hhmm. E’ conforme alle seguenti
regole:
v Quando hhmm indica un orario precedente a quello
corrente, il momento di avvio è immediato.
v Quando hhmm indica un orario successivo a quello
corrente, l’ora di avvio è quella specificata da hhmm del
giorno corrente.
v Quando hhmm supera 2400, viene divisa per 2400 per
ottenere l’ora e il giorno. Del risultato della divisione, la
parte intera rappresenta il giorno (numero di + days),
mentre quella decimale corrisponde all’ora:
Capitolo 5. Riferimento a Conman 137
– Se l’ora calcolata è precedente a quella corrente, l’ora
di avvio è un giorno prima del giorno calcolato all’ora
calcolata.
– Se l’ora calcolata è successiva a quella corrente, l’ora
di avvio il giorno calcolato all’ora calcolata.
Ad esempio, se l’ora corrente è 1200 e un giorno viene
inviato allehhmm=3500 (2400 + 1100), con parola chiave
abs specificata, il lavoro viene avviato alle 1100 del
giorno successivo. Senza la specificazione della parola
chiave abs, il lavoro viene avviato alle 1100, due giorni
dopo.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i flussi di lavoro con
ore di avvio pianificate o i flussi di lavoro con ore successive a
quelle pianificate.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
nello stesso formato di time. Vengono selezionati i flussi di lavoro
con ore di avvio pianificate o i flussi di lavoro con ore precedenti a
quelle pianificate.
Se at viene utilizzato da solo, l’intervallo è open-ended e, se è stata
pianificata l’ora di avvio dei flussi di lavoro, questi vengono selezionati o
esclusi.
carriedforward
Seleziona o esclude i flussi di lavoro portati avanti.
carryforward
Seleziona o esclude i flussi di lavoro che sono stati pianificati utilizzando la
parola chiave carryforward.
finished[=time | lowtime, | ,hightime | lowtime,hightime]
Seleziona o esclude i flussi di lavoro in base al fatto che siano stati
terminati o meno.
time Specifica l’ora esatta in cui sono stati terminati i flussi di lavoro,
espressi nel modo seguente:
hhmm [date] [timezone|tz tzname]
hhmm L’ora e i minuti.
date La ricorrenza successiva di hhmm sulla data, espressa come
mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del flusso di lavoro. Consultare
Appendice B, “Gestione dei fusi orari”, a pagina 331 per i
nomi validi.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i flussi di lavoro che
vengono terminati all’ora prestabilita o successivamente.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
138 IBM Tivoli Workload Scheduler - Manuale di riferimento
nello stesso formato di time. Vengono selezionati i flussi di lavoro
che vengono terminati all’ora prestabilita o precedentemente.
Se finished viene utilizzato da solo, l’intervallo è open-ended e, se è stata
pianificata l’ora di avvio dei flussi di lavoro, questi vengono selezionati o
esclusi.
follows[=[netagent::][wkstation#] jobstream[.job[;nocheck][;wait=time]]
Seleziona o specifica i flussi di lavoro in base al fatto che abbiano o meno
una dipendenza follows.
netagent
Specifica il nome dell’agent di rete che viene interfacciato con la
rete dello scheduler remoto che contiene il lavoro o il flusso di
lavoro prerequisito. Sono consentiti caratteri jolly. Per ulteriori
informazioni sugli agent di rete, fare riferimento a Capitolo 9,
“Riferimento Agent di rete”, a pagina 299.
wkstation
Specifica il nome della workstation su cui sono in esecuzione il
lavoro o i flussi di lavoro. Sono consentiti caratteri jolly.
jobstream
Specifica il nome del flusso di lavoro prerequisito. Sono consentiti
caratteri jolly.
job Specifica il nome del lavoro prerequisito. Sono consentiti caratteri
jolly.
nocheck
È valido solo per i comandi sbd, sbj e sbs. Il comando non verifica
l’esistenza di lavori prerequisiti nella symphony. Quando Batchman
elabora il comando di invio, aggiunge gli argomenti del comando
alla symphony (ad esempio il lavoro da inviare) incluse le
dipendenze dal lavoro prerequisito esistente nella symphony. Per i
lavori prerequisiti che non esistono nel file symphony, Batchman
stampa un avviso in stdlist.
wait=time
È valido solo per i comandi sbd, sbj e sbs. Per l’intervallo di tempo
specificato, conman verifica ogni secondo l’esistenza dei lavori
prerequisiti nel file symphony. Conman continua la verifica finché
non vengono trovati i lavori prerequisiti o non viene raggiunto
l’intervallo specificato per la parola chiave wait. Una volta rilevati
tutti i lavori prerequisiti, Batchman elabora il comando submit. Se
anche un solo lavoro prerequisito non viene trovato nella
symphony e l’intervallo di tempo scade, Conman non elabora il
comando command e restituisce un messaggio di errore. Il numero
massimo di secondi è 1200.
Se si specifica nocheck insieme a wait, quando l’intervallo di
tempo scade, Batchman elabora il comando submit anche se il
lavoro prerequisito non è presente nella symphony. Il lavoro da
inviare e i lavori prerequisiti che esistono nella symphony vengono
aggiunti alla symphony.
Se follows viene utilizzato da solo, i flussi di lavoro vengono selezionati o
esclusi se hanno una dipendenza follows.
Capitolo 5. Riferimento a Conman 139
limit[=limit | lowlimit, | ,highlimit | lowlimit,highlimit]
Selezionare o escludere i flussi di lavoro in base al fatto che abbiano o
meno un limite di lavoro.
limit Specifica il valore esatto del limite di lavoro.
lowlimit
Specifica il limite di intervallo inferiore. Vengono selezionati i flussi
di lavoro che hanno limiti di lavoro uguali o maggiori di questo
limite.
highlimit
Specifica il limite di intervallo superiore. Vengono selezionati i
flussi di lavoro che hanno dei limiti di lavoro inferiori o uguali a
questo limite.
Se limit viene utilizzato da solo, l’intervallo è open-ended e, se i flussi di
lavoro hanno un limite di lavoro, vengono selezionati o esclusi.
needs[=[wkstation#]resourcename]
Seleziona o esclude i flussi di lavoro in base al fatto che abbiano o meno
una dipendenza resource.
wkstation
Specifica il nome della workstation su cui viene definita la risorsa.
Sono consentiti caratteri jolly.
resourcename
Specifica il nome della risorsa. Sono consentiti caratteri jolly.
Se needs viene utilizzato da solo, i flussi di lavoro vengono selezionati o
esclusi se hanno una dipendenza resource.
opens[=[wkstation#]filename[(qualifier)]]
Seleziona esclude i flussi di lavoro in base al fatto che abbiano o meno una
dipendenza file. Per dipendenza file si intende quando un lavoro o flusso
di lavoro dipende dall’esistenza di uno o più file prima di poter iniziare
l’esecuzione.
wkstation
Specifica il nome della workstation su cui si trovano i file. Sono
consentiti caratteri jolly.
filename
Specifica il nome del file. Il nome deve essere racchiuso tra apici (″)
se contiene caratteri diversi dai seguenti: alfanumerici, trattini (-),
barre (/), barre retroverse (\) e caratteri di sottolineatura (_). Sono
consentiti caratteri jolly.
qualifier
Una condizione di testo valida. Se omessa, i flussi di lavoro
vengono selezionati o esclusi senza considerare un qualificativo.
Se opens viene utilizzato da solo, i flussi di lavoro vengono selezionati o
esclusi se hanno una dipendenza file. Per dipendenza file si intende
quando un lavoro o flusso di lavoro dipende dall’esistenza di uno o più
file prima di poter iniziare l’esecuzione.
priority=pri | lowpri, | ,highpri | lowpri,highpri
Seleziona o esclude i flussi di lavoro in base alle priorità.
pri Specifica il valore della priorità. E’ possibile immettere un valore
compreso tra 0 e 99, hi o go.
140 IBM Tivoli Workload Scheduler - Manuale di riferimento
lowpri Specifica il limite inferiore di un intervallo di priorità. I flussi di
lavoro vengono selezionati con le priorità uguali o maggiori di
questo valore.
highpri Specifica il limite superiore di un intervallo priorità. I flussi di
lavoro vengono selezionati con le priorità inferiori a questo valore.
prompt[=promptname | msgnum]
Seleziona o esclude i flussi di lavoro in base alla dipendenza di un prompt.
promptname
Specifica il nome di un prompt globale. Sono consentiti caratteri
jolly.
msgnum
Specifica il numero di messaggi di un prompt locale.
Se prompt viene utilizzato da solo, i flussi di lavori vengono selezionati o
esclusi se hanno una dipendenza prompt.
started[=time | lowtime, | ,hightime | lowtime,hightime]
Seleziona o esclude i flussi di lavoro in base al fatto che siano stati avviati
o meno.
time Specifica l’ora esatta in cui sono stati avviati i flussi di lavoro,
espressa come segue:
hhmm [date] [timezone|tz tzname]
hhmm L’ora e i minuti.
date La ricorrenza successiva di hhmm sulla data, espressa come
mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del flusso di lavoro. Consultare
Appendice B, “Gestione dei fusi orari”, a pagina 331 per i
nomi validi.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i flussi di lavoro avviati
A quell’ora o successivamente.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
nello stesso formato di time. Vengono selezionati i flussi di lavoro
avviati a quell’ora o precedentemente.
Se started viene utilizzato da solo, l’intervallo è open-ended e i flussi di
lavoro vengono selezionati o esclusi se hanno avviato l’esecuzione.
state=state[,...]
Seleziona o esclude i flussi di lavoro in base ai loro stati.
stato Specifica lo stato corrente del flusso di lavoro. Gli stati del flusso di
lavoro validi sono:
abend Il flusso di lavoro è stato interrotto in modalità anomala.
add La pianificazione è stata inoltrata.
exec Il flusso di lavoro è in esecuzione.
hold Il flusso di lavoro è in attesa della risoluzione dipendenza.
Capitolo 5. Riferimento a Conman 141
ready Il flusso di lavoro è pronto per l’avvio tutte le dipendenze
sono state risolte.
stuck L’esecuzione è stata interrotta. Nessun lavoro viene avviato
senza l’intervento dell’operatore.
succ Il flusso di lavoro è stato completato con esito positivo.
until[=time | lowtime, | ,hightime | lowtime,hightime [absolute | abs]]
Seleziona o esclude i flussi di lavoro in base all’ora di chiusura pianificata.
time Specifica l’ora finale pianificata espressa nel modo seguente:
hhmm[+n days | date] [timezone|tz tzname]
hhmm L’ora e i minuti.
+n days
La ricorrenza successiva di hhmm in n giorni.
date La ricorrenza successiva di hhmm su date, espressa come
mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del flusso di lavoro. Consultare
Appendice B, “Gestione dei fusi orari”, a pagina 331 per i
nomi validi.
lowtime
Specifica il limite inferiore di un intervallo di tempo, espresso nello
stesso formato di time. Vengono selezionati i flussi di lavoro con
ore di chiusura pianificate o con ore successive a quelle specificate.
hightime
Specifica il limite superiore di un intervallo di tempo, espresso
nello stesso formato di time. Vengono selezionati i flussi di lavoro
con ore di chiusura pianificate o con ore precedenti a quelle
specificate.
absolute | abs
Specifica l’ora di avvio specificata per il giorno corrente. Questa
parola chiave può essere utilizzata solo con timezone|tz tzname e
hhmm. E’ conforme alle seguenti regole:
v Quando hhmm indica un orario precedente a quello corrente, il
momento di avvio è immediato.
v Quando hhmm indica un orario successivo a quello corrente,
l’ora di avvio è quella specificata da hhmm del giorno corrente.
v Quando hhmm supera 2400, viene divisa per 2400 per ottenere
l’ora e il giorno. Del risultato della divisione, la parte intera
rappresenta il giorno (numero di + days), mentre quella decimale
corrisponde all’ora:
– Se l’ora calcolata è precedente a quella corrente, l’ora di avvio
è un giorno prima del giorno calcolato all’ora calcolata.
– Se l’ora calcolata è successiva a quella corrente, l’ora di avvio
il giorno calcolato all’ora calcolata.
Ad esempio, se l’ora corrente è 1200 e un giorno viene inviato
allehhmm=3500 (2400 + 1100), con parola chiave abs specificata,
il lavoro viene avviato alle 1100 del giorno successivo. Senza la
specificazione della parola chiave abs, il lavoro viene avviato alle
1100, due giorni dopo.
142 IBM Tivoli Workload Scheduler - Manuale di riferimento
Se until viene utilizzato da solo, l’intervallo è open-ended e i flussi di
lavoro vengono selezionati o esclusi se hanno un ora di chiusura
pianificata.
Descrizioni comandi
Le pagine seguenti contengono descrizioni dettagliate sui comandi Conman.
Nota: Nei comandi, i termini sched e schedule fanno riferimento a flussi di lavoro
e il termine cpu fa riferimento alle workstation.
Elaborazione del comando Conman
Quando si utilizzano vari comandi, è necessario essere a conoscenza del modo in
cui vengono elaborati i comandi conman.
Quando si modificano le dipendenze di un lavoro o di una pianificazione nella
symphony, conman arresta l’inserimento delle dipendenze impedendo al comando
rilevante di essere inoltrato a Batchman. Tuttavia, è possibile che tale modifica non
sia stata completata con esito positivo, malgrado sia stata apportata.
Il motivo consiste nel fatto che conman non scrive direttamente sul file symphony,
ma richiede al Batchman di eseguire tale operazione. Batchman riceve una
sequenza di eventi così come si verificano su ogni sistema nella rete e nella stessa
sequenza in cui si verificano. Mentre Batchman elabora questi eventi, symphony
specifica la modifica sulla rete dello scheduler. Se un Batchman è occupato per
qualsiasi ragione, i comandi conman vengono accodati e symphony non viene
aggiornato fino a quando il Batchman non legge i comandi dalla mailbox e li
elabora. In questo modo, un comando conman può eseguire diverse operazioni, a
seconda di quando viene elaborato.
Inoltre, quando il Batchman elabora l’evento, l’operatore non viene informato. Di
conseguenza, è possibile cancellare una dipendenza e potrebbe sembrare che essa
non sia stata cancellata perché il Batchman era occupato. Se si esegue nuovamente
il comando, la cancellazione potrebbe avere avuto esito positivo, anche se viene
visualizzato un messaggio che indica che il comando è stato inoltrato al Batchman.
Capitolo 5. Riferimento a Conman 143
adddep job
Aggiunge le dipendenze ad un lavoro.
E’ necessario disporre dell’accesso adddep al lavoro. Per includere le dipendenze
needs e prompt, è necessario disporre dell’accesso use alle risorse e ai prompt
globali.
Sintesi
adj jobselect[;dependency[;...]][;noask]
Argomenti
jobselect
Consultare “Selezione dei lavori nei comandi” a pagina 129.
dependency
Il tipo di dipendenza. Specificare uno dei seguenti. Non sono consentiti i
caratteri jolly.
at=hhmm[timezone | tz tzname][+n days | mm/dd/yy] | [absolute | abs]
confirmed
deadline=time [timezone|tz tzname][+n day[s | mm/dd/yy]
every=rate
follows=[netagent::][wkstation#]jstream{.job | @} | job[,...]
needs=[num] [wkstation#]resource[,...]
opens=[wkstation#]″filename″[(qualifier)][,...] priority[=pri | hi | go]
prompt=″[: | !]text″ | promptname[,...]
until time [timezone|tz tzname][+n day[s]] | [absolute | abs] [onuntil
action]
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni lavoro di qualificazione.
Note sull’utilizzo
Se non si specifica un valore per priority, il lavoro ritorna alla sua priorità
originaria. Se non si specifica una workstation in follows, needs o opens, il valore
di default è la workstation su cui è in esecuzione il lavoro. Per aggiungere le
dipendenze del prompt durante l’esecuzione di Conman su un FTA, è necessario
disporre dell’accesso alla directory TWShome/mozart sul Gestore dominio master.
Non è possibile utilizzare questo comando per aggiungere una risorsa o un prompt
come dipendenze, a meno che non siano già stati indicati da un lavoro o da una
pianificazione nel file Symphony.
Esempi
Per aggiungere una dipendenza risorsa al lavoro job3 nel flusso di lavoro sked9,
eseguire il comando:
adddep sked9.job3;needs=2 tapes
Per aggiungere una dipendenza file e un’ora until al lavoro job6 nel flusso di
lavoro sked2, eseguire il comando:
adj sked2.job6;opens="/usr/lib/prdata/file5"(-s %p);
until=2330
144 IBM Tivoli Workload Scheduler - Manuale di riferimento
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione delle dipendenze tra i lavori e la sezione relativa
all’aggiunta delle dipendenze esterne a un flusso di lavoro nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 145
adddep sched
Aggiunge le dipendenze ad un flusso di lavoro.
E’ necessario disporre dell’accesso adddep al flusso di lavoro. Per includere le
dipendenze needs e prompt, è necessario disporre dell’accesso use alle risorse e ai
prompt globali.
Sintesi
ads jstreamselect[;dependency[;...]][;noask]
Argomenti
jstreamselect
Consultare “Selezione dei flussi di lavoro nei comandi” a pagina 137.
dependency
Il tipo di dipendenza. Specificare uno dei seguenti. Non sono consentiti i
caratteri jolly.
at=hhmm[timezone | tz tzname][+n days | mm/dd/yy] | [absolute | abs]
carryforward
deadline=time [timezone|tz tzname][+n day[s | mm/dd/yy]
follows=[netagent::][wkstation#]jstream{.job | @} | job[,...]
limit=limit
needs=[num] [wkstation#]resource[,...]
opens=[wkstation#]″filename″[(qualifier)][,...] priority[=pri | hi | go]
prompt=″[: | !]text″ | promptname[,...]
until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil
action]
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni flusso di lavoro di qualificazione.
Note sull’utilizzo
v Se non si specifica un valore per priority, il flusso di lavoro ritorna alla priorità
pianificata originale.
v Se non si specifica un valore per limit, il valore viene impostato su 0.
v Se non si specifica una workstation in follows, needs o opens, il valore di
default è la workstation su cui è in esecuzione il flusso di lavoro.
v Per aggiungere le dipendenze del prompt durante l’esecuzione Conman su un
FTA, è necessario disporre dell’accesso alla directory TWShome/mozart sul
Gestore dominio master.
v Non è possibile utilizzare questo comando per aggiungere una risorsa o un
prompt come dipendenze, a meno che non siano già stati indicati da un lavoro o
da una pianificazione nel file Symphony.
Esempi
Per aggiungere una dipendenza prompt al flusso di lavoro sked3, eseguire il
comando:
adddep sched=sked3;prompt=msg103
Per aggiungere una dipendenza follows e un limite di lavoro al flusso di lavoro
sked4, eseguire il comando:
146 IBM Tivoli Workload Scheduler - Manuale di riferimento
ads sked4;follows=sked3;limit=2
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione delle dipendenze tra i flussi di lavoro nel manuale
Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 147
altpass
Altera la password di un oggetto utente nel piano di produzione corrente.
E’ necessario disporre dell’accesso altpass all’oggetto dell’utente.
Sintesi
altpass [wkstation#]username[;″password″]
Argomenti
wkstation Specifica la workstation su cui viene definito l’utente. Il valore di
default è la workstation su cui è in esecuzione Conman.
username Specifica il nome di un utente.
password Specifica la nuova password. Essa deve essere racchiusa tra apici.
Per non indicare alcuna password per l’utente, utilizzare due apici
consecutivi (″″).
Note sull’utilizzo
Se non si specifica password, Conman effettua il prompt per una password e per
una conferma. In questo caso, la password non viene visualizzata così come viene
immessa e non deve essere racchiusa tra apici. Tenere presente che la modifica
viene apportata solo nel piano di produzione corrente ed è dunque temporanea.
Per apportare una modifica permanente, consultare “Definizioni utente” a pagina
52.
Esempi
Per modificare la password dell’utente jim sulla workstation mis5 in giraffe,
eseguire il comando:
altpass mis5#jim;”giraffe”
Per modificare la password dell’utente jim sulla workstation mis5 in giraffe senza
visualizzare la password, eseguire il comando:
altpass mis5#jim
password: xxxxxxxx
confirm: xxxxxxxx
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla modifica delle password utente di Windows nel manuale
Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
148 IBM Tivoli Workload Scheduler - Manuale di riferimento
altpri
Altera la priorità di un lavoro o di un flusso di lavoro.
E’ necessario disporre dell’accesso di altpri al lavoro o al flusso di lavoro.
Synopsis
ap jobselect | jstreamselect[;pri][;noask]
Arguments
jobselect Consultare “Selezione dei lavori nei comandi” a pagina 129.
jstreamselect Consultare “Selezione dei flussi di lavoro nei comandi” a pagina
137.
pri Specifica il livello di priorità. E’ possibile immettere un valore
compreso tra 0 e 99, hi o go.
noask Indica di non eseguire il prompt di conferma prima di avviare
l’operazione su ogni lavoro o flusso di lavoro di qualificazione.
Examples
Per modificare la priorità del lavoro balance nel flusso di lavoro glmonth, eseguire
il comando:
altpri glmonth.balance;55
Per modificare la priorità di tutti lavori nel flusso di lavoro mis5, eseguire il
comando:
ap mis5.@;25
Per modificare la priorità del flusso di lavoro glmonth, eseguire il comando:
altpri glmonth;10
Per modificare la priorità del flusso di lavoro mis5, eseguire il comando:
ap mis5;30
Capitolo 5. Riferimento a Conman 149
cancel job
Annulla un lavoro.
E’ necessario disporre dell’accesso cancel al lavoro.
Sintesi
cj jobselect[;pend][;noask]
Argomenti
jobselect Consultare “Selezione dei lavori nei comandi” a pagina 129.
pend Annulla il lavoro solo dopo che vengono risolte le sue dipendenze.
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni lavoro di qualificazione.
Note sull’utilizzo
Se un lavoro viene annullato prima di essere stato avviato, non verrà più avviato.
Se si annulla un lavoro dopo che è stato avviato, il lavoro continua ad essere
eseguito. Se un lavoro di esecuzione viene annullato e viene completato nello stato
abend, non verrà effettuato il ripristino automatico di tale lavoro.
Se non si utilizza l’opzione ;pend, i lavori e i flussi di lavoro che dipendono dal
lavoro annullato vengono immediatamente rilasciati dalla dipendenza.
Se si include l’opzione ;pend e il lavoro non è stato avviato, la cancellazione verrà
ritardata fino a quando non vengono risolte tutte le dipendenze, inclusa l’ora at.
Una volta risolte tutte le dipendenze, il lavoro viene annullato e qualsiasi lavoro o
flusso di lavoro che dipende dal lavoro annullato verrà rilasciato dalla dipendenza.
Durante il periodo in cui verrà ritardata l’operazione di annullamento, la nota
[Cancel Pend] viene elencata nella colonna Dipendenze del lavoro in un pannello
showjobs.
Se si include l’opzione ;pend e il lavoro è già stato avviato, l’opzione viene
ignorata e tutti i lavori o i flussi di lavoro che dipendono dal lavoro annullato
verranno immediatamente rilasciati dalla dipendenza.
E’ possibile utilizzare il comando rerun per eseguire nuovamente i lavori che sono
stati annullati o che sono stati contrassegnati come [Cancel Pend]. E’ possibile
inoltre aggiungere e cancellare le dipendenze sui lavori che sono stati
contrassegnati come [Cancel Pend].
Per annullare immediatamente un lavoro contrassegnato come [Cancel Pend], è
possibile immettere un comando release per il lavoro e immettere un altro
comando cancel senza l’opzione ;pend.
Per i lavori con ore Until scadute, la notazione [Until] viene elencata nella colonna
Dipendenze in un pannello showjobs e le dipendenze non vengono più valutate.
Se tale lavoro viene contrassegnato anche come [Cancel Pend], non viene annullato
fino a quando non si rilascia o si cancella l’ora until o fino a quando non si
immette un altro comando cancel senza l’opzione ;pend.
Per arrestare le dipendenze di valutazione, impostare la priorità di un lavoro su
zero con il comando altpri. Per riprendere la valutazione delle dipendenze,
impostare la priorità su un valore maggiore di zero.
150 IBM Tivoli Workload Scheduler - Manuale di riferimento
Nota: Nel caso di dipendenze internetwork, la cancellazione di un lavoro nel
flusso di lavoro external rilascia tutti i lavori e i flussi di lavoro dalla
dipendenza. I lavori nel flusso di lavoro external rappresentano i lavori e i
flussi di lavoro che sono stati specificati come dipendenze internetwork. Lo
stato della dipendenza internetwork non viene controllato dopo l’esecuzione
di cancel. Per ulteriori informazioni consultare “Dipendenze Internetwork” a
pagina 302.
Esempi
Per annullare il lavoro report nel flusso di lavoro apwkly sulla workstation site3,
eseguire il comando:
cancel site3#apwkly.report
Per annullare il lavoro setup nel flusso di lavoro mis5, se non si trova in uno stato
abend, eseguire il comando:
cj mis5.setup~state=abend
Per annullare il lavoro job3 nel flusso di lavoro sked3 solo dopo che sono state
risolte le dipendenze, eseguire il comando:
cj sked3.job3;pend
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa all’eliminazione di una definizione da un flusso di lavoro nel
manuale Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 151
cancel sched
Annulla un flusso di lavoro.
E’ necessario disporre dell’accesso cancel al flusso di lavoro.
Sintesi
cs jstreamselect[;pend][;noask]
Argomenti
jstreamselect Consultare “Selezione dei flussi di lavoro nei comandi” a pagina
137.
pend Annulla il flusso di lavoro solo dopo che vengono risolte le
dipendenze.
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni flusso di lavoro di qualificazione.
Note sull’utilizzo
Se un flusso di lavoro viene annullato prima di essere avviato, non verrà mai
avviato. Se viene annullato dopo il suo avvio, i lavori che sono stati avviati
possono terminare, ma gli altri no.
Se non si utilizza l’opzione ;pend, i lavori e i flussi di lavoro che dipendono dal
flusso di lavoro annullato vengono rilasciati immediatamente dopo dalla
dipendenza.
Se si utilizza l’opzione ;pend e il flusso di lavoro non è stato avviato, l’operazione
di annullamento viene ritardata fino a quando non vengono risolte tutte le
dipendenze, inclusa un’ora at. Una volta risolte tutte le dipendenze, il flusso di
lavoro viene annullato e tutti i lavori e i flussi di lavoro dipendenti vengono
rilasciati dalla dipendenza. Durante il periodo in cui viene ritardata l’operazione di
annullamento, la nota [Cancel Pend] viene inserita nella colonna Dipendenze di
un pannelloshowschedules.
Se si include l’opzione ;pend e il flusso di lavoro è già stato avviato, tutti i lavori
rimanenti nel flusso di lavoro vengono annullati e tutti i lavori e i flussi di lavoro
dipendenti vengono rilasciati dalla dipendenza.
Per annullare immediatamente un flusso di lavoro contrassegnato come [Cancel
Pend], immettere un comando release per il flusso di lavoro o immettere un altro
comando cancel senza l’opzione ;pend.
Per i flussi di lavoro con ore until scadute, la nota [Until] viene visualizzata nella
colonna Dipendenze del pannello showschedules e non vengono più valutate le
relative dipendenze. Se anche tale flusso di lavoro viene contrassegnato come
[Cancel Pend], non verrà annullato fino a quando non si rilascia o cancella l’ora
until o non si immette un altro comando cancel senza l’opzione ;pend.
Per arrestare la valutazione delle dipendenze, impostare la priorità del flusso di
lavoro su zero con il comandoaltpri. Per riprendere la valutazione delle
dipendenze, impostare la priorità su un valore maggiore di zero.
Esempi
Per annullare il flusso di lavoro sked1 sulla workstation site2, eseguire il comando:
cancel site2#sked1
152 IBM Tivoli Workload Scheduler - Manuale di riferimento
Per annullare il flusso di lavoro mis2 se si trova nello stato stuck, eseguire il
comando:
cs mis2+state=stuck
Per annullare il flusso di lavoro sked3 solo dopo che sono state risolte le
dipendenze, eseguire il comando:
cs sked3;pend
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa all’eliminazione dei flussi di lavoro del manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 153
confirm
Conferma il completamento di un lavoro che è stato pianificato con la parola
chiave confirmed. Si nota un’eccezione nella sezione “Note sull’utilizzo”.
E’ necessario disporre dell’accesso confirm al lavoro.
Synopsis
confirm jobselect;{succ | abend}[;noask]
Arguments
jobselect Consultare “Selezione dei lavori nei comandi” a pagina 129.
succ Conferma che il lavoro è stato terminato con esito positivo.
abend Conferma che il lavoro è stato terminato con esito negativo.
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni lavoro di qualificazione.
Usage Notes
La modifica dello stato di un lavoro da abend in succ non richiede che venga
utilizzata la parola chiave confirmed per pianificare il lavoro. Per ulteriori
informazioni sulla conferma del lavoro, consultare “confirmed” a pagina 94. Per
ulteriori informazioni sui lavori esterni, consultare “Dipendenze Internetwork” a
pagina 302.
La seguente tabella mostra in che modo il comandoconfirm influenza i vari stati
del lavoro:
Stato lavoro iniziale Stato dopo la conferma ;succ
Stato dopo la conferma
;abend
ready nessuna influenza nessuna influenza
hold nessuna influenza nessuna influenza
exec succp abenp
abenp succp nessuna influenza
succp nessuna influenza nessuna influenza
pend succ abend
done succ abend
succ nessuna influenza nessuna influenza
abend succ nessuna influenza
fail nessuna influenza nessuna influenza
skel nessuna influenza nessuna influenza
qualsiasi lavoro external succ abend
Examples
Per emettere una conferma succ per il lavoro job3 nel flusso di lavoro misdly,
eseguire il comando:
confirm misdly.job3;succ
Per emettere una conferma abend per il lavoro 234, eseguire il comando:
conf 234;abend
154 IBM Tivoli Workload Scheduler - Manuale di riferimento
console
Assegna la console dello scheduler e imposta il livello del messaggio.
E’ necessario disporre dell’accesso console alla workstation.
Synopsis
console [sess | sys][;level=msglevel]
Arguments
sess Invia i messaggi e i prompt della console dello scheduler all’output
standard.
sys Arresta l’invio dei messaggi e dei prompt della console dello
scheduler all’output standard. Ciò si verifica automaticamente
quando si chiude Conman.
msglevel Il livello dei messaggi dello scheduler che vengono inviati alla
console. Specificare uno dei seguenti livelli:
0 Nessun messaggio. È il valore di default sugli FTA (Fault
Tolerant Agent).
1 Messaggi di eccezione come i prompt dell’operatore e le
interruzioni anomale del lavoro.
2 Livello 1, più i messaggi del flusso di lavoro che hanno
avuto esito positivo.
3 Livello 2, più i messaggi lavoro che hanno avuto esito
positivo. Questo è il valore di default sul Gestore dominio
master.
4 Livello 3, più i messaggi inviati dal lavoro.
Usage Notes
Se si immette il comando console senza nessuna opzione, viene visualizzato lo
stato corrente della console.
Per default, il controllo dello scheduler elabora i messaggi scritti della console ed
effettua dei prompt ai file di elenco standard. Su UNIX, è possibile inoltre inviarli
al daemon syslog.
Examples
Per avviare la scrittura dei prompt e dei messaggi della console sull’output
standard e modificare il livello del messaggio su 1, eseguire il comando:
console sess;level=1
Per arrestare la scrittura dei prompt e dei messaggi della console sull’output
standard e modificare il livello del messaggio su 4, eseguire il comando:
cons sys;l=4
Per visualizzare lo stato corrente della console, eseguire il comando:
cons
Console is #J675, level 2, session
675 è l’ID del processo della shell dell’utente.
Capitolo 5. Riferimento a Conman 155
continue
Ignora il successivo errore del comando.
Synopsis
continue
Usage Notes
Questo comando è utile quando i comandi vengono immessi in modalità non
interattiva. Esso istruisce Conman su come continuare l’esecuzione dei comandi
anche se il comando successivo, che segue continue, è in errore.
Examples
Per consentire a Conman di continuare con il comando rerun anche se il comando
cancel non ha esito positivo, eseguire il comando:
conman "continue&cancel=176&rerun job=sked5.job3"
156 IBM Tivoli Workload Scheduler - Manuale di riferimento
lavoro deldep
Cancella le dipendenze da un lavoro.
E’ necessario disporre dell’accesso deldep al lavoro.
Sintesi
ddj jobselect;dependency[;...][;noask]
Argomenti
jobselect
Consultare “Selezione dei lavori nei comandi” a pagina 129.
dependency
Il tipo di dipendenza. Specificare almeno uno dei seguenti. E’ possibile
utilizzare caratteri jolly in wkstation, jstream, job, resource, filename e
promptname.
at[=time | lowtime | hightime | lowtime,hightime]
confirmed
deadline[=time[timezone | tz tzname][+n days | mm/dd/yy]]
every
follows[=[netagent::][wkstation#]jstream{.job | @} | job[,...]]
needs[=[num] [wkstation#]resource[,...]]
opens[=[wkstation#]″filename″[(qualifier)][,...]]
priority
prompt[=″[: | !]text″ | promptname[,...]]
until[=time [timezone|tz tzname][+n day[s]] [onuntil action]]
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni lavoro di qualificazione.
Note sull’utilizzo
Se priority viene cancellato, il lavoro ritorna alla sua priorità originale. Quando si
cancella una dipendenza opens, è possibile includere solo il nome del file di base e
Conman esegue una ricerca sensibile al maiuscolo e al minuscolo per i file
corrispondenti, ignorando i nomi della directory. Vengono cancellate le dipendenze
su tutti i file corrispondenti.
In determinate circostanze, quando si inoltra un comandodeldep, questo potrebbe
avere avuto esito positivo anche se è stato inoltrato nuovamente al Batchman. Per
ulteriori informazioni, consultare “Elaborazione del comando Conman” a pagina
143.
Esempi
Per eliminare una dipendenza risorsa dal lavoro job3 nel flusso di lavoro sked5,
eseguire il comando:
deldep sked5.job3;needs=2 tapes
Per eliminare tutte le dipendenze follows dal lavoro job4 nel flusso di lavoro
sked3, eseguire il comando:
ddj sked3.job4;follows
Capitolo 5. Riferimento a Conman 157
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla gestione dei lavori nel manuale Guida per l’utente di IBM
Tivoli Workload Scheduler Job Scheduling Console.
158 IBM Tivoli Workload Scheduler - Manuale di riferimento
deldep sched
Cancella le dipendenze da un flusso di lavoro.
E’ necessario disporre dell’accesso deldep al flusso di lavoro.
Sintesi
dds jstreamselect;dependency[;...][;noask]
Argomenti
jstreamselect
Consultare “Selezione dei lavori nei comandi” a pagina 129.
dependency
Il tipo di dipendenza. Specificare almeno uno dei seguenti. E’ possibile
utilizzare caratteri jolly in wkstation, jstream, job, resource, filename e
promptname.
at[=time | lowtime | hightime | lowtime,hightime]
carryforward
deadline[=time[timezone | tz tzname][+n days | mm/dd/yy]]
follows[=[netagent::][wkstation#]jstream{.job | @} | job[,...]]
limit
needs[=[num] [wkstation#]resource[,...]]
opens[=[wkstation#]″filename″[(qualifier)][,...]]
priority
prompt[=″[: | !]text″ | promptname[,...]]
until[=time [timezone|tz tzname][+n day[s]] [onuntil action]]
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni flusso di lavoro di qualificazione.
Note sull’utilizzo
Se priority viene cancellato, il lavoro ritorna alla sua priorità originale. Quando si
cancella una dipendenza opens, è possibile includere solo il nome del file di base e
Conman effettua una ricerca sensibile al maiuscolo e al minuscolo dei file
corrispondenti, ignorando i nomi della directory. Vengono cancellate le dipendenze
su tutti i file corrispondenti.
In determinate circostanze, quando si inoltra un comandodeldep, questo potrebbe
avere avuto esito positivo anche se è stato inoltrato nuovamente al Batchman. Per
ulteriori informazioni, consultare “Elaborazione del comando Conman” a pagina
143.
Esempi
Per eliminare una dipendenza risorsa dal flusso di lavoro sked5, eseguire il
comando:
deldep sked5;needs=2 tapes
Per eliminare tutte le dipendenze follows dal flusso di lavoro sked3, eseguire il
comando:
dds sked3;follows
Capitolo 5. Riferimento a Conman 159
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla gestione dei flussi di lavoro del manuale Guida per l’utente di
IBM Tivoli Workload Scheduler Job Scheduling Console.
160 IBM Tivoli Workload Scheduler - Manuale di riferimento
display
Visualizza un file lavoro o una definizione del flusso di lavoro.
Se si specifica un file per nome, è necessario disporre dell’accesso alla lettura del
file. Per i file lavoro o le definizioni del flusso di lavoro, è necessario disporre
dell’accesso display al lavoro o al flusso di lavoro.
Sintesi
df filename[;offline]
dj jobselect[;offline]
ds jstreamselect[;offline]
Argomenti
filename Specifica il nome del file, di solito un file script lavoro. E’
necessario che il nome sia racchiuso tra apici (″) se contiene
caratteri diversi dai seguenti: caratteri alfanumerici, trattini (-),
barre (/), barre retroverse (\) e caratteri di sottolineatura (_). Sono
consentiti caratteri jolly. Il file deve essere accessibile dalla propria
workstation di login.
jobselect Il lavoro di cui si visualizza il file lavoro. Consultare “Selezione dei
lavori nei comandi” a pagina 129. Il file lavoro deve essere accessibile
dalla propria workstation di login.
jstreamselect Il flusso di lavoro di cui viene visualizzata la descrizione.
Consultare “Selezione dei flussi di lavoro nei comandi” a pagina 137. La
directory mozart dello scheduler sul gestore dominio master deve
essere accessibile dalla propria workstation di login.
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Esempi
Per visualizzare il file c:\maestro\jclfiles\arjob3, eseguire il comando:
df c:\apps\maestro\jclfiles\arjob3
Per visualizzare il file script per il lavoro job6 nel flusso di lavoro sked3 non in
linea, eseguire il comando:
dj sked3.job6;off
Per visualizzare la definizione del flusso di lavoro sked9, eseguire il comando:
ds sked9
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla gestione dei lavori e dei flussi di lavoro del manuale Guida
per l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 161
exit
Esce dal programma Conman.
Synopsis
e
Usage Notes
Se in modalità di aiuto su UNIX, questo comando riporta Conman in modalità di
input del comando.
Examples
Per uscire dal programma Conman, eseguire il comando:
exit
o
e
162 IBM Tivoli Workload Scheduler - Manuale di riferimento
fence
Modifica il contenitore lavori su una workstation. I lavori non vengono inviati
sulla workstation se le relative proprietà sono inferiori o uguali al contenitore
lavori.
E’ necessario disporre dell’accesso fence alla workstation.
Sintesi
fence workstation;pri[;noask]
Argomenti
workstation Specifica il nome della workstation. Il valore di default è la propria
workstation di login.
pri Specifica il livello di priorità. E’ possibile immettere un valore
compreso tra 0 e 99, hi o go. L’immissione di system imposta il
contenitore lavori su zero.
noask Specifica di non eseguire il prompt di conferma prima di avviare
l’operazione di ogni workstation di qualificazione.
Note sull’utilizzo
Il contenitore lavori impedisce l’avvio di lavori con priorità inferiore, a prescindere
dalle priorità dei loro flussi di lavoro. E’ possibile, tuttavia, riportare i lavori con
priorità inferiore in flussi di lavoro con priorità superiore, consentendo così l’invio
dei lavori con priorità superiore in flussi di lavoro con priorità inferiore.
Quando si avvia IBM Tivoli Workload Scheduler seguendo l’installazione, il
contenitore lavori viene impostato su zero. Una volta modificato il contenitore
lavori, esso viene inoltrato durante l’elaborazione precedente la produzione al
piano di lavoro del giorno successivo.
Per visualizzare l’impostazione corrente del contenitore lavori, utilizzare il
comando status.
Esempi
Per modificare il delimitatore lavori sulla workstation site4, eseguire il comando:
fence site4;20
Per modificare il delimitatore lavori sulla workstation su cui è in esecuzione il
programma Conman, eseguire il comando:
f ;40
Per impedire a tutti i lavori di essere avviati dallo scheduler sulla workstation tx3,
eseguire il comando:
f tx3;go
Per modificare il delimitatore lavori su zero sulla workstation dove è in esecuzione
il programma Conman, eseguire il comando:
f ;system
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla visualizzazione e alla modifica delle proprietà della
workstation nel manuale Guida per l’utente di IBM Tivoli Workload Scheduler Job
Scheduling Console.
Capitolo 5. Riferimento a Conman 163
help
Visualizza informazioni di aiuto sui comandi. Non disponibile su Windows.
Synopsis
comando help
Arguments
command
Specifica il nome di un comando di sistema o Conman. Per i comandi
Conman, immettere il nome completo del comando, abbreviazioni e forme
abbreviate non sono supportate. Nel caso di comandi composti da due
parole, immettere la prima parola e viene visualizzato l’aiuto per tutte le
versioni del comando. Ad esempio, l’immissione di help display consentirà
la visualizzazione delle informazioni sui comandi display file, display job
edisplay sched . Inoltre è possibile immettere le seguenti parole chiave:
commands
Elenca tutti i comandi Conman.
jobselect
Elenca le informazioni sulla selezione dei lavori per i comandi.
jobstates
Elenca le informazioni sugli stati del lavoro.
schedselect
Elenca le informazioni sulla selezione dei flussi di lavoro per i
comandi.
schedstates
Elenca le informazioni sugli stati del flusso di lavoro.
Examples
Per visualizzare un elenco di tutti i comandi Conman, eseguire il comando:
help commands
Per visualizzare le informazioni sul comando fence, eseguire il comando:
help fence
Per visualizzare le informazioni sui comandi altpri job e altpri sched, eseguire il
comando:
h altpri
164 IBM Tivoli Workload Scheduler - Manuale di riferimento
kill
Arresta un lavoro di esecuzione. Su UNIX, questo viene effettuato con un comando
UNIX kill.
Synopsis
kill jobselect[;noask]
Arguments
jobselect Consultare “Selezione dei lavori nei comandi” a pagina 129.
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni lavoro di qualificazione.
Usage Notes
L’operazione kill non viene eseguita da Conman, ma da un processo di
produzione dello scheduler, in questo modo potrebbe esservi un piccolo ritardo.
I lavori interrotti terminano in uno stato abend. Tutti i lavori e i flussi di lavoro
che dipendono da un lavoro interrotto non vengono rilasciati. I lavori interrotti
possono essere eseguiti nuovamente.
Examples
Per interrompere il lavoro report nel flusso di lavoro apwkly sulla workstation
site3, eseguire il comando:
kill site3#apwkly.report
Per interrompere il lavoro 456, eseguire il comando:
k 456
Capitolo 5. Riferimento a Conman 165
limit cpu
Modifica il limite dei lavori sua workstation di agent standard. E’ necessario
disporre dell’accesso limit alla workstation.
Sintesi
lc wkstation;limit[;noask]
Argomenti
wkstation Specifica il nome dell’agent della workstation. Sono consentiti
caratteri jolly. Il valore di default è la propria workstation di login.
limit Specifica il limite del lavoro. E’ possibile immettere un valore
compreso tra 0 e 1024. L’immissione di system imposta il limite
lavoro su zero. Se viene impostato un limite pari a zero, nessun
lavoro diverso dai lavori con priorità hi e go, viene inviato sulla
workstation.
noask Specifica di non eseguire il prompt di conferma prima di avviare
l’operazione di ogni workstation di qualificazione.
Note sull’utilizzo
Per visualizzare il limite del lavoro corrente sulla propria workstation di login,
utilizzare il comando status.
Quando si avvia IBM Tivoli Workload Scheduler seguendo l’installazione, il limite
del lavoro della workstation viene impostato su zero e deve essere aumentato
prima che i lavori vengano avviati. Una volta modificato il limite, viene portato
avanti durante l’elaborazione precedente la produzione del piano di produzione
del giorno successivo.
Lo scheduler tenta di avviare quanti più lavori possibili nei limiti del lavoro. Esiste
un limite pratico al numero di processi che possono essere avviati su una
workstation. Se viene raggiunto il limite, il sistema risponde con un messaggio che
indica che le risorse del sistema non sono disponibili. Se un lavoro non può essere
avviato per questo motivo, immette lo stato fail. E’ possibile impedire ciò
diminuendo il limite di lavoro.
Esempi
Per modificare il limite di lavori sulla workstation site3, eseguire il comando:
limit cpu=site3;25
Per modificare il limite di lavori sulla workstation su cui è in esecuzione il
programma Conman, eseguire il comando:
lc ;12
Per modificare il limite di lavori sulla workstation rx12, eseguire il comando:
lc rx12;6
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla visualizzazione e alla modifica delle proprietà della
workstation nel manuale Guida per l’utente di IBM Tivoli Workload Scheduler Job
Scheduling Console.
166 IBM Tivoli Workload Scheduler - Manuale di riferimento
limit sched
Modifica il limite del lavoro per un flusso di lavoro. E’ necessario disporre
dell’accesso limite al flusso di lavoro.
Sintesi
ls jstreamselect;limit[;noask]
Argomenti
jstreamselect Consultare “Selezione dei flussi di lavoro nei comandi” a pagina
137.
limit Specifica il limite del lavoro. E’ possibile immettere un valore
compreso tra 0 e 1024. Se si specifica un limite pari a zero, non
viene avviato nessun lavoro ulteriore dal flusso di lavoro.
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni flusso di lavoro di qualificazione.
Esempi
Per modificare il limite di lavori su tutti i flussi di lavoro che includono sales nel
nome, eseguire il comando:
limit sched=sales@;4
Per modificare il limite di lavori sul flusso di lavoro apwkly, eseguire il comando:
ls apwkly;6
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla gestione dei flussi di lavoro del manuale Guida per l’utente di
IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 167
link
Apre i collegamenti di comunicazione tra le workstation. In una rete dello
scheduler, gli agent tolleranti l’errore e gli agent standard vengono collegati ai
rispettivi gestori domini e questi vengono collegati ai propri gestori domini parent.
Gli agent estesi (XA) non vengono collegati; essi comunicano tramite un host.
E’ necessario disporre dell’accesso link alla workstation di destinazione.
Synopsis
lk [domain!]wkstation[;noask]
Arguments
domain Specifica il nome del dominio in cui vengono aperti i collegamenti.
Sono consentiti caratteri jolly.
Questo argomento è utile nel momento in cui si effettua il
collegamento a più di una workstation in un dominio. Ad esempio,
per collegare tutti gli agent nel dominio stlouis, utilizzare il
seguente comando:
link stlouis!@
Il dominio non è necessario se non vengono inclusi caratteri jolly
in wkstation.
Se non si includedomain e vengono inseriti caratteri jollyin
wkstation, il dominio di default è quello su cui è in esecuzione
Conman.
wkstation Specifica il nome della workstation da collegare. Sono consentiti
caratteri jolly.
noask Specifica di non eseguire il prompt di conferma prima di avviare
l’operazione di ogni workstation di qualificazione.
Usage Notes
Se l’opzione autolink viene impostata su attivo in una definizione della
workstation, il collegamento viene aperto automaticamente ogni volta che si avvia
lo scheduler. Se autolink viene impostato su disattivo, è necessario utilizzare i
comandi link e unlink per controllare i collegamenti. Per informazioni su autolink
consultare “Definizioni delle workstation” a pagina 37.
Presumendo che un utente disponga dell’accesso link alle workstation collegate,
vengono applicate le seguenti regole:
v Un utente che sta eseguendo Conman sul gestore dominio master può collegare
qualsiasi workstation nella rete.
v Un utente che sta eseguendo Conman su un gestore dominio diverso dal master
può collegarsi a qualsiasi workstation nel proprio dominio e nei domini
subordinati. L’utente non può collegare le workstation nei domini peer.
v Un utente che sta eseguendo Conman su un agent può collegarsi a qualsiasi
workstation nel proprio dominio locale purché la workstation sia un gestore
dominio o un host. Non è possibile collegare un agente peer nel dominio locale.
v Per collegare un dominio subordinato durante l’esecuzione di Conman in un
dominio superiore, non è necessario che siano aperti i collegamenti di
interconnessione.
168 IBM Tivoli Workload Scheduler - Manuale di riferimento
Examples
L’illustrazione e la tabella sottostante mostrano i collegamenti aperti dai comandi
link eseguiti dagli utenti in varie ubicazioni nella rete.
DMn sono i gestori domini e Ann sono gli agent.
Comando
Collegamenti aperti
da User1
Collegamenti aperti
da User2
Collegamenti aperti
da User3
link @!@ Tutti i collegamenti
sono aperti.
DM1-DM2
DM2-A21
DM2-A22
DM2-DM4
DM4-A41
DM4-A42
DM2-A21
link @ DM1-A11
DM1-A12
DM1-DM2
DM1-DM3
DM1-DM2
DM2-A21
DM2-A22
DM2-DM4
DM2-A21
link DOMAIN3!@ DM3-A31
DM3-A32
Non consentito. Non consentito.
link DOMAIN4!@ DM4-A41
DM4-A42
DM4-A41
DM4-A42
Non consentito.
link DM2 DM1-DM2 Non applicabile. DM2-A21
link A42 DM4-A42 DM4-A42 Non consentito.
link A31 DM3-A31 Non consentito. Non consentito.
A11 A12
DM1
DM2 DM3
DM4
A21 A22 A31 A32
A41 A42
Dominio1
Dominio2 Dominio3
Dominio4
Utente1
Utente2
Utente3
Figura 3. Collegamenti di rete
Capitolo 5. Riferimento a Conman 169
listsym
Elenca i file di log (Symphony) del piano di produzione.
E’ necessario disporre dell’accesso display al file Symphony.
Synopsis
listsym [;offline]
Arguments
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Command Output
Data di pianificazione
La data utilizzata dal comando schedulr per selezionare i flussi di lavoro
per l’esecuzione.
Data reale
La data in cui il batchman ha iniziato l’esecuzione del file Symphony.
Ora di avvio
L’ora in cui il batchman ha avviato l’esecuzione del file Symphony.
Data di registrazione
La data in cui è stato registrato il piano (Symphony) dal
comandostageman.
Numero di esecuzione
Il numero di esecuzione assegnato al piano (Symphony). Questi vengono
utilizzati internamente per la sincronizzazione della rete dello scheduler.
Dimensione
La dimensione del file di log nei record.
Numero di log
Il numero di registrazione che indica l’ordine cronologico dei file di log.
Questo numero può essere utilizzato in un comando setsym da commutare
su un file di log specifico.
Nome file
Il nome del file di log assegnato dal comandostageman.
Examples
Per elencare i file di log del piano di produzione, eseguire il comando:
listsym
Per elencare i file di log del piano di produzione sull’unità di output del
programma Conman, eseguire il comando:
lis ;off
170 IBM Tivoli Workload Scheduler - Manuale di riferimento
recall
Visualizza i prompt in attesa di risposta.
E’ necessario disporre dell’accesso display ai prompt.
Synopsis
rc [wkstation][;offline]
Arguments
wkstation Specifica il nome della workstation su cui è stata emesso il prompt.
Se non si specifica una workstation, vengono visualizzate solo le
workstation di login e i prompt globali.
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Command Output
Stato Lo stato del prompt. Lo stato dei prompt in sospeso è sempre ASKED.
Messaggio o Prompt
Per i prompt denominati, il numero del messaggio, il nome del prompt e il
testo del messaggio. Per i prompt non denominati, il numero del
messaggio, il nome del lavoro o del flusso di lavoro e il testo del
messaggio.
Examples
Per visualizzare i prompt in sospeso emessi sulla workstation su cui è in
esecuzione il programma Conman, eseguire il comando:
recall
o:
rc
Per visualizzare i prompt in sospeso sulla workstation site3, eseguire il comando:
rc site3
Per visualizzare i prompt in sospeso su tutte le workstation ed inviare l’output
all’unità non in linea di Conman, eseguire il comando:
rc @;offline
Capitolo 5. Riferimento a Conman 171
redo
Modifica ed esegue nuovamente il comando precedente.
Synopsis
redo
Contesto
Quando si esegue il comando redo, Conman visualizza il comando precedente, in
modo che possa essere modificato ed eseguito nuovamente. Utilizzare la barra
spaziatrice per spostare il cursore sotto il carattere da modificare e immettere le
seguenti direttive.
Direttive
d[dir] Cancella il carattere che precede la d. Questa operazione può
essere seguita da altre direttive.
itext Inserisce il testo prima del carattere che precede la i.
rtext Sostituisce uno o più caratteri con il testo, iniziando con il carattere
che precede la r. La sostituzione è implicita se non viene immessa
nessun altra direttiva.
>text Accoda il testo alla fine della riga.
>d[dir | text]
Cancella i caratteri alla fine della riga. Questa operazione può
essere seguita da un altra direttiva o un altro testo.
>rtext Sostituisce i caratteri alla fine della riga con il testo.
Esempi di direttive
ddd Cancella i tre caratteri che si trovano sulla d.
iabc Inserisce l’abc prima del carattere che precede la i.
rabc Sostituisce i tre caratteri, cominciando da quello che precede lar
con abc.
abc Sostituisce i tre caratteri precedenti abc con abc.
d diabc
Cancella il carattere che precede la prima d, ignora un carattere,
cancella il carattere che precede la seconda d e, al suo posto,
inserisce abc.
>abc Accoda abc alla fine della riga.
>ddabc
Cancella gli ultimi due caratteri nella riga e li sostituisce con abc.
>rabc Sostituisce gli ultimi tre caratteri nella riga con abc.
Examples
Per inserire un carattere, eseguire il comando:
redo
setsm 4
iy
setsym 4
Per sostituire un carattere, eseguire questo comando:
172 IBM Tivoli Workload Scheduler - Manuale di riferimento
release job
Rilascia i lavori dalle dipendenze.
E’ necessario disporre dell’accesso release al lavoro.
Sintesi
rj jobselect[;dependency[;...]][;noask]
Argomenti
jobselect
Specifica il lavoro o i lavori da rilasciare. Consultare “Selezione dei lavori
nei comandi” a pagina 129.
dependency
Il tipo di dipendenza. E’ possibile specificare uno dei seguenti. E’ possibile
utilizzare caratteri jolly in wkstation, jstream, job, resource, filename e
promptname.
at[=time | lowtime | hightime | lowtime,hightime]
confirmed
deadline[=time[timezone | tz tzname][+n days | mm/dd/yy]]
every
follows[=[netagent::][wkstation#]jstream{.job | @} | job[,...]]
needs[=[num] [wkstation#]resource[,...]]
opens[=[wkstation#]″filename″[(qualifier)][,...]]
priority
prompt[=″[: | !]text″ | promptname[,...]]
until[=time [timezone|tz tzname][+n day[s]] [onuntil action]]
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni lavoro di qualificazione.
Note sull’utilizzo
Quando si rilascia una dipendenza opens, è possibile includere solo il nome del
file di base e Conman esegue una ricerca sensibile al maiuscolo e al minuscolo dei
file corrispondenti, ignorando i nomi della directory. Vengono rilasciate le
dipendenze su tutti i file corrispondenti.
Per le dipendenze needs, al lavoro rilasciato viene fornito il numero richiesto di
unità della risorsa, anche se potrebbe non essere disponibile. Ciò può causare alle
unità disponibili in showresources la visualizzazione di un numero negativo.
Quando si rilascia un lavoro da una dipendenzapriority, il lavoro ritorna alla sua
priorità pianificata originale.
Esempi
Per rilasciare il lavoro job3 nel flusso di lavoro ap da tutte le sue dipendenze,
eseguire il comando:
release job=ap.job3
Per rilasciare il lavoro job2 nel flusso di lavoro skedr da tutte le sue dipendenze
opens, eseguire il comando:
174 IBM Tivoli Workload Scheduler - Manuale di riferimento
rj skedr.job2;opens
Per rilasciare tutti i lavori sulla workstation site4 dalle loro dipendenze su un
prompt denominato glprmt, eseguire il comando:
rj site4#@.@;prompt=glprmt
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa al rilascio delle dipendenze per un’istanza del lavoro nel
manuale Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 175
release sched
Rilascia i flussi di lavoro dalle dipendenze.
E’ necessario disporre dell’accesso release sul flusso di lavoro.
Sintesi
rs jstreamselect[;dependency[;...]][;noask]
Argomenti
jstreamselect
Consultare “Selezione dei flussi di lavoro nei comandi” a pagina 137.
dependency
Il tipo di dipendenza. Specificare uno dei seguenti. E’ possibile utilizzare
caratteri jolly in wkstation, jstream, job, resource, filename e promptname.
at[=time | lowtime | hightime | lowtime,hightime]
carryforward
deadline[=time[timezone | tz tzname][+n days | mm/dd/yy]]
follows[=[netagent::][wkstation#]jstream{.job | @} | job[,...]]
limit
needs[=[num] [wkstation#]resource[,...]]
opens[=[wkstation#]″filename″[(qualifier)][,...]]
priority
prompt[=″[: | !]text″ | promptname[,...]]
until[=time [timezone|tz tzname][+n day[s]] [onuntil action]]
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni flusso di lavoro di qualificazione.
Note sull’utilizzo
Quando is cancella una dipendenza opens, è possibile includere solo il nome del
file (basename) e Conman esegue una ricerca sensibile al maiuscolo e al minuscolo
dei file corrispondenti, ignorando i nomi della directory. Vengono rilasciate le
dipendenze su tutti i file corrispondenti.
Per le dipendenze needs, al flusso di lavoro rilasciato viene fornito il numero
richiesto di unità della risorsa, anche se potrebbe non essere disponibile. Ciò può
causare alle unità disponibili in showresources la visualizzazione di un numero
negativo.
Quando si rilascia una pianificazione da una dipendenza priority, il flusso di
lavoro ritorna alla sua priorità originale.
In determinate circostanze, quando si inoltra un comando deldep, questo potrebbe
avere avuto esito positivo anche se è stato inoltrato nuovamente al batchman. Per
ulteriori informazioni, consultare “Elaborazione del comando Conman” a pagina
143.
Esempi
Per rilasciare il flusso di lavoro ap da tutte le dipendenze, eseguire il comando:
release sched=ap
176 IBM Tivoli Workload Scheduler - Manuale di riferimento
Per rilasciare il flusso di lavoro sked5 da tutte le dipendenze opens, eseguire il
comando:
rs sked5;opens
Per rilasciare tutti i flussi di lavoro sulla workstation site3 dalle dipendenze sul
flusso di lavoro main#sked23, eseguire il comando:
rs site3#@;follows=main#sked23
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa al rilascio delle dipendenze per un’istanza del flusso di lavoro
nel manuale Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling
Console.
Capitolo 5. Riferimento a Conman 177
reply
Risponde ad un prompt del lavoro o del flusso di lavoro.
E’ necessario disporre dell’accesso reply al prompt globale o denominato. Per
rispondere ad un prompt non denominato, è necessario disporre dell’accesso reply
ai prompt e dell’accesso reply al lavoro o al flusso di lavoro associato.
Synopsis
reply { promptname | [wkstation#]msgnum};reply[;noask]
Arguments
promptname Specifica il nome di un prompt globale. Sono consentiti caratteri
jolly.
wkstation Specifica il nome della workstation su cui è stato emesso un
prompt non denominato.
msgnum Specifica il numero del messaggio di un prompt non denominato.
E’ possibile visualizzare i numeri messaggio con i comandi recall e
showprompts.
reply Specifica la risposta, Y per yes o N per no.
noask Specifica di non eseguire il prompt di conferma prima di avviare
l’operazione su ogni prompt di qualificazione.
Usage Notes
Se la risposta è Y, vengono soddisfatte le dipendenze sul prompt. Se la risposta è
N, le dipendenze non vengono soddisfatte e il prompt non viene emesso
nuovamente.
E’ possibile rispondere ai prompt prima di essere emessi. E’ possibile utilizzare il
comando showprompts per visualizzare tutti i prompt, nel caso in cui siano stati
emessi o meno.
Examples
Per rispondere Y al prompt globale arprmt, eseguire il comando:
reply arprmt;y
Per rispondere N al numero di messaggi 24 sulla workstation site4, eseguire il
comando:
rep site4#24;n
178 IBM Tivoli Workload Scheduler - Manuale di riferimento
rerun
Esegue nuovamente un lavoro.
E’ necessario disporre dell’accesso rerun al lavoro.
Sintesi
rr jobselect[;from=[wkstat#]job[;at=time][;pri=pri]][;noask]
rr jobselect[;step=step][;noask]
Argomenti
jobselect
Specifica il nome di uno o più lavori. Sono consentiti caratteri jolly.
from=[wkstat#]job
Specifica il nome di un lavoro definito nel database dello scheduler il cui
file di lavoro o comando verrà eseguito in sostituzione del lavoro
specificato da jobselect.
wkstat#
Specifica il nome della workstation su cui viene eseguito il lavoro
from. Il valore di default è la workstation su cui è in esecuzione
Conman.
job Specifica il nome della definizione lavorofrom. Non sono consentiti
i seguenti tipi di nomi lavoro:
v I nomi dei lavori inoltrati utilizzando i comandi submit file e
submit docommand.
v I nomi degli alias dei lavori inoltrati utilizzando il
comandosubmit job.
Per utilizzare l’argomento from, è necessario disporre dell’accesso al
database dello scheduler da computer su cui è in esecuzione Conman
at=time
Specifica l’ora di avvio del lavoro rerun, espresso nel modo seguente:
hhmm [timezone|tz tzname] [+n days | date]
dove:
hhmm L’ora e i minuti.
+n days
La ricorrenza successiva di hhmm in n giorni.
date La ricorrenza successiva di hhmm su date, espressa come mm/dd/yy.
timezone|tz tzname
Il nome del fuso orario del lavoro. Consultare Appendice B,
“Gestione dei fusi orari”, a pagina 331 per i nomi validi.
pri=pri
Specifica la priorità da assegnare al lavoro rerun. Se non viene specificata
una priorità, al lavoro viene data la stessa priorità del lavoro originale.
step=step
Specifica che il lavoro viene eseguito nuovamente utilizzando questo nome
al posto del nome lavoro originale. Per ulteriori informazioni, consultare
“Note sull’utilizzo”.
Capitolo 5. Riferimento a Conman 179
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni lavoro di qualificazione.
Note sull’utilizzo
E’ possibile eseguire nuovamente i lavori che si trovano nello stato succ, fail o
abend. Un lavoro eseguito nuovamente viene inserito nello stesso flusso di lavoro
del lavoro originale ed eredita le dipendenze del lavoro originale. Se si esegue
nuovamente un lavoro ripetitivo(every), l’esecuzione del lavoro viene pianificata
sullo stesso intervallo del lavoro originale.
Nota: E’ possibile emettere rerun per i lavori nel flusso di lavoro external che si
trovano nello stato error. I lavori nel flusso di lavoro external rappresentano
i lavori e i flussi di lavoro che sono stati specificati come dipendenze
internetwork. Lo stato del lavoro viene impostato inizialmente su extrn
subito dopo l’esecuzione di rerun e Conman inizia a controllare lo stato.
Quando viene utilizzato ;from, il nome del lavoro rieseguito dipende dal valore
dell’opzione globale conserva i nomi lavori rieseguiti. Se l’opzione viene
impostata su Y, i lavori rieseguiti mantengono i nomi lavoro originali. Se l’opzione
viene impostata su N, ai lavori rerun vengono forniti i nomi lavoro from. Per
ulteriori informazioni, consultare Manuale per la pianificazione e installazione di IBM
Tivoli Workload Scheduler.
Nei pannelli Conman, vengono visualizzati i lavori rerun con l’annotazione
>>rerun as. Per fare riferimento ad un lavoro rerun in un altro comando, come ad
esempio altpri, è necessario utilizzare il nome lavoro originale.
Quando un’opzione viene eseguita nuovamente con l’opzione ;step, il lavoro viene
eseguito con step in sostituzione del nome originale. In uno script di lavoro, è
possibile utilizzare il comando jobinfo per ritornare al nome lavoro ed eseguire lo
script in maniera differente per ogni iterazione. Ad esempio, nel seguente script
UNIX, viene utilizzato il comando jobinfo per impostare una variabile denominata
STEP sul nome che è stato utilizzato per eseguire il lavoro. La variabile STEP
viene utilizzata quindi per determinare come viene eseguito lo script.
...
MPATH=`maestro`
STEP=`$MPATH/bin/jobinfo job_name`
if [$STEP = JOB3]
then
...
STEP=JSTEP1
fi
if [$STEP = JSTEP1]
then
...
STEP=JSTEP2
fi
if [$STEP = JSTEP2]
then
...
fi
...
Nei pannelli Conman, i lavori rieseguiti con l’opzione ;step vengono visualizzati
con l’annotazione >>rerun step.
Per informazioni su jobinfo, consultare “jobinfo” a pagina 246.
180 IBM Tivoli Workload Scheduler - Manuale di riferimento
Esempi
Per ripetere il lavoro job4 nel flusso di lavoro sked1 sulla workstation main,
eseguire il comando:
rerun main#sked1.job4
Per ripetere il lavoro job5 nel flusso di lavoro sked2 utilizzando la definizione per
il lavoro jobx, dove l’ora del lavoro at è impostata su 6:30 p.m. e la priorità su 25,
eseguire il comando:
rr sked2.job5;from=jobx;at=1830;pri=25
Per ripetere il lavoro job3 nel flusso di lavoro sked4 utilizzando il nome jstep2,
eseguire il comando:
rr sked4.job3;step=jstep2
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla ripetizione dell’istanza di un lavoro nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 181
resource
Modifica il numero delle unità totali di una risorsa.
E’ necessario disporre dell’accesso resource alla risorsa.
Sintesi
resource [wkstation#]resource;num[;noask]
Argomenti
wkstation Specifica il nome della workstation su cui viene definita la risorsa.
Il valore di default è la workstation su cui è in esecuzione
Conman.
resource Specifica il nome della risorsa.
num Specifica il numero totale delle unità della risorsa. I valori validi
sono compresi tra 0 e 1024.
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione su ogni risorsa di qualificazione.
Esempi
Per modificare il numero di unità della risorsa tapes in 5, eseguire il comando:
resource tapes;5
Per modificare il numero di unità della risorsa jobslots sulla workstation site2 in
23, eseguire il comando:
res site2#jobslots;23
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla gestione delle risorse del database nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
182 IBM Tivoli Workload Scheduler - Manuale di riferimento
setsym
Seleziona un file di archivio del piano di produzione. I comandi di visualizzazione
successivi mostrano il contenuto del piano di produzione archiviato. Non è
possibile modificare le informazioni in un file di archivio del piano di produzione.
Synopsis
setsym [filenum]
Arguments
filenum Specifica il numero del file di archivio del piano di produzione. Se
non si specifica un numero di file di log, il puntatore ritorna sullo
zero, il piano di produzione corrente (Symphony). Utilizzare il
comando listsym per elencare i numeri del file di archivio.
Examples
Per selezionare il file di archivio del piano di produzione 5, eseguire il comando:
setsym 5
Per selezionare il piano di produzione corrente (Symphony), eseguire il comando:
set
Capitolo 5. Riferimento a Conman 183
showcpus
Visualizza le informazioni sulle workstation e sui collegamenti.
Sintesi
sc [[domain!]wkstation][;info|;link][;offline]
Argomenti
domain Specifica il nome di un dominio. Il valore di default è il dominio
su cui in esecuzione il comando.
wkstation Specifica il nome di una workstation. Il valore di default è la
workstation su cui where esecuzione il comando. Se non si
specificano domini o workstation, l’output potrebbe essere:
v Il seguente comando visualizza tutte le workstation presenti nel
dominio della workstation su cui viene eseguito il comando e
tutti i gestori dominio associati, se la workstation è un gestore
dominio.
conman "sc"
v Il seguente comando visualizza tutte le workstation presenti nel
dominio della workstation su cui viene eseguito il comando,
senza i gestori dominio associati.
conman "sc @"
info Visualizza le informazioni nel formato info.
link Visualizza le informazioni nel formato link.
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Output del comando
L’output del comando viene prodotto in tre formati, standard, info e link.
Formato standard:
CPUID
Il nome della workstation a cui si applicano queste informazioni.
RUN Il numero di esecuzione del file Controllo di produzione (Symphony).
NODE
Il tipo di nodo e il tipo di workstation. I tipi di nodi sono:
v UNIX
v WINT
v OTHER
I tipi di workstation sono:
v MASTER
v MANAGER
v FTA
v S-AGENT
v X-AGENT
LIMIT
Il limite di lavoro dello scheduler.
FENCE
Contenitore lavori dello scheduler.
184 IBM Tivoli Workload Scheduler - Manuale di riferimento
DATE TIME
La data e l’ora in cui lo scheduler ha avviato l’esecuzione del piano di
produzione corrente (Symphony).
STATE
Lo stato dei collegamenti della workstation. Fino a cinque caratteri
vengono visualizzati nel modo seguente:
[L] [T|H|X] [I] [J] [W|H|X]
L Il collegamento primario è aperto (linked) con il gestore
dominio/superiore.
T Il collegamento è TCP/IP.
H La workstation è collegata tramite l’host.
X La workstation è collegata come un agent esteso.
I Il programma jobman ha completato l’inizializzazione dell’avvio.
J Il programma jobman è in esecuzione.
W La workstation è collegata da TCP/IP.
F La workstation è collegata attraverso la connessione primaria e
tutte le secondarie.
Nota: Se la workstation su cui è in esecuzione Conman è l’host dell’agent
esteso, lo stato dell’agent esteso è
LXI JX
Se la workstation su cui è in esecuzione Conman non è l’host
dell’agent esteso, lo stato dell’agent esteso è
LHI JH
METHOD
Il nome del metodo di accesso specificato nella definizione della
workstation. Solo per gli agent estesi.
DOMAIN
Il nome del dominio di cui la workstation è membro.
Formato info:
CPUID
Il nome della workstation a cui si applicano queste informazioni.
VERSION
La versione del programma jobman di IBM Tivoli Workload Scheduler.
TIMEZONE
Il fuso orario della workstation. E’ uguale al valore della variabile
d’ambiente TZ. Per un agent esteso, si tratta del fuso orario del suo host.
INFO La versione del Sistema operativo e il modello dell’hardware. Per gli agent
estesi, non viene inserita alcuna informazione.
Formato del collegamento:
CPUID
Il nome della workstation a cui si applicano queste informazioni.
HOST Il nome della workstation che funziona come host su un agent standard o
su un agent esteso. Per i gestori domini e gli agent tolleranti l’errore, è
uguale a CPUID. Per le workstation degli agent standard, è il nome del
gestore dominio. Per gli agent estesi, è il nome della workstation host.
Capitolo 5. Riferimento a Conman 185
FLAGS
Lo stato dei collegamenti della workstation. Fino a cinque caratteri
vengono visualizzati nel modo seguente:
[A] [F] [s] [T]
A Il collegamento automatico viene attivato nella definizione della
workstation.
F La modalità Stato completo viene attivata sulla definizione della
workstation.
s L’ID del server mailman per la workstation.
T Il collegamento viene definito come TCP/IP.
ADDR
Il numero porta TCP per la workstation.
NODE
Il nome del nodo della workstation.
Esempi
1. Per visualizzare le informazioni sulla workstation su cui è in esecuzione
Conman nel formato info, eseguire il comando:
showcpus ;info
2. Per visualizzare le informazioni sui collegamenti non in linea per tutte le
workstation, eseguire il comando:
sc @!@;link;off
3. Per visualizzare le informazioni sulla workstation, eseguire il comando:
showcpus
Se si esegue questo comando e la connessione primaria della workstation con il
gestore dominio o superiore non è attiva, si riceverà il seguente output:
MASTER 360 *WNT MASTER 10 0 12/04/03 13:48 I J MASTERDM
FTA1 360 WNT FTA 10 0 12/04/03 13:48 FTI JW MASTERDM
FTA2 360 WNT FTA 10 0 12/04/03 13:48 FTI JW MASTERDM
FTA3 360 WNT MANAGER 10 0 12/04/03 13:48 LTI JW DOMAIN1
FTA4 360 WNT FTA 10 0 12/04/03 13:48 F I J DOMAIN1
FTA5 360 WNT FTA 10 0 12/04/03 13:48 I J DOMAIN1
SA1 360 WNT S-AGENT 10 0 12/04/03 13:48 F I J DOMAIN1
XA_FTA4 360 OTHR X-AGENT 10 0 12/04/03 13:48 L I J DOMAIN1
FTA6 360 WNT MANAGER 10 0 12/04/03 13:48 F I J DOMAIN2
FTA7 360 WNT FTA 10 0 12/04/03 13:49 F I J DOMAIN2
Se si esegue questo comando e la connessione primaria della workstation con il
gestore dominio o superiore è attiva ma almeno una delle connessioni
secondarie non lo è, si riceverà il seguente output:
MASTER 360 *WNT MASTER 10 0 12/04/03 13:48 I J MASTERDM
FTA1 360 WNT FTA 10 0 12/04/03 13:48 FTI JW MASTERDM
FTA2 360 WNT FTA 10 0 12/04/03 13:48 FTI JW MASTERDM
FTA3 360 WNT MANAGER 10 0 12/04/03 13:48 FTI JW DOMAIN1
FTA4 360 WNT FTA 10 0 12/04/03 13:48 F I J DOMAIN1
FTA5 360 WNT FTA 10 0 12/04/03 13:48 L I DOMAIN1
SA1 360 WNT S-AGENT 10 0 12/04/03 13:48 F I J DOMAIN1
XA_FTA4 360 OTHR X-AGENT 10 0 12/04/03 13:48 L I J DOMAIN1
FTA6 360 WNT MANAGER 10 0 12/04/03 13:48 F I J DOMAIN2
FTA7 360 WNT FTA 10 0 12/04/03 13:49 F I J DOMAIN2
Se si esegue questo comando e la connessione primaria della workstation con il
gestore dominio o superiore e tutte le connessioni secondarie sono attive, si
riceverà il seguente output:
MASTER 360 *WNT MASTER 10 0 12/04/03 13:48 I J MASTERDM
FTA1 360 WNT FTA 10 0 12/04/03 13:48 FTI JW MASTERDM
FTA2 360 WNT FTA 10 0 12/04/03 13:48 FTI JW MASTERDM
FTA3 360 WNT MANAGER 10 0 12/04/03 13:48 FTI JW DOMAIN1
186 IBM Tivoli Workload Scheduler - Manuale di riferimento
FTA4 360 WNT FTA 10 0 12/04/03 13:48 F I J DOMAIN1
FTA5 360 WNT FTA 10 0 12/04/03 13:48 F I DOMAIN1
SA1 360 WNT S-AGENT 10 0 12/04/03 13:48 F I J DOMAIN1
XA_FTA4 360 OTHR X-AGENT 10 0 12/04/03 13:48 L I J DOMAIN1
FTA6 360 WNT MANAGER 10 0 12/04/03 13:48 F I J DOMAIN2
FTA7 360 WNT FTA 10 0 12/04/03 13:49 F I J DOMAIN2
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla gestione degli elenchi di oggetti nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 187
showdomain
Visualizza le informazioni sul dominio.
Sintesi
showdomain [domain][;info][;offline]
Argomenti
domain Specifica il nome del dominio. Il valore di default è il dominio in
cui in esecuzione Conman. Sono consentiti caratteri jolly.
info Visualizza le informazioni le dipendenze info.
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Output del comando
L’output del comando viene prodotto in due formati, standard e info.
Formato standard:
DOMAIN
Il nome del dominio a cui si applicano queste informazioni.
MANAGER
Il nome del gestore dominio.
PARENT
Il nome del dominio parent.
Formato info:
DOMAIN
Il nome del dominio a cui si applicano queste informazioni.
MEMBER-CPUS
I nomi delle workstation nel dominio.
CPU-TYPE
Il tipo di ogni workstation: MASTER, MANAGER, FTA, S-AGENT o
X-AGENT.
Esempi
Per visualizzare le informazioni sul dominio masterdm, eseguire il comando:
showdomain masterdm
Per visualizzare le workstation membro in tutti i domini nel formato info, eseguire
il comando:
showdomain @;info
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla visualizzazione e alla modifica delle proprietà del dominio
nel manuale Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling
Console.
188 IBM Tivoli Workload Scheduler - Manuale di riferimento
showfiles
Visualizza le informazioni sulle dipendenze file. Si parla di dipendenza file quando
un lavoro o un flusso di lavoro necessita di verificare l’esistenza di uno o più file
prima che possa avviare l’esecuzione.
Synopsis
sf [[wkstation#]file][;state[;...]][;keys][;offline]
sf [[wkstation#]file][;state[;...]][;deps[;keys | info | logon]][;offline]
Arguments
wkstation Specifica il nome della workstation su cui si trovano i file. Il valore
di default è la workstation su cui è in esecuzione Conman. Sono
consentiti caratteri jolly.
file Specifica il nome del file. Il nome deve essere racchiuso tra apici (″)
se contiene caratteri diversi dai seguenti: alfanumerici, trattini (-),
barre (/), barre retroverse (\) e caratteri di sottolineatura (_). Il
valore di default è di visualizzare tutte le dipendenze file. Sono
consentiti caratteri jolly.
stato Specifica lo stato delle dipendenze file da visualizzare. Il valore di
default è di visualizzare le dipendenze file in tutti gli stati. Gli stati
sono come i seguenti:
yes Il file esiste ed è disponibile.
no Il file non è disponibile o non esiste.
? Viene controllata la disponibilità.
<blank>
Il file non è stato ancora controllato oppure il file era
disponibile e veniva utilizzato per soddisfare una
dipendenza lavoro o del flusso di lavoro.
keys Visualizza un singolo elenco di colonne degli oggetti selezionati dal
comando.
deps Visualizza le informazioni le dipendenze deps. Utilizzare keys,
info o logon per modificare la visualizzazione.
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Command Output
L’output del comando viene prodotto in tre formati: standard, keys e deps. Gli
argomenti keys, info e logon modificano la visualizzazione deps.
Formato standard:
Esiste Lo stato della dipendenza file.
Nome file
Il nome del file.
Formato keys: I file vengono inseriti con un file su ogni riga. I nomi delle
directory non sono inclusi. Ogni file viene elencato nel seguente formato:
wkstation#file
Capitolo 5. Riferimento a Conman 189
Formato deps: Vengono elencati i file seguiti dai lavori e dai flussi di lavoro
dipendenti. I lavori vengono elencati nel formato standard showjobs. I flussi di
lavoro vengono elencati nel formato standard showschedules.
Formato deps;keys: Vengono elencati i lavori e i flussi di lavoro che hanno una
dipendenza file per ogni riga, nel seguente formato:
wkstation#jstream[.job]
Formato deps;info: Vengono elencati i file seguiti dai lavori e dai flussi di lavoro
dipendenti. I lavori vengono elencati le dipendenze showjobs;info. I flussi di
lavoro vengono elencati nel formato standard showschedules.
Formato deps;logon: Vengono elencati i file seguiti dai lavori e dai flussi di lavoro
dipendenti. I lavori vengono elencati nel formato showjobs;logon. I flussi di lavoro
vengono elencati nel formato standard showschedules.
Examples
Per visualizzare lo stato di una dipendenza file per d:\apps\mis\lib\data4,
eseguire il comando:
showfiles d:\apps\mis\lib\data4
Per visualizzare lo stato non in linea di tutte le dipendenze file su tutte le
workstation nel formato deps, eseguire il comando:
sf @#@;deps;offline
190 IBM Tivoli Workload Scheduler - Manuale di riferimento
showjobs
Visualizza le informazioni sui lavori.
Sintesi
sj [jobselect] [;keys | info | step | logon | retcod][;short | single][;offline]
sj [jobselect] [;deps[;keys | info | logon]][;short | single][;offline]
sj [jobselect|wkstation# {jobnumber.hhmm}] [;stdlist[;keys]][;short |
single][;offline]
Argomenti
jobselect Consultare “Selezione dei lavori nei comandi” a pagina 129.
wkstation Il nome della workstation su cui è in esecuzione il lavoro. Sono
consentiti caratteri jolly.
jobnumber Il numero del lavoro.
hhmm L’ora di avvio del lavoro. Utilizzare questa insieme agli argomenti
stdlist e single, per visualizzare un’istanza specifica del lavoro.
keys Visualizza un singolo elenco di colonne degli oggetti selezionati dal
comando.
info Visualizza le informazioni le dipendenze info.
step Visualizza le informazioni nel formato step.
logon Visualizza le informazioni le dipendenze logon.
retcod Visualizza il codice di ritorno del lavoro.
stdlist Visualizza le informazioni nel formato stdlist. Utilizzare
l’argomento keys per modificare la vista.
deps Visualizza le informazioni le dipendenze deps. Utilizzare keys,
info o logon per modificare la visualizzazione.
short Riduce la visualizzazione per i lavori every e rerun per includere
solo quanto segue:
v la prima iterazione
v i lavori nei diversi stati
v i lavori esattamente corrispondenti
single Seleziona solo il lavoro parent in una catena che può includere
riesecuzioni, ripetizioni e lavori di ripristino. Il lavoro deve essere
identificato dal numero di lavoro in jobselect. Ciò è particolarmente
utile con l’opzione stdlist.
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Output del comando
L’output del comando showjobs viene prodotto i sette formati: standard, keys,
info, step, logon, deps e stdlist. Gli argomenti keys, info e logon modificano le
visualizzazioni.
Formato standard:
CPU La workstation su cui è in esecuzione il lavoro.
Capitolo 5. Riferimento a Conman 191
Schedule
Il nome del flusso di lavoro.
Lavoro
Il nome del lavoro. La seguente notazione può precedere un nome lavoro:
>> rerun as
Un lavoro che è stato rieseguito con il comando rerun o come
risultato di un ripristino automatico.
>> rerun step
Un lavoro che è stato rieseguito con il comando rerun ;step.
>> every run
La seconda o la successiva esecuzione di ogni lavoro.
>> recovery
L’esecuzione di un lavoro di ripristino.
Stato Lo stato del lavoro o del flusso di lavoro. Gli stati del lavoro sono:
abend Il lavoro è terminato con un codice di uscita diverso da zero.
abenp E’ stata ricevuta una conferma abend, ma il lavoro non è stato
completato.
add Il lavoro è stato inoltrato.
done Il lavoro è stato completato in uno stato sconosciuto.
error Solo per le dipendenze internetwork, si è verificato un errore
durante il controllo dello stato remoto.
exec Il lavoro è in esecuzione.
extrn Solo per le dipendenze internetwork, lo stato è sconosciuto. Si è
verificato un errore, è stata eseguita un’operazione di nuova
esecuzione sul lavoro nel flusso di lavoro esterno oppure il lavoro
remoto o il flusso di lavoro non esiste.
fail Non in grado di avviare il lavoro.
fence La priorità del lavoro si trova sotto il delimitatore.
hold Il lavoro è in attesa della risoluzione della dipendenza.
intro Il lavoro viene introdotto per l’avvio dal sistema.
pend Il lavoro è stato completato ed è in attesa di conferma.
ready Il lavoro è pronto per l’avvio e tutte le dipendenze sono state
risolte.
sched Non è arrivata l’ora at del lavoro.
succ Il lavoro è stato completato con un codice di uscita pari a zero.
succp E’ stata ricevuta una conferma succ, ma il lavoro non è stato
completato.
wait Il lavoro si trova nello stato di attesa. (Extended Agent)
Gli stati del flusso di lavoro sono:
abend Il flusso di lavoro è stato terminato con un codice di uscita diverso
da zero.
add Il flusso di lavoro è stato aggiunto con l’intervento dell’operatore.
192 IBM Tivoli Workload Scheduler - Manuale di riferimento
cancel Il flusso di lavoro è stato annullato.
cancel pend
L’annullamento del flusso di lavoro è in sospeso. L’annullamento
viene ritardato fino a quando non vengono risolte tutte le
dipendenze, inclusa l’ora at.
error Solo per le dipendenze internetwork, si è verificato un errore
durante il controllo dello stato remoto.
exec Il flusso di lavoro è in esecuzione.
extrn Solo per le dipendenze internetwork, il flusso di lavoro si trova in
una rete remota dello scheduler e il suo stato è sconosciuto. Si è
verificato un errore, è stata effettuata una nuova esecuzione del
flusso di lavoro EXTERNAL oppure il lavoro INET o il flusso di
lavoro esistono.
hold Il flusso di lavoro è in attesa della risoluzione dipendenza.
ready Il flusso di lavoro è pronto per l’avvio e tutte le dipendenze sono
state risolte.
stuck L’esecuzione del flusso di lavoro è stata interrotta. Nessun lavoro è
stato avviato senza l’intervento dell’operatore.
succ Il flusso di lavoro è stato completato con esito positivo.
Pr La priorità del flusso di lavoro o del lavoro. Un segno (+) che precede la
priorità indica che il lavoro è stato avviato.
(Est)Start
L’ora di avvio del flusso di lavoro o del lavoro. Le parentesi indicano una
stima dell’ora di avvio. Se l’ora di avvio è superiore alle 24 ore nel passato
o nel futuro, la data viene elencata al posto dell’ora.
(Est)Elapse
Il run time del flusso di lavoro o del lavoro. Le parentesi indicano una
stima in base alle statistiche registrate.
dependencies
Un elenco delle dipendenze lavoro e dei commenti. Può essere elencata
una qualsiasi delle seguenti combinazioni:
v Per una dipendenza follows, viene visualizzato un nome lavoro o del
flusso di lavoro.
v Per una dipendenza opens, viene visualizzato il nome del file. Se il file
si trova su un agent esteso e il suo nome è più lungo di 25 caratteri,
vengono visualizzati solo gli ultimi 25 caratteri.
v Per una dipendenza needs, viene visualizzato un nome risorsa racchiuso
tra trattini (-). Se il numero delle unità necessarie è maggiore di uno, il
numero viene visualizzato prima del primo trattino.
v Per un’ora deadline, viene visualizzata l’ora preceduta da segni di
maggiore e minore (<).
v Per un intervallo every, viene visualizzato l’intervallo di ripetizione
preceduto da un ampersand (&).
v Per un’ora until, viene visualizzata l’ora preceduta da segni di maggiore
e minore (<).
v Per una dipendenza prompt, il numero della prompt viene visualizzato
nel formato #num. Per i prompt globali, il nome del prompt segue tra
parentesi.
Capitolo 5. Riferimento a Conman 193
v Per i lavori di esecuzione, il PID (process identification number) viene
visualizzato nel formato #Jnnnnn.
v I lavori inoltrati su UNIX utilizzando i comandi IBM Tivoli Workload
Scheduler at e batch vengono etichettati [Userjcl].
v I lavori annullati vengono etichettati [Cancelled].
v I lavori annullati con l’opzione ;pend vengono etichettati [Cancel Pend].
v I lavori con ore until scadute, inclusi i lavori annullati con l’opzione
;pend , vengono etichettati [Until].
v [Recovery] indica che l’intervento di quell’operazione è necessario.
v [Confirm] indica che la conferma è necessaria perché il lavoro è stato
pianificato utilizzando la parola chiave confirm.
v [Script] si applica solo alle reti end-to-end; indica che questo lavoro ha
uno script centralizzato e che Tivoli Workload Scheduler per z/OS non
lo ha ancora scaricato sull’agent.
Formato keys: I nomi dei lavori elencati uno su ogni riga nel seguente formato:
wkstation#jstream.job
Formato info:
CPU La workstation su cui è in esecuzione il lavoro.
Schedule
Il nome del flusso di lavoro.
Lavoro
Il nome del lavoro. La seguente notazione può precedere un nome lavoro:
>> rerun as
Un lavoro che è stato rieseguito con il comando rerun o come
risultato di un ripristino automatico.
>> rerun step
Un lavoro che è stato rieseguito con il comando rerun ;step.
>> every run
La seconda o la successiva esecuzione di ogni lavoro.
>> recovery
L’esecuzione di un lavoro di ripristino.
File lavoro
Il nome dello script del lavoro o del file eseguibile. I nomi lunghi del file
potrebbero essere suddivisi, provocando un’impaginazione non corretta.
Per evitare ciò, eseguire il pipe dell’output su more. Ad esempio:
conman “sj;info | more
Opt L’opzione di ripristino del lavoro, se presente. Le opzioni di ripristino sono
RE per la riesecuzione, CO per la continuazione e ST per l’arresto.
Lavoro
Il nome del lavoro di ripristino, se presente.
Prompt
Il numero del prompt di ripristino, se presente.
Formato step: Questo formato non è supportato su Windows.
CPU La workstation su cui è in esecuzione il lavoro.
194 IBM Tivoli Workload Scheduler - Manuale di riferimento
Schedule
Il nome del flusso di lavoro.
Lavoro
Il nome del lavoro. La seguente notazione potrebbe precedere un nome
lavoro:
>> rerun as
Un lavoro che è stato rieseguito con il comandorerun o come
risultato di un ripristino automatico.
>> repeated as
La seconda e le successive esecuzioni di un lavoro every.
State Lo stato del lavoro o del flusso di lavoro. Consultare “Formato standard”
per informazioni sullo stato.
Codice di ritorno
Il codice di ritorno del lavoro.
Job# Il numero di identificazione del processo viene visualizzato come#Jnnnnn.
Step Un elenco di processi discendenti che sono associati al lavoro. Per i lavori
dell’agent esteso, vengono elencati solo i processi host.
Formato logon:
CPU La workstation su cui è in esecuzione il lavoro.
Schedule
Il nome del flusso di lavoro.
Lavoro
Il nome del lavoro. La seguente notazione può precedere un nome lavoro:
>> rerun as
Un lavoro che è stato rieseguito con il comandorerun o come
risultato di un ripristino automatico.
>> repeated as
La seconda e le successive esecuzioni di un lavoro every.
State Lo stato del lavoro o del flusso di lavoro. Consultare “Formato standard”
per informazioni sullo stato.
Codice di ritorno
Il codice di ritorno del lavoro.
Job# Il numero di identificazione del processo viene visualizzato come#Jnnnnn.
Logon Il nome utente sotto il quale viene eseguito il lavoro.
Formato stdlist: Un elenco standard viene creato automaticamente da Jobmon su
Windows or Jobman on UNIX, per ogni lavoro Jobmon. È possibile visualizzare il
contenuto dei file di elenco files utilizzando Conman. Un file di elenco standard
contiene:
v banner iniziali e finali
v comandi ripetuti
v output stdout del lavoro
v output stderr del lavoro
Capitolo 5. Riferimento a Conman 195
Per specificare un particolare formato della data da utilizzare nei file di elenco
standard, modificare il formato della data di IBM Tivoli Workload Scheduler prima
di creare i file di elenco standard. Eseguire questa operazione modificando il
formato della locale per la data.
In base al proprio ambiente, modificare il formato della locale per la data
completando i seguenti passi:
v Su UNIX, impostare la variabile LANG quando si avvia Netman. Se la variabile
LANG non è impostata, la locale del sistema operativo viene impostata per
default su ″C″.
v Su Windows, effettuare le seguenti operazioni:
1. Andare al Pannello di controllo→Impostazioni internazionali ed impostare la
propria locale.
2. Fare clic col tastino destro del mouse doppio su ″Risorse del computer″,
andare a Proprietà, fare clic su ″Avanzate″, selezionare le Variabili di
ambiente ed impostare la variabile LANG come variabile di sistema.
3. Spegnere e riavviare il sistema.
Vengono visualizzati i file di elenco standard per i lavori selezionati.
Formato stdlist;keys: Vengono selezionati i nomi dei file elenco standard per i
lavori selezionati, uno su ogni riga.
Formato deps: Vengono elencati i lavori utilizzati nelle dipendenze follows
seguiti dai lavori e dai flussi di lavoro. I lavori vengono elencati nel formato
standard showjobs. I flussi di lavoro vengono elencati nel formato standard
showschedules.
Formato deps;keys: Vengono elencati i lavori e i flussi di lavoro che hanno
dipendenze follows, una su ogni riga.
Formato deps;info: Vengono elencati i lavori utilizzati nelle dipendenze follows,
seguiti dai lavori e dai flussi di lavoro dipendenti. Vengono elencati i lavori nel
formato showjobs;info. I flussi di lavoro vengono elencati le dipendenze standard
showschedules.
Formato deps;logon: Vengono elencati i lavori utilizzati nelle dipendenze follows,
seguiti dai lavori e dai flussi di lavoro dipendenti. I lavori vengono elencati nel
formato showjobs;logon. I flussi di lavoro vengono elencati le dipendenze
standard showschedules.
Esempi
Per visualizzare lo stato di tutti i lavori in tutti i flussi di lavoro acctg sulla
workstation site3, eseguire il comando:
showjobs site3#acctg@.@
Per visualizzare lo stato di tutti i lavori sulla workstation su cui è in esecuzione
Conman nel formato logon, eseguire il comando:
sj ;logon
Per visualizzare lo stato di tutti i lavori nello stato hold su tutte le workstation, nel
formato deps, eseguire il comando:
sj @#@.@+state=hold;deps
196 IBM Tivoli Workload Scheduler - Manuale di riferimento
Per visualizzare tutti i file di elenco standard per il lavoro sendmail nel flusso di
lavoro mail sulla workstation WN1, in esecuzione in un ambiente Windows,
eseguire il comando:
sj WN1#mail.sendmail;stdlist
L’output è il seguente:
=================================================================
= JOB : WN1#MAIL.SENDMAIL
= USER : xpress
= JCLFILE : \users\xpress\sendxpmail
= Job Number : 8027
= Fri Jun 5 12:17:10 1997
=================================================================
...
... <stdout, stderr, and echoed commands>
...
=================================================================
= Exit Status : 0
= System Time (Seconds) : 0 Elapsed Time (Minutes) : 0
= User Time (Seconds) : 0
= Fri Jun 5 12:17:12 1997
==================================================================
dove:
Exit Status
Indica lo stato del lavoro al completamento.
Elapsed Time
Indica il tempo trascorso per il lavoro.
System Time
Indica il periodo di tempo impiegato dal sistema kernel per il lavoro.
User Time
Indica il periodo di tempo impiegato dall’utente per il lavoro.
Nota: I campi System Time e User Time vengono utilizzati solo su UNIX. I valori
di questi campi in Windows sono sempre impostati su 0, perché il processo
joblnch.exe viene eseguito in un intervallo di tempo così breve da essere
considerato nullo.
Il seguente esempio visualizza lo stato del lavoro dbseload con il codice di ritorno
7 e lo stato SUCCESSFUL:
$ conman sj workstation#DAILY_DB_LOAD
TWS for UNIX (AIX)/CONMAN 8.2 (1.36.1.7)
Materiale su licenza proprietà di IBM
5698-WKB
(C) Copyright IBM Corp 1998,2001
US Government User Restricted Rights
Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Installed for user ‘’
Locale LANG set to “en_US”
Schedule (Exp) 09/30/03 (#126) on MASTER. Batchman LIVES. Limit: 10,
Fence: 0, Audit Level: 1
sj workstation#DAILY_DB_LOAD
(Est) (Est)
CPU Schedule Job State Pr Start
Elapse Dependencies Return Code
WORKSTATION #DAILY_DB_LOAD **************************************** SUCC 10 22:11
00:04
DATASPLT SUCC 10 22:11
Capitolo 5. Riferimento a Conman 197
00:01 #J17922 0
DATAMRGE ABEND 10 22:12
00:01 #J17924 1
CHCKMRGE SUCC 10 22:12
00:01 #J17926 0
DATACLNS SUCC 10 22:12
00:01 #J17932 0
DATARMRG SUCC 10 22:13
00:01 #J18704 0
DBSELOAD SUCC 10 22:13
00:01 #J18706 7
DATAREPT SUCC 10 22:13
00:01 #J18712 0
DATARTRN SUCC 10 22:14
00:01 #J18714 0
$
Esiste anche un nuovo argomento retcod che, se specificato con keys, fornisce il
codice di ritorno per un lavoro specifico, come indicato nel seguente esempio:
$ conman sj workstation#daily_db_load.dbseload\;keys\;retcod
TWS for UNIX (AIX)/CONMAN 8.2 (1.36.1.7)
Licensed Materials Property of IBM
5698-WKB
(C) Copyright IBM Corp 1998,2001
US Government User Restricted Rights
Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM
Corp.
Installed for user ‘’
Locale LANG set to “en_US”
Schedule (Exp) 10/16/03 (#150) on MASTER. Batchman LIVES. Limit: 10, Fence:
0,
Audit Level: 1
sj workstation#daily_db_load.dbseload;keys;retcod
8$
La funzione retcod, se integrata in uno script, può diventare alquanto potente.
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla gestione degli elenchi di oggetti nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
198 IBM Tivoli Workload Scheduler - Manuale di riferimento
showprompts
Visualizza le informazioni sui prompt.
Sintesi
sp [promptselect][;keys][;offline]
sp [promptselect] [;deps[;keys | info | logon]][;offline]
Argomenti
promptselect
[promptname | [wkstation#]msgnum][;state[;...]]
promptname
Specifica il nome di un prompt globale. Sono consentiti caratteri
jolly.
wkstation
Specifica il nome della workstation su cui è stata emesso un
prompt non definito. Il valore di default è la workstation su cui è
in esecuzione Conman.
msgnum
Specifica il numero del messaggio di un prompt non denominato.
stato Specifica lo stato dei prompt da visualizzare. Gli stati sono come i
seguenti:
YES Al prompt è stato risposto y.
NO Al prompt è stato risposto n.
ASKED
Il prompt è stato emesso, ma non è stata fornita alcuna
risposta.
INACT
Il prompt non è stata emesso.
keys Visualizza un singolo elenco di colonne degli oggetti selezionati dal
comando.
deps Visualizza le informazioni le dipendenze deps. Utilizzare keys, info o
logon per modificare la visualizzazione.
info Visualizza le informazioni le dipendenze info.
logon Visualizza le informazioni le dipendenze logon.
offline
Invia l’output del comando all’unità di output Conman. Per informazioni
su tale unità, fare riferimento a “Output non in linea” a pagina 124.
Output del comando
L’output del comando viene prodotto in tre formati: standard, keys e deps. Gli
argomenti keys, info e logon modificano la visualizzazione deps.
Formato standard:
Stato Lo stato del prompt.
Messaggio o Prompt
Per i prompt denominati, il numero di messaggio, il nome e il testo del
Capitolo 5. Riferimento a Conman 199
prompt. Per i prompt non denominati, il numero del messaggio, il nome
del lavoro o del flusso di lavoro e il testo del prompt.
Formato keys: I prompt vengono elencati una su ogni riga. I prompt denominati
vengono elencati con i relativi nomi e numeri messaggio. I prompt non denominati
vengono elencati con i relativi numeri messaggio e i nomi dei lavori o dei flussi di
lavoro in cui vengono visualizzati come dipendenze.
Formato deps: Vengono elencate i prompt utilizzati come dipendenze, seguite dai
lavori e dai flussi di lavoro dipendenti. I lavori vengono elencati le dipendenze
standard showjobs. I flussi di lavoro vengono elencati le dipendenze standard
showschedules.
Formato deps;keys: I lavori e i flussi di lavoro che hanno dipendenze del prompt
vengono elencati uno su ogni riga.
Formato deps;info: Vengono elencate i prompt utilizzati come dipendenze,
seguite dai lavori e dai flussi di lavoro dipendenti. I lavori vengono elencati le
dipendenze showjobs;info. I flussi di lavoro vengono elencati nel formato
standard showschedules.
Formato deps;logon: Vengono elencate i prompt utilizzati come dipendenze,
seguite dai lavori e dai flussi di lavoro dipendenti. I lavori vengono elencati nel
formato showjobs;logon. I flussi di lavoro vengono elencati nel formato standard
showschedules.
Esempi
Per visualizzare lo stato di tutti i prompt emessi sulla workstation su cui è in
esecuzione il programma Conman, eseguire il comando:
showprompts
Per visualizzare lo stato di tutti i prompt mis che sono stati emessi, nel formato
deps, eseguire il comando:
sp mis@;asked;deps
Per visualizzare lo stato del prompt 34 sulla workstation main, eseguire il
comando:
sp main#34
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla visualizzazione e alla modifica delle proprietà dei prompt
nel manuale Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling
Console.
200 IBM Tivoli Workload Scheduler - Manuale di riferimento
showresources
Visualizza le informazioni sulle risorse.
Sintesi
sr [[wkstation#]resourcename][;keys][;offline]
sr [[wkstation#]resourcename][;deps[;keys | info | logon]][;offline]
Argomenti
wkstation Specifica il nome della workstation su cui viene definita la risorsa.
Il valore di default è la workstation su cui è in esecuzione
Conman.
resourcename Specifica il nome della risorsa. Sono consentiti caratteri jolly.
keys Visualizza un singolo elenco di colonne degli oggetti selezionati dal
comando.
deps Visualizza le informazioni le dipendenze deps. Utilizzare keys,
info o logon per modificare la visualizzazione.
info Visualizza le informazioni le dipendenze info.
logon Visualizza le informazioni le dipendenze logon.
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Output del comando
L’output del comando viene prodotto in tre formati: standard, keys e deps. Gli
argomenti keys, info e logon modificano la visualizzazione deps.
Formato standard:
CPU La workstation su cui viene definita la risorsa.
Risorsa Il nome della risorsa.
Total Il numero totale delle unità delle risorsa definite.
Available Il numero delle unità della risorsa che non sono state assegnate.
Qty Il numero delle unità della risorsa assegnato ad un lavoro o ad un
flusso di lavoro.
Used By Il nome del lavoro o del flusso di lavoro.
Formato keys: Viene elencata una risorsa su ogni riga.
Formato deps: Vengono elencate le risorse utilizzate come dipendenze, seguite dai
lavori e dai flussi di lavoro. I lavori vengono elencati le dipendenze standard
showjobs. I flussi di lavoro vengono elencati le dipendenze standard
showschedules.
Formato deps;keys: Vengono elencati i lavori e i flussi di lavoro che hanno una
dipendenza su ogni riga.
Formato deps;info: Vengono elencate le risorse utilizzate come dipendenze,
seguite dai lavori e dai flussi di lavoro. Vengono elencati i lavori nel formato
showjobs;info. I flussi di lavoro vengono elencati nel formato standard
showschedules.
Capitolo 5. Riferimento a Conman 201
Formato deps;logon: Vengono elencate le risorse utilizzate come dipendenze,
seguite dai lavori e dai flussi di lavoro. I lavori vengono elencati nel formato
showjobs;logon. I flussi di lavoro vengono elencati nel formato standard
showschedules.
Esempi
Per visualizzare le informazioni su tutte le risorse sulla workstation su cui è in
esecuzione il programma Conman, eseguire il comando:
showresources
Per visualizzare le informazioni sulla risorsa dbase sulla workstation main nel
formato deps, eseguire il comando:
sr main#dbase;deps
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla visualizzazione delle proprietà delle risorse nel manuale
Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
202 IBM Tivoli Workload Scheduler - Manuale di riferimento
showschedules
Visualizza le informazioni sui flussi di lavoro.
Sintesi
ss [jstreamselect][;keys][;offline]
ss [jstreamselect][;deps[;keys | info | logon]][;offline]
Argomenti
jstreamselect Consultare “Selezione dei flussi di lavoro nei comandi” a pagina
137.
keys Visualizza un singolo elenco di colonne degli oggetti selezionati dal
comando.
deps Visualizza le informazioni le dipendenze deps. Utilizzare keys,
info o logon per modificare la visualizzazione.
info Visualizza le informazioni le dipendenze info.
logon Visualizza le informazioni le dipendenze logon.
offline Invia l’output del comando all’unità di output Conman. Per
informazioni su tale unità, fare riferimento a “Output non in linea”
a pagina 124.
Output del comando
L’output del comando viene prodotto in tre formati: standard, keys e deps. Gli
argomenti keys, info e logon modificano la visualizzazione deps.
Formato standard:
CPU La workstation su cui è in esecuzione il flusso di lavoro.
Schedule
Il nome del flusso di lavoro.
Stato Lo stato del flusso di lavoro. Gli stati sono come i seguenti:
add Il flusso di lavoro è stato aggiunto con l’intervento dell’operatore.
abend Il flusso di lavoro è stato terminato con un codice di uscita diverso
da zero.
cancel Il flusso di lavoro è stato annullato.
cancel pend
L’annullamento del flusso di lavoro è in sospeso. L’annullamento
viene ritardato fino a quando non vengono risolte tutte le
dipendenze, inclusa l’ora at.
error Solo per le dipendenze internetwork, si è verificato un errore
durante il controllo dello stato remoto.
exec Il flusso di lavoro è in esecuzione.
extrn Solo per le dipendenze internetwork, il flusso di lavoro si trova in
una rete remota dello scheduler e il suo stato è sconosciuto. Si è
verificato un errore, è stata effettuata una nuova esecuzione del
flusso di lavoro EXTERNAL oppure il lavoro INET o il flusso di
lavoro esistono.
hold Il flusso di lavoro è in attesa della risoluzione della dipendenza.
Capitolo 5. Riferimento a Conman 203
ready Il flusso di lavoro è pronto per l’avvio e tutte le dipendenze sono
state risolte.
stuck L’esecuzione del flusso di lavoro è stata interrotta. Nessun lavoro è
stato avviato senza l’intervento dell’operatore.
succ Il flusso di lavoro è stato completato con esito positivo.
Pr La priorità del flusso di lavoro.
(Est)Start
L’ora di avvio del flusso di lavoro. Le parentesi indicano una stima dell’ora
di avvio. Se l’ora di avvio è superiore alle 24 ore nel passato o nel futuro,
la data viene elencata al posto dell’ora.
(Est)Elapse
Il run time del flusso di lavoro. Le parentesi indicano una stima in base
alle statistiche registrate.
Jobs # Il numero di lavori nel flusso di lavoro.
Job OK
Il numero di lavori che sono stati completati con esito positivo.
Sch Lim
Il limite del lavoro del flusso di lavoro. Se non ne viene elencato alcuno,
non ha effetto nessun limite.
dependencies
Un elenco di dipendenze e commenti del flusso di lavoro. Può essere
elencata una combinazione qualsiasi dei seguenti:
v Per una dipendenza follows, viene visualizzato un nome lavoro o del
flusso di lavoro.
v Per una dipendenza opens, viene visualizzato il nome del file. Se il file
si trova su un agent esteso e il suo nome è più lungo di 25 caratteri,
vengono visualizzati solo gli ultimi 25 caratteri.
v Per una dipendenza needs, viene visualizzato un nome risorsa racchiuso
tra trattini (-). Se il numero delle unità necessarie è maggiore di uno, il
numero viene visualizzato prima del primo trattino.
v Per un’ora until, l’ora preceduta da segni di maggiore e minore (<).
v Per una dipendenza prompt, il numero del prompt viene visualizzato
come #num. Per i prompt globali, segue il nome del prompt tra
parentesi.
v I flussi di lavoro annullati vengono etichettati [Cancelled].
v I flussi di lavoro annullati con l’opzione ;pend vengono etichettati
[Cancel Pend].
v Per un’ora deadline, viene visualizzata l’ora preceduta da segni di
maggiore e minore (<).
v I flussi di lavoro con ore until scadute, inclusi i flussi di lavoro annullati
con l’opzione ;pend, vengono etichettati: [Until].
v I flussi di lavoro che contengono la parola chiave carryforward vengono
etichettati [Carry].
v Per i flussi di lavoro che sono stati portati avanti dal giorno precedente,
il nome e la data originali vengono visualizzati tra parentesi.
Formato keys: I flussi di lavoro vengono elencati uno su ogni riga.
204 IBM Tivoli Workload Scheduler - Manuale di riferimento
Formato deps: Vengono elencate le risorse utilizzate come dipendenze, seguite dai
lavori e i flussi di lavoro dipendenti. I lavori vengono elencati le dipendenze
standard showjobs. I flussi di lavoro vengono elencati le dipendenze standard
showschedules.
Formato deps;keys: Vengono elencati i flussi di lavoro che hanno
dipendenzefollows, uno su ogni riga.
Formato deps;info: Vengono elencate le risorse utilizzate come dipendenze,
seguite dai lavori e i flussi di lavoro dipendenti. Vengono elencati i lavori nel
formato showjobs;info. I flussi di lavoro vengono elencati le dipendenze standard
showschedules.
Formato deps;logon: Vengono elencate le risorse utilizzate come dipendenze,
seguite dai lavori e i flussi di lavoro dipendenti. I lavori vengono elencati nel
formato showjobs;logon. I flussi di lavoro vengono elencati le dipendenze
standard showschedules.
Esempi
Per visualizzare lo stato di tutti i flussi di lavoro hold sulla workstation su cui è in
esecuzione il programma Conman, eseguire il comando:
showschedules @+state=hold
Per visualizzare lo stato di tutti i flussi di lavoro corp sulla workstation site2 nel
formato deps;info, eseguire il comando:
ss site2#corp@;deps;info
Per visualizzare lo stato non in linea di tutti i flussi di lavoro nello stato abend su
tutte le workstation, eseguire il comando:
ss @#@+state=abend;off
Per visualizzare lo stato di tutti i flussi di lavoro su tutte le workstation, eseguire il
comando:
%ss @#@
Dopo aver eseguito il comando, verrà ricevuto un output simile al seguente:
CPU Schedule State Pr Start Elapse # OK Lim
TWS820A #SCHED-1 ABEND 10 09/03 0:00 100 0
TWS820A #SCHED-2 READY 10 100 0
TWS820A #SCHED-3 ABEND 10 09/03 0:00 100 0
TWS820A #SCHED-4 EXEC 10 09/03 100 0
TWS820A #SCHED-5 READY 10 100 0
TWS820A #SCHED-6 READY 10 100 0
TWS820A #SCHED-7 SUCC 10 09/03 0:02 2 2
TWS820A #SCHED-8 READY 10 ( 0:01) 1 0
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla visualizzazione di un flusso di lavoro nel manuale Guida per
l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
Capitolo 5. Riferimento a Conman 205
shutdown
Arresta incondizionatamente tutti i processi di produzione dello scheduler, inclusi
Batchman, Jobman, Netman, Mailman, tutti i server Mailman e tutti gli
sviluppatori.
E’ necessario disporre dell’accesso shutdown alla workstation.
Synopsis
shutdown [;wait]
Arguments
wait Attende che tutti i processi siano stati arrestati prima di effettuare
il prompt di un altro comando.
Usage Notes
Il comando shutdown arresta i processi solo sulla workstation su cui è in
esecuzione Conman. Per riavviare solo Netman, eseguire il comando StartUp. Per
informazioni sul comando StartUp, consultare “StartUp” a pagina 265. Per
riavviare l’intero albero di processi, eseguire un comando Conman start.
E’ necessario eseguire un comando Conman unlink @ prima del comando
shutdown.
Examples
Per arrestare la produzione sulla workstation su cui è in esecuzione il programma
Conman, eseguire il comando:
unlink @
shutdown
Per arrestare la produzione sulla workstation su cui è in esecuzione il programma
Conman e attendere la chiusura di tutti i processi, eseguire il comando:
unlink@;noask
shut ;wait
206 IBM Tivoli Workload Scheduler - Manuale di riferimento
avvio
Avvia i processi di produzione dello scheduler.
E’ necessario disporre dell’accesso start alla workstation.
Synopsis
start [domain!]wkstation[;mgr][;noask][;demgr]
Arguments
domain Specifica il nome del dominio in cui vengono avviate le
workstation. Sono consentiti caratteri jolly.
Questo argomento è utile quando si avvia più di una workstation
in un dominio. Ad esempio, per avviare tutti gli agent nel dominio
stlouis, utilizzare il seguente comando:
start stlouis!@
Se domain viene omesso e wkstation contiene caratteri jolly, il
dominio di default è quello su cui è in esecuzione Conman.
wkstation Specifica il nome della workstation da avviare. Sono consentiti
caratteri jolly.
mgr Questo può essere immesso solo sulla workstation su cui è in
esecuzione Conman. Avvia la workstation locale come Gestore
dominio. La workstation diventa il nuovo gestore dominio e il
gestore dominio corrente diventa un FTA. Questa forma di
comando di solito segue un comando stop. Tenere presente che il
metodo preferito di commutazione di un gestore dominio è quello
di utilizzare un comando switchmgr. Per ulteriori informazioni,
consultare “switchmgr” a pagina 221.
noask Specifica di non eseguire il prompt di conferma prima di avviare
l’operazione di ogni workstation di qualificazione.
demgr Questa opzione non consente l’apertura di connessioni esterne
durante la transazione quando un agent viene avviato come un
vecchio gestore domini e quando si esegue il comando switchmgr,
impedendo all’agent del gestore domini di funzionare. Questa
opzione viene eseguita automaticamente, ma quando il vecchio
gestore domini elabora l’evento switchmgr (ad esempio, in caso di
riavvio ritardato o riavvio dopo il ripristino di un agent
danneggaito), è necessario utilizzare l’opzione demgr per avviare il
vecchio gestore dalla riga comandi locale. Per ulteriori
informazioni su questa opzione, consultare Manuale per la
pianificazione e installazione di IBM Tivoli Workload Scheduler.
Usage Notes
Il comando start viene utilizzato all’inizio di ogni giorno per riavviare
l’elaborazione della produzione precedente dello scheduler. In quel momento causa
l’inizializzazione e l’avvio automatico degli FTA e degli agent standard collegati
automaticamente. Gli agent non collegati automaticamente vengono inizializzati e
avviati quando si esegue il comando link.
Presumendo che l’utente disponga dell’accesso start alle workstation avviate, si
applicano le seguenti regole:
Capitolo 5. Riferimento a Conman 207
v Un utente che esegue Conman sul gestore dominio master può avviare qualsiasi
workstation nella rete.
v Un utente che esegue Conman su un gestore dominio diverso dal master può
avviare qualsiasi workstation in quel dominio e nei domini subordinati. L’utente
non può avviare le workstation nel dominio peer.
v Un utente che esegue Conman su un agent può avviare le workstation
dell’agent.
Examples
L’illustrazione e la tabella sottostante visualizzano le workstation avviate dai
comandi start eseguiti dagli utenti in varie ubicazioni nella rete.
DMn sono i gestori domini e Ann sono gli agent.
Comando Avviato da User1 Avviato da User2 Avviato da User3
start @!@ Tutte le workstation
sono state avviate.
DM2
A21
A22
DM4
A41
A42
A21
start @ DM1
A11
A12
DM2
A21
A22
A21
start DOMAIN3!@ DM3
A31
A32
Non consentito. Non consentito
start DOMAIN4!@ DM4
A41
A42
DM4
A41
A42
Non consentito
start DM2 DM2 DM2 Non consentito
start A42 A42 A42 Non consentito
start A31 A31 Non consentito. Non consentito
A11 A12
DM1
DM2 DM3
DM4
A21 A22 A31 A32
A41 A42
Dominio1
Dominio2 Dominio3
Dominio4
Utente1
Utente2
Utente3
Figura 4. Workstation avviate in rete
208 IBM Tivoli Workload Scheduler - Manuale di riferimento
status
Visualizza il banner Conman e lo stato della produzione IBM Tivoli Workload
Scheduler.
Synopsis
status
Command Output
La modalità (Symphony) del piano di produzione che segue la parola Schedule
sulla seconda riga dell’output, viene visualizzato in parentesi. Potrebbe apparire
l’informazione Def o Exp. Def indica che il piano di produzione si trova in
modalità non estesa e Exp indica che si trova tale modalità estesa. La modalità del
piano di produzione viene determinata dall’impostazione dell’opzione globale
versione estesa. Con IBM Tivoli Workload Scheduler, Versione 8.2, i database e i
piani sono sempre estesi, ma questa informazione appare per motivi di
compatibilità con le versioni precedenti.
Examples
Il seguente esempio visualizza lo stato del piano di produzione corrente. Quindi
imposta il puntatore del piano di produzione su 2 e visualizza lo stato del piano di
produzione.
%status
TWS per WINDOWS NT/CONMAN 8.2 (1.36.1.7)
Materiale su licenza proprietà di IBM
5698-WKB
(C) Copyright IBM Corp 1998,2001
US Government User Restricted Rights
Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Schedule (Exp) 05/19/03 (#17) on DEMOCPU. Batchman down.
Limit: 30, Fence: 0, Audit Level: 1
Capitolo 5. Riferimento a Conman 209
stop
Arresta i processi di produzione dello scheduler. Per arrestare il processo Netman,
utilizzare il comando shutdown. E’ necessario disporre dell’accesso stop alla
workstation.
Synopsis
stop [domain!]wkstation[;wait][;noask]
Arguments
domain Specifica il nome del dominio in cui vengono arrestate le
workstation. Poiché le workstation hanno nomi univoci, il dominio
non è necessario quando si arresta una workstation specifica. Sono
consentiti caratteri jolly.
Questo argomento è utile quando si arresta più di una workstation
in un dominio. Ad esempio, per arrestare tutti gli agent nel
dominio stlouis, utilizzare il seguente comando:
stop stlouis!@
Se domain viene omesso e wkstation contiene caratteri jolly, il
dominio di default è quello su cui è in esecuzione Conman.
wkstation Specifica il nome della workstation da arrestare. Sono consentiti
caratteri jolly.
wait Specifica di non accettare un altro comando fino a quando non
sono stati arrestati tutti i processi.
noask Specifica di non eseguire il prompt di conferma prima di avviare
l’operazione di ogni workstation di qualificazione.
Usage Notes
Se il comando stop non può essere applicato ad una workstation distante (ad
esempio, se il percorso TCP/IP non è disponibile), il comando viene memorizzato
localmente in un file pobox e inviato alla workstation dopo il collegamento.
Presumendo che l’utente disponga dell’accesso stop alle workstation arrestate, si
applicano le seguenti regole:
v Un utente che esegue Conman sul gestore dominio master può arrestare
qualsiasi workstation nella rete.
v Un utente che esegue Conman su un gestore dominio diverso dal master può
arrestare qualsiasi workstation in quel dominio e nei domini subordinati.
L’utente non può arrestare le workstation in domini peer.
v Un utente che esegue Conman su un agent può arrestare qualsiasi workstation
nel dominio locale.
Quando si emette un comando stop @ su un gestore dominio, sulle CPU remote
viene eseguito il comando conman stop locale. Il comando avvia l’esecuzione sulle
stazioni che si trovano nella parte inferiore della gerarchia della rete e viene
eseguito sul gestore dominio. Tuttavia, i file symphony non vengono aggiornati
prima che le CPU diventino inattive. Quindi, se si emette un comandoconman
sc@!@ da qualsiasi CPU, le informazioni che ne derivano potrebbero essere un
quadro accurato degli stati delle CPU, anche del gestore dominio.
210 IBM Tivoli Workload Scheduler - Manuale di riferimento
Examples
L’illustrazione e la tabella sottostante visualizzano le workstation arrestate da
diversi comandi stop eseguiti dagli utenti in diverse ubicazioni nella rete.
DMn sono gestori dominio e Ann sono agent.
Comando Arrestato da: User1 Arrestato da: User2 Arrestato da: User3
stop @!@ Tutte le workstation
sono state arrestate.
DM2
A21
A22
DM4
A41
A42
DM2
A21
A22
stop @ DM1
A11
A12
DM2
A21
A22
DM2
A21
A22
stop DOMAIN3!@ DM3
A31
A32
Non consentito. Non consentito.
stop DOMAIN4!@ DM4
A41
A42
DM4
A41
A42
Non consentito.
stop DM2 DM2 DM2 DM2
stop A42 A42 A42 Non consentito.
stop A31 A31 Non consentito. Non consentito.
A11 A12
DM1
DM2 DM3
DM4
A21 A22 A31 A32
A41 A42
Dominio1
Dominio2 Dominio3
Dominio4
Utente1
Utente2
Utente3
Figura 5. Workstation arrestate in rete
Capitolo 5. Riferimento a Conman 211
stop ;progressive
Arresta i processi di produzione scheduler gerarchicamente quando è stata definita
almeno una workstation come behindfirewall in una rete IBM Tivoli Workload
Scheduler Versione 8.2. Analogo al comando stop @!@, ma più efficace nel
migliorare le prestazioni dell’esecuzione dei piani. Il comando non viene eseguito
dal dominio in cui è stato inizialmente emesso per ciascun dominio subordinato,
ma viene eseguito in ciascun livello gerarchi co.
E’ necessario disporre dell’accesso stop alla workstation.
Synopsis
stop ;progressive
Usage Notes
Quando si emette il comando su un gestore dominio, tutte le workstation del
dominio vengono arrestate, quindi il dominio stesso viene arrestato e il comando
continua l’esecuzione si tutti i domini subordinati. Il comando continua
l’esecuzione in questo modo gerarchico, il gestore dominio arresta le workstation
dello stesso dominio, si arresta e continua l’esecuzione sui domini subordinati.
Examples
La figura Figura 5 a pagina 211 e la tabella seguente mostrano le workstation
arrestate emettendo il comando stop ;progressive su DM2.
Comando Arrestato da DM2 Arrestato da DM4
stop ;progressive A21
A22
DM2
A41
A42
DM4
212 IBM Tivoli Workload Scheduler - Manuale di riferimento
submit docommand
Inoltra un comando da avviare come lavoro dello scheduler.
E’ necessario disporre dell’accesso submit al lavoro. Per includere le dipendenze
needs e prompt, è necessario disporre dell’accesso use alle risorse e ai prompt
globali.
Synopsis
sbd [wkstation#]″cmd″[;alias[=name]][;into=jobstream]
[;joboption[;...]]
Arguments
wkstation
Specifica il nome della workstation su cui verrà avviato il lavoro. Sono
consentiti i caratteri jolly, in tal caso, il lavoro viene avviato su tutte le
workstation di qualificazione. Il valore di default è la workstation su cui è
in esecuzione Conman. Non è possibile specificare un dominio o una classe
della workstation.
cmd Specifica un comando di sistema valido composto da massimo 255
caratteri. L’intero comando deve essere racchiuso tra apici (″). Il comando
viene considerato come un lavoro e vengono applicate tutte le regole del
lavoro.
alias=name
Specifica un nome univoco da assegnare al lavoro. Se si immette la parola
chiave alias senza specificare un nome, viene creato un nome come
utilizzando le prime lettere alfabetiche(fino a sei) in maiuscolo del
commando, a seconda del numero di caratteri del comando, seguito da un
numero casuale a 10 cifre. Se il comando contiene spazi vuoti, il nome
viene costruito utilizzando i primi sei caratteri alfanumerici prima dello
spazio. Ad esempio, se il comando è ″rm apfile″, il nome generato sarà
simile a RM0123456789. Se il comando contiene più sei caratteri, ad
esempio ″wlsinst″, il nome generato sarà wlsins0396578515.
Se non si include alias la prima volta che si invia il comando, un nome
lavoro viene costruito utilizzando fino a 255 caratteri del nome comando.
Se si invia un comando una seconda volta dalla stessa workstation, la
parola chiave alias è obbligatoria e deve essere univoca per ciascun invio
di comando.
into=jobstream
Specifica il nome del flusso di lavoro in cui verrà posizionato il lavoro per
l’avvio. Immettere il nome come segue:
[wkstation#]jstream Se non si specifica wkstation, il valore di default è la
workstation su cui è in esecuzione Conman. Se non viene utilizzato into, il
lavoro viene aggiunto ad un flusso di lavoro definito JOBS.
joboption
Specificare uno dei seguenti:
at=hhmm [timezone|tz tzname] [+n days | mm/dd/yy] | [absolute | abs]
confirmed
deadline=time [timezone|tz tzname][+n day[s | mm/dd/yy]
every=rate
Capitolo 5. Riferimento a Conman 213
follows=[netagent::][wkstation#]jstream{.job | @} |
job[;nocheck][;wait=time][,...]
interactive
logon=user
needs=[num] [wkstation#]resource[,...]
opens=[wkstation#]″filename″[(qualifier)][,...] priority[=pri | hi | go]
prompt=″[: | !]text″ | promptname[,...]
rccondsucc″Success Condition″
recovery=stop | continue | rerun
after [wkstation#]jobname
abendprompt “text”
until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil
action]
Usage Notes
Se non si specifica workstation con follows, needs o opens, il valore di default è la
workstation del lavoro. Se il lavoro viene eseguito su un agent tollerante l’errore e
si desidera includere una dipendenza prompt o un recoveryprompt, è necessario
che la directory mozart (TWShome/mozart) sul gestore profilo master sia accessibile,
caricata o condivisa.
Examples
Per inoltrare un comando rm nel flusso di lavoro JOBS con una dipendenza
follows, eseguire il comando:
submit docommand="rm apfile";follows sked3
Per inoltrare un comando sort con l’alias sortit e posizionare il lavoro nel flusso di
lavoro reports con un’ora at impostata su 5:30 p.m., eseguire il comando:
sbd "sort < file1 > file2";alias=sortit;into=reports;at=1730
Per inoltrare i comandi chmod su tutte le workstation con nomi che cominciano
con site, eseguire il comando:
sbd site@#"chmod 444 file2";alias
214 IBM Tivoli Workload Scheduler - Manuale di riferimento
submit file
Inoltra un file da avviare come un lavoro dello scheduler.
E’ necessario disporre dell’accesso submit al lavoro. Per includere le dipendenze
needs e prompt, è necessario disporre dell’accesso use alle risorse e ai prompt
globali.
Synopsis
sbf filename[;alias[=name]][;into=jobstream][;joboption[;...]][;noask]
Arguments
filename
Specifica il nome del file, fino a 255 caratteri. Sono consentiti caratteri jolly.
Il nome deve essere racchiuso tra apici (″) se contiene caratteri diversi da
quelli alfanumerici, trattini(-), barre (/), barre retroverse (\) e caratteri di
sottolineatura (_).
alias=name
Specifica un nome univoco da assegnare al lavoro. Se si immette la parola
chiave alias senza specificare un nome, viene creato un nome utilizzando
le prime lettere alfabetiche(fino a sei) in maiuscolo del file, a seconda del
numero di caratteri del file, seguito da un numero casuale a 10 cifre. Ad
esempio, se il nome del file è jclttx5, il nome creato sarà simile a
JCLTTX0123456789.
Se non si include alias, viene creato un nome file utilizzando fino a 255
caratteri alfanumerici del nome di base del file, tutto in maiuscolo.
In entrambi i casi precedenti, se il nome del file non inizia con una lettera,
all’utente verrà richiesto di utilizzare alias= name.
Se si invia un file una seconda volta dalla stessa workstation, la parola
chiave alias è obbligatoria e deve essere univoca per ciascun invio di file.
into=jobstream
Il nome del flusso di lavoro dove verrà posizionato il lavoro per l’avvio.
Immettere il nome come:
[wkstation#]jstream Se non si specifica wkstation, il valore di default è la
workstation su cui è in esecuzione Conman. Se non viene utilizzato into, il
lavoro viene aggiunto ad un flusso di lavoro definito JOBS.
joboption
Specificare uno dei seguenti:
at=hhmm [timezone|tz tzname] [+n days | mm/dd/yy] | [absolute | abs]
confirmed
deadline=time[timezone | tz tzname][+n days | mm/dd/yy]
every=rate
follows=[netagent::][wkstation#]jstream{.job | @} | job[,...]
interactive
logon=user
needs=[num] [wkstation#]resource[,...]
opens=[wkstation#]″filename″[(qualifier)][,...] priority[=pri | hi | go]
prompt=″[: | !]text″ | promptname[,...]
Capitolo 5. Riferimento a Conman 215
rccondsucc″Success Condition″
recovery=stop | continue | rerun
after [wkstation#]jobname
abendprompt “text”
until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil
action]
noask Specifica di non effettuare i prompt di conferma prima di avviare
l’operazione relativa ad ogni file di qualificazione.
Usage Notes
Se non si specifica una workstation con follows, needs o opens, il valore di default
è la workstation su cui è in esecuzione Conman. Se il lavoro viene eseguito su un
agent tollerante l’errore e si desidera includere una dipendenza prompt o un
recoveryprompt, è necessario che la directory mozart (TWShome/mozart) sul
gestore profilo master sia accessibile, caricata o condivisa.
Examples
Per inoltrare un file nel flusso di lavoro jobs (il nome del lavoro è myjcl), eseguire
il comando:
submit file=d:\jobs\lib\daily\myjcl
Per inoltrare un file, con un nome lavoro misjob4, nel flusso di lavoro missked,
eseguire il comando:
sbf /usr/lib/mis/jcl4;alias=misjob4;into=missked ;needs=2 slots
Il lavoro necessita di due unità della risorsa slots.
Per inoltrare tutti i file che hanno nomi che cominciano con back nel flusso di
lavoro bkup, eseguire il comando:
sbf "/usr/lib/backup/back@";into=bkup
216 IBM Tivoli Workload Scheduler - Manuale di riferimento
submit job
Inoltra un lavoro che deve essere avviato dallo scheduler.
E’ necessario disporre dell’accesso submit al lavoro. Per includere le dipendenze
needs e prompt, è necessario disporre dell’accesso use alle risorse e ai prompt
globali.
Per inoltrare un lavoro, è necessario che Conman sia in esecuzione su un gestore
dominio master o che disponga dell’accesso ai database dello scheduler sul gestore
dominio master.
Sintesi
sbj [wkstation#]jobname[;alias[=name]][;into=jobstream]
[;joboption[;...]][;noask]
Argomenti
wkstation
Specifica il nome della workstation su cui verrà avviato il lavoro. Sono
consentiti i caratteri jolly, in tal caso, il lavoro viene avviato su tutte le
workstation di qualificazione. Il valore di default è la workstation su cui è
in esecuzione Conman. Non è possibile specificare un dominio o una classe
della workstation.
jobname
Specifica il nome del lavoro. Sono consentiti caratteri jolly, in tal caso,
vengono inoltrati tutti i lavori di qualificazione. Se il lavoro si trova già nel
piano di produzione e viene inoltrato nello stesso flusso di lavoro, è
necessario utilizzare l’argomento alias per assegnare un nome univoco.
alias=name
Specifica un nome univoco da assegnare al lavoro in sostituzione di
jobname. Se si immette la parola chiave alias senza specificare un nome,
questo viene creato utilizzando i primi due caratteri alfanumerici di
jobname seguiti da un numero casuale a sei cifre. Il nome è sempre in
maiuscolo. Ad esempio, se jobname è jcrttx5, il nome creato sarà simile a
JC123456.
into=jobstream
Specifica il nome del flusso di lavoro in cui verrà posizionato il lavoro per
l’avvio. Immettere il nome come:
[wkstation#]jstream Se non si specifica wkstation, il valore di default è la
workstation su cui è in esecuzione Conman. Se non viene utilizzato into, il
lavoro viene aggiunto ad un flusso di lavoro definito jobs.
joboption
Specificare uno dei seguenti:
at=hhmm [timezone|tz tzname] [+n days | mm/dd/yy] | [absolute | abs]
confirmed
deadline=time[timezone | tz tzname][+n days | mm/dd/yy]
every=rate
follows=[netagent::][wkstation#]jstream{.job | @} |
job[;nocheck][;wait=time][,...]
needs=[num] [wkstation#]resource[,...]
Capitolo 5. Riferimento a Conman 217
opens=[wkstation#]″filename″[(qualifier)][,...] priority[=pri | hi | go]
prompt=″[: | !]text″ | promptname[,...]
rccondsucc″Success Condition″
recovery=stop | continue | rerun
after [wkstation#]jobname
abendprompt “text”
until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil
action]
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione relativa ad ogni lavoro di qualificazione.
Note sull’utilizzo
Se non si specifica una workstation con follows, needs o opens, il valore di default
è la workstation del lavoro. Se il lavoro viene eseguito su un agent tollerante
l’errore e si desidera includere una dipendenza prompt o un recoveryprompt, è
necessario che la directory mozart (TWShome/mozart) sul gestore profilo master sia
accessibile, caricata o condivisa.
Esempi
Per inoltrare i lavori test nel flusso di lavoro JOBS, eseguire il comando:
submit job=test
Per inoltrare un lavoro con l’alias rptx4 e posizionare il lavoro nel flusso di lavoro
reports con un’ora at impostata su 5:30 p.m., eseguire il comando:
sbj rjob4;alias=rptx4;into=reports;at=1730
Per inoltrare il lavoro txjob3 su tutte le workstation con nomi che cominciano con
site, eseguire il comando:
sbj site@#txjob3;alias
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa all’inoltro dei lavori nel manuale Guida per l’utente di IBM Tivoli
Workload Scheduler Job Scheduling Console.
218 IBM Tivoli Workload Scheduler - Manuale di riferimento
submit sched
Inoltra un flusso di lavoro che deve essere avviata dallo scheduler.
E’ necessario disporre dell’accesso submit al flusso di lavoro. Per includere le
dipendenze needs e prompt, è necessario disporre dell’accesso use alle risorse e ai
prompt globali.
Per inoltrare un flusso di lavoro, è necessario che sia in esecuzione Conman sul
gestore dominio master o disporre dell’accesso ai database dello scheduler sul
gestore dominio master.
Sintesi
sbs [wkstation#]jstreamname[;alias[=name]]
[;jstreamoption[;...]][;noask]
Argomenti
wkstation
Specifica il nome della workstation su cui verrà avviato il flusso di lavoro.
Sono consentiti i caratteri jolly, in tal caso, il flusso di lavoro viene avviato
su tutte le workstation di qualificazione. Il valore di default è la
workstation su cui è in esecuzione Conman. Non è possibile specificare un
dominio o una classe della workstation.
jstreamname
Specifica il nome del flusso di lavoro. Sono consentiti caratteri jolly, in tal
caso, vengono inoltrati tutti i flussi di lavoro di qualificazione. Se il flusso
di lavoro si trova già nel piano di produzione, è necessario utilizzare
l’argomento alias per assegnare un nome univoco.
alias=name
Specifica un nome univoco che deve essere assegnato al flusso di lavoro in
sostituzione di jstreamname. Se si immette la parola chiave alias senza
specificare un nome, questo viene creato utilizzando i primi due caratteri
alfanumerici di jstreamname seguiti da un numero casuale a sei cifre. Il
nome è sempre in maiuscolo. Ad esempio, se jstreamname è sttrom, il nome
creato sarà simile a ST123456.
jstreamoption
Immettere uno dei seguenti:
at=hhmm [timezone|tz tzname] [+n days | mm/dd/yy] | [absolute | abs]
carryforward
deadline=time[timezone | tz tzname][+n days | mm/dd/yy]
follows=[netagent::][wkstation#]jstream{.job | @} |
job[;nocheck][;wait=time][,...]
limit=joblimit
needs=[num] [wkstation#]resource[,...]
opens=[wkstation#]″filename″[(qualifier)][,...] priority[=pri | hi | go]
prompt=″[: | !]text″ | promptname[,...]
until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil
action]
noask Specifica di non effettuare il prompt di conferma prima di avviare
l’operazione relativa ad ogni flusso di lavoro di qualificazione.
Capitolo 5. Riferimento a Conman 219
Note sull’utilizzo
Se non si specifica una workstation con follows, needs o opens, il valore di default
è la workstation del flusso di lavoro. Se il flusso di lavoro viene eseguito su un
agent tollerante l’errore e si desidera includere una dipendenza prompt o un
recoveryprompt, è necessario che la directory mozart (TWShome/mozart) sul
gestore profilo master sia accessibile, caricata o condivisa.
Esempi
Per inoltrare il flusso di lavoro adhoc sulla workstation site1 e contrassegnarlo
come un flusso di lavoro carryforward, eseguire il comando:
submit sched=site1#adhoc;carryforward
Per inoltrare il flusso di lavoro fox4 con un limite di lavoro 2, una priorità di 23 e
un’ora until impostata su mezzanotte, eseguire il comando:
sbs fox4;limit=2;pri=23;until=0000
Per inoltrare il flusso di lavoro sched3 su tutte le workstation con nomi che
cominciano con site, eseguire il comando:
sbs site@#sched3
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla pianificazione delle workstation distribuite nel manuale
Guida per l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.
220 IBM Tivoli Workload Scheduler - Manuale di riferimento
switchmgr
Commuta la gestione dominio dal gestore dominio corrente su un gestore dominio
di backup.
E’ necessario disporre dell’accesso start e stop al gestore dominio di backup.
Synopsis
switchmgr domain;newmgr
Arguments
domain Specifica il dominio in cui si desidera commutare i manager.
newmgr Specifica il nome del nuovo gestore dominio. E’ necessario che
questa sia una workstation nello stesso dominio e che venga
definita prima come un agent tollerante l’errore con Risolvi
dipendenze e Stato completo abilitati.
Usage Notes
Il comando arresta una workstation specificata e lo riavvia come gestore dominio.
Tutte le workstation del membro di dominio vengono informate della
commutazione e il gestore dominio precedente viene convertito in un agent
tollerante l’errore nel dominio.
Se l’elaborazione del nuovo giorno (lavoro Jnextday) viene eseguita sul vecchio
gestore dominio, il dominio funzionerà come se fosse stato eseguito un altro
comando switchmgr e il vecchio gestore dominio riprenderà automaticamente le
responsabilità del gestore dominio.
Examples
Per commutare il gestore dominio sulla workstation orca nel dominio masterdm,
eseguire il comando:
switchmgr masterdm,orca
Per commutare il gestore dominio sulla workstation ruby nel dominio bldg2,
eseguire il comando:
switchmgr bldg2,ruby
Capitolo 5. Riferimento a Conman 221
system
Esegue un comando di sistema.
Synopsis
[: | !] sys-command
Arguments
sys-command Specifica qualsiasi comando di sistema valido. Il prefisso (: o !) è
necessario solo quando un nome comando è uguale ad un
comando Conman.
Examples
Per eseguire un comando ps su UNIX, immettere il comando:
ps -ef
Per eseguire un comando dir in Windows, immettere il comando:
dir \bin
222 IBM Tivoli Workload Scheduler - Manuale di riferimento
tellop
Invia un messaggio alla console dello scheduler.
Synopsis
to [text]
Arguments
text Specifica il testo del messaggio. Il messaggio può contenere fino a
900 caratteri.
Usage Notes
Se tellop viene emesso sul gestore dominio master, il messaggio viene inviato a
tutte le workstation collegate. Se viene emesso su un gestore dominio, il messaggio
viene inviato a tutti gli agent collegati nel dominio e i domini subordinati. Se viene
emesso su una workstation diversa da un gestore dominio, il messaggio viene
inviato solo ai relativi gestori domini, se collegato. Il messaggio viene visualizzato
solo se il livello di messaggi della console è maggiore di zero. Consultare “console”
a pagina 155.
Se tellop viene immesso da solo, effettua il prompt per il testo del messaggio. Al
prompt, immettere ogni riga e premere il tasto Invio. Alla fine del messaggio,
immettere due barre (//) o un punto (.)e premere il tasto Invio. E’ possibile
utilizzare la nuova sequenza della riga (\n) per formattare i messaggi.
L’immissione di Control+c in qualunque momento terminerà il comando tellop
senza inviare il messaggio.
Examples
Per inviare un messaggio, eseguire il comando:
tellop TWS will be stopped at\n4:30 for 15 minutes.
Per effettuare un prompt per il testo prima di inviare un messaggio, eseguire il
comando:
to
TELLOP>*********************************
TELLOP>* TWS will be stopped at *
TELLOP>* 4:30 for 15 minutes. *
TELLOP>*********************************
TELLOP>//
Capitolo 5. Riferimento a Conman 223
unlink
Chiude i collegamenti di comunicazione tra le workstation.
E’ necessario disporre dell’accesso unlink alla workstation di destinazione.
Synopsis
unlink [domain!]wkstation[;noask]
Arguments
domain Specifica il nome del dominio in cui vengono chiusi i collegamenti.
È necessario specificare il nome dominio di una workstation nel
dominio master. Sono consentiti caratteri jolly.
Nota: È sempre necessario specificare il nome dominio se si
scollega una workstation non presente nel dominio master.
Questo argomento è utile quando si effettua lo scollegamento di
più di una workstation in un dominio. Ad esempio, per scollegare
tutti gli agent nel dominio stlouis, utilizzare il seguente comando:
link stlouis!@
Se non si specifica domain e wkstation include caratteri jolly, il
dominio di default è quello in cui è in esecuzione Conman.
wkstation Specifica il nome della workstation da scollegare. Sono consentiti
caratteri jolly.
noask Specifica di non eseguire il prompt di conferma prima di avviare
l’operazione di ogni workstation di qualificazione.
Usage Notes
Presumendo che un utente disponga dell’accesso unlink alle workstation
scollegate, vengono applicate le seguenti regole:
v Un utente che esegue Conman sul gestore dominio master può scollegare
qualsiasi workstation nella rete.
v Un utente che esegue Conman su un gestore dominio diverso dal master può
scollegare qualsiasi workstation nel proprio dominio e nei domini subordinati.
L’utente non può scollegare le workstation nei domini peer.
v Un utente che sta eseguendo Conman su un agent può sccollegare qualsiasi
workstation nel proprio dominio locale purché la workstation sia un gestore
dominio o un host. Non è possibile sccollegare un agente peer dello stesso
dominio.
Per informazioni aggiuntive, consultare “link” a pagina 168.
Examples
L’illustrazione e la tabella sottostante visualizzano i collegamenti interrotti dai
comandi unlink eseguiti dagli utenti in varie ubicazioni nella rete.
224 IBM Tivoli Workload Scheduler - Manuale di riferimento
DMn sono gestori dominio e Ann sono agent.
Comando Chiuso da User1 Chiuso da User2 Chiuso da User3
unlink @!@ Tutti i collegamenti
sono chiusi.
DM1-DM2
DM2-A21
DM2-A22
DM2-DM4
DM4-A41
DM4-A42
DM2-A21
unlink @ DM1-A11
DM1-A12
DM1-DM2
DM1-DM3
DM1-DM2
DM2-A21
DM2-A22
DM2-DM4
DM2-A21
unlink DOMAIN3!@ DM3-A31
DM3-A32
Non consentito. Non consentito.
unlink DOMAIN4!@ DM4-A41
DM4-A42
DM4-A41
DM4-A42
Non consentito.
unlink DM2 DM1-DM2 Non applicabile. DM2-A21
unlink A42 DM4-A42 DM4-A42 Non consentito.
unlink A31 DM3-A31 Non consentito. Non consentito.
A11 A12
DM1
DM2 DM3
DM4
A21 A22 A31 A32
A41 A42
Dominio1
Dominio2 Dominio3
Dominio4
Utente1
Utente2
Utente3
Figura 6. Workstation di rete non collegate
Capitolo 5. Riferimento a Conman 225
version
Visualizza il banner del programma Conman.
Synopsis
version
Examples
Per visualizzare il banner del programma Conman, eseguire il comando:
%version
MAESTRO for UNIX (HPUX)/CONMAN 6.0 (3.34) (C) Tivoli Systems 1998
Schedule 5/16/98 (#7) on SFO. Batchman down. Limit: 6, Fence: 0
226 IBM Tivoli Workload Scheduler - Manuale di riferimento
Capitolo 6. Comandi di utilità
Questo capitolo descrive i comandi di utilità IBM Tivoli Workload Scheduler.
Questi comandi sono tool che consentono di gestire lo scheduler. I comandi, ad
eccezione dei comandi StartUp e version, sono installati nella directory
TWShome/bin. StartUp è installato nella directory TWShome e version è installato
nella directory TWShome/version.
Descrizioni comandi
Comando Descrizione
at Solo per UNIX. Inoltra un lavoro da eseguire a un’ora specifica.
batch Solo per UNIX. Inoltra un lavoro da eseguire appena possibile.
caxtract Estrae informazioni sui calendari.
cpuinfo Restituisce le informazioni da una definizione di workstation.
datecalc Converte la data e l’ora in un formato desiderato
dbexpand Espande i database dello scheduler.
delete Rimuove i file script e i file di elenco standard in base al nome.
evtsize Definisce la dimensione massima dei file messaggio di evento.
jbxtract Estrae informazioni sui lavori.
jobinfo Restituisce le informazioni su un lavoro.
jobstdl Restituisce i nomi del percorso dei file di elenco standard.
listproc Solo per Windows. Elenca le elaborazioni. Questo comando non è
supportato.
killproc Solo per Windows. Interrompe i processi. Questo comando non è
supportato.
maestro Restituisce la directory home dello scheduler.
makecal Crea calendari personalizzati.
metronome.pl Esegue un’istantanea di IBM Tivoli Workload Scheduler e genera un
report html per facilitare la risoluzione dei problemi.
morestdl Visualizza il contenuto dei file di elenco standard.
parms Visualizza, modifica e aggiunge i parametri.
paxtract Estrae informazioni sui parametri.
prxtract Estrae informazioni sui prompt.
r11xtr Estrae le informazioni sui flussi di lavoro.
release Rilascia le unità di una risorsa.
rextract Estrae informazioni sulle risorse.
rmstdlist Rimuove i file di elenco standard in base all’età.
showexec Solo per UNIX. Visualizza le informazioni sull’esecuzione dei lavori.
StartUp Avvia il processo Netman.
version Solo per UNIX. Visualizza le informazioni sulla versione.
xrxtrct Estrae le informazioni sui riferimenti incrociati.
wmaeutil Estrae le informazioni sui riferimenti incrociati.
© Copyright IBM Corp. 1999, 2004 227
Comandi at e batch
Solo per UNIX. Inoltra i comandi ad hoc e i lavori da avviare tramite IBM Tivoli
Workload Scheduler.
Consultare at.allow e at.deny per informazioni sulla disponibilità agli utenti.
Synopsis
at -v | -u
at -sjstream | -qqueuetime-spec
batch -v | -u
batch [-s jstream]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-s jstream
Specifica il nome di un flusso di lavoro a cui viene inoltrato un lavoro. Se
il flusso di lavoro non esiste, viene creato. Il nome deve cominciare con
una lettera e può contenere caratteri alfanumerici e trattini. Può contenere
fino a 16 caratteri.
Se vengono omessi gli argomenti -s e -q, un nome del flusso di lavoro
viene selezionato in base al valore della variabile d’ambiente ATSCRIPT. Se
ATSCRIPT contiene la parola maestro, il nome del flusso di lavoro sarà
costituito dai primi otto caratteri del nome gruppo utente. Se ATSCRIPT
non è impostato oppure è impostato su un valore diverso da maestro, il
nome del flusso di lavoro sarà at (per lavori inoltrati con at) o batch (per i
lavori inoltrati con 4batch).
Per ulteriori informazioni sui flussi di lavoro, consultare “Altre
considerazioni” a pagina 231.
-qqueue
Specifica di inoltrare il lavoro in un flusso di lavoro con il nome queue, che
può essere una lettera singola (a-z). Per ulteriori informazioni sui flussi di
lavoro, consultare “Altre considerazioni” a pagina 231.
time-spec
Specifica l’ora in cui verrà avviato il lavoro. Solo per i lavori at. La sintassi
è come quella utilizzata con il comando at di UNIX.
Usage Notes
Dopo aver immesso at o batch, immettere i comandi che costituiscono il lavoro.
Chiudere ogni riga di input premendo il tasto Restituisci. L’intera sequenza viene
chiusa con una fine del file (in genere con Control+d) oppure immettendo un
punto nella riga (.). In alternativa, utilizzare i segni di maggiore o minore (<) per
leggere i comandi da un file. Consultare “Examples” a pagina 231.
Le informazioni sui lavori at e batch vengono inviate all’MDM, dove vengono
aggiunti i lavori ai flussi di lavoro nel piano di produzione, Symphony. I lavori
vengono avviati in base alle dipendenze incluse ai flussi di lavoro.
Capitolo 6. Comandi di utilità 229
La shell UNIX utilizzata per i lavori inoltrati con i comandi IBM Tivoli Workload
Scheduler at e batch viene determinata dalla variabile SHELL_TYPE nello script di
configurazione jobmanrc. Non utilizzare la shell C. Per ulteriori informazioni,
consultare Manuale per la pianificazione e installazione di IBM Tivoli Workload
Scheduler.
Una volta inoltrati, i lavori vengono avviati nello stesso modo in cui vengono
pianificati gli altri lavori. Ogni lavoro viene eseguito nell’ambiente utente di
inoltro. Per verificare che l’ambiente sia completo, i comandi set vengono inseriti
nello script in modo da essere messi in corrispondenza con le impostazioni della
variabile nell’ambiente dell’utente.
Sostituzione dei comandi UNIX: I comandi at e batch UNIX standard possono
essere sostituiti dai comandi dello scheduler. I seguenti comandi illustrano il modo
in cui sostituire i comandi at e batch UNIX:
$ mv /usr/bin/at /usr/bin/uat
$ mv /usr/bin/batch /usr/bin/ubatch
$ ln -s TWShome/bin/at /usr/bin/at
$ ln -s TWShome/bin/batch /usr/bin/batch
Solo sulle piattaforme di secondo livello, quando si installa lo scheduler tramite lo
script customize, vengono creati per default i seguenti collegamenti:
/usr/bin/mat —>TWShome/bin/at
/usr/bin/mbatch —> TWShome/bin/batch
Perciò è possibile eseguire i comandi nel modo riportato di seguito:
/usr/bin/mat
/usr/bin/mbatch
File at.allow e at.deny: I comandi at e batch utilizzano i file /usr/lib/cron/at.allow
e usr/lib/cron/at.deny per limitarne l’utilizzo. Se il file at.allow esiste, solo gli
utenti elencati nel file possono utilizzare at e batch. Se il file non esiste, viene
verificato at.deny per controllare che all’utente venga negata esplicitamente
l’autorizzazione. Se non esiste alcun file, solo l’utente root può utilizzare il
comando. Sulle piattaforme di secondo livello, se i comandi vengono eseguiti come
mat e mbatch, at.allow e at.deny vengono ignorati e non si applica alcuna
restrizione.
File script: I comandi immessi con at o batch vengono memorizzati nei file script.
Il file viene creato dallo scheduler utilizzando la seguente convenzione di
denominazione:
TWShome/atjobs/epoch.sss
dove:
epoch Il numero di secondi dal 00:00, 1/1/70.
sss I primi tre caratteri del nome del flusso di lavoro.
Nota: Lo scheduler rimuove i file script per i lavori non inoltrati. Tuttavia, Tivoli
consiglia di monitorare lo spazio su disco nella directory atjobs e di
rimuovere i file precedenti, se necessario.
Nomi lavoro: Nel momento in cui vengono inoltrati, a tutti i lavori at e batch
vengono forniti nomi univoci dallo scheduler. I nomi sono costituiti da un PID
230 IBM Tivoli Workload Scheduler - Manuale di riferimento
(Process ID) dell’utente, preceduti dal nome utente troncato, in modo da non
superare gli otto caratteri. Il nome risulterà in maiuscolo.
Altre considerazioni: Tivoli consiglia di creare per primi, con il Composer, i flussi
di lavoro in cui vengono inoltrati i lavori at e batch. I flussi di lavoro possono
contenere dipendenze che determinano il momento in cui verranno avviati i lavori.
I flussi di lavoro devono contenere almeno la parola chiave carryforward. In
questo modo i lavori non completi o non avviati nel giorno corrente verranno
proseguiti il giorno di produzione successivo. Alcuni altri suggerimenti relativi ai
flussi di lavoro at e batch:
v Includere l’espressione tutti i giorni in modo che i flussi di lavoro vengano
selezionati ogni giorno.
v Utilizzare la parola chiave limit per limitare il numero dei lavori inoltrati che
possono essere eseguiti contemporaneamente.
v Utilizzare la parola chiave priority per impostare la priorità dei lavori inoltrati
relativi agli altri lavori.
Se il valore dell’ora è minore dell’ora corrente viene considerato per il giorno
successivo. Se il valore dell’ora è maggiore dell’ora corrente viene considerato per
il giorno corrente. Se il valore dell’ora è maggiore di 2400, viene diviso per 2400
per ottenere il numero di giorni. Se si specifica il valore in giorni, questo viene
aggiunto al valore ottenuto dividendolo per 2400.
Examples
Per inoltrare un lavoro in un flusso di lavoro sched8 da avviare quanto prima,
eseguire il comando:
batch -s sched8
command <Return>
...
<Control d>
Per inoltrare un lavoro in un flusso di lavoro k da avviare alle 9:45 p.m., eseguire
il comando:
at -qk 21h45
command <Return>
...
<Control d>
Per inoltrare un lavoro da avviare due ore dopo l’immissione del comando,
eseguire il comando:
at now + 2 hours
command <Return>
...
<Control d>
Se la variabile ATSCRIPT è null, il lavoro viene inoltrato in un flusso di lavoro con
il nome uguale a quello del gruppo utente. Altrimenti, viene inoltrata al flusso di
lavoro denominato at.
Per inoltrare un lavoro in un flusso di lavoro sked-mis da avviare alle 5:30 p.m.,
eseguire il comando:
at -s sked-mis 17h30
command <Return>
...
<Control d>
Capitolo 6. Comandi di utilità 231
Il seguente comando è uguale a quello precedente, l’unica differenza sta nel fatto
che i comandi del lavoro vengono letti da un file:
at -s sked-mis 17h30 < ./myjob
Il fatto che i comandi vengano letti da un file non modifica il modo in cui vengono
elaborati. Cioè, i comandi vengono copiati dal file ./myjob in un file script.
232 IBM Tivoli Workload Scheduler - Manuale di riferimento
caxtract
Estrae informazioni sui calendari dal database dello scheduler.
Synopsis
caxtract [-v | -u] [-o file]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-o file Specifica il file di output. Il valore di default è stdout.
Command Output
Ogni record del calendario contiene campi a lunghezza variabile, delimitati dal
separatore. I campi vengono descritti nella tabella seguente.
Campo Descrizione
Lunghezza
massima (byte)
1 Nome calendario 8
2 descrizione calendario 64
Examples
Per estrarre tutte le informazioni sulle definizioni del calendario e indirizzarle al
file di output cainfo, eseguire il comando:
caxtract -o cainfo
Capitolo 6. Comandi di utilità 233
cpuinfo
Restituisce le informazioni da una definizione di workstation.
Synopsis
cpuinfo -v | -u
cpuinfo wkstation [infotype] [...]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
wkstation
Il nome della workstation.
infotype
Il tipo di informazioni da visualizzare. Specificare uno o più dei seguenti:
os_type
Restituisce il calore del campo os: UNIX, WNT e OTHER.
node Restituisce il valore del campo node.
port Restituisce il valore del campo porta.
autolink
Restituisce il valore del campo autolink: ON oppure OFF.
fullstatus
Restituisce il valore del campo fullstatus: ON oppure OFF.
resolvedep
Restituisce il valore del campo resolvedep: ON oppure OFF.
host Restituisce il valore del campo host.
method
Restituisce il valore del campo accesso.
server Restituisce il valore del campo server.
type Restituisce il tipo di workstation: MASTER, MANAGER, FTA,
S-AGENT e X-AGENT.
time_zone
Restituisce il fuso orario della workstation. Per un XA, il campo è
vuoto.
versione
Restituisce la versione dello scheduler in esecuzione sulla
workstation. Per un XA, il campo è vuoto.
info Restituisce la versione del sistema operativo e il modello della
workstation. Per un XA, il campo è vuoto.
Usage Notes
Vengono restituiti i valori, separati da nuove righe, nello stesso ordine in cui gli
argomenti erano stati immessi sulla riga comandi. Se non vengono specificati
argomenti, tutte le informazioni applicabili possono essere restituite con etichette
separate da nuove righe.
234 IBM Tivoli Workload Scheduler - Manuale di riferimento
Examples
Gli esempi riportati di seguito si basano sulla seguente definizione di workstation:
cpuname oak
os UNIX
node oak.tivoli.com
tcpaddr 31111
for maestro
autolink on
fullstatus on
resolvedep on
end
Per stampare il tipo di os per la workstation oak, eseguire il comando:
>cpuinfo oak os_type
UNIX
Per stampare node e port per la workstation oak, eseguire il comando:
>cpuinfo oak node port
oak.tivoli.com
31111
Per stampare tutte le informazioni per la workstation oak, eseguire il comando:
>cpuinfo oak
OS TYPE:UNIX
NODE:oak.tivoli.com
PORT:31111
AUTOLINK:ON
FULLSTATUS:ON
RESOLVEDEP:ON
HOST:
METHOD:
SERVER:
TYPE: FTA
TIME ZONE:US/Pacif
VERSION:6.1
INFO:SunOS 5.3 Generic 1016 sun4m
Capitolo 6. Comandi di utilità 235
datecalc
Risolve le espressioni della data e restituisce le date nei formati desiderati.
Synopsis
datecalc -v | -u
datecalc base-date [offset] [pic format][freedays Calendar_Name [-sa] [-su]]
datecalc -t time [base-date] [offset] [pic format]
datecalc yyyymmddhhtt [offset] [pic format]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
base-date
Specificare uno dei seguenti:
day | date | today | tomorrow | scheddate
dove:
day Specifica un giorno della settimana. Valori validi sono: su, mo, tu,
we, th, fr o sa.
date Specifica una data, nel formato element/element[/element], dove
element è: g[g], m[m] e aa[aa].
Se vengono utilizzate due cifre per l’anno (yy), un numero
maggiore di 70 è una data relativa al ventesimo secolo e un
numero inferiore a 70 è la data relativa al ventunesimo secolo.
Valori validi per il mese (m[m]) sono jan, feb, mar, apr, may, jun,
jul, aug, sep, oct, nov o dec.
Le barre (/) possono essere sostituite da trattini(-), punti (.), virgole
(,) o spazi. Ad esempio, per il 28 marzo 1999 è possibile immettere:
03/28/99
3-28-1999
28.mar.99
99,28,3
mar 28 1999
28 3 99
Se vengono utilizzati numeri, è possibile immettere una data
ambigua, ad esempio 2,7,98. In questo caso, datecalc utilizza il
formato data definito nel catalogo messaggi dello scheduler per
interpretare la data. Se la data non corrisponde al formato, datecalc
crea un messaggio di errore.
today Specifica la data corrente del sistema.
tomorrow
Specifica la data corrente del sistema più un giorno oppure, in caso
di calcoli di tempo, più 24 ore.
scheddate
Specifica la data del piano di produzione. Potrebbe non essere
236 IBM Tivoli Workload Scheduler - Manuale di riferimento
uguale alla data del sistema. Quando utilizzato all’interno di lavori
che rientrano in un flusso di lavoro non proseguito, restituisce la
data in cui deve essere eseguito il lavoro. Tale data può essere
diversa dalla data di produzione del flusso di lavoro se per il
lavoro è specificata una dipendenza AT. Quando utilizzato
all’interno di lavori che rientrano in un flusso di lavoro proseguito,
restituisce la data in cui deve essere eseguito il lavoro. Tale data
può essere diversa dalla data di produzione del flusso di lavoro
proseguito se per il lavoro è specificata una dipendenza AT. Se la
dipendenza AT viene utilizzata con la seguente sintassi: at=hhmm +
n days, n days non vengono aggiunti alla variabile
TIVOLI_JOB_DATE, pertanto il comando datecalc non crea report
per quei giorni.
-t time [base-date]
Specificare time in uno dei formati seguenti:
now | noon | midnight | [h[h][[:]mm] [am | pm] [zulu]
dove:
now Specifica la data e l’ora correnti del sistema.
noon Specifica 12:00 P.M. (o 1200).
midnight
Specifica 12:00 A.M. (o 0000).
h[h][[:]mm]
Specifica l’ora e i minuti in un formato ora di 12 ore (se vengono
utilizzati am o pm) o un formato ora di 24 ore. Il delimitatore
facoltativo (:) può essere sostituito da un punto (.), una virgola (,),
un apostrofo (’), dalla lettera h o da uno spazio. Ad esempio, per le
8:00 PM è possibile immettere:
8:00pm
20:00
0800pm
2000
8pm
20
8,00pm
20.00
8\’00pm
20 00
zulu Specifica che l’ora immessa è quella Greenwich Mean Time
(Universal Coordinated Time). datecalc la convertirà nell’ora locale.
yyyymmddhhtt
Specifica l’anno, il mese, il giorno, l’ora e i minuti espressi esattamente in
dodici cifre. Ad esempio, per 1999, 7 maggio, 9:15 a.m., immettere:
199905070915
offset Specifica uno scostamento da base-date nel seguente formato:
{[+ | > | - | < number | nearest] | next} day[s] | weekday[s] |
workday[s] | week[s] | month[s] | year[s] | hour[s] | minute[s] |
day | calendar
dove:
Capitolo 6. Comandi di utilità 237
+ | > Specifica uno scostamento in una data o un’ora successive.
Utilizzare + (Più) su Windows. Utilizzare > (Maggiore di) su UNIX.
Verificare che vi sia un carattere escape davanti al segno Maggiore
di (″\>″).
- | < Specifica uno scostamento in una data o un’ora precedenti.
Utilizzare - (Meno) su Windows. Utilizzare < (Minore di) su UNIX.
Verificare che vi sia un carattere escape davanti al segno Maggiore
di (″\<″).
number
Il numero di unità del tipo specificato.
nearest
Specifica uno scostamento alla ricorrenza più vicina del tipo di
unità (precedente o successiva).
next Specifica la ricorrenza successiva del tipo di unità.
day[s] Specifica tutti i giorni.
weekday[s]
Specifica tutti i giorni tranne il sabato e la domenica.
workday[s]
Come weekday[s], ma esclude anche le date sul calendario
holidays.
week[s]
Specifica sette giorni.
month[s]
Specifica i mesi del calendario.
year[s]
Specifica gli anni del calendario.
hour[s]
Specifica le ore.
minute[s]
Specifica i minuti.
day Specifica un giorno della settimana. Valori validi sono: su, mo, tu,
we, th, fr o sa.
calendar
Specifica le voci in un calendario con questo nome.
pic format
Specifica il formato in cui vengono restituite la data e l’ora. I caratteri
format sono i seguenti:
m Numero del mese.
d Numero del giorno.
y Numero dell’anno.
j Numero del giorno del calendario Giuliano.
h Numero di ore.
t Numero minuti.
238 IBM Tivoli Workload Scheduler - Manuale di riferimento
^|/ Uno spazio. Utilizzare ^ su UNIX questo carattere deve essere
preceduto da un carattere escape (\) nella shell Bourne). Utilizzare
/ (Barra) su Windows.
Inoltre è possibile includere i caratteri di punteggiatura. Sono uguali ai
delimitatori utilizzati nella data e nell’ora.
Se non viene definito un formato, datecalc restituisce la data e l’ora nel
formato definito dalle variabili d’ambiente NLS (Native Language
Support). Se le variabili NLS non sono definite, il linguaggio di origine
viene impostato per default su C.
freedays
Specifica il nome del calendario dei giorni liberi Calendar_Name che serve a
sostituire vacanze nella valutazione dei giorni lavorativi.
In questo caso, giorni lavorativi viene valutato come tutti i giorni, esclusi il
sabato, la domenica e tutte le date elencate in Calendar_Name.
Per default, sabato e domenica non sono considerati giorni lavorativi, a meno
che non si verifichi esplicitamente l’opposto -sa e/o -su
dopoCalendar_Name.
E’ possibile inoltre specificareholidays come nome per il calendario dei
giorni liberi.
Examples
Per restituire la data successiva, da oggi sul calendario monthend, eseguire il
comando:
>datecalc today next monthend
Negli esempi seguenti, da data di sistema corrente è Venerdì, 9 aprile 1999.
>datecalc today +2 days pic mm/dd/yy
04/11/99
>datecalc today next tu pic yy\^mm\^dd
99 04 13
>LANG=american;export LANG
>datecalc -t 14:30 tomorrow
Sat, Apr 10, 1999 02:30:00 PM
>LANG=french;datecalc -t 14:30 tomorrow
Samedi 10 avril 1999 14:30:00
Nell’esempio seguente, l’ora del sistema corrente è 10:24.
>datecalc -t now \> 4 hours pic hh:tt
14:24
Capitolo 6. Comandi di utilità 239
dbexpand
Converte i database sull’MDM da una modalità non espansa a una modalità
espansa. Il comando imposta l’opzione globale versione espansa su sì e crea copie
di backup dei vecchi file di database che possono essere utilizzate per ritornare, se
necessario, alla modalità non espansa.
Se si aggiorna la rete gradualmente e se tale rete contiene workstation su cui è in
esecuzione Tivoli Maestro Versione 5.x o versione precedente, è necessario
utilizzare database non espansi fino a che tutti i computer non siano stati
aggiornati con Tivoli Maestro 6.x o IBM Tivoli Workload Scheduler. Una volta
aggiornati tutti i computer, eseguire dbexpand sull’MDM per convertire i database
alla modalità estesa.
Synopsis
dbexpand -v | -u
dbexpand -n [-b backup-dir ]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-n
Specifica di non richiedere un nome directory di backup. Se è incluso -b, la
directory denominata viene utilizzata come backup. Se non è inclusa
l’opzione -b, viene utilizzata la directory di default. In entrambi i casi, se la
directory esiste, viene sostituita.
-b backup-dir
Specifica una directory in cui effettuare il backup dei file di database. La
directory di default è:
TWShome/mozart/mozart.old
Se si omette -n e se la directory di backup esiste già, è necessario
immettere un nome directory di backup.
Usage Notes
E’ possibile eseguire il comando dbexpand senza arrestare lo scheduler. Tuttavia, è
impossibile inoltrare i lavori o i flussi di lavoro al piano di produzione corrente
fino alla volta successiva in cui si verifica il turnover. Per questo motivo, Tivoli
consiglia di eseguire dbexpand subito dopo l’esecuzione del lavoro Jnextday.
Examples
Per espandere i database ed effettuare il backup dei file correnti nella directory
/usr/lib/maestro/temp, eseguire il comando:
dbexpand -n -b /usr/lib/maestro/temp
Se la directory esiste già, il contenuto verrà sovrascritto.
Per espandere i database ed effettuare il backup dei file correnti nella directory
c:\programs\wsched\temp, eseguire il comando:
dbexpand -b c:\programs\wsched\temp
Viene visualizzato un prompt se la directory esiste già.
240 IBM Tivoli Workload Scheduler - Manuale di riferimento
delete
Rimuove i file. Questo comando è destinato a rimuovere i file di elenco standard.
Gli utenti maestro e root su UNIX e Administrator su Windows possono
rimuovere tutti i file. Gli altri utenti possono rimuovere tutti i file associati a lavori
propri.
Synopsis
delete -v | -u
delete filename
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
filename
Specifica il nome del file o gruppo di file da rimuovere. Il nome deve
essere racchiuso tra apici (″) se contiene caratteri diversi dai seguenti:
alfanumerici, trattini (-), barre (/), barre retroverse (\) e caratteri di
sottolineatura (_). Sono consentiti caratteri jolly.
Avvertenza:
Utilizzare questo comando con attenzione. Un utilizzo improprio dei caratteri
jolly può provocare una rimozione accidentale dei file.
Examples
Per rimuovere tutti i file di elenco standard per il 4/11/04, eseguire il comando:
delete d:\win32app\maestro\stdlist\2004.4.11\@
Lo script seguente, incluso in un lavoro pianificato su UNIX, rimuove il file di
elenco standard del lavoro se non vi sono errori:
...
#Remove the stdlist for this job:
if grep -i error $UNISON_STDLIST
then
exit 1
else
`maestro`/bin/delete $UNISON_STDLIST
fi
...
Tenere presente che lo script di configurazione standard, jobmanrc, imposta la
variabile UNISON_STDLIST sul nome del file di elenco standard del lavoro. Per
ulteriori informazioni su jobmanrc, consultare Manuale per la pianificazione e
installazione di IBM Tivoli Workload Scheduler.
Capitolo 6. Comandi di utilità 241
evtsize
Definisce la dimensione dei file di evento dello scheduler. Questo comando viene
utilizzato per accrescere la dimensione di un file di evento dopo la ricezione del
messaggio, “Fine del file sul file degli eventi.” E’ necessario maestro o root su
UNIX o Administrator su Windows per eseguire evtsize. Assicurarsi di arrestare il
motore IBM Tivoli Workload Scheduler prima di eseguire questo comando.
Synopsis
evtsize -v | -u
evtsize filename size
evtsize -show filename
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-show filename
Interroga la lunghezza della coda corrente del file specificato.
filename
Il nome del file di evento. Specificare uno dei seguenti:
Courier.msg
Intercom.msg
Mailbox.msg
pobox/wkstation.msg
size La dimensione massima del file file di evento in byte. Se viene creato
prima dallo scheduler, la dimensione massima è impostata su 10 MB.
Examples
Per impostare la dimensione del file Intercom su 20 MB, eseguire il comando:
evtsize Intercom.msg 20000000
Per impostare la dimensione massima del file pobox per la workstation chicago su
15 MB, eseguire il comando:
evtsize pobox\chicago.msg 15000000
Il seguente comando:
evtsize -show Intercom.msg
restituisce i seguente output:
TWS for Windows NT/EVTSIZE 8.2 (1.2.2.2)
Materiale su licenza proprietà di IBM
5698-WKB
(C) Copyright IBM Corp 1998,2001
US Government User Restricted Rights
Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
AWS11140703 Queue size current 880, maximum 10000000 bytes
(read 48, write 928)
dove:
880 È la dimensione della coda corrente del file Intercom.msg
242 IBM Tivoli Workload Scheduler - Manuale di riferimento
10000000
È la dimensione massima del file Intercom.msg
read 48
È la posizione del puntatore per la lettura dei record
write 928
È la posizione del puntatore per la scrittura dei record
Capitolo 6. Comandi di utilità 243
jbxtract
Estrarre le informazioni sui lavori dal database dello scheduler.
Synopsis
jbxtract [-v | -u] [-j job] [-c wkstat] [-o file]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-j job Specifica il lavoro per cui viene eseguita l’estrazione. Il valore di default è
Tutti i lavori.
-c wkstat
Specifica la workstation dei lavori per cui viene eseguita l’estrazione. Il
valore di default è di tutte le workstation.
-o file Specifica il file di output. Il valore di default è stdout.
Command Output
La variabile MAESTRO_OUTPUT_STYLE specifica lo stile dell’output per nomi di
oggetti estesi. Impostare la variabile su LONG per utilizzare campi a lunghezza
completa (lunghi) per i nomi degli oggetti. Se la variabile non è impostata o è
impostata su un valore diverso da LONG, i nomi lunghi vengono troncati ai primi
otto caratteri e un segno +. Ad esempio: A1234567+.
Ogni record del lavoro contiene campi a lunghezza variabile, delimitati dal
separatore. I campi vengono descritti nella tabella seguente.
Campo Descrizione
Lunghezza
massima (byte)
1 nome workstation 16
2 nome lavoro 16
3 nome file script lavoro 4096
4 descrizione lavoro 65
5 nome lavoro ripristino 16
6 opzione ripristino (0=stop, 1=rerun, 2=continue) 5
7 testo prompt ripristino 64
8 indicatore di auto documentazione (0=disabilitato,
1=abilitato)
5
9 nome utente login lavoro 36
10 nome utente amministratore lavoro 36
11 numero di esecuzioni riuscite 5
12 numero di esecuzioni terminate in modo anomalo 5
13 tempo totale trascorso di tutte le esecuzioni del lavoro 8
14 tempo totale della cpu di tutte le esecuzioni del lavoro 8
15 media del tempo trascorso 8
16 data ultima esecuzione (yymmdd) 8
17 ora ultima esecuzione (yymmdd) 8
18 secondi impiegati dalla cpu 8
244 IBM Tivoli Workload Scheduler - Manuale di riferimento
Campo Descrizione
Lunghezza
massima (byte)
19 tempo trascorso 8
20 num. max. di secondi impiegati dalla cpu 8
21 tempo massimo trascorso 8
22 data di esecuzione massima (yymmdd) 8
23 num. min. secondi impiegati dalla cpu 8
24 tempo minimo trascorso 8
25 data di esecuzione minima (yymmdd) 8
Examples
Per estrarre le informazioni su un lavoro myjob sulla workstation principale e
indirizzare l’output al file jinfo, eseguire il comando:
jbxtract -j myjob -c main -o jinfo
Capitolo 6. Comandi di utilità 245
jobinfo
Utilizzato nello script del lavoro per rieseguire le informazioni sul lavoro.
Synopsis
jobinfo -v | -u
jobinfo job-option [...]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
job-option
L’opzione lavoro. Specificare uno o più dei seguenti:
confirm_job
Restituisce YES se il lavoro richiede una conferma.
is_command
Restituisce SI se il lavoro viene pianificato o inoltrato utilizzando il
costrutto docommand.
job_name
Restituisce il nome del lavoro senza i nomi della workstation e del
flusso di lavoro.
job_pri
Restituisce il livello di priorità del lavoro.
programmatic_job
Restituisce YES se il lavoro viene inoltrato con il comando
scheduler at o batch. Solo per UNIX.
re_job Restituisce SI se il lavoro viene rieseguito come risultato di un
comando rerun Conman o per rieseguire l’opzione di ripristino.
re_type
Restituisce l’opzione di ripristino di un lavoro (arresta, continua o
riesegui).
rstrt_flag
Restituisce YES se il lavoro viene eseguito come lavoro di
ripristino.
rstrt_retcode
Se il lavoro corrente è un lavoro di ripristino, restituisce il codice di
ritorno del lavoro parent.
time_started
Restituisce l’ora di avvio dell’esecuzione di un lavoro.
Usage Notes
I valori delle opzioni di un lavoro vengono restituiti, separati da nuove righe, nello
stesso ordine in cui vengono richiesti.
246 IBM Tivoli Workload Scheduler - Manuale di riferimento
Examples
1. Il file script /jcl/backup è documentato due volte, assegnandolo ai nomi lavoro
partback e fullback. Se il lavoro viene eseguito come partback, esso esegue un
backup parziale. Se viene eseguito come fullback, esegue un backup completo.
Nello script, i comandi come quello riportato di seguito vengono utilizzati per
stabilire:
#Determine partial (1) or full (2):
if [ "`\`maestro\`/bin/jobinfo job_name`" = "PARTBACK" ]
then
bkup=1
else
bkup=2
fi
...
2. Per visualizzare il codice di ritorno del lavoro parent, se il lavoro corrente è un
lavoro di recupero, eseguire il comando:
$ jobinfo rstrt_retcode
Il primo lavoro (parent) è stato definito nello script recovery.sh, mentre il
secondo lavoro (di recupero) viene abilitato solo se il primo termina in modo
anomalo.
Se combinato con una condizione del codice di ritorno, jobinfo rstrt_retcode
può essere utilizzato per indirizzare il lavoro di recupero ed eseguire
operazioni differenti a seconda del codice di ritorno del lavoro principale. Di
seguito è riportato un esempio del lavoro di recupero:
$JOBS
MASTER#DBSELOAD DOCOMMAND "/usr/local/tws/maestro/scripts/populate.sh"
STREAMLOGON "^TWSUSER^"
DESCRIPTION "populate database manual"
RECOVERY RERUN AFTER MASTER#RECOVERY
RCCONDSUCC "(RC = 0) OR ((RC > 4) AND (RC < 11))"
Si osservi che il lavoro viene definito con l’azione di recupero RERUN. Ciò
consente al lavoro di recupero di effettuare delle correzioni, prima che il lavoro
parent venga eseguito di nuovo.
Di seguito è riportato un esempio di come viene definito il lavoro di recupero:
$ JOBS
MASTER#RECOVERY DOCOMMAND "^TWSHOME^/scripts/recovery.sh"
STREAMLOGON "^TWSUSER^"
DESCRIPTION "populate database recovery manual"
RECOVERY STOP
Capitolo 6. Comandi di utilità 247
jobstdl
Restituisce i nomi dei file di elenco standard. Questo comando deve essere eseguito
dall’utente per il quale è stato installato IBM Tivoli Workload Scheduler. Se si
utilizza questo comando senza alcun parametro, assicurarsi di essere collegati come
un utente di IBM Tivoli Workload Scheduler.
Synopsis
jobstdl -v | -u
jobstdl [-day num] [-first | -last | -num n | -all]
[-name jstream.job | jobnum]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-day num
Restituisce i nomi dei file di elenco standard che indicano il numero di
giorni precedenti specificato (1 per ieri, 2 per due giorni precedenti, ecc.). Il
valore di default è zero (oggi).
-first Restituisce il nome del primo file qualificativo di elenco standard.
-last Restituisce il nome dell’ultimo file qualificativo di elenco standard.
-num n
Restituisce il nome del file di elenco standard per l’esecuzione specificata
di un lavoro.
-all Restituisce il nome di tutti i file qualificativi di elenco standard.
-name jstream.job
Specifica il nome del flusso di lavoro o del lavoro per cui vengono restituiti
i nomi file di elenco standard.
jobnum
Specifica il numero del lavoro per cui vengono restituiti i nomi file di
elenco standard.
Usage Notes
I nomi file vengono restituiti in un formato adatto all’input per altri comandi. Più
nomi sono separati da uno spazio.
Examples
Per restituire i nomi del percorso di tutti i file di elenco standard per il giorno
corrente, eseguire il comando:
jobstdl
Per restituire il nome del percorso dell’elenco standard per la prima esecuzione del
lavoro mailxhg1.getmail nel giorno corrente, eseguire il comando:
jobstdl -first -name mailxhg1.getmail
Per restituire il nome del percorso dell’elenco standard per la seconda esecuzione
del lavoro mailxhg1.getmail nel giorno corrente, eseguire il comando:
jobstdl -num 2 -name mailxhg1.getmail
Per restituire i nomi del percorso dei file di elenco standard per tutte le esecuzioni
di un lavoro mailxhg1.getmail di tre giorni prima, eseguire il comando:
248 IBM Tivoli Workload Scheduler - Manuale di riferimento
jobstdl -day 3 -name mailxhg1.getmail
Per restituire il nome del percorso dell’elenco standard per l’ultima esecuzione del
lavoro mailxhg1.getmail di quattro giorni prima, eseguire il comando:
jobstdl -day 4 -last -name mailxhg1.getmail
Per restituire il nome del percorso dell’elenco standard per il lavoro numero 455,
eseguire il comando:
jobstdl 455
Per stampare il contenuto del file di elenco standard per il lavoro numero 455,
eseguire il comando:
cd `maestro`/bin
lp -p 6 `jobstdl 455`
Capitolo 6. Comandi di utilità 249
maestro
Restituisce il nome del lavoro della directory home dello scheduler, a cui ci si
riferisce come TWShome.
Synopsis
maestro [-v | -u]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
Examples
Per visualizzare la directory home dello scheduler, eseguire il comando:
$ maestro
/usr/lib/maestro
Per modificare la directory nella directory home dello scheduler, eseguire il
comando:
$ cd `maestro`
250 IBM Tivoli Workload Scheduler - Manuale di riferimento
makecal
Crea un calendario personalizzato. Su UNIX, la shell Korn è necessaria per
eseguire questo comando.
Synopsis
makecal [-v | -u]
makecal [-c name] -d n | -e | {-f 1 | 2 | 3 -s date} | -l | -m | -p n |
{-r n -s date} | -w n [-i n] [-x | -z][-freedays Calendar_Name [-sa] [-su] ]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-c name
Specifica un nome per il calendario. Le parola chiave IBM Tivoli Workload
Scheduler (ad esempio Giorni liberi o Pianifica) non possono essere
utilizzate come nomi calendario. Il nome può contenere fino a otto caratteri
alfanumerici e deve cominciare con una lettera. Non utilizzare i nomi dei
giorni della settimana per i nomi dei calendari. Il nome di default è:
Chhmm, dove hhmm è l’ora esatta corrente.
-d n Specifica il n° giorno di ogni mese.
-e Specifica l’ultimo giorno di ogni mese.
-f 1 | 2 | 3
Crea un calendario fiscale di fine mese contenente l’ultimo giorno del mese
fiscale. Specificare uno dei seguenti formati:
1 formato settimana 4-4-5
2 formato settimana 4-5-4
3 formato settimana 5-4-4
Questo argomento richiede l’argomento -s.
-i n Specifica di inserire n date nel calendario.
-l Specifica l’ultimo giorno lavorativo di ogni mese. Affinché questo
argomento funzioni regolarmente, il piano di produzione (file Symphony) e
il calendario vacanze devono esistere già.
Nota: L’utilizzo di questo argomento crea il nuovo calendario, incluso
anche l’ultimo giorno lavorativo del mese precedente la data di
creazione del calendario.
-m Specifica il primo e il quindicesimo giorno di ogni mese.
-p n Specifica il giorno lavorativo precedente il n° giorno di ogni mese. Affinché
questo argomento funzioni regolarmente, il piano di produzione (file
Symphony) e il calendario vacanze devono esistere già
-r n Specifica tutti i n° giorni. Questo argomento richiede l’argomento -s.
-s date Specifica la data di inizio per gli argomenti -f e -r. La data deve trovarsi tra
apici e deve essere valida e non ambigua, ad esempio, utilizzare JAN 10
1999, non 1/10/99. Consultare base-date per datecalc a pagina 236 per
ulteriori informazioni sui formati data.
-w n Specifica il giorno lavorativo successivo al n° giorno del mese. Affinché
Capitolo 6. Comandi di utilità 251
questo argomento funzioni regolarmente, il piano di produzione (file
Symphony) e il calendario vacanze devono esistere già.
-x Invia l’output del calendario a stdout piuttosto che aggiungerla al database
del calendario.
-z Aggiunge il calendario al database del calendario e compila il piano di
produzione (file Symphony). AVVERTENZA: questo argomento inoltra
nuovamente i lavori e i flussi di lavoro dal piano di produzione del giorno
corrente. Potrebbe essere necessario annullare i flussi di lavoro e i lavori.
-freedays
Specifica il nome del calendario dei giorni liberi Calendar_Name che serve a
sostituire vacanze nella valutazione dei giorni lavorativi.
In questo caso, giorni lavorativi viene valutato come tutti i giorni, esclusi il
sabato, la domenica e tutte le date elencate in Calendar_Name.
Per default, sabato e domenica non sono considerati giorni lavorativi, a meno
che non si verifichi esplicitamente l’opposto -sa e/o -su
dopoCalendar_Name.
E’ possibile inoltre specificareholidays come nome per il calendario dei
giorni liberi.
Questa parola chiave influisce sull’elaborazione di makecal con le opzioni
-l, -p e -w.
Examples
Per creare un calendario di due anni con l’ultimo giorno di ogni mese selezionato,
eseguire il comando:
makecal -e -i24
Per creare un calendario con 30 giorni che parte dal 30 maggio del 1999 ed ha tutti
i 3° giorni selezionati, eseguire il comando:
makecal -r 3 -s "30 MAY 1999" -i30
252 IBM Tivoli Workload Scheduler - Manuale di riferimento
metronome.pl
Uno script PERL che esegue un’istantanea di IBM Tivoli Workload Scheduler e
genera un report html. Quando un utente incontra un problema con il prodotto,
questo report può aiutare il personale di assistenza di IBM Tivoli Workload
Scheduler.
Usage Notes
Fare riferimento a IBM Tivoli Workload Scheduler Troubleshooting and Error Messages
per ulteriori informazioni sull’utilità metronome.
Capitolo 6. Comandi di utilità 253
morestdl
Visualizza il contenuto dei file di elenco standard. Questo comando deve essere
eseguito dall’utente per il quale è stato installato IBM Tivoli Workload Scheduler.
Se si utilizza questo comando senza alcun parametro, assicurarsi cdi essere
collegati a un utente di IBM Tivoli Workload Scheduler.
Synopsis
morestdl -v | -u
morestdl [-day num] [-first | -last | -num n | -all]
[-name jstream.job | jobnum]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-day num
Visualizza i file di elenco standard che indicano il numero di giorni
precedenti specificato (1 per ieri, 2 per due giorni precedenti, ecc.). Il valore
di default è zero (oggi).
-first Visualizza il primo file di elenco standard di qualifica.
-last Visualizza l’ultimo file di elenco standard di qualifica.
-num n
Visualizza il file di elenco standard per l’esecuzione specificata di un
lavoro.
-all Visualizza tutti i file qualificativi di elenco standard.
-name jstream.job
Specifica il nome del flusso di lavoro o del lavoro per cui vengono
visualizzati i file di elenco standard.
jobnum
Specifica il numero lavoro del lavoro per cui viene visualizzato il file di
elenco standard.
Examples
Per visualizzare il file di elenco standard per la prima esecuzione del lavoro
mailxhg1.getmail nel giorno corrente, eseguire il comando:
morestdl -first -name mailxhg1.getmail
Per visualizzare il file di elenco standard per la seconda esecuzione del lavoro
mailxhg1.getmail nel giorno corrente, eseguire il comando:
morestdl -num 2 -name mailxhg1.getmail
Per visualizzare i file di elenco standard per tutte le esecuzioni di un lavoro
mailxhg1.getmail di tre giorni prima, eseguire il comando:
morestdl -day 3 -name mailxhg1.getmail
Per visualizzare il file di elenco standard per l’ultima esecuzione del lavoro
mailxhg1.getmail di quattro giorni prima, eseguire il comando:
morestdl -day 4 -last -name mailxhg1.getmail
Per stampare il file di elenco standard per il lavoro numero 455, eseguire il
comando:
254 IBM Tivoli Workload Scheduler - Manuale di riferimento
parms
Restituisce il valore corrente di un parametro, modifica il valore di un parametro o
aggiunge un nuovo parametro.
Synopsis
parms [-v | -u]
parms name
parms -c name value
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
name Specifica il nome del parametro di cui viene visualizzato il valore.
-c name value
Specifica il nome e il valore di un parametro. Il valore può contenere fino a
72 caratteri. Gli apici sono necessari se il valore contiene caratteri speciali.
Se il parametro non esiste, viene aggiunto al database. Se il parametro
esiste già, il suo valore viene modificato.
Usage Notes
Quando parms viene eseguito sulla riga comandi senza argomenti, esso richiede i
nomi dei valori e dei parametri.
Examples
Per restituire il valore di myparm, eseguire il comando:
parms myparm
Per modificare il valore di myparm, eseguire il comando:
parms -c myparm "item 123"
Per creare un nuovo parametro denominato hisparm, eseguire il comando:
parms -c hisparm "item 789"
Per modificare il valore di myparm e aggiungere herparm, eseguire il comando:
parms
Name of parameter ? myparm < Return>
Value of parameter? "item 456" < Return>
Name of parameter ? herparm < Return>
Value of parameter? "item 123" < Return>
Name of parameter ? < Return>
256 IBM Tivoli Workload Scheduler - Manuale di riferimento
paxtract
Estrarre le informazioni sui parametri dal database dello scheduler.
Synopsis
paxtract [-v | -u] [-o file]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-o file Specifica il file di output. Il valore di default è stdout.
Command Output
Ogni record di parametro contiene campi a lunghezza variabile, delimitati dal
separatore. I campi vengono descritti nella tabella seguente.
Campo Descrizione
Lunghezza massima
(byte)
1 nome parametro 8
2 valore parametro 64
Examples
Per estrarre tutte le informazioni sulle definizioni dei parametri e indirizzarle al
file di output painfo, eseguire il comando:
paxtract -o painfo
Capitolo 6. Comandi di utilità 257
prxtract
Estrarre le informazioni sui prompt dal database dello scheduler.
Synopsis
prxtract [-v | -u] [-o file]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-o file Specifica il file di output. Il valore di default è stdout.
Command Output
Ogni record del prompt contiene campi a lunghezza variabile, delimitati dal
separatore. I campi vengono descritti nella tabella seguente.
Campo Descrizione
Lunghezza massima
(byte)
1 nome prompt 8
2 valore prompt 200
Examples
Per estrarre tutte le informazioni sulle definizioni dei prompt e indirizzarle al file
di output prinfo, eseguire il comando:
prxtract -o prinfo
258 IBM Tivoli Workload Scheduler - Manuale di riferimento
r11xtr
Estrarre le informazioni sui flussi di lavoro dal database dello scheduler.
Synopsis
prxtract [-v | -u] [-m mm[yy]] [-c wkstat] [-o file]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-mmm[yy]
Specifica il mese (mm) e, facoltativamente, l’anno (yy) dei flussi di lavoro. Il
valore di default è l’anno e il mese corrente.
-c wkstat
Specifica la workstation dei flussi di lavoro. Il valore di default è di tutte le
workstation.
-o file Specifica il file di output. Il valore di default è stdout.
Command Output
La variabile MAESTRO_OUTPUT_STYLE specifica lo stile dell’output per nomi di
oggetti estesi. Impostare la variabile su LONG per utilizzare campi a lunghezza
completa (lunghi) per i nomi degli oggetti. Se la variabile non è impostata o è
impostata su un valore diverso da LONG, i nomi lunghi vengono troncati ai primi
otto caratteri e un segno +. Ad esempio: A1234567+.
Ogni record del flusso di lavoro contiene campi a lunghezza variabile, delimitati
dal separatore. I campi vengono descritti nella tabella seguente.
Campo Descrizione
Lunghezza massima
(byte)
1 nome workstation 16
2 nome flusso di lavoro 16
3 data flusso di lavoro (yymmdd) 6
4 secondi cpu stimati 6
5 indicatore di più workstation (* indica i lavori in
esecuzione su altre workstation)
1
6 numero di lavori 4
7 giorni della settimana (dom, lun, mar, mer, gio, ven,
sab)
2
Examples
Per estrarre le informazioni sui flussi di lavoro a giugno 1999 per la workstation
principale, eseguire il comando:
r11xtr -m 0699 -c main
Per estrarre le informazioni sui flussi di lavoro a giugno di questo anno per tutte le
workstation e indirizzare l’output al file r11out, eseguire il comando:
r11xtr -m 06 -o r11out
Capitolo 6. Comandi di utilità 259
rilascia
Rilascia le unità di una risorsa al flusso di lavoro o al livello del lavoro.
Synopsis
release -v | -u
release [-s] [wkstation#]resourcename
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-s Rilascia le unità della risorsa solo al livello del flusso di lavoro.
Se non viene utilizzato -s, le unità della risorsa vengono rilasciate al livello
del lavoro o al livello del flusso di lavoro se la risorsa non viene trovata al
livello del lavoro.
wkstation#
Specifica il nome della workstation o della classe workstation su cui viene
definita la risorsa. Il valore di default è la workstation locale.
resourcename
Specifica il nome della risorsa.
Usage Notes
Le unità di una risorsa vengono acquisite da un lavoro o da un flusso di lavoro
nell’ora in cui viene avviato e vengono rilasciate automaticamente al
completamento del lavoro o del flusso di lavoro. Il comando release può essere
utilizzato in uno script di lavoro per rilasciare le risorse prima del completamento
del lavoro o del flusso di lavoro. Le unità di una risorsa vengono rilasciate nello
stesso ordine in cui erano state acquisite.
Examples
Nel seguente flusso di lavoro, due unità della risorsa dbase sono richieste dal
flusso di lavoro sked5:
schedule ux1#sked5 on tu
needs 2 dbase :
job1
jobrel follows job1
job2 follows jobrel
end
Per rilasciare la risorsa dbase prima dell’inizio di un lavoro job2, il file script per
jobrel contiene il seguente comando:
`maestro`/bin/release -s dbase
Tenere presente che l’argomento -s può essere omesso, poiché non sono state
riservate risorse al livello del lavoro.
Nel seguente flusso di lavoro, otto unità della risorsa discio sono richieste da job2.
Questo è definito in due blocchi di 5 e 3 in modo che possano essere rilasciati in
modo incrementale nello stesso ordine in cui sono state acquisite.
260 IBM Tivoli Workload Scheduler - Manuale di riferimento
schedule ux1#sked7 on weekdays
:
job1
job2 follows job1 needs 5 discio,3 discio
job3 follows job2
end
Per rilasciare la risorsa discio in modo incrementale durante l’esecuzione di job2,
lo script per job2 contiene il seguente comando:
...
# Release 5 units of discio:
`maestro`/bin/release discio
...
# Release 3 units of discio:
`maestro`/bin/release discio
...
Capitolo 6. Comandi di utilità 261
rextract
Estrarre le informazioni sulle risorse dal database dello scheduler.
Synopsis
rextract [-v | -u] [-o file]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-o file Specifica il file di output. Il valore di default è stdout.
Command Output
Ogni record della risorsa contiene campi a lunghezza variabile, delimitati dal
separatore. I campi vengono descritti nella tabella seguente.
Campo Descrizione
Lunghezza massima
(byte)
1 nome workstation 8/16
2 nome risorsa 8
3 unità totali della risorsa 4
4 descrizione della risorsa 72
Examples
Per estrarre tutte le informazioni sulle definizioni delle risorse e indirizzarle al file
di output reinfo, eseguire il comando:
rextract -o reinfo
262 IBM Tivoli Workload Scheduler - Manuale di riferimento
rmstdlist
Rimuove o visualizza file di elenco standard in base alla durata del file.
Synopsis
rmstdlist -v | -u
rmstdlist [-p] [age]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-p Visualizza le directory dei nomi del file di elenco qualificativo standard.
Non sono stati rimossi né file né directory. Se non si specifica -p, i file di
elenco qualificativi standard vengono rimossi.
age La durata minima, in giorni, delle directory del file di elenco standard da
visualizzare o da rimuovere. Il valore di default è 10 giorni.
Examples
Per visualizzare i nomi del file di elenco standard che hanno più di 14 giorni,
eseguire il comando:
rmstdlist -p 14
Per rimuovere tutti i file di elenco standard (e le relative directory) che hanno più
di 7 giorni, eseguire il comando:
rmstdlist 7
Capitolo 6. Comandi di utilità 263
showexec
Visualizza lo stato di esecuzione dei lavori. Solo per UNIX. Questo comando è
relativo solo agli agent standard. Sui gestori dominio e gli FTA, utilizzare invece il
comando conman showjobs.
Synopsis
showexec [-v | -u | -info]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-info Visualizza il nome del nome file del lavoro invece dell’utente, della data e
dell’ora.
Command Output
L’output del comando è disponibile in due formati: standard e info.
Formato standard:
CPU La workstation su cui è in esecuzione il lavoro.
Schedule Il nome del flusso di lavoro in cui viene eseguito il lavoro.
Lavoro Il nome lavoro.
Job# Il numero del lavoro.
Utente Il nome utente del lavoro.
Data di avvio La data e l’ora in cui è stata avviata l’esecuzione.
Ora di avvio L’ora in cui è stata avviata l’esecuzione del lavoro.
(Est) tempo trascorso
L’ora stimata, in minuti, per l’esecuzione del lavoro.
Formato info:
CPU La workstation su cui è in esecuzione il lavoro.
Schedule Il nome del flusso di lavoro in cui viene eseguito il lavoro.
Lavoro Il nome lavoro.
Job# Il numero del lavoro.
JCL Il nome file del lavoro.
Examples
Per visualizzare l’esecuzione dei lavori nel formato standard, eseguire il comando:
showexec
Per visualizzare l’esecuzione dei lavori nel formato info, eseguire il comando:
showexec -info
264 IBM Tivoli Workload Scheduler - Manuale di riferimento
StartUp
Avvia il processo di gestione della rete dello scheduler, Netman. E’ necessario
disporre dell’accesso start alla workstation.
Synopsis
StartUp [-v | -u]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
Usage Notes
Su Windows, il servizio Netman viene avviato automaticamente al riavvio del
computer. StartUp può essere utilizzato per riavviare il servizio se questo viene
arrestato per un qualunque motivo.
Su UNIX, il comando StartUp viene installato generalmente nel file /etc/rc, in
modo che Netman venga avviato ad ogni riavvio del sistema. StartUp può essere
utilizzato per riavviare Netman se questo viene arrestato per un qualunque
motivo.
La parte rimanente dell’albero del processo può essere riavviata con un comando
conman start. Per ulteriori informazioni, consultare “avvio” a pagina 207.
Examples
Per visualizzare il nome del comando e la versione, eseguire il comando:
StartUp -v
Per avviare il processo Netman, eseguire il comando:
StartUp
Capitolo 6. Comandi di utilità 265
version
Visualizza le informazioni sulla versione dello scheduler. Solo per UNIX. Le
informazioni vengono estratte da un file version.
Synopsis
version/version -V | -u | -h
version/version [-a] [-f vfile] [-p product] [file [...]]
Arguments
-V Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
-h Visualizza le informazioni di aiuto del comando ed esce.
-a Visualizza le informazioni su tutti i file del prodotto. Il valore di default è
di visualizzare le informazioni solo sui file specificati.
-f vfile Specifica il nome della versione del file. Il valore di default è un file
denominato version.info nella directory di lavoro corrente o nella directory
di lavoro specificata con -p.
-p product
Specifica il nome del prodotto Tivoli la cui directory si trova direttamente
sotto la directory di lavoro corrente e contiene un file version.info. Se
omesso, viene utilizzato-f o il relativo valore di default.
file Specifica i nomi dei file del prodotto, separati da spazi, per cui vengono
visualizzate le informazioni sulla versione. Il valore di default è di non
visualizzare informazioni sul file oppure, se si utilizza -a, visualizzare tutte
le informazioni sul file.
Command Output
L’intestazione dell’output contiene il nome del prodotto, versione, piattaforma,
livello patch e data di installazione. Il pannello rimanente elenca le informazioni
sul file e sui file specificati. I file vengono elencati nel formato seguente:
File Il nome del file.
Revisione Il numero di revisione del file.
Patch Il livello patch del file, se presente.
Dimensione (byte)
La dimensione dei file in byte.
Checksum Il checksum per il file. I checksum vengono calcolati utilizzando il
comando UNIX sum. Su AIX, il comando sum viene utilizzato con
l’argomento -o.
Usage Notes
Le informazioni sul file IBM Tivoli Workload Scheduler si trovano nel file
version.info. Questo file viene ubicato nella directory TWShome/version durante
l’installazione. Il file version.info si trova in un formato specifico e non deve essere
modificato.
E’ possibile spostare il file version.info su un’altra directory. Tuttavia, è necessario
includere l’argomento -f per individuare il file.
266 IBM Tivoli Workload Scheduler - Manuale di riferimento
E’ possibile utilizzare l’argomento -p se la directory corrente contiene le directory
di più prodotti Tivoli. In questo modo è possibile accedere alle informazioni sulla
versione specificando il nome del prodotto.
Examples
Per visualizzare le informazioni su tutti i file, eseguire il comando:
version/version -a -f version/version.info
Per visualizzare le informazioni sul file customize, eseguire il comando:
cd version
./version customize
Per visualizzare le informazioni sul file customize, quando version.info si trova in
/apps/maestro, eseguire il comando:
cd version
./version -f /apps/maestro/version.info customize
Capitolo 6. Comandi di utilità 267
wmaeutil
Utilizzato per arrestare il server connettore per il piano, per il database e per il
motore. Il comando makesec non verrà eseguito con esito positivo su piattaforme
Windows fino a che non vengono arrestati i connettori.
Synopsis
UNIX:
wmaeutil.sh instance_name [-stop DB | PL | EG | “*”] [-version DB | PL | EG |
“*”] [-dbinfo DB | PL] [-sethome] [-gethome] [ALL -stop]
Windows:
wmaeutil.cmd instance_name [-stop DB | PL | EG | “*”] [-version DB | PL | EG
| “*”] [-dbinfo DB | PL] [-sethome] [-gethome] [ALL -stop]
Arguments
instance_name
Il nome dell’istanza dello scheduler. Si riferisce al nome dell’istanza
immesso durante l’installazione del motore dello scheduler e l’installazione
del connettore.
-stop DB | PL | EG | “*”
Questa opzione può essere utilizzata per chiudere il server connettore
specificato. L’asterisco (*) può essere utilizzato per chiudere tutti e tre i
server connettore. Se viene utilizzato, deve essere inserito tra doppi apici.
-version DB | PL | EG | “*”
Questa opzione viene utilizzata per ottenere il numero della versione del
server connettore per il piano, il database, il motore e deve essere installata
sul sistema. L’asterisco (*) può essere utilizzato per richiamare
contemporaneamente le versioni di tutti e tre i server connettore. Se viene
utilizzato, deve essere inserito tra doppi apici.
-dbinfo DB | PL
Questa opzione viene utilizzata per stabilire se il database dello scheduler
e il piano a cui questo connettore è collegato è espanso o meno. Con IBM
Tivoli Workload Scheduler, Versione 8.2, i database e i piani sono sempre
estesi, ma questa opzione esiste per motivi di compatibilità con le versioni
precedenti.
-sethome
Questa opzione viene utilizzata per impostare l’attributo TWShome degli
oggetti dello scheduler (Engine, Database e Plan) nel database degli oggetti
Tivoli. Questo valore attributo collega i connettori per l’istanza dell’oggetto
specificato al prodotto scheduler core. Utilizza un nome file completo della
directory home dello scheduler come argomento. Anche la stringa del
nome del percorso deve trovarsi tra apici per impedire qualunque
interpretazione shell.
-gethome
Questa opzione non richiede argomenti se stampa il valore dell’attributo
TWShome per le istanze degli oggetti Engine, Database e Plan nel database
dell’oggetto.
ALL -stop
Questa opzione arresta i server connettori per tutte le istanze connettore
268 IBM Tivoli Workload Scheduler - Manuale di riferimento
dello scheduler connesse all’installazione corrente dello scheduler, cioè
arresta i server connettore per tutte le istanze che hanno un attributo
TWShome corrispondente alla directory home dell’installazione corrente
dello scheduler.
Usage Notes
Impostazione delle variabili di ambiente: Prima che wmaeutil possa essere
eseguito correttamente, è necessario:
1. Impostare l’ambiente Tivoli Management Framework:
Su Windows:c:\>%SystemRoot%\system32\drivers\etc\Tivoli\setup_env.cmd
Su UNIX:$ . /etc/Tivoli/setup_env.sh
2. Impostare l’ambiente IBM Tivoli Workload Scheduler:
Su Windows:TWShome\tws_env.cmd
Su UNIX:TWShome/tws_env.sh per shell Bourne e TWShome/tws_env.csh per shell
C.
E’ possibile aggiornare il proprio profilo UNIX per eseguire questo file, in modo da
evitare la riesecuzione manuale del comando.
Considerazioni Makesec: Il comando wmaeutil deve essere eseguito prima del
comando makesec. Il comando makesec non verrà eseguito con esito positivo su
piattaforme Windows fino a che non vengono arrestati i connettori. E’ necessario
inoltre arrestare i connettori quando si utilizza il comando makesec su UNIX.
Nome istanza di IBM Tivoli Workload Scheduler: Se non si ricorda il nome
istanza immesso al momento dell’installazione, seguire queste istruzioni:
1. L’origine delle variabili di ambiente Tivoli:
. /etc/Tivoli/setup_env.sh (for UNIX)
C:\winnt\system32\drivers\etc\Tivoli\setup_env.cmd (per Windows)
2. Eseguire il comando wlookup per ottenere il nome dell’istanza dello scheduler:
wlookup -ar MaestroEngine
maestro2 1697429415.1.596#Maestro::Engine#
dove maestro2 è il nome istanza dello scheduler.
Examples
Per arrestare i connettori per il database, il piano e il sistema per una istanza
denominata maestro, eseguire il comando:
wmaeutil.sh maestro ALL -stop
Per arrestare i connettori del database per una istanza denominata tws, eseguire il
comando:
wmaeutil.sh tws ALL -stop DB
Per arrestare le versioni del connettore per il database, il piano e il motore per una
istanza denominata maestro2, eseguire il comando:
wmaeutil.sh maestro2 -version *
Capitolo 6. Comandi di utilità 269
xrxtrct
Estrarre le informazioni sui riferimenti incrociati dal database dello scheduler.
Synopsis
xrxtrct [-v | -u]
Arguments
-v Visualizza la versione del comando ed esce.
-u Visualizza le informazioni sull’utilizzo del comando ed esce.
Command Output
La variabile MAESTRO_OUTPUT_STYLE specifica lo stile dell’output per nomi di
oggetti estesi. Impostare la variabile su LONG per utilizzare campi a lunghezza
completa (lunghi) per i nomi degli oggetti. Se la variabile non è impostata o è
impostata su un valore diverso da LONG, i nomi lunghi vengono troncati ai primi
otto caratteri e un segno +. Ad esempio: A1234567+.
L’output del comando è scritta su otto file, xdep_job, xdep_sched, xfile, xjob,
xprompt, xresources, xsched e xwhen.
File xdep_job: Il file xdep_job contiene due tipi di record. Il primo contiene
informazioni sui lavori e sui flussi di lavoro che dipendono da un lavoro. Ogni
record di lavoro dipendente e del flusso di lavoro dipendente contiene i campi a
lunghezza fissa, senza delimitatori. I campi vengono descritti nella tabella
seguente.
Campo Descrizione Lunghezza (byte)
1 03 2
2 nome workstation 16
3 nome lavoro 40
4 nome flusso di lavoro 16
5 non utilizzato 240
6 nome workstation flusso di lavoro dipendente 16
7 nome flusso di lavoro dipendente 16
8 nome workstation di lavoro dipendente 16
9 nome lavoro dipendente 40
10 non utilizzato 6
11 non utilizzato 6
12 non utilizzato 8
13 fine del record (null) 1
Il secondo contiene informazioni sui lavori e sui flussi di lavoro che dipendono da
una dipendenza internetwork. Ogni record di lavoro dipendente e del flusso di
lavoro dipendente contiene i campi a lunghezza fissa, senza delimitatori. I campi
vengono descritti nella tabella seguente.
Campo Descrizione Lunghezza (byte)
1 08 2
270 IBM Tivoli Workload Scheduler - Manuale di riferimento
Campo Descrizione Lunghezza (byte)
2 nome workstation 16
3 nome lavoro 120
4 non utilizzato 128
5 nome workstation flusso di lavoro dipendente 16
6 nome flusso di lavoro dipendente 16
7 nome workstation di lavoro dipendente 16
8 nome lavoro dipendente 40
9 non utilizzato 6
10 non utilizzato 6
11 non utilizzato 8
12 fine del record (null) 1
File xdep_sched: Il file xdep_sched contiene informazioni sui flussi di lavoro che
dipendono da un flusso di lavoro. Ogni record del flusso di lavoro dipendente
contiene i campi a lunghezza fissa, senza delimitatori. I campi vengono descritti
nella tabella seguente.
Campo Descrizione Lunghezza (byte)
1 02 2
2 nome workstation 16
3 nome flusso di lavoro 16
4 non utilizzato 248
5 nome workstation flusso di lavoro dipendente 16
6 nome flusso di lavoro dipendente 16
7 non utilizzato 8
8 non utilizzato 8
9 non utilizzato 6
10 non utilizzato 6
11 non utilizzato 8
12 fine del record (null) 1
File xfile: Il file xfile contiene informazioni sui lavori e sui flussi di lavoro che
dipendono da un file. Ogni record contiene campi a lunghezza fissa, senza
delimitatori. I campi vengono descritti nella tabella seguente.
Campo Descrizione Lunghezza (byte)
1 07 2
2 nome workstation 16
3 nome file 256
4 nome workstation flusso di lavoro dipendente 16
5 nome flusso di lavoro dipendente 16
6 nome workstation di lavoro dipendente 16
7 nome lavoro dipendente 40
Capitolo 6. Comandi di utilità 271
Campo Descrizione Lunghezza (byte)
8 non utilizzato 6
9 non utilizzato 6
10 non utilizzato 8
11 fine del record (null) 1
File xjob: Il file xjob contiene informazioni sul flusso di lavoro in cui appare ogni
lavoro. Ogni record del lavoro contiene campi a lunghezza fissa, senza delimitatori.
I campi vengono descritti nella tabella seguente.
Campo Descrizione Lunghezza (byte)
1 04 2
2 nome workstation 16
3 nome lavoro 40
4 non utilizzato 248
5 nome workstation flusso di lavoro 16
6 nome flusso di lavoro 16
7 non utilizzato 8
8 non utilizzato 8
9 non utilizzato 6
10 non utilizzato 6
11 non utilizzato 8
12 fine del record (null) 1
File xprompt: Il file xprompt contiene informazioni sui lavori e sui flussi di
lavoro che dipendono da un prompt. Ogni record del prompt contiene campi a
lunghezza fissa, senza delimitatori. I campi vengono descritti nella tabella
seguente.
Campo Descrizione Lunghezza (byte)
1 05 2
2 nome workstation 16
3 nome prompt o testo 20
4 non utilizzato 236
5 nome workstation flusso di lavoro dipendente 16
6 nome flusso di lavoro dipendente 16
7 nome workstation di lavoro dipendente 16
8 nome lavoro dipendente 40
9 non utilizzato 6
10 non utilizzato 6
11 non utilizzato 8
12 fine del record (null) 1
272 IBM Tivoli Workload Scheduler - Manuale di riferimento
File xresource: Il file xresource contiene informazioni sui lavori e sui flussi di
lavoro che dipendono da una risorsa. Ogni record della risorsa contiene campi a
lunghezza fissa, senza delimitatori. I campi vengono descritti nella tabella
seguente.
Campo Descrizione Lunghezza (byte)
1 06 2
2 nome workstation 16
3 nome risorsa 8
4 non utilizzato 248
5 nome workstation flusso di lavoro dipendente 16
6 nome flusso di lavoro dipendente 16
7 nome workstation di lavoro dipendente 16
8 nome lavoro dipendente 40
9 unità assegnate 6
10 non utilizzato 6
11 non utilizzato 8
12 fine del record (null) 1
File xsched: Il file xsched contiene informazioni sui flussi di lavoro. Ogni record
del flusso di lavoro contiene campi a lunghezza fissa, senza delimitatori. I campi
vengono descritti nella tabella seguente.
Campo Descrizione Lunghezza (byte)
1 00 2
2 nome workstation 16
3 nome flusso di lavoro 16
4 non utilizzato 248
5 nome workstation (come 2 precedente) 16
6 nome flusso di lavoro (uguale al 3 precedente) 16
7 non utilizzato 8
8 non utilizzato 8
9 non utilizzato 6
10 non utilizzato 6
11 non utilizzato 8
12 fine del record (null) 1
File xwhen: Il file xwhen contiene informazioni sul momento in cui viene
eseguito il flusso di lavoro. Ogni flusso di lavoro contiene i seguenti campi a
lunghezza fissa, senza delimitatori. I campi vengono descritti nella tabella
seguente.
Campo Descrizione Lunghezza (byte)
1 01 2
2 nome workstation 16
3 nome o data ON/EXCEPT 8
Capitolo 6. Comandi di utilità 273
Campo Descrizione Lunghezza (byte)
4 indicatore except (*=EXCEPT) 1
5 non utilizzato 247
6 nome workstation 16
7 nome flusso di lavoro 16
8 non utilizzato 8
9 non utilizzato 8
10 non utilizzato 6
11 num. offset 6
12 unità scostamento 8
13 fine del record (null) 1
Examples
Per estrarre le informazioni su tutti i riferimenti incrociati, eseguire il comando:
xrxtrct
274 IBM Tivoli Workload Scheduler - Manuale di riferimento
Comandi non supportati
I seguenti comandi di utilità non supportati forniscono funzioni su Windows che
sono simili ai comandi UNIX ps e kill. Possono essere utilizzati se non sono
disponibili simili programmi di utilità Windows.
Synopsis
listproc
killproc pid
Usage Notes
listproc
Visualizza un elenco tabulare dei processi sul sistema.
killproc
Esegue il Kill del processo con l’ID del processo pid.
Nota: Quando eseguito dall’amministratore, killproc è in grado di interrompere i
processi del sistema.
Capitolo 6. Comandi di utilità 275
Capitolo 7. Comandi report
Questo capitolo descrive i comandi report che consentono di ottenere un riepilogo
o informazioni dettagliate sul giorno di produzione precedente o successivo.
Comandi report
I comandi report di IBM Tivoli Workload Scheduler vengono elencati nella
seguente tabella.
Comando Report
rep1 Report 01 - Elenco dettagli lavoro
rep2 Report 02 - Elenco prompt
rep3 Report 03 - Elenco calendari
rep4a Report 04A - Elenco parametri
rep4b Report 04B - Elenco risorse
rep7 Report 07 - Elenco cronologie lavori
rep8 Report 08 - Istogramma lavori
rep11 Report 11 - Pianificazione produzione
reptr Report 09A - Riepilogo produzione pianificato
Report 09B - Dettaglio di produzione pianificato
Report 09D - Dettaglio di produzione pianificato (Nomi lunghi)
Report 10A - Riepilogo di produzione reale
Report 10B - Dettagli di produzione reale
xref Report 12 - Report di riferimento incrociato
Output del comando
L’output dei comandi del report vengono controllati dalle seguenti variabili:
MAESTROLP
Specifica la destinazione dell’output di un comando. Il valore di default è
stdout. E’ possibile impostarlo su uno qualsiasi dei seguenti:
filename
Scrivere l’output su un file.
> filename
Solo per UNIX. Reindirizzare l’output ad un file, sostituendo il
contenuto del file. Se il file non esiste, viene creato.
>> filename
Solo per UNIX. Reindirizzare l’output ad un file, accodandolo alla
fine del file. Se il file non esiste, viene creato.
| comando
Solo per UNIX. Associare l’output ad un processo o comando di
sistema. Il comando di sistema viene sempre eseguito.
|| command
Solo per UNIX. Associare l’output ad un processo o comando di
sistema. Se non esiste alcun output, il comando di sistema non
viene eseguito.
© Copyright IBM Corp. 1999, 2004 277
MAESTRO_OUTPUT_STYLE
Specifica lo stile dell’output per i nomi oggetto lunghi. Impostare la
variabile su LONG per utilizzare campi a lunghezza completa (lunghi) per
i nomi degli oggetti.
Se la variabile non è impostata oppure se è impostata su un valore diverso
da LONG, i nomi lunghi vengono troncati a otto caratteri e con un segno
più. Ad esempio: A1234567+.
Modifica del formato della data
In IBM Tivoli Workload Scheduler, il formato della data influenza tutti i comandi
che accettano una data come opzione di input (fatta eccezione per il comando
datecalc) e le intestazioni in tutti i report. Il formato della data di default è
mm/gg/aa. Per selezionare un formato diverso, modificare l’opzione locale date
format. I valori sono:
0 Per selezionare: aa/mm/gg
1 Per selezionare: mm/gg/aa
2 Per selezionare: gg/mm/aa
3 Per utilizzare: Variabili NLS (Native Language Support).
Per informazioni sulla modifica delle variabili delle locale, consultare Manuale per
la pianificazione e installazione di IBM Tivoli Workload Scheduler.
278 IBM Tivoli Workload Scheduler - Manuale di riferimento
Comandi rep1 - rep4b
Questi comandi stampano i seguenti report:
Report 01 - Elenco dettagli lavoro
Report 02 - Elenco messaggi del prompt
Report 03 - Elenco calendari utente
Report 04A - Elenco parametri utente
Report 04B - Elenco risorse Maestro
Synopsis
rep[x] [-v|-u]
Arguments
x Un numero corrispondente al report. I numeri sono: 1, 2, 3, 4a o 4b.
-u Visualizza la versione del comando e termina.
-v Visualizza le informazioni sull’utilizzo del comando e termina.
Examples
Print Report 03, Elenco calendari utente:
rep3
Visualizza le informazioni sull’utilizzo per il comando rep2:
rep2 -u
Su UNIX, stampare due copie del report 04A, Elenco parametri utente, su una
stampante lp2:
MAESTROLP="| lp -dlp2 -n2"
export MAESTROLP
rep4a
Capitolo 7. Comandi report 279
Comando rep7
Questo comando stampa Report 07-Elenco cronologie lavoro.
Synopsis
rep7 -v|-u
rep7 [-c wkstat] [-s jstream] [-j job] [-f date -t date] [-l]
Arguments
-u Visualizza la versione del comando e termina.
-v Visualizza le informazioni sull’utilizzo del comando e termina.
-c wkstat
Specifica il nome della workstation sulla quale vengono eseguiti i lavori. Il
valore di default è di tutte le workstation.
-s jstream
Specifica il nome del flusso di lavoro in cui sono in esecuzione i lavori. Il
valore di default è Tutti i flussi di lavoro.
-j job Specifica il nome del lavoro. Il valore di default è Tutti i lavori.
-f data Specifica la stampa della cronologia dei lavori da questa data in poi.
Immettere la data come yyyymmdd. Il valore di default è la prima data
disponibile.
-t date Specifica la stampa della cronologia dei lavori fino a questa data.
Immettere la data come yyyymmdd. Il valore di default è la data più
recente.
-l Limita le informazioni sulla riga di riepilogo per i lavori che si trovano
nell’intervallo data specificato dalle opzioni -f o -t. L’utilizzo di questa
opzione causa l’inversione dell’ordine dell’output: la riga di riepilogo del
lavoro verrà stampata dopo le righe di esecuzione del lavoro individuale.
Questa opzione è valida solo se si specifica almeno una delle opzioni -f o
-t.
Examples
Stampare tutta la cronologia dei lavori per la workstation ux3:
rep7 -c ux3
Stampare tutta la cronologia dei lavori per tutti i lavori nel flusso di lavoro sked25:
rep7 -s sked25
Stampare la cronologia dei lavori per tutti i lavori nel flusso di lavoro mysked
sulla workstation x15 tra 1/21/99 e 1/25/99:
rep7 -c x15 -s mysked -f 19990121 -t 19990125
280 IBM Tivoli Workload Scheduler - Manuale di riferimento
Comando rep8
Questo comando stampa Report 08-Istogramma lavoro.
Synopsis
rep8 -v|-u
rep8 [-f date -b time -t date -e time] [-i file] [-p ]
rep8 [-b time -e time] [-i file] [-p ]
Arguments
-u Visualizza la versione del comando e termina.
-v Visualizza le informazioni sull’utilizzo del comando e termina.
-f data Specifica la stampa della cronologia dei lavori da questa data in poi.
Immettere la data come yyyymmdd. Il valore di default e la data odierna.
-b time
Specifica la stampa della cronologia dei lavori da quest’ora in poi.
Immettere l’ora come segue hhmm. Il valore di default è l’ora di avvio dello
scheduler.
-t date Specifica la stampa della cronologia dei lavori fino a questa data.
Immettere la data come yyyymmdd. Il valore di default è la data più
recente.
-e time Specifica la stampa della cronologia dei lavori fino a quest’ora. Immettere
l’ora come segue hhmm. Il valore di default è l’ora di avvio dello scheduler.
-i file Specifica il nome del file di log da cui viene estratta la cronologia dei
lavori. Tenere presente che i file di log vengono archiviati nella
directoryschedlog. Il valore di default è il piano corrente (file Symphony).
Nota: Assicurarsi che l’intervallo di tempo specificato dagli argomenti [-f
date -b time -t date -e time] rientri nella data e l’ora definita
nell’argomento del file di log -i file.
-p Specifica di inserire un’interruzione di pagina dopo ogni data di
esecuzione.
Examples
Stampare un istogramma dei lavori che include tutte le informazioni nel piano
corrente (file Symphony):
rep8
Stampare un istogramma dei lavori che inizia alle 6:00 a.m. dell’1/25/99 e termina
alle 5:59 a.m. dell’1/26/99:
rep8 -f 19990125 -b 0600 -t 19990126 -e 0559 -i schedlog/M199801260601
Stampare un’istogramma dei lavori, dal piano corrente (file Symphony), che inizia
alle 6:00 am e termina alle 10:00 pm:
rep8 -b 0600 -e 2200
Capitolo 7. Comandi report 281
Comando rep11
Questo comando stampa Report 11-Pianificazione produzione.
Synopsis
rep11 -v|-u
rep11 [-m mm[yy] [...]] [-c wkstat [...]] [-o file]
Arguments
-u Visualizza la versione del comando e termina.
-v Visualizza le informazioni sull’utilizzo del comando e termina.
-m mm[yy]
Specifica i mesi da registrare. Immettere il numero del mese nel formato
mm. Il valore di default è il mese corrente.
E’ possibile inoltre immettere un anno nel seguente formato yy. Il valore di
default è l’anno corrente o l’anno successivo se si specifica un mese
precedente a quello corrente.
-c wkstat
Specifica le workstation da registrare. Il valore di default è di tutte le
workstation.
-o file Specifica il file di output. Il valore di default è il file definito dalla variabile
MAESTROLP. Se MAESTROLP non viene impostato, il valore di default è
stdout.
Examples
Fare riferimento a giugno, luglio e agosto del 1999 per le workstation main, site1 e
sagent1:
rep11 -m 0699 0799 0899 -c main site1 sagent1
Fare riferimento a giugno, luglio e agosto dell’anno corrente per tutte le
workstation e indirizzare l’output al file r11out:
rep11 -m 06 07 08 -o r11out
Fare riferimento a questo mese e anno per la workstation site2:
rep11 -c site2
282 IBM Tivoli Workload Scheduler - Manuale di riferimento
Comando reptr
Questo comando stampa i seguenti report:
v Report 09A - Riepilogo produzione pianificato
v Report 09B - Dettaglio di produzione pianificato
v Report 10A - Riepilogo di produzione reale
v Report 10B - Dettagli di produzione reale
Synopsis
reptr [-v|-u]
reptr -pre [-{summary | detail}] [symfile]
reptr -post [-{summary | detail}] [logfile]
Arguments
-u Visualizza la versione del comando e termina.
-v Visualizza le informazioni sull’utilizzo del comando e termina.
-pre Specifica di stampare i report che precedono la produzione (09A, 09B).
-post Specifica di stampare i report successivi alla produzione (10A, 10B).
-summary
Specifica di stampare i report di riepilogo (09A, 10A). Se vengono omessi
-summary e -detail, vengono stampate entrambe le serie di report.
-detail Specifica di stampare i report dei dettagli (09B, 10B). Se vengono omessi
-summary e -detail, vengono stampate entrambe le serie di report.
symfile Specifica il nome del file di piano da cui verranno stampati i report. Il
valore di default è Symnew nella directory corrente.
logfile Specifica il nome del file di log da cui verranno stampati i report. Tenere
presente che i file di log del piano vengono archiviati nella directory
schedlog. Il valore di default è rappresentato dal piano corrente(file
Symphony).
Se il comando viene eseguito senza opzioni, vengono stampati tutti i report
precedenti e successivi.
Examples
Stampare il report dei dettagli precedenti alla produzione dal file Symnew:
reptr -pre -detail
Stampare il report di riepilogo della produzione precedente dal file mysym:
reptr -pre -summary mysym
Stampare il report di riepilogo precedente alla produzione dal file di log
M199903170935:
reptr -post -summary schedlog/M199903170935
Stampare tutti i report precedenti e successivi alla produzione.
reptr
I report precedenti alla produzione si basano sulle informazioni lette dal file
Symnew. I report precedenti alla produzione si basano sulle informazioni lette dal
Capitolo 7. Comandi report 283
Comando xref
Questo comando stampa Report 12-Report di riferimento incrociato.
Synopsis
xref [-V|-U]
xref [-cpu wkstat] [-depends|-files|-jobs|-prompts|-resource|-schedules|-when
[...]]
Arguments
-U Visualizza la versione del comando e termina.
-V Visualizza le informazioni sull’utilizzo del comando e termina.
-cpu wkstat
Specifica di stampare il report per la workstation denominata. E’ consentito
il carattere jolly @, nel caso in cui sono incluse le informazioni da tutte le
workstation qualificate. Il valore di default è di tutte le workstation.
-depends
Specifica di stampare un report che visualizza i flussi di lavoro e i lavori
successori di ogni lavoro.
-files Specifica di stampare un report che visualizza i flussi di lavoro e i lavori
che dipendono da ogni file.
-jobs Specifica di stampare un report che visualizza i flussi di lavoro in cui è in
esecuzione ogni lavoro.
-prompts
Specifica di stampare un report che visualizza i flussi di lavoro e i lavori
che dipendono da ogni prompt.
-resource
Specifica di stampare un report che visualizza i flussi di lavoro e i lavori
che dipendono da ogni risorsa.
-schedules
Specifica di stampare un report che visualizza i flussi di lavoro e i lavori
successori di ogni flusso di lavoro.
-when Specifica di stampare un report che visualizza i flussi di lavoro nelle date
di Inclusione e di Esclusione.
Se il comando viene eseguito senza nessuna opzione, vengono selezionate tutte le
workstation e tutte le opzioni.
Examples
Stampare un report per tutte le workstation, che visualizzano tutte le informazioni
a riferimento incrociato:
xref
Stampare un report per tutte le workstation. Inserire tutte le informazioni a
riferimento incrociato relative alle dipendenze del successore:
xref -cpu @ -depends -schedules
Capitolo 7. Comandi report 285
Report di esempio
Report 01 — Elenco dettagli lavoro:
TWS for UNIX (SOLARIS)/REPORT1 8.2 (1.8)
IBM Page 1
Report 01 Job Details
Listing 06/11/03
Job: SUN001 #ACC
Description:
JCL File : ^ACCHOME^
Logon : ^ACCLOGIN^ Creator:
maestro
Recovery Job :
Recovery Type : STOP
Recovery Prompt :
Composer Autodoc : Yes
Total Runs : 0 - 0 Successful, 0 Aborted
Elapsed(mins) CPU(secs)
Total 00:00:00 0
Normal 00:00:00
Last Run 00:00:00 0 (On at 00:00)
Maximum 00:00:00 0 (On )
Minimum 00:00:00 0 (On )
Report 02 — Elenco prompt:
TWS for UNIX (SOLARIS)/REPORT2 8.2 (1.6) IBM
Page 1
Report 02 Prompt Message Listing
06/11/03
Prompt Message
ACCRES Reply YES when ready to run acc103 and acc104.
ACCUSERS Have all ACC users logged out?
CALLNO 555-0911
CALLOPER Call ^PERSONONCALL^ at ^CALLNO^ to ensure all time cards have
been processed.
HRSRES Reply YES when ready to run hrs103 and hrs104.
MISRES Reply YES when ready to run mis103 and mis104.
PERSONONCALL Lou Armstrong
Total number of prompts on file: 7
Report 03 — Elenco calendari:
TWS for UNIX (SOLARIS)/REPORT3 8.2 (1.7) IBM
Report 03 User Calendar Listing 06/22/03
Calendar Type: PAYDAYS Description: Company Paydays
Oct 2003 Nov 2003
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri
. . . . . . . . . . . . .
12 . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . 27 28
Report 04A — Elenco parametri:
TWS for UNIX (SOLARIS)/REPORT4A 8.2 (1.6) IBM
Page 1
Report 4A User Parameter Listing
06/11/03
Parameter Name Contents
ACCHOME /usr/local/Tivoli/maestro/scripts
ACCLOGIN maestro
BADEXIT 99
GOODEXIT 0
286 IBM Tivoli Workload Scheduler - Manuale di riferimento
LONG 2000
SCRPATH /usr/local/Tivoli/maestro/scripts
SHORT 20
Number of Parameters on file: 7
Report 04B — Elenco risorse:
TWS for UNIX (SOLARIS)/REPORT4B 8.2 (1.6) IBM
Page 1
Report 4B TWS Resources Listing
06/11/03
Resource Number
CPU Name Avail Description
SUN001 #ACCDB 1 Database
SUN001 #ACCODB 5 Maestro Class Resource
SUN001 #ACCONE 1 Maestro Class Resource
SUN001 #ACCPRT 2 Printers
SUN001 #ACCTAPE 1 Tape Drive
SUN001 #HRSODB 5 Maestro Class Resource
SUN001 #HRSONE 1 Maestro Class Resource
SUN001 #MISODB 5 Maestro Class Resource
SUN001 #MISONE 1 Maestro Class Resource
Number of Resources on file: 9
Report 07 — Elenco cronologie lavori:
TWS for UNIX (SOLARIS)/REPORT7 8.2 (1.10)
IBM Page 1
Report 07 Job History
Listing 06/11/03
Date Time Schedule Name Elapsed CPU
Status
Job:SUN001 #ACCJOB01 Runs: Aborted 1 Successful 1 Elapsed
Time: Normal 2 Min 2 Max 2
06/10/03 09:36 SUN001 #ACCW01 2 1
SU
06/10/03 10:32 SUN001 #ACCW11 2 1
AB
Job:SUN001 #ACCJOB02 Runs: Aborted 1 Successful 1 Elapsed
Time: Normal 2 Min 1 Max 2
06/10/03 09:44 SUN001 #ACCW01 2 1
SU
06/10/03 10:31 SUN001 #ACCW11 1 1
AB
Report 08 — Istogramma lavori:
TWS for UNIX (SOLARIS)/REPORT8 8.2 (1.7) IBM
Page 1
Report 08 Job Histogram 06/10/03 12:41 - 06/11/03 12:40
06/11/03
Interval Per Column: 15 minutes
2 0 0 0 0 0 0 0 1 1
CPU is SUN001 3 0 2 3 5 6 8 9 1 2
1 4 1 4 1 4 1 4 1 4
Job Name Stat 1 1 1 1 1 1 1 1 1 0
06/11/03
TESTRET+.ACCJOB03SU .
ACCW02 .ACCJOB14AB .
HRSW02 .HRSJOB14AB .
MISW02 .MISJOB14AB .
JOBS .ACCENV SU .
Report 11 — Pianificazione produzione:
TWS for UNIX/REP11 8.2
AWSBJA001I Licensed Materials Property of IBM
5698-WKB
Capitolo 7. Comandi report 287
(C) Copyright IBM Corp 1998,2003
US Government User Restricted Rights
Use, duplication or disclosure restricted by GSA ADP Schedule Contrac
TWS for UNIX (SOLARIS)/REPORT11 8.2 (1.5.1.1) IBM
Report 11 Planned Production Schedule for JUN 2003
CPU: SUN001
Num Est Cpu 1 2 3 4 5 6 7
12 13 14 15 16 17 18 19 20
26 27 28 29 30
Schedule Jobs Time Sun Mon Tue Wed Thu Fr
Wed Thu Fri Sat Sun Mon Tue Wed Thu
Wed Thu Fri Sat Sun Mon
ACCDAIL+ 1 0 * * * * * * * * * *
ACCW01 4 4 * * * * * * * * * *
ACCW02 5 3 * * * * * * * * * *
ACCW11 3 3 * * * * * * * * * *
ACCW12 3 3 * * * * * * * * * *
FINAL 1 4 * * * * * * * * * * * * * * *
HRSW01 4 0 * * * * * * * * * *
HRSW02 5 2 * * * * * * * * * *
Report 12 — Report di riferimento incrociato:
TWS for UNIX (SOLARIS)/CROSSREF 8.2 (1.5)
IBM Page 1
Report 12 Cross Reference Report for Job
Dependencies. 06/13/03
CPU: SUN001
Job Name Dependencies
ACCR01 #ACCJOB01 ACCR01 .ACCJOB02
ACCW01 #ACCJOB01 ACCW01 .ACCJOB04
ACCR01 #ACCJOB02 ACCR01 .ACCJOB03
ACCR01 #ACCJOB03 ACCR01 .ACCJOB04
ACCW01 #ACCJOB03 ACCW01 .ACCJOB01
ACCW01 #ACCJOB04 ACCW01 .ACCJOB02
ACCR01 #ACCJOB05 ACCR01 .ACCJOB06
ACCW02 #ACCJOB11 ACCW02 .ACCJOB12
ACCW02 #ACCJOB12 ACCW02 .ACCJOB13
ACCW02 #ACCJOB14 ACCW02 .ACCJOB15
288 IBM Tivoli Workload Scheduler - Manuale di riferimento
Capitolo 8. Riferimento Agent esteso
Questo capitolo descrive l’interfaccia dell’agent esteso e fornisce informazioni utili
ai programmatori che desiderano creare metodi di accesso personalizzati. Gli agent
estesi vengono utilizzati per estendere le funzioni di pianificazione dei lavori di
IBM Tivoli Workload Scheduler su altri sistemi e applicazioni, quali: sistemi locali e
remoti UNIX, Peoplesoft, SAP R/3, z/OS, OPC, Oracle CCM e VMS. Questo
capitolo contiene informazioni sui seguenti argomenti:
v Cosa sono gli Agent estesi?
v Interfaccia metodo di accesso
v Esecuzione del metodo
v Risoluzione dei problemi
Cosa sono gli Agent estesi?
Gli agent estesi vengono utilizzati per estendere le funzioni di pianificazione
lavoro di IBM Tivoli Workload Scheduler su altri sistemi e applicazioni.
Un agent esteso viene definito come una workstation che dispone di un host e di
un metodo di accesso. L’host è qualsiasi altra workstation, ad eccezione dell’agent
esteso. Il metodo di accesso è uno script o un programma fornito da IBM o
dall’utente che viene eseguito dall’host ogni volta che si faccia riferimento all’agent
esteso nel piano di produzione. Ad esempio, per avviare un lavoro su un agent
esteso, l’host esegue il metodo di accesso, inviando i dettagli relativi al lavoro
come opzioni della riga comandi. Il metodo di accesso comunica con i sistemi
esterni o con le applicazioni per avviare il lavoro e restituire lo stato del lavoro.
Definizione della workstation
Ogni agent esteso deve avere una definizione logica della workstation. Questa
workstation logica deve trovarsi su una workstation fisica di IBM Tivoli Workload
Scheduler, un gestore dominio master, FTA o SA. La definizione della workstation
dell’agent esteso fa riferimento al nome del metodo di accesso e alla workstation
host. Quando i lavori vengono inviati sulla workstation dell’agent esteso, viene
definito il metodo di accesso e si inviano le informazioni sul lavoro al sistema
esterno.
Interfaccia del metodo di accesso
L’interfaccia tra IBM Tivoli Workload Scheduler e un metodo di accesso consiste di
informazioni inviate al metodo sulla riga comandi e di messaggi restituiti allo
scheduler in stdout.
Sintassi della riga comandi del metodo
L’host dello scheduler esegue un metodo di accesso utilizzando la seguente sintassi
della riga comandi:
methodname -t task options -- taskstring
dove:
© Copyright IBM Corp. 1999, 2004 289
methodname
Specifica il nome del file del metodo di accesso. Tutti i metodi di accesso
devono essere memorizzati nella directory: TWShome/methods
-t task Specifica l’attività da eseguire, dove task è una delle seguenti:
LJ Avvia un lavoro job.
MJ Gestisce un lavoro precedentemente avviato. Utilizzare questa
opzione per effettuare nuovamente la sincronizzazione se
un’attività precedente LJ è stata terminata in modalità non
prevista.
CF Controlla la disponibilità di un file. Utilizzare questa opzione per
controllare le dipendenze opens del file.
GS Riceve lo stato di un lavoro. Utilizzare questa opzione per
controllare le dipendenze follows del lavoro.
options Specifica le opzioni associate all’attività. Consultare “Opzioni attività” per
ulteriori informazioni.
taskstring
Una stringa di massimo 255 caratteri associati all’attività. Consultare
“Opzioni attività”.
Opzioni attività
Le opzioni relative alle attività vengono elencate nella seguente tabella. Una X
indica che l’opzione è valida per l’attività.
Attività Opzioni
Stringa
attività
-t -c -n -p -r -s -d -l -o -j -q -w -S
LJ X X X X X X X X X X ljstring
MJ X X X X X X X X X mjstring
CF X X X X cfstring
GS X X X X X X gsstring
-c xagent,host,master
Specifica i nomi scheduler dell’agent esteso, l’host e il Gestore dominio
master separato da virgole.
-n nodename
Specifica il nome del nodo del computer associato all’agent esteso, se
presente. Ciò viene definito nel campo Nodo nella definizione della
workstation dell’agent esteso.
-p portnumber
Specifica il numero porta TCP associato all’agent esteso, se presente. Ciò
viene definito nel campo Indirizzo TCP di definizione della workstation
dell’agent esteso.
-r currentrun,specificrun
Specifica il numero di esecuzione corrente dello scheduler e il numero di
esecuzione specifico associato al lavoro separato da una virgola. I numeri
di esecuzione corrente e specifico devono essere diversi se il lavoro viene
terminato da una esecuzione precedente.
-s jstream
Specifica il nome del flusso di lavoro del lavoro.
290 IBM Tivoli Workload Scheduler - Manuale di riferimento
-d scheddate,epoch
Specifica la data di pianificazione (yymmdd) e l’epoca equivalente, separati
da una virgola.
-l user Specifica il nome utente del lavoro. Viene definito nel campo Logon nella
definizione lavoro.
-o stdlist
Specifica il nome completo del percorso del file elenco standard del lavoro.
Qualsiasi output dal lavoro deve essere scritto in questo file.
-j jobname,id
Specifica il nome del lavoro e l’identificativo univoco assegnato dallo
scheduler, separati da una virgola. Il nome viene definito nel campo Nome
lavoro della definizione lavoro.
-q qualifier
Specifica il qualificativo da utilizzare in un comando di testo emesso dal
metodo rispetto al file.
-w timeout
Specifica la quantità di tempo di attesa dello scheduler, espresso in secondi,
per ricevere una risposta su un lavoro esterno prima di inviare un segnale
SIGTERM al metodo di accesso. Il valore di default è pari a 300.
-S new name
Specifica che il lavoro viene eseguito nuovamente utilizzando questo nome
al posto del nome lavoro originale. In uno script di lavoro, è possibile
utilizzare il comando jobinfo per ritornare al nome lavoro ed eseguire lo
script in maniera differente per ogni iterazione. Per ulteriori informazioni,
vedere la descrizione del comando conman rerun in IBM Tivoli Workload
Scheduler Reference Guide.
-- ljstring
Utilizzato con l’attività LJ. La stringa dal campo File script o Comando
della definizione lavoro.
-- mjstring
Utilizzato con l’attività MJ. Le informazioni fornite allo scheduler dal
metodo in una risposta %CJ ad un’attività LJ. Generalmente, ciò identifica
il lavoro che è stato avviato. Ad esempio, un metodo Unix può fornire il
PID (process identification) del lavoro avviato, che viene inviato dallo
scheduler come parte di un’attività MJ.
-- cfstring
Utilizzato con l’attività CF. Per una dipendenza opens del file, la stringa
dal campo File aperti della definizione del flusso di lavoro.
-- gsstring
Utilizzato con l’attività GS. Specifica il lavoro di cui viene controllato lo
stato. Il formato è il seguente:
followsjob[,jobid]
dove:
followsjob
La stringa dall’elenco di definizioni del flusso di lavoro Follows
Sched/Job.
jobid Un identificativo del lavoro facoltativo ricevuto dallo scheduler in
una risposta %CJ ad un’attività GS precedente.
Capitolo 8. Riferimento Agent esteso 291
Messaggi di risposta del metodo
I metodi restituiscono informazioni a IBM Tivoli Workload Scheduler in messaggi
scritti su stdout. Ogni riga che inizia con un segno di percentuale (%) e che
termina con una nuova riga, viene interpretato come un messaggio. I messaggi
hanno il seguente formato:
%CJ state [mjstring | jobid]
%JS [cputime]
%RC rc
%UT [errormessage]
dove:
CJ Modifica lo stato del lavoro.
stato Lo stato in cui è stato modificato il lavoro. Tutti gli stati lavoro
dello scheduler sono validi, ad eccezione di hold e ready. Per
l’attività GS, sono validi anche i seguenti stati:
ERROR
Si è verificato un errore.
EXTRN
Stato non conosciuto.
mjstring
Una stringa di massimo 255 caratteri inclusi dallo scheduler in
qualsiasi attività MJ associata al lavoro. Consultare 291.
jobid Una stringa di massimo 64 caratteri che lo scheduler inserirà in
qualsiasi attività GS associata al lavoro. Consultare 291.
JS [cputime]
Indica il completamento riuscito di un lavoro e fornisce il tempo di
esecuzione trascorso in secondi.
RC rc rc è un numero interpretato da IBM Tivoli Workload Scheduler come il
codice di ritorno del lavoro dell’agent esteso. Il codice di ritorno è preso in
considerazione solo se è stata specificata una condizione di codice di
ritorno nella definizione di lavoro di agent esteso. In caso contrario, viene
ignorato e il completamento dell’agent esteso viene indicato dalla presenza
del messaggio %JS [cputime]. Analogamente, se il metodo non invia il
messaggio %RC, il completamento dell’agent esteso viene indicato dalla
presenza del messaggio %JS [cputime].
UT [errormessage]
Indica che l’attività richiesta non è supportata dal metodo. Visualizza una
stringa composta da massimo 255 caratteri che lo scheduler inserirà nel suo
messaggio di errore.
File di opzioni del metodo
E’ possibile utilizzare un file di opzioni del metodo per specificare informazioni
speciali sul login e altre informazioni. Lo scheduler legge il file, se esiste, prima di
eseguire un metodo. Se il file viene modificato dopo l’avvio dello scheduler, le
modifiche hanno effetto quando viene arrestato e riavviato.
292 IBM Tivoli Workload Scheduler - Manuale di riferimento
Il file può contenere opzioni dello scheduler e altre informazioni sul metodo. Le
opzioni riconosciute dallo scheduler sono come i seguenti:
LJuser=username
CFuser=username
GSuser=username
GStimeout=seconds
dove:
LJuser=username
Specifica il login da utilizzare per le attività LJ e MJ. Il valore di default è
il login dalla definizione lavoro.
CFuser=username
Specifica il login da utilizzare per l’attività CF. Il valore di default è root
per Unix e per Windows è il nome utente dell’account in cui è stato
installato lo scheduler.
GSuser=username
Specifica il login da utilizzare per le attività GS. Il valore di default è root
per Unix e per Windows è il nome utente dell’account in cui è stato
installato lo scheduler.
GStimeout=seconds
Specifica la quantità di tempo di attesa dello scheduler, espresso in secondi,
per ricevere una risposta prima di interrompere il metodo di accesso. Il
valore di default è 300 secondi.
Nota: Se l’host dell’agent esteso è un computer Windows, questi utenti devono
essere definiti come oggetti dell’utente dello scheduler.
Il file opzioni deve avere lo stesso nome percorso del metodo di accesso, con
un’estensione file .opts. Ad esempio, il nome del percorso Windows di un file delle
opzioni per un metodo definito netmth è TWShome\methods\netmth.opts.
Esecuzione del metodo
I seguenti argomenti descrivono lo scambio tra IBM Tivoli Workload Scheduler e
un metodo di accesso.
Attività LJ (Launch job)
L’attività LJ istruisce il metodo dell’agent esteso ad avviare un lavoro su un
sistema o un’applicazione esterna. Prima di eseguire il metodo, IBM Tivoli
Workload Scheduler stabilisce un ambiente di esecuzione. Il parametro LJuser
viene letto dal file di opzioni del metodo per stabilire l’account dell’utente con cui
eseguire il metodo. Se il parametro non è presente o se il file opzioni non esiste,
viene utilizzato l’account utente specificato nel campo Logon della definizione del
lavoro. Inoltre, vengono impostate le seguenti variabili d’ambiente:
HOME
La directory home dell’utente di login.
LOGNAME
Il nome dell’utente di login.
Capitolo 8. Riferimento Agent esteso 293
PATH Per UNIX, viene impostato su /bin:/usr/bin. Per Windows, viene impostato
su %SYSTEM%\SYSTEM32.
TZ Fuso orario.
Se il metodo non può essere eseguito, il lavoro viene posizionato nello stato fail.
Una volta che il metodo è in esecuzione, scrive messaggi sul relativostdout che
indicano lo stato del lavoro sul sistema esterno. I messaggi vengono riepilogati
nella seguente tabella.
Attività Risposta metodo Azione IBM Tivoli Workload Scheduler
LJ e MJ %CJ state [mjstring] Imposta lo stato del lavoro sustate. Include
mjstring in qualsiasi attività MJ successiva.
%JS [cputime] Imposta lo stato del lavoro susucc.
Exit code=non-zero Imposta lo stato del lavoro suabend.
%UT [errormessage] and Exit
code=2
Imposta lo stato del lavoro suabend e
visualizza errormessage.
Una sequenza tipica consiste di uno o più messaggi %CJ che indicano le modifiche
allo stato del lavoro e un messaggio %JS prima che il metodo venga chiuso per
indicare che il lavoro è stato terminato con esito positivo. Se il lavoro ha avuto un
esito negativo, è necessario che il metodo termini senza scrivere il messaggio%JS.
Un metodo che non supporta l’attivitàLJ, scrive un messaggio %UT su stdout e
termina con un codice di uscita pari a2.
Attività MJ (Manage job)
L’attività MJ viene utilizzata per sincronizzarsi con un lavoro avviato
precedentemente se lo scheduler determina se l’attività LJ è stata terminata in
modalità imprevista. Lo scheduler imposta l’ambiente nello stesso modo
dell’attività LJ e la invia in mjstring. Per ulteriori informazioni, consultare “Attività
LJ (Launch job)” a pagina 293.
Se il metodo individua il lavoro specificato, risponde con gli stessi messaggi di
un’attività LJ. Se il metodo non riesce ad individuare il lavoro, termina con un
codice di uscita non zero, inducendo lo scheduler a posizionare il lavoro nello stato
abend.
Interruzione di un lavoro
Mentre un’attività LJ o MJ è in esecuzione, il metodo deve effettuare il trap di un
segnale SIGTERM (segnale 15). Il segnale viene inviato quando un operatore
emette un comando Kill tramite il gestore della console dello scheduler. Durante la
ricezione del segnale, il metodo deve tentare di arrestare (kill) il lavoro e deve
terminare senza scrivere il messaggio %JS.
Attività CF (Check file)
L’attività CF richiede al metodo dell’agent esteso di controllare la disponibilità di
un file su un sistema esterno. Prima di eseguire il metodo, lo scheduler stabilisce
un ambiente di esecuzione. Il parametro CFuser viene letto dal file opzioni del
metodo per stabilire l’account utente con cui eseguire il metodo. Se il parametro
non è presente o se il file delle opzioni non esiste, l’utente root viene utilizzato su
Unix, mentre su Windows viene utilizzato il nome utente dell’account in cui è stato
installato lo scheduler. Se il metodo non può essere eseguito, la dipendenza opens
294 IBM Tivoli Workload Scheduler - Manuale di riferimento
del file viene contrassegnata come non riuscita, cioè, lo stato del file viene
impostato su NO e qualsiasi lavoro o flusso di lavoro dipendente non può essere
eseguito.
Una volta in esecuzione, il metodo esegue un comando di verifica, o l’equivalente,
in relazione al file che utilizza il qualificativo inviatogli nell’opzione della riga
comandi -q. Se la verifica del file è true, il metodo termina con un codice di uscita
pari a zero. Se la verifica del file è false, il metodo termina con un codice di uscita
non zero. Viene riepilogato nella seguente tabella.
Attività Risposta metodo Azione IBM Tivoli Workload Scheduler
CF Exit code=0 Imposta lo stato del file su YES.
Exit code=non-zero Imposta lo stato del file suNO.
%UT [errormessage] and Exit
code=2
Imposta lo stato del file suNO.
Un metodo che non supporta l’attività CF scrive un messaggio %UT su stdout e
termina con un codice di uscita pari a 2.
Attività GS (Get status)
L’attività GS indica al metodo dell’agent esteso di controllare lo stato di un lavoro.
Ciò è necessario quando un altro lavoro dipende dal completamento riuscito di un
lavoro esterno. Prima di eseguire il metodo, il parametro GSuser viene letto dal
file di opzioni del metodo per stabilire l’account dell’utente con cui eseguire il
metodo. Se il parametro non è presente o se il file delle opzioni non esiste, l’utente
root viene utilizzato su Unix, mentre su Windows viene utilizzato il nome utente
dell’account in cui è stato installato lo scheduler. Se il metodo non può essere
eseguito, il lavoro o il flusso di lavoro dipendente non può effettuare l’esecuzione.
Se è disponibile un jobid da un’attività GS precedente, viene inoltrato al metodo.
Il metodo controlla lo stato del lavoro specificato e lo restituisce in un messaggio
%CJ scritto sustdout. Inoltre, termina con un codice di uscita pari a zero. In una
velocità impostata dall’opzione locale bm check status, il metodo viene eseguito
nuovamente con un’attività GS fino a quando non viene restituito uno dei seguenti
stati:
abend Il lavoro è stato terminato in modalità anomala.
succ Il lavoro è stato completato con esito positivo.
cancl Il lavoro è stato annullato.
done Il lavoro è stato effettuato, ma non si conosce il suo esito, positivo o
negativo.
fail Il lavoro potrebbe non essere in esecuzione.
error Si è verificato un errore nel metodo durante il controllo dello stato del
lavoro.
extrn Il controllo del lavoro ha avuto esito negativo o lo stato del lavoro non può
essere determinato.
Tenere presente che GStimeout nel file di opzioni del metodo specifica il periodo
di attesa della risposta dello scheduler prima di interrompere il metodo. Per
ulteriori informazioni, consultare “File di opzioni del metodo” a pagina 292.
Capitolo 8. Riferimento Agent esteso 295
Le risposte del metodo vengono riepilogate nella seguente tabella:
Attività Risposta metodo Azione IBM Tivoli Workload Scheduler
GS %CJ state [jobid] Imposta lo stato del lavoro state e include
jobid in ogni attività GS successiva.
%UT [errormessage] and Exit
code=2
Lo stato del lavoro è invariato.
Un metodo che non supporta l’attività GS scrive un messaggio %UT su stdout e
termina con un codice di uscita pari a 2.
Comando cpuinfo
Il comando cpuinfo può essere utilizzato in un metodo di accesso per restituire le
informazioni da una definizione della workstation. Consultare “cpuinfo” a pagina
234 per informazioni complete sul comando.
Risoluzione dei problemi
I seguenti argomenti vengono forniti per aiutare a risolvere i problemi e per
effettuare il debug dell’extendendb agent e accedere ai problemi del metodo.
Messaggi di errore dell’elenco standard del lavoro
Tutti i messaggi dell’output da un metodo di accesso, ad eccezione di quelli che
cominciano con un segno di percentuale (%), vengono scritti sul file dell’elenco
standard del lavoro (stdlist). Per le attività GS e CF che non sono associate ai
lavori dello scheduler, i messaggi vengono scritti sul di elenco standard dello
scheduler. Per informazioni relative ad un problema di qualunque tipo, controllare
questi file.
Metodo non eseguibile
Se non è possibile accedere ad un metodo di accesso, si verificherà quanto segue:
v Per le attività LJ e MJ, il lavoro viene posizionato nello stato fail.
v Per l’attività CF, la dipendenza file non viene risolta e il lavoro dipendente
rimane nello stato hold.
v Per l’attività GS, la dipendenza del lavoro non è risolta e il lavoro dipendente
rimane nello stato hold.
Per ricevere più informazioni, visualizzare nuovamente i file di elenco standard
(stdlist) per il lavoro e per lo scheduler.
Messaggi Gestore console
Questo messaggio di errore viene visualizzato se si immette un comando start,
stop, link o unlink per un agent esteso:
Error executing command: Not implemented for extended
agent. [2202.58]
Questo errore non viene visualizzato se si seleziona un agent esteso come risultato
dell’utilizzo di caratteri jolly.
296 IBM Tivoli Workload Scheduler - Manuale di riferimento
Messaggi del composer e del compiler
I seguenti messaggi di errore vengono creati quando il Composer rileva una
sintassi non valida in una definizione della workstation:
ACCESS METHOD is syntactically invalid [1116.45]
Duplicate ACCESS keyword [1116.46]
Missing or invalid ACCESS METHOD [1116.47]
Se un agent esteso viene definito con un metodo di accesso ma senza un host,
viene visualizzato il seguente messaggio:
"Method needs a Host CPU"
Messaggi Jobman
Per gli agent estesi, i messaggi di errore, di avvertenza e di informazioni vengono
scritti sul file stdlist del Jobman.
L’avvio con esito positivo di un lavoro crea il seguente messaggio:
Launched job jobname for wkstation, #Jjobid for user username.
La non riuscita dell’avvio del lavoro crea il seguente messaggio:
Error launching jobname for wkstation: errortext
La non riuscita di un’attività del file di verifica crea il seguente messaggio:
Error invoking methodname for wkstation: errortext
L’errore di un’attività di lavoro di gestione crea il seguente messaggio:
Error managing jobname for wkstation using methodname: errortext
Quando un metodo invia un messaggio a Jobman che non viene riconosciuto,
viene creato il seguente messaggio:
Error: message invalid for jobname, #jjobnumber for
wkstation using methodname.
"first 64 characters of the offending message"
Capitolo 8. Riferimento Agent esteso 297
Capitolo 9. Riferimento Agent di rete
Le dipendenze internetwork di IBM Tivoli Workload Scheduler consentono ai
lavori e ai flussi di lavoro in una rete locale dello scheduler di utilizzare i lavori e i
flussi di lavoro in una rete remota come dipendenze follows. Questo capitolo
descrive come utilizzare le dipendenze internetwork. Questo capitolo contiene
informazioni sui seguenti argomenti:
v Panoramica
v Configurazione della Workstation NA
v Dipendenze Internetwork
Panoramica
Un agent di rete è una definizione logica della workstation che abilita le
dipendenze follows tra una rete locale e una rete remota dello scheduler. Le
dipendenze follows remote vengono assegnate ai lavori e ai flussi di lavoro nello
stesso modo delle dipendenze follows locali, tranne se il nome dell’agent di rete
viene incluso per verificare che il lavoro o il flusso di lavoro si trovi in una rete
esterna dello scheduler. Questo tipo di dipendenza viene definita dipendenza
internetwork.
Se tutti i flussi di lavoro con dipendenze internetwork vengono inclusi nel piano,
viene creato un flusso di lavoro speciale definito EXTERNAL per visualizzare lo
stato di queste dipendenze. Questo flusso di lavoro EXTERNAL contiene i lavori
del place holder per rappresentare ogni dipendenza follows remota.
La definizione della workstation per un agent di rete contiene il nome del metodo
di accesso di rete netmth. Viene utilizzato un file opzioni per specificare l’utente
sotto cui è in esecuzione il metodo e la velocità con cui viene controllata la
dipendenza del lavoro o del flusso di lavoro. Questo file delle opzioni deve avere
lo stesso nome di percorso del metodo di accesso e deve essere definito
netmth.opts.
Il metodo di accesso viene richiamato dallo scheduler ogni volta che è necessario
controllare lo stato di un lavoro o di un flusso di lavoro remoto. Il metodo di
accesso richiede alla rete remota lo stato del lavoro o del flusso di lavoro
predecessore. Lo scheduler continua il controllo fino a quando il lavoro o il flusso
di lavoro remoto non raggiunge lo stato SUCC, CANCL o ERROR.
E’ possibile monitorare lo stato delle dipendenze internetwork con Job Scheduling
Console visualizzando il flusso di lavoro EXTERNAL.
Configurazione della workstation dell’agent di rete
Prima di specificare una dipendenza internetwork, è necessario creare una
definizione della workstation dello scheduler per la rete remota. La definizione
della workstation per una rete remota viene definita Agent di rete. Le definizioni
della workstation dell’agent di rete vengono definite in modalità standard come
Agent estesi e richiedono una workstation host e un metodo di accesso, netmeth.
Utilizzando la console di pianificazione lavori, definire una workstation Agent di
rete nel database dello scheduler nel modo seguente:
© Copyright IBM Corp. 1999, 2004 299
1. Nel pannello di elenco di azioni della console di pianificazione lavori,
selezionare l’interruttore Nuova workstation.
2. Fare clic sul nome motore. Viene visualizzata la finestra Proprietà -
Workstation nel Database.
3. Nel campo Nome, specificare un nome per questa workstation. Il nome della
workstation può contenere fino a 16 caratteri alfanumerici, può comprendere il
trattino e il carattere di sottolineatura, ma deve iniziare con una lettera, ad
esempio MasterB.
4. Nel campo Nodo, specificare il nome del nodo o l’indirizzo IP per questa
workstation. E’ possibile immettere i nomi dominio completi. Questo campo è
obbligatorio.
5. Nel campo Porta TCP, immettere il numero di porta utilizzato dal gestore
dominio master nella rete remota. Nell’esempio seguente, il numero di porta
utilizzato da MasterA.
6. Nel campo Sistema operativo, selezionare OTHER.
7. Nel campo Dominio, specificare il dominio della workstation host.
8. Nel campo Fuso orario, specificare il fuso orario di questa workstation
(facoltativo).
9. Nel campo Descrizione, specificare una descrizione della workstation. La
descrizione può essere lunga fino a 40 caratteri e deve cominciare con una
lettera.
10. Nel campo Tipo di workstation, selezionare Agent esteso esteso dall’elenco a
discesa.
11. Lasciare la casella Ignora vuota.
12. Nel campo Metodo di accesso, immettere netmeth.
13. Nel campo Host, specificare il nome del nodo della workstation host (il nome
host MasterB nell’esempio) o selezionarne uno dall’elenco fornito facendo clic
sul pulsante Host.
14. Fare clic su OK. La workstation Agent di rete viene salvata nel database dello
scheduler MasterB (rete locale).
L’esempio seguente mostra come definire una workstation di agent di rete per una
rete remota, la rete A, che consente alla rete locale, la rete B, di utilizzare lavori e
flussi di lavoro nella rete remota come dipendenze follows.
300 IBM Tivoli Workload Scheduler - Manuale di riferimento
I passi successivi mostrano come definire una workstation di agent di rete
denominata NetAgent che utilizza il metodo di accesso netmth.
1. Definire la cpu MasterA sul database the MasterA. L’utente di questa cpu è
tws_masterA.
2. Specificare il numero di posta TCP per MasterA come 12345.
3. Specificare il nodo per MasterA come MasterA.rome.tivoli.com.
4. Definire la cpu MasterB sul database Master B. L’utente di questa cpu è
tws_masterB.
5. Specificare il nodo per MasterB come MasterB.rome.tivoli.com.
La definizione di workstation di agent di rete viene salvata nel database di Master
B.
Esempio della riga comandi dell’agent di rete
Il seguente esempio illustra la definizione di workstation della riga comandi per
l’agent di rete NetAgent in Figura 7:
CPUNAME NETAGENT
DESCRIPTION "NETWORK AGENT"
OS OTHER
NODE MASTERA.ROME.TIVOLI.COM
TCPADDR 12345
(La cpu NetAgent attende sulla porta MasterA.)
FOR maestro
HOST MASTERB
ACCESS NETMTH
END
File delle opzioni
Viene creato un file opzione per specificare l’utente sotto cui è in esecuzione il
metodo di accesso e la frequenza con cui viene controllata una dipendenza lavoro
Rete A
in remotoRete B
Locale
Network Agent
MasterA MasterB
Figura 7. Reti locali e remote
Capitolo 9. Riferimento Agent di rete 301
o un flusso di lavoro remota. Le modifiche a questo file non hanno effetto fino a
quando non si arresta e si riavvia lo scheduler.
Questo file delle opzioni deve avere lo stesso nome di percorso del metodo di
accesso e deve essere definito netmth.opts.
TWShome/methods/netmth.opts
Sintassi
GSuser=login_name
GStimeout=seconds
dove:
login_name
Il login utilizzato per eseguire il metodo. Se l’host dell’agent di rete è un
computer Windows, questo utente deve essere definito nello scheduler.
seconds
La quantità di tempo di attesa dello scheduler, espressa in secondi, prima
di interrompere il metodo di accesso. Il valore di default è 300 secondi. Se
il metodo di accesso viene definito nuovamente, verrà avviato
automaticamente.
Esempio di un file delle opzioni
Un file opzioni di esempio su MasterBper il metodo netmth è:
GSuser=tws_masterA
GStimeout=600
Dipendenze Internetwork
Utilizzando Job Scheduling Console, le dipendenze internetwork vengono
specificate nell’editor del flusso di lavoro. Utilizzare il pulsante Aggiungi la
dipendenza a Internetwork per aggiungere un’icona lavoro Internetwork al flusso
di lavoro (che rappresenta il predecessore) e creare la dipendenza follows da
questa icona per qualsiasi altro lavoro utilizzando il pulsante Aggiungi
collegamento.
Nota: i lavori e i flussi di lavoro remoti vengono definiti sulla loro rete locale nella
maniera standard. Il loro utilizzo come dipendenze internetwork non ha alcun
effetto sul funzionamento locale.
Quando si specificano i lavori e i flussi di lavoro come dipendenze Follows nei
flussi di lavoro locali, vengono tracciati dal Conman in un flusso di lavoro
EXTERNAL specificatamente creato. I nomi vengono creati per le dipendenze e
vengono considerati come lavori nel flusso di lavoro EXTERNAL.
Creazione di una dipendenza internetwork in un flusso di
lavoro
Per aggiungere una dipendenza internetwork ad flusso di lavoro:
1. Aprire la vista Grafico facendo clic con il pulsante destro del mouse e
selezionando Apri dal menu a comparsa.
2. Nella vista Grafico, fare clic su Aggiungi dipendenza ad Internetwork nella
barra degli strumenti. Viene visualizzata la finestra Dipendenza Internetwork.
3. Fare clic sul pulsante Trova (...) e utilizzare la finestra Trova workstation per
selezionare il nome dell’agent di rete.
302 IBM Tivoli Workload Scheduler - Manuale di riferimento
4. Nel campo Dipendenza, specificare la dipendenza a formato libero o il
predecessore lavoro o flusso di lavoro nel formato workstation#jobstream.job.
La lunghezza massima di questo campo è:
v 120 per i caratteri a formato libero
v 16 per la workstation v
v 16 per il flusso di lavoro
v 40 per il lavoro5. Fare clic su OK per chiudere la finestra. Se si sta aggiungendo una nuova
dipendenza internetwork, un nuovo pulsante dipendenza internetwork viene
aggiunto alla vista Grafico.
6. Salvare il flusso di lavoro.
Utilizzo della riga comandi
Le dipendenze Internetwork possono essere incluse nei flussi di lavoro composti
con il Composer della riga comandi. Ad esempio, per creare una dipendenza
follows su un lavoro e flusso di lavoro utilizzando la parola chiave follows,
procedere come segue:
v Dipendenza internetwork del flusso di lavoro
1. Definire un flusso di lavoro denominato schedA sul database di MasterA.
2. Definire un flusso di lavoro denominato schedB sul database di MasterB con
una dipendenza da schedA.
Utilizzare la riga di comandi del composer per definire la dipendenza
internetwork del flusso di lavoro come segue:
schedule schedB
on everyday
follows NetAgt::MasterA#schedA
:
end
v Dipendenza internetwork del lavoro
1. Definire un lavoro denominato jobA sul database di MasterA.
2. Definire un flusso di lavoro denominato jobB sul database di MasterB con
una dipendenza da jobA.
Utilizzare la riga di comandi del composer per definire la dipendenza
internetwork del flusso di lavoro come segue:
$jobs
jobB
......
follows NetAgt::MasterA#jobA
end
end
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione dei flussi di lavoro del manuale Guida per l’utente
di IBM Tivoli Workload Scheduler Job Scheduling Console.
Dipendenze Internetwork e Conman
Le dipendenze Internetwork vengono visualizzate e gestite nel piano in diversi
modi.
v Pianificazione adhoc
v Flusso di lavoro EXTERNAL
Capitolo 9. Riferimento Agent di rete 303
Pianificazione adhoc e dipendenze internetwork
Le dipendenze Internetwork possono essere utilizzate come di pendenze follows
per i lavori e i flussi di lavoro inoltrati nel piano. Le dipendenze vengono
specificate così come sono per altre dipendenze follows. Fare riferimento a
“Creazione di una dipendenza internetwork in un flusso di lavoro” a pagina 302
per ulteriori informazioni.
Flusso di lavoro EXTERNAL
Tutte le dipendenze internetwork vengono visualizzate in un flusso di lavoro
definito EXTERNAL. Le dipendenze vengono elencate come lavori a prescindere
dal fatto se sono definiti per i lavori o per i flussi di lavoro. Esiste un flusso di
lavoro EXTERNAL per ogni agent di rete nel piano.
I nomi di lavoro univoci vengono creati nel seguente modo:
Ennnmmss
dove:
nnn è un numero casuale.
mm sono i minuti correnti.
ss sono i secondi correnti.
Il nome reale del lavoro o del flusso di lavoro viene memorizzato nella parte JCL
del record lavoro.
Stati dei flussi di lavoro
Lo stato di rilascio dei lavori viene determinato dal metodo di accesso e viene
elencato nel campo Stato rilascio del flusso di lavoro EXTERNAL. Lo stato è
corrente solo rispetto all’ultima volta in cui la rete remota è stata sottoposta a
polling. I lavori potrebbero ignorare gli stati che si verificano tra i polling.
Vengono elencati tutti gli stati per i lavori e i flussi di lavoro, fatta eccezione per
FENCE. Inoltre, esistono due stati univoci per i lavori EXTERNAL:
ERROR
Si è verificato un errore durante il controllo per lo stato remoto.
EXTRN
Stato sconosciuto. Si è verificato un errore, è stata eseguita un’operazione
Rerun sul flusso di lavoro EXTERNAL o il lavoro o il flusso di lavoro
INET non esiste.
Azione sui lavori external
E’ possibile avviare tre operazioni sui lavori remoti in una pianificazione
EXTERNAL: Cancel, Rerun e Confirm.
Nota: Nessuno di questi comandi ha effetto sul lavoro remoto o sulla
pianificazione sulla rete remota. Essi manipolano semplicemente la
dipendenza per la rete locale.
Cancel
Annulla il lavoro EXTERNAL, rilasciando la dipendenza per tutti i lavori e
tutte le pianificazioni. Lo stato della dipendenza cessa di essere sottoposto
a controlli.
304 IBM Tivoli Workload Scheduler - Manuale di riferimento
Rerun Istruisce Conman per riavviare il controllo dello stato del lavoro
EXTERNAL. Lo stato del lavoro viene impostato su EXTRN subito dopo
l’esecuzione di Rerun.
Rerun è utile per i lavori EXTERNAL nello stato ERROR. Ad esempio, se
un lavoro EXTERNAL non può essere avviato perché il metodo di accesso
non concede l’autorizzazione all’esecuzione, il lavoro immette lo stato
ERROR e lo stato cessa di essere sottoposto a controlli. Dopo aver corretto
le autorizzazioni, il metodo può essere avviato ma Conman non inizierà il
controllo dello stato del lavoro EXTERNAL fino a quando non si esegue
Rerun.
Confirm SUCC / ABEND
Imposta lo stato di EXTERNAL su SUCC o ABEND, rilasciando la
dipendenza per tutti i lavori e le dipendenze locali. Lo stato della
dipendenza cessa di essere sottoposto a controlli.
Azione sulle dipendenze internetwork per i lavori e le
pianificazioni
Le dipendenze internetwork vengono elencate nella colonna Dipendenze delle
finestre SHOWJOBS e SHOWSCHEDULES nel seguente formato:
net::net_dep
dove:
net Il nome della CPU dell’agent di rete. I doppi due
punti (::) rappresentano un delimitatore necessario.
Sono consentiti caratteri jolly.
net_dep La dipendenza internetwork nel seguente formato:
[cpu#] sched[.job]
Se non viene specificata alcuna CPU, il valore di
default è la CPU dello scheduler a cui è connesso
l’agent di rete. Ciò viene determinato dai campi
Nodo e Indirizzo TCP della definizione di CPU
dell’agent di rete. Sono consentiti caratteri jolly.
Le operazioni di Rilascio, Aggiungi dipendenza e Cancella dipendenza funzionano
allo stesso delle dipendenze internetwork o di altre dipendenze.
Specifica della riga comandi Conman
I comandi Conman che possono specificare le dipendenze internetwork vengono
elencati di seguito con un esempio che si basa su:
v Una CPU dello scheduler locale definita local1
v Una pianificazione definita per local1 denominata sched1
v Un lavoro in local1#sched1 definito job1
v Un agent di rete dello scheduler definito netagt
v Una CPU nella rete remota netagt definita remote1
v Una pianificazione definita per remote1 denominata rcshed
v Un lavoro in remote1#rsched definito rjob
adddep job: Aggiungere un lavoro remoto come una dipendenza Follows ad un
lavoro:
adj local1#sched1.job1;follows=netagt::remote1#rsched.rjob
Capitolo 9. Riferimento Agent di rete 305
adddep sched: Aggiungere una pianificazione remota come dipendenza Follows
ad una pianificazione:
ads local1#sched1;follows=netagt::remote1#rsched
cancel job: Annullare tutti i lavori EXTERNAL per un agent di rete (i due
comandi sono equivalenti):
cj netagt#EXTERNAL.@
cj netagt::@
confirm: Confermare che un lavoro EXTERNAL sia stato completato con esito
positivo:
confirm netagt::remote1#rsched.rjob;succ
deldep job: Cancellare una dipendenza del lavoro remoto da un lavoro:
ddj local1#sched1.job1;follows=netagt::remote1#rsched.rjob
deldep sched: Cancellare una dipendenza del lavoro remoto da una
pianificazione
dds local1#sched1;follows=netagt::remote1#rsched.rjob
release job: Rilasciare un lavoro da una dipendenza internetwork:
rj local1#sched1.job1;follows=netagt::remote1#rsched.rjob
release sched: Rilasciare una pianificazione da una dipendenza internetwork:
rs local1#sched1;follows=netagt::remote1#rsched.rjob
rerun: Eseguire nuovamente un lavoro EXTERNAL (i due comandi sono
equivalenti):
rr netagt#EXTERNAL.rjob
rr netagt::remote1#rsched.rjob
showjobs;info: Visualizzare tutte le dipendenze remote per un agent di rete con i
loro nomi originali e i nomi creati dallo scheduler:
sj netagt#EXTERNAL.@;info
submit: Inoltrare un comando rm nella pianificazione JOBS con una pianificazione
remota come dipendenza Follows:
sbd "rm apfile";follows=netagt::remote1#rsched
Vedere anche
Per informazioni sull’attività corrispondente in Job Scheduling Console, consultare
la sezione relativa alla creazione dei flussi di lavoro del manuale Guida per l’utente
di IBM Tivoli Workload Scheduler Job Scheduling Console.
306 IBM Tivoli Workload Scheduler - Manuale di riferimento
Capitolo 10. Impostazione delle definizioni di sicurezza utente
I programmi e i comandi IBM Tivoli Workload Scheduler determinano le capacità
di un utente, confrontando il nome dell’utente con le definizioni dell’utente nel file
Security. Questo capitolo spiega come scrivere le definizioni utente e gestire il file
Security.
Centralizzazione della sicurezza
L’opzione globale centralized security consente all’amministratore Tivoli Workload
Scheduler di scegliere tra i due seguenti modelli di sicurezza:
Sicurezza centralizzata
I file Security di tutte le workstation sulla rete Tivoli Workload Scheduler
possono essere creati e modificati solo su MDM (Master Domain Manager)
e l’amministratore Tivoli Workload Scheduler è responsabile della loro
produzione, gestione e distribuzione.
Nota: La sicurezza centralizzata non è supportata se si utilizzano database
non espansi IBM Tivoli Workload Scheduler.
Sicurezza locale
Il file Security di ciascuna workstation può essere gestito
dall’amministratore o dall’utente root. L’utente locale può eseguire il
comando makesec per creare o aggiornare il file.
Impostare l’opzione globale centralized security su ON per il master IBM Tivoli
Workload Scheduler, in modo da abilitare il meccanismo di sicurezza centralizzata.
Una volta attivata l’opzione globale, il programma di utilità Jnextday ricarica le
informazioni sulla sicurezza nel file Symphony. Questo file registra l’opzione come
attivata. Dopo che MDM distribuisce il file Symphony attraverso la rete, ogni
workstation avrà un proprio file Symphony contenente le stesse informazioni sulla
sicurezza.
Il meccanismo di sicurezza centralizzata viene attivato ogni volta che si stabilisce
un collegamento e quando si esegue un comando IBM Tivoli Workload Scheduler.
In una rete con il meccanismo di sicurezza centralizzata, due workstation non
potranno stabilire una connessione se una delle due ha disattivato l’opzione
centralized security nel file Symphony o se le informazioni contenute nel file
Security non corrispondono. Tuttavia, una workstation deve sempre accettare le
connessioni in arrivo dal proprio gestore dominio, anche se le informazioni nel file
Security inviate dal gestore non corrispondono a quelle contenute nel file
Symphony della workstation. Ciò viene evidenziato per consentire
all’amministratore di modificare il file Security sul master senza dover distribuirlo
di nuovo all’intera rete prima dell’esecuzione del comando Jnextday.
Ogni volta che viene eseguito un comando, con il programma conman o da Job
Scheduling Console, sulla workstation di una rete che ha attivato il meccanismo di
sicurezza centralizzata, le routine di sicurezza verificano che le informazioni nel
file Symphony corrispondano a quelle del file Security locale. Se non
corrispondono, non viene concesso l’accesso agli oggetti e ai comandi di IBM Tivoli
Workload Scheduler e viene registrato un messaggio sulla violazione della
sicurezza.
© Copyright IBM Corp. 1999, 2004 307
Il meccanismo di sicurezza centralizzata non è valido per le operazioni IBM Tivoli
Workload Scheduler che non richiedono l’utilizzo del file Symphony. I comandi che
non richiedono l’esecuzione del file Symphony, utilizzano il file Security locale. Ad
esempio, il comando parms, utilizzato per modificare o visualizzare il database dei
parametri locali, continua a funzionare in base al file Security locale, anche se la
sicurezza centralizzata è attiva e se il file locale non rispetta le regole della
sicurezza centralizzata.
Se il file Security di una workstation viene eliminato e creato di nuovo, le
informazioni sulla sicurezza in esso contenute non corrisponderanno a quelle del
file Security del master (registrato nel file Symphony). Inoltre, un meccanismo
associato al processo di creazione del file Symphony garantisce l’integrità dei dati
del file.
Gestione dei file Security
Ogni workstation in una rete IBM Tivoli Workload Scheduler (gestori dominio,
FTA e SA) possiede il proprio file Security. E’ possibile gestire un file su ogni
workstation o creare un file Security sul gestore dominio master e copiarlo su ogni
gestore dominio, FTA e SA. Verificare che a tutti gli utenti di IBM Tivoli Workload
Scheduler sia stata assegnata l’autorizzazione richiesta nel file Security.
Con il software viene fornito un file maschera denominato
TWShome/config/Security.conf. Durante l’installazione, una copia della maschera
viene installata come TWShome/config/Security.conf e una copia compilata e
operativa viene installata come TWShome/Security.conf.
Creazione del file Security
Per creare definizioni utente, modificare il file maschera TWShome/Security.conf.
Non modificare la maschera originale in TWShome/config/Security.conf. Utilizzare
il comando makesec per compilare e installare un nuovo file security operativo.
Dopo averlo installato, è possibile eseguire ulteriori modifiche utilizzando il
comando dumpsec. Consultare “dumpsec” a pagina 323 e “makesec” a pagina 324.
Modifica del file Security
Per modificare il file Security, effettuare le operazioni riportate di seguito:
1. Arrestare i connettori. Consultare “Arresto del connettore per implementare le
modifiche”.
2. Eseguire dumpsec per scaricare il file security. Consultare “dumpsec” a pagina
323.
3. Modificare la sintassi del file security. Consultare “Sintassi del file Security” a
pagina 309.
4. Eseguire makesec per caricare il file security. Consultare “makesec” a pagina
324.
5. Arrestare e avviare conman o composer per implementare le modifiche
apportate al file Security. Consultare Capitolo 5, “Riferimento a Conman”, a
pagina 123 o Capitolo 3, “Riferimento al Composer”, a pagina 35.
Arresto del connettore per implementare le modifiche
Su Windows, è necessario arrestare il connettore prima di eseguire il comando
makesec. Su UNIX, è possibile arrestarlo prima o dopo l’esecuzione del comando
makesec.
Utilizzare il comando wmaeutil per arrestare il connettore.
308 IBM Tivoli Workload Scheduler - Manuale di riferimento
Esecuzione di wmaeutil: Per eseguire il comando wmaeutil:
1. Impostare l’ambiente Tivoli:
v Da una riga comandi UNIX:
– Per ksh:
. /etc/Tivoli/setup_env.sh
– Per csh:
source /etc/Tivoli/setup_env.sh
v Da una riga comandi di Windows:
%SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd
2. Immettere il seguente comando:
v Per UNIX
wmaeutil.sh ALL -stop
v Per Windows
wmaeutil.cmd ALL -stop
Sintassi del file Security
Il file Security contiene una o più definizioni utente.
Definizioni utente
Una definizione utente definisce una serie di utenti, gli oggetti a cui essi possono
accedere e le operazioni che possono eseguire.
Sintesi
[# comment]
user def-name user-attributes
begin [* comment]
object-type [object-attributes] access[=action[,...]]
[object-type ... ]
[end]
Parametri
[# | *] comment
Tutto il testo che segue un segno # o un asterisco ed uno spazio almeno si
considera un commento. I commenti non vengono copiati nel file operativo
Security installato dal comando makesec.
def-name
Specifica il nome della definizione utente. Il nome può contenere fino a 36
caratteri alfanumerici e deve iniziare con una lettera.
user-attributes
Specifica uno o più attributi che identificano la serie di utenti a cui la
definizione si applica. Specificare gli attributi dell’utente nel modo che
segue:
user-attribute[{+ | ~}user-attribute[...]]
Capitolo 10. Impostazione delle definizioni di sicurezza utente 309
Utilizzare un segno più (+) per aggiungere un attributo all’utente o agli
utenti. Utilizzare una tilde (~) per aggiungere un attributo che un utente o
più utenti non devono avere. Un user-attribute è definito come:
cpu=wkstation|$framework|@ [,...]
dove:
wkstation
Specifica la workstation a cui è collegato l’utente. Sono
consentiti caratteri jolly. E’ possibile utilizzare le seguenti
variabili IBM Tivoli Workload Scheduler:
$master
L’utente è collegato al Gestore dominio master IBM
Tivoli Workload Scheduler.
$remotes
L’utente è collegato a ogni Agent standard IBM
Tivoli Workload Scheduler.
$slaves
L’utente è collegato a ogni FTA IBM Tivoli
Workload Scheduler.
$thiscpu
L’utente è collegato alla workstation IBM Tivoli
Workload Scheduler su cui è in esecuzione il
programma protetto.
Per gli utenti Job Scheduling Console, utilizzare
$framework.
$framework
Specifica la workstation dalla quale l’utente esegue la Job
Scheduling Console.
@ Specifica se l’utente sta accedendo a IBM Tivoli Workload
Scheduler con la Job Scheduling Console o se è collegato
alla workstation IBM Tivoli Workload Scheduler.
group=groupname[,...]
Solo per utenti UNIX. Non utilizzare questo argomento per gli
utenti Job Scheduling Console. Specifica il gruppo UNIX di cui
l’utente è membro. Sono consentiti caratteri jolly.
logon=username|tme-admin|@ [,...]
dove:
username
Specifica il nome con cui l’utente è collegato a una
workstation IBM Tivoli Workload Scheduler. Sono
consentiti caratteri jolly. L’attributo cpu= deve essere
impostato su un nome workstation o su @.
tme-admin
Specifica il nome del gruppo di amministratori Tivoli di cui
è membro l’utente. Se il nome contiene spazi, deve essere
racchiuso tra doppi apici. Sono consentiti caratteri jolly.
L’attributo cpu= deve essere impostato su $framework o
@.
@ Specifica che l’utente è registrato con un qualsiasi nome o
sia membro di un gruppo di amministratori Tivoli.
310 IBM Tivoli Workload Scheduler - Manuale di riferimento
object-type
Specifica il tipo di oggetto a cui l’utente ha il permesso di accedere. I tipi
di oggetto sono i seguenti:
calendar Calendari utenti.
cpu Workstation e domini.
file File database IBM Tivoli Workload
Scheduler.
job Lavori pianificati.
parameter Parametri utente.
prompt Prompt globali.
resource Risorse di pianificazione.
schedule Flussi di lavoro.
userobj Oggetti utente.
E’ possibile includere più tipi di oggetti in una definizione utente.
L’omissione di un tipo di oggetto impedisce l’accesso a tutti gli oggetti di
quel tipo.
object-attributes
La Tabella 11 elenca gli attributi in base al tipo di oggetto.
Tabella 11. Attributi dell’oggetto
Attributo Nome cpu jcl logon
Oggetto
calendario,
calendar
yes no no no
cpu no yes no no
file yes no no no
lavoro, job yes yes yes yes
parametro,
parameter
yes yes no no
prompt yes no no no
resource yes yes no no
schedule yes yes no no
userobj no yes no yes
Specifica uno o più attributi che identificano una serie di oggetti del tipo
specificato. Se non vengono specificati attributi, sono accessibili tutti gli
oggetti del tipo specificato. Specificare gli attributi degli oggetti nel modo
riportato di seguito:
attributo-oggetto[{+ | ~}attributo-oggetto[...]]
Utilizzare un segno più (+) per aggiungere un attributo necessario agli
oggetti. Utilizzare una tilde (~) per aggiungere un attributo che gli oggetti
non dovrebbero avere. Un object-attribute può essere uno qualsiasi dei
seguenti:
name=name[,...]
Specifica uno o più nomi per il tipo di oggetto. Sono consentiti
caratteri jolly. Più nomi devono essere separati da virgole. Se
questo attributo non è specificato, è possibile accedere a tutti gli
oggetti definiti. I seguenti valori fanno riferimento al tipo di
oggetto file:
calendars Contiene calendari.
Capitolo 10. Impostazione delle definizioni di sicurezza utente 311
cpudata Contiene workstation e domini.
jobs Contiene lavori.
mastsked Contiene flussi di lavoro.
parameters Contiene parametri.
prodsked Contiene il piano di produzione.
prompts Contiene prompt.
resources Contiene risorse.
security Il file Security.
Symphony Contiene il piano di produzione.
cpu=wkstation[,...]
Specifica uno o più workstation o nomi dominio. Sono consentiti
caratteri jolly. Più nomi devono essere separati da virgole. Se
omesso, vengono qualificate tutte le workstation. Le seguenti
variabili IBM Tivoli Workload Scheduler sono consentite: $master,
$remotes, $slaves e $thiscpu. Per ulteriori informazioni, consultare
“Variabili fornite con il prodotto” a pagina 315.
jcl=″path″ | ″cmd ″
Specifica il comando o il nome del percorso del file eseguibile del
lavoro. Il percorso o il comando devono essere racchiusi tra apici
(″). Sono consentiti caratteri jolly. Se omesso, vengono qualificati
tutti i file del lavoro e i comandi.
logon=username[,...]
Specifica il nome utente. Sono consentiti caratteri jolly. Più nomi
devono essere separati da virgole. Se omesso, vengono qualificati
tutti i nomi utente. Per il tipo di oggetto job, sono consentite le
seguenti variabili: $jclowner, $owner e $user. Per ulteriori
informazioni, consultare “Variabili fornite con il prodotto” a pagina
315.
action Specifica l’azione che può essere eseguita dall’utente. Più azioni devono
essere separate da virgole. Se non specificate, non sono consentite azioni.
L’immissione di access=@ dà agli utenti la capacità di eseguire tutte le
operazioni. La Tabella 12 e la Tabella 13 elencano tutti i tipi di azioni
possibili a seconda del tipo di oggetto.
Tabella 12. Azioni
Azione add adddep altpass altpri build cancel confirm console deldep delete display fence kill
Oggetto
calendario,
calendar
yes no no no no no no no no yes yes no no
cpu yes no no no no no no yes no yes yes yes no
file no no no no yes no no no no yes yes no no
lavoro, job yes yes no yes no yes yes no yes yes no no no
parametro,
parameter
yes no no no no no no no no yes yes no no
prompt yes no no no no no no no no yes yes no no
resource yes no no no no no no no no yes yes no no
schedule yes yes no yes no yes no no yes yes yes no no
useobj yes no yes no no no no no no yes yes no no
Tabella 13. Azioni (continuo)
Azione limit link list modify release reply rerun
shut
down start stop submit unlink use
Oggetto yes
312 IBM Tivoli Workload Scheduler - Manuale di riferimento
Tabella 13. Azioni (continuo) (Continua)
Azione limit link list modify release reply rerun
shut
down start stop submit unlink use
calendario,
calendar
no no no yes no no no no no no no no yes
cpu yes yes yes yes no no no yes yes yes no yes no
file no no no no no no no no no no no no no
lavoro, job no no yes yes yes yes yes no no no yes no yes
parametro,
parameter
no no no yes no no no no no no no no no
prompt no no yes yes no no no no no no no no yes
resource no no yes yes no no no no no no no no yes
schedule yes no yes yes yes yes no no no no yes no no
useobj no no no yes no no no no no no no no no
Note:
1. Il tipo di oggetto file viene utilizzato per gestire la sicurezza sulla CLI
ed è valido solo per la CLI.
2. Per il tipo di oggetto file, l’azione clean corrisponde all’azione build.
3. Affinché un utente possa convertire una funzione gestore domini su
una workstation, deve avere l’accesso a start e stop alla workstation.
add Aggiunge e salva i nuovi calendari nel
database.
adddep Aggiunge le dipendenze ai lavori nel piano
di produzione. Questa azione non è
disponibile sulle workstation connesse a
IBM Tivoli Workload Scheduler for z/OS
per una pianificazione end-to-end.
altpass Modifica le password dell’utente nel
database.
altpri Modifica la priorità dei lavori nel piano di
produzione. Questa azione non è
disponibile sulle workstation connesse a
IBM Tivoli Workload Scheduler for z/OS
per una pianificazione end-to-end.
build Creare i file di database di IBM Tivoli
Workload Scheduler. Questa azione è
disponibile solo dalla riga comandi.La
chiave clean che viene visualizzata nel file
Security per questo oggetto corrisponde a
build.
cancel Annulla i lavori nel piano di produzione.
Questa azione non è disponibile sulle
workstation connesse a IBM Tivoli
Workload Scheduler for z/OS per una
pianificazione end-to-end.
confirm Conferma il completamento dei lavori nel
piano di produzione. Questa azione non è
disponibile sulle workstation connesse a
IBM Tivoli Workload Scheduler for z/OS
per una pianificazione end-to-end.
Capitolo 10. Impostazione delle definizioni di sicurezza utente 313
console Visualizzare e modificare la console IBM
Tivoli Workload Scheduler.
deldep Cancella tutte le dipendenze dai lavori nel
piano di produzione. Questa azione non è
disponibile sulle workstation connesse a
IBM Tivoli Workload Scheduler for z/OS
per una pianificazione end-to-end.
delete Cancella i calendari dal database.
display Visualizza i calendari nel database.
fence Modifica i delimitatori di lavoro della
workstation nel piano di produzione.
kill Esegue il kill dei lavori nel piano di
produzione.
limit Modifica i limiti di lavoro della
workstation nel piano di produzione.
link Apre i collegamenti della workstation.
list Consente a tutti gli utenti di visualizzare le
workstation e i domini nel piano quando si
esegue una query Job Scheduling Console
o un comando conman show.
modify Modifica i calendari nel database.
release Rilascia i lavori dalle dipendenze nel piano
di produzione. Questa azione non è
disponibile sulle workstation connesse a
IBM Tivoli Workload Scheduler for z/OS
per una pianificazione end-to-end.
reply Risponde alle richieste del lavoro nel piano
di produzione.
rerun Riavvia i lavori nel piano di produzione.
Questa azione non è disponibile sulle
workstation connesse a IBM Tivoli
Workload Scheduler for z/OS per una
pianificazione end-to-end.
shutdown Arresta l’elaborazione IBM Tivoli Workload
Scheduler. Questa azione è disponibile solo
nella riga comandi.
start Avvia l’elaborazione IBM Tivoli Workload
Scheduler.
stop Arresta l’elaborazione IBM Tivoli Workload
Scheduler.
submit Inoltra i lavori nel piano di produzione.
Questa azione non è disponibile sulle
workstation connesse a IBM Tivoli
Workload Scheduler for z/OS per una
pianificazione end-to-end.
unlink Chiude i collegamenti della workstation.
314 IBM Tivoli Workload Scheduler - Manuale di riferimento
use Utilizza i calendari per pianificare i flussi
di lavoro.
Ordine di qualifica utente
Nel qualificare gli utenti all’accesso agli oggetti IBM Tivoli Workload Scheduler, gli
attributi effettivi di un utente sono confrontati con le definizioni di un utente
nell’ordine in cui le definizioni vengono immesse nel file Security. La prima
definizione che corrisponde all’utente determina le capacità dell’utente. Per questo
motivo, è importante mettere in ordine le definizioni dell’utente dalla più specifica
alla meno specifica. Ad esempio:
#Incorrect:
#First User Definition in the Security File
USER First
CPU=@+LOGON=TWSUser
Begin
...
End
#Second User Definition in the Security File
USER Second
CPU=@+LOGON=TWSDomain/TWSUser
Begin
...
End
#Correct:
#First User Definition in the Security File
USER First
CPU=@+LOGON=TWSDomain/TWSUser
Begin
...
End
#Second User Definition in the Security File
USER Second
CPU=@+LOGON=TWSUser
Begin
...
End
Per ulteriori informazioni, consultare “File Security di esempio” a pagina 319.
Ordine di qualifica oggetto
In una definizione dell’utente, è possibile utilizzare più istruzioni per un tipo di
oggetto singolo per assegnare capacità di accesso a differenti serie di oggetti.
Poiché viene utilizzata la prima istruzione corrispondente, l’ordine delle istruzioni
dell’oggetto è importante. Esse devono essere messe in ordine dalla più specifica
alla meno specifica. Ad esempio:
#Incorrect:
job name=@ access=display
job name=ar@ access=@
#Correct:
job name=ar@ access=@
job name=@ access=display
Per ulteriori informazioni, consultare “File Security di esempio” a pagina 319.
Variabili fornite con il prodotto
Le variabili fornite con il prodotto che si possono utilizzare negli attributi oggetto
sono le seguenti:
Capitolo 10. Impostazione delle definizioni di sicurezza utente 315
$jclgroup
Il nome gruppo di un file eseguibile del lavoro.
$jclowner
Il proprietario di un file eseguibile del lavoro.
$master
Il gestore dominio master IBM Tivoli Workload Scheduler.
$owner
Il generatore di un flusso di lavoro e dei relativi lavori.
$remotes
Tutte le workstation SA (standard agent).
$slaves
Tutte le workstation FTA (fault-tolerant agent).
$thiscpu
La workstation su cui l’utente esegue il comando o il programma IBM
Tivoli Workload Scheduler.
$user L’utente che esegue il comando o il programma IBM Tivoli Workload
Scheduler.
Le variabili $jclgroup e $jclowner sono verificabili solo se l’utente esegue un
programma IBM Tivoli Workload Scheduler su una workstation in cui risiede il file
eseguibile del lavoro. Se si sta eseguendo il programma su una workstation
differente, all’utente verrà negato l’accesso.
Caratteri jolly
Se notificati nelle descrizioni di sintassi, i seguenti caratteri jolly sono consentiti:
? Sostituisce un carattere alfanumerico.
% Sostituisce un carattere numerico.
@ Sostituisce zero o più caratteri alfanumerici.
Superutente su UNIX
Se il file Security non esiste, nessun utente diverso dal root potrà accedere agli
oggetti IBM Tivoli Workload Scheduler e l’utente root ha un accesso illimitato a
tutti gli oggetti e può eseguire i programmi e i comandi IBM Tivoli Workload
Scheduler. Per controllare root, creare un file Security con un definizione utente per
l’utente root. Nel file Security per una rete, è possibile effettuare una distinzione
tra utenti root locali e l’utente root nel gestore dominio master. Ad esempio, è
possibile limitare utenti locali all’esecuzione di operazioni che influenzano solo le
loro workstation di login e consentire all’utente root master di eseguire operazioni
che interessano tutte le workstation nella rete. Consultare “File Security di
esempio” per ulteriori informazioni.
Capacità di accesso
La seguente tabella elenca le parole chiave di accesso disponibili per ogni tipo di
oggetto e le capacità fornite agli utenti nella riga comandi di Tivoli Workload
Scheduler.
316 IBM Tivoli Workload Scheduler - Manuale di riferimento
Tipo di oggetto Parola chiave di accesso Capacità utente CLI
calendario,
calendar
add nd
delete nd
display composer display, create
modify nd (vedere file modify)
use composer - use calendar in schedule
cpu (domini) add composer add, new
console conman console
delete composer delete
display composer display, create
list conman showcpus
fence conman fence
limit conman limit
link conman link
modify composer modify, replace
shutdown conman shutdown
start conman start
stop conman stop
unlink conman unlink
file build composer build
delete na
display Access Security, dumpsec
modify Access Security makesec e composer
modify per calendari, parametri, prompt e
risorse
lavoro, job add composer add, new
adddep conman adddep
altpri conman altpri
cancel conman cancel
confirm conman confirm
deldep conman deldep
delete composer delete
display conman display composer display
list conman showjobs
kill conman kill
modify composer modify, replace
release conman release
reply conman reply
rerun conman rerun
submit conman submit (docommand, file, job)
use composer - use job in schedule
Capitolo 10. Impostazione delle definizioni di sicurezza utente 317
Tipo di oggetto Parola chiave di accesso Capacità utente CLI
parametro,
parameter
add parms per aggiungere i parametri
delete nd
display composer display, create e parms per
visualizzare i parametri
modify nd (vedere anche file modify)
prompt add nd
delete nd
display composer display, create conman recall
list conman showprompts
modify nd (vedere file modify)
reply conman reply
use composer - use prompt in job stream;
conman - add dependency
resource add nd
delete nd
display composer display, create
list conman showresources
modify nd (vedere file modify)
resource conman resource
use composer - use resource in job stream;
conman - add dependency
schedule add composer add, new
adddep conman adddep
altpri conman altpri
cancel conman cancel
deldep conman deldep
delete composer delete
display composer display, create conman display
elenco conman showschedules
limit conman limit
modify composer modify, replace
release conman release
reply conman reply
submit conman submit sched
userjob add composer add, new
delete composer delete
display composer display (password non
visualizzata)
modify composer modify
altpass conman altpass
318 IBM Tivoli Workload Scheduler - Manuale di riferimento
File Security di esempio
Il seguente è un file Security di esempio. Di seguito è riportata una descrizione del
file.
###########################################################
# File Security di esempio
###########################################################
# (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE
# MASTER DOMAIN MANAGER OR FRAMEWORK.
user mastersm cpu=$master,$framework + logon=maestro,root,Root_london-region
begin
# OBJECT ATTRIBUTES ACCESS CAPABILITIES
# ---------- ------------ ----------------------
job access=@
schedule access=@
resource access=@
prompt access=@
file access=@
calendar access=@
cpu access=@
parameter name=@ ~ name=r@ access=@
userobj cpu=@ + logon=@ access=@
end
###########################################################
# (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY
# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.
user sm logon=maestro,root
begin
# OBJECT ATTRIBUTES ACCESS CAPABILITIES
# ---------- ------------ ----------------------
job cpu=$thiscpu access=@
schedule cpu=$thiscpu access=@
resource cpu=$thiscpu access=@
prompt access=@
file access=@
calendar
access=@
cpu cpu=$thiscpu access=@
parameter cpu=$thiscpu
~ name=r@ access=@
end
###########################################################
# (3) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON THE
# MASTER DOMAIN MANAGER OR FRAMEWORK.
user masterop cpu=$master,$fw + group=sys
begin
# OBJECT ATTRIBUTES ACCESS CAPABILITIES
# ---------- ------------ ----------------------
job cpu=@
+ logon=TWSDomain\TWSUser access=@
job cpu=@
+ logon=root access=adddep,altpri,cancel,
confirm,deldep,release,
reply,rerun,submit,use
job cpu=@
+ logon=$user,$jclowner
~ logon=root access=add,adddep,altpri,
cancel,confirm,
deldep,release,reply,
Capitolo 10. Impostazione delle definizioni di sicurezza utente 319
rerun,submit,use
schedule cpu=$thiscpu access=@
schedule cpu=@ access=adddep,altpri,cancel,
deldep,limit,release,
submit
resource access=add,display,
resource,use
prompt access=add,display,reply,use
file access=build
calendar access=display,use
cpu cpu=@ access=@
parameter name=@ ~ name=r@ access=@
end
###########################################################
# (4) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON ANY
# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER
user op group=sys
begin
# OBJECT ATTRIBUTES ACCESS CAPABILITIES
# ---------- ------------ ----------------------
job cpu=$thiscpu
+ logon=$user access=@
job cpu=$thiscpu
+ logon=root access=adddep,altpri,cancel,
confirm,deldep,release,
reply,rerun,submit,use
job cpu=$thiscpu
~ logon=root access=adddep,altpri,cancel,
confirm,deldep,release,
reply,rerun,submit,use
schedule cpu=$thiscpu access=@
resource access=add,display,resource,use
prompt access=add,display,reply,use
file access=build
calendar access=use
cpu cpu=$thiscpu access=console,fence,limit,
link,start,stop,unlink
parameter name=@ ~ name=r@ access=@
end
###########################################################
# (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON
# ANY WORKSTATION OR FRAMEWORK.
user misusers group=mis
begin
# OBJECT ATTRIBUTES ACCESS CAPABILITIES
# ---------- ------------ ----------------------
job cpu=$thiscpu
+ logon=$user access=@
job cpu=$thiscpu
+ logon=$jclowner
~ logon=root access=submit,use
schedule cpu=$thiscpu access=add,submit,
modify,display
parameter name=r@ access=@
parameter name=@ access=display
end
###########################################################
# (6) APPLIES TO ALL OTHER USERS LOGGED IN ON ANY
# WORKSTATION.
user default logon=@
begin
# OBJECT ATTRIBUTES ACCESS CAPABILITIES
# ---------- ------------ ----------------------
job cpu=$thiscpu
+ logon=$user access=@
320 IBM Tivoli Workload Scheduler - Manuale di riferimento
job cpu=$thiscpu
+ logon=$jclowner
~ logon=root access=submit,use
schedule cpu=$thiscpu access=add,submit,
modify,display
parameter name=u@ access=@
parameter name=@ ~ name=r@ access=display
end
###########################################################
Notare che l’ordine delle definizioni va dalla più specifica alla meno specifica. A
causa dell’ordine, gli utenti maestro e root vengono confrontati per primi, seguiti
dagli utenti nel gruppo sys ed infine dagli utenti nel gruppo mis. Tutti gli altri
utenti vengono confrontati con l’ultima definizione, che è la meno specifica.
# (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE
MASTER DOMAIN MANAGER OR FRAMEWORK. user mastersm
cpu=$master,$fw + logon=maestro,root,Root_london-region
Questa definizione utente si applica all’accesso CLI e GUI di eredità per gli utenti
maestro e root collegati al gestore dominio master. Essa consente inoltre, agli utenti
elencati nel gruppo di amministratori Tivoli Root_london-region, di accedere alla
GUI Ad essi è consentito accesso illimitato a tutti gli oggetti, tranne parametri che
hanno nomi che iniziano con r. Accesso ai parametri r viene consentito solo ad
utenti nel gruppo mis.
# (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY
WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user sm
logon=maestro,root
Questa definizione utente si applica agli utenti maestro e root per cui non si
applica la definizione (1), che sono quelli collegati ad una qualsiasi workstation
diversa dal gestore dominio master o da un computer Framework. Ad essi è
consentito l’accesso illimitato a tutti gli oggetti nella loro workstation di login.
Notare che richieste, file e calendari sono per natura globali e non sono associati
con una workstation.
# (3) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON THE
MASTER DOMAIN MANAGER OR FRAMEWORK. user masterop
cpu=$master,$fw + group=sys
Questa definizione utente si applica ad utenti collegati all’interno del gruppo sys
ad un gestore dominio master o ad un computer Framework. Ad essi viene fornita
una serie univoca di capacità di accesso. Più istruzioni oggetto sono utilizzate per
fornire a questi utenti tipi specifici di accesso a serie differenti di oggetti. Ad
esempio, esistono tre istruzioni lavoro:
v La prima istruzione lavoro permette accesso illimitato a lavori che si eseguono
su qualsiasi workstation (@) sotto il nome dell’utente ($user).
v La seconda istruzione lavoro permette tipi specifici di accesso a lavori che si
eseguono su qualsiasi workstation e che vengono eseguiti come root.
v La terza istruzione lavoro permette tipi specifici di accesso a lavori che si
eseguono su qualsiasi workstation. I lavori devono essere eseguiti sotto il nome
dell’utente ($user) o sotto il nome del proprietario del file lavoro ($jclowner).
Sono esclusi lavori che si eseguono come root.
Capitolo 10. Impostazione delle definizioni di sicurezza utente 321
# (4) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON ANY
WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user op
group=sys
Questa definizione utente si applica agli utenti del gruppo sys per i quali non si
applica la definizione (3), che sono quelli collegati a qualsiasi workstation diversa
dall’MDM o da un computer Framework. Ad essi è fornita una serie di capacità di
accesso simili a quelle contenute nella definizione (3). L’eccezione è che l’accesso è
limitato ad oggetti nella workstation di login dell’utente ($thiscpu).
# (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON ANY
WORKSTATION OR FRAMEWORK. user misusers group=mis
Questa definizione utente si applica ad utenti collegati all’interno del gruppo mis a
qualsiasi workstation o ad un computer Framework. Ad essi viene fornita una
serie limitata di capacità di accesso. Risorse, richieste, file, calendari e workstation
sono omesse, il che impedisce l’accesso a questi oggetti. A questi utenti viene
consentito accesso illimitato a parametri con nomi che iniziano con r, ma possono
soltanto visualizzare gli altri parametri.
# (6) APPLIES TO ALL OTHER USERS LOGGED IN ON ANY
WORKSTATION.
user default logon=@
Questa definizione utente fornisce una serie di capacità di default ad utenti diversi
da quelli compresi nelle precedenti definizioni (1 - 5). A questi utenti viene
consentito accesso illimitato a parametri con nomi che iniziano con u, ma possono
soltanto visualizzare gli altri parametri. Non è consentito alcun accesso a parametri
con nomi che iniziano con r.
322 IBM Tivoli Workload Scheduler - Manuale di riferimento
dumpsec
Decompila il file Security e invia l’output a stdout.
L’utente deve disporre di un accesso display al file Security.
Synopsis
dumpsec -v | -u
dumpsec security-file
Description
Se non viene specificato alcun argomento, il file Security operativo
(TWShome/Security.conf) viene sottoposto a dump. Per creare una copia
modificabile di un file Security, reindirizzare l’output del comando verso un altro
file, come mostrato nei seguenti esempi.
Arguments
-v Visualizza solo informazioni relative alla versione del comando.
-u Visualizza solo informazioni relative all’uso del comando.
security-file
Specifica il nome dei file Security da sottoporre a dump.
Examples
Il seguente comando visualizza la versione del comando:
dumpsec -v
Il seguente comando registra come dump il file Security operativo in stdout:
dumpsec
Il seguente comando registra come dump il file Security operativo in un file
denominato mysec:
dumpsec > mysec
Il seguente comando registra come dump un file Security denominato sectemp in
stdout:
dumpsec sectemp
Capitolo 10. Impostazione delle definizioni di sicurezza utente 323
makesec
Compila definizioni utente ed installa il file security. Le modifiche apportate al file
security verranno riconosciute quando viene arrestato e riavviato uno dei seguenti
programmi:
Conman
Uscire dal programma ed eseguire di nuovo l’operazione.
Composer
Uscire dal programma ed eseguire di nuovo l’operazione.
Connettori IBM Tivoli Workload Scheduler
Arrestare i connettori eseguendo il comando wmaeutil. I connettori
verranno automaticamente riavviati al primo aggiornamento di una query
su Job Scheduling Console.
Per utilizzare il comando makesec, è necessario disporre dell’accesso modify al file
security.
Synopsis
makesec -v | -u
makesec [-verify] in-file
Description
Il comando makesec compila il file specificato e lo installa come file Security
operativo (../TWShome/Security). Se viene specificato l’argomento -verify, il file
viene controllato per la sintassi corretta, ma non viene compilato né installato.
Arguments
-v Visualizza solo informazioni relative alla versione del comando.
-u Visualizza solo informazioni relative all’uso del comando.
-verify
Controlla la sintassi delle definizioni utente solo in in-file . Il file non è
installato come file Security. Il controllo della sintassi viene eseguito
automaticamente quando è installato il file Security.
in-file Specifica il nome di un file o di una serie di file che contengono definizioni
utente. E’ consentito un modello di espansione del nome file.
Examples
Il seguente comando visualizza la versione del comando:
makesec -v
Il seguente comando crea una copia modificabile del file Security operativo in un
file denominato tempsec; modifica le definizioni utente con un editor di testo;
quindi compila tempsec e sostituisce il file Security operativo:
dumpsec > tempsec
edit tempsec
Qui è possibile apportare le modifiche necessarie al file tempsec. Quando viene
completata la modifica del file tempsec eseguire il comando makesec per caricare il
file security nel IBM Tivoli Workload Scheduler:
324 IBM Tivoli Workload Scheduler - Manuale di riferimento
makesec tempsec
Il seguente comando compila definizioni utente dalla serie di file userdef* e
sostituisce il file Security operativo:
makesec userdef*
Capitolo 10. Impostazione delle definizioni di sicurezza utente 325
Appendice A. Informazioni di supporto
Questa sezione descrive le seguenti opzioni per ottenere il supporto sui prodotti
IBM:
v “Ricerca basi della conoscenza”
v “Come ottenere le correzioni” a pagina 328
v “Come contattare l’assistenza software IBM” a pagina 328
Ricerca basi della conoscenza
Se si verifica un problema al software IBM, si desidera risolverlo velocemente.
Ricercare quindi gli elementi fondamentali disponibili per stabilire se la risoluzione
a questo problema è già documentata.
Ricerca nel centro informazioni sulla rete o sul sistema locale
IBM fornisce una documentazione aggiuntiva che può essere installata sul
computer locale o su un server intranet. La documentazione viene fornita sul CD
della pubblicazione disponibile con il prodotto, può essere scaricata da IBM come
descritto nella sezione “Accesso alle pubblicazioni in linea” a pagina xvi oppure
ordinata in formato cartaceo da IBM come riportato nella sezione “Richiesta
pubblicazioni” a pagina xvi.
Aprire le versioni pdf dei documenti e utilizzare la funzione di ricerca integrata di
Adobe Reader per ricercare le informazioni richieste.
Ricerca nel centro informazioni sul sito Web di supporto IBM
Il sito Web di supporto software IBM fornisce molti documenti disponibili in linea,
uno o più dei quali può contenere le informazioni richieste:
1. Visitare il sito Web http://www.ibm.com/software/support.
2. Sotto Products A - Z, selezionare il nome del prodotto: selezionare ″I″ per IBM
e scorrere l’elenco fino alle voci dei prodotti che cominciano con ″IBM Tivoli
Workload Scheduler″. In questo modo, è possibile aprire i siti di supporto di
prodotti specifici.
3. Sotto Self help e Learn, scegliere dall’elenco uno dei diversi tipi di
documentazioni di supporto del prodotto:
v Manuali
v Redbook
v Pagine bianche
v File readme e altri documenti
Per accedere ad alcuni documenti che occorre registrare (indicati da un’icona
chiave accanto al titolo del documento). Per eseguire la registrazione, selezionare il
documento che si desidera esaminare e, alla richiesta di collegamento, seguire i
link. Esiste anche un FAQ disponibile sui vantaggi della registrazione.
Ricerca in Internet
Se non si trova una risposta al problema nel centro informazioni, ricercare in
Internet le ultime informazioni che potrebbero semplificare la risoluzione del
problema.
© Copyright IBM Corp. 1999, 2004 327
Come ottenere le correzioni
Una correzione del prodotto potrebbe essere disponibile per risolvere il problema.
È possibile reperire le correzioni disponibili per il proprio prodotto IBM sul sito
Web di supporto per i prodotti:
1. Visitare il sito Web http://www.ibm.com/software/support.
2. Sotto Products A - Z, selezionare il nome del prodotto: selezionare ″I″ per IBM
e scorrere l’elenco fino alle voci dei prodotti che cominciano con ″IBM Tivoli
Workload Scheduler″. In questo modo, è possibile aprire i siti di supporto di
prodotti specifici.
3. In Self help, seguire il link a Search all Downloads, contenente un elenco di
correzioni e altri aggiornamenti di servizio per il proprio prodotto.
4. Fare clic sul nome di una correzione per leggere la descrizione ed
eventualmente scaricarla.
Per ricevere settimanalmente messaggi e-mail sulle correzioni e su altre novità sui
prodotti IBM, completare questi passi:
1. Dalla pagina di supporto per un qualsiasi prodotto IBM, fare clic su My
support nell’angolo superiore destro della pagina.
2. Se si è già registrati, passare alla fase successiva. Se non si è registrati, fare clic
sul registro nell’angolo superiore destro della pagina di supporto per stabilire
l’ID utente e la password.
3. Collegarsi a My support.
4. Nella pagina My support, selezionare la scheda Edit profile e fare clic su
Subscribe to email. Selezionare una famiglia di prodotti e contrassegnare le
caselle appropriate per il tipo di informazione desiderata.
5. Fare clic su Aggiorna.
6. Per i messaggi e-mail su altri prodotti, ripetere i passi 4 e 5.
Per ulteriori informazioni sui tipi di correzioni, consultare la sezione Software
Support Handbook (http://techsupport.services.ibm.com/guides/handbook.html).
Come contattare l’assistenza software IBM
Il servizio di assistenza IBM fornisce assistenza in caso di malfunzionamento dei
prodotti.
Prima di contattare l’assistenza IBM, la propria società deve avere un contratto di
manutenzione software IBM attivo e deve essere autorizzata a sottoporre i
problemi all’IBM. Questo tipo di contratto richiesto dipende dal tipo di prodotto
acquistato:
v Per i prodotti software IBM (inclusi i prodotti Tivoli, Lotus, Rational, DB2 e
WebSphere che vengono eseguiti sui sistemi operativi Windows o UNIX),
registrarsi a Passport Advantage in uno dei seguenti modi:
– Online: andare alla pagina web Passport Advantage
(http://www.lotus.com/services/passport.nsf/WebDocs/
Passport_Advantage_Home) e fare clic su How to Enroll
– Telefonicamente: per il numero di telefono relativo al proprio paese, visitare
il sito Web IBM (http://techsupport.services.ibm.com/guides/contacts.html) e
fare clic sul nome della regione geografica.v Per i prodotti software IBM (inclusi i prodotti DB2 e WebSphere che vengono
eseguiti in ambienti zSeries, pSeries e iSeries), è possibile acquistare un contratto
di manutenzione software direttamente da un rappresentante IBM o da un
328 IBM Tivoli Workload Scheduler - Manuale di riferimento
Business Partner IBM. Per ulteriori informazioni sul supporto dei prodotti
software eServer, visitare la pagina Web:
http://www.ibm.com/servers/eserver/techsupport.html.
Per informazioni sul tipo di contratto necessario, chiamare il numero telefonico
1-800-IBMSERV (1-800-426-7378) negli Stati Uniti oppure, dagli altri paesi, visitare
il sito Web IBM Software Support Handbook all’indirizzo
http://techsupport.services.ibm.com/guides/contacts.html e fare clic sul nome
della regione geografica per il numero di telefono del supporto tecnico locale.
Seguire i passi riportati in questo argomento per contattare l’assistenza IBM:
1. Determinare l’impatto aziendale del problema.
2. Descrivere il problema e raccogliere le informazioni di background.
3. Sottoporre il problema al personale del supporto tecnico IBM.
Determinazione dell’impatto aziendale del problema
Quando si sottopone un problema all’assistenza IBM, viene richiesto di indicare il
livello di gravità. È quindi necessario valutare l’impatto aziendale del problema
notificato. Utilizzare i seguenti criteri:
Gravità 1 Impatto aziendale critico: è impossibile utilizzare il programma
con conseguenze critiche sulle operazioni. Questa condizione
richiede una soluzione immediata.
Gravità 2 Impatto aziendale significativo: il programma è utilizzabile ma in
condizioni fortemente limitate.
Gravità 3 Grosso impatto aziendale: il programma è utilizzabile con un
numero meno incidente di funzioni inutilizzabili.
Gravità 4 Impatto aziendale minimo: il problema causa un impatto minimo
sulle operazioni.
Descrizione del problema e raccolta delle informazioni di
background
Quando si descrive un problema al personale di supporto IBM, cercare di essere
precisi. Includere tutte le informazioni importanti in modo che il personale IBM
possa risolvere il problema in maniera efficiente. Per risparmiare tempo, prepararsi
a rispondere a queste domande:
v Quale versione software era in esecuzione quando si è verificato il problema?
v Esistono messaggi, tracce e file di log correlati al problema? È probabile che il
personale del supporto tecnico IBM richieda tali informazioni.
v È possibile riprodurre il problema? Se sì, quali passi hanno causato l’errore?
v Sono state apportate modifiche al sistema? Ad esempio, hardware, sistema
operativo, software di rete e così via.
v Viene correntemente applicata una soluzione temporanea al problema? Se sì,
prepararsi a descriverla alla notifica del problema.
Notifica del problema all’assistenza IBM
È possibile sottoporre il problema all’assistenza in uno dei seguenti modi:
v Online: Andare alla pagina ″Submit and track problems″ del sito di supporto
tecnico IBM (http://www.ibm.com/software/support/probsub.html). Specificare
le informazioni nel campo di immissione appropriato.
Appendice A. Informazioni di supporto 329
v Telefonicamente: per il numero di telefono relativo al proprio paese, visitare il
sito Web IBM Software Support Handbook
(http://techsupport.services.ibm.com/guides/contacts.html) e fare clic sul nome
della regione geografica.
Se il problema è causato da un errore software o da una documentazione
imprecisa, l’assistenza IBM crea un APAR (Authorized Program Analysis Report).
L’APAR descrive dettagliatamente il problema. Se possibile, l’assistenza IBM
fornisce una soluzione temporanea da applicare fino alla risoluzione dell’APAR.
IBM pubblica gli APAR risolti nelle pagine web di supporto dei prodotti IBM, in
modo che se altri utenti incontrano lo stesso problema possono applicare le stesse
risoluzioni.
Per ulteriori informazioni sulla risoluzione dei problemi, consultare le sezioni
Ricerca basi della conoscenza e Come ottenere le correzioni.
330 IBM Tivoli Workload Scheduler - Manuale di riferimento
Appendice B. Gestione dei fusi orari
IBM Tivoli Workload Scheduler supporta fusi orari differenti. L’abilitazione dei fusi
orari fornisce all’utente la capacità di gestire il proprio workload a livello globale.
L’implementazione del fuso orario consente anche una facile pianificazione
attraverso più fusi orari e per lavori che si devono eseguire nella ″zona morta.″ La
zona morta è l’intervallo tra l’ora di avvio del giorno IBM Tivoli Workload
Scheduler su MDM e l’ora nell’FTA in un altro fuso orario. Ad esempio, se un
master orientale con un’ora di avvio del giorno IBM Tivoli Workload Scheduler
impostata su 6 a.m. inizializza un agent occidentale con una differenza di fuso
orario di 3 ore, la zona morta per questo FTA è compresa tra le 3 a.m. e le 6 a.m.
In precedenza, si richiedeva una gestione speciale per eseguire i lavori entro questo
lasso di tempo. Adesso, abilitando la funzione fuso orario e specificando un fuso
orario con un’ora di avvio per un lavoro o un flusso di lavoro, IBM Tivoli
Workload Scheduler eseguirà il lavoro all’ora prevista.
La Figura 8 mostra l’ora di avvio del giorno e la zona morta per un master
orientale con l’ora di avvio IBM Tivoli Workload Scheduler impostata su 6 a.m. ed
un agent occidentale con una differenza di fuso orario di tre ore.
Attivazione della funzione fuso orario
Attivare la funzione fuso orario su IBM Tivoli Workload Scheduler effettuando le
seguenti operazioni:
1. Impostare su yes l’opzione Timezone enable nel file TWSHOME/mozart/globalopts
su MDM (Master Domain Manager). Il valore di default è no e il fuso orario
non è abilitato.
2. Impostare un fuso orario specifico per ogni workstation nella rete IBM Tivoli
Workload Scheduler modificando le proprietà della workstation tramite Job
Scheduling Console.
Se non si specifica un fuso orario per una workstation, verrà utilizzato il fuso
orario del gestore master.
Master
Agente tolleranzaerrore
3h
3 am
6 am
Area inattiva
Inizio giorno
Iniziogiorno
6 am
24h
Area inattiva
3 am
3h
Inizio giorno
Iniziogiorno
Figura 8. Zone morte
© Copyright IBM Corp. 1999, 2004 331
Per ulteriori informazioni su come abilitare la funzione fuso orario, consultare
Manuale per la pianificazione e installazione di IBM Tivoli Workload Scheduler.
Esecuzione di un flusso di lavoro senza l’abilitazione del fuso
orario quando il gestore dominio master è in anticipo su FTA
Questa sezione mostra l’istruzione della definizione del flusso di lavoro per
eseguire un flusso di lavoro ogni giorno lavorativo su un FTA PST (Pacific
Standard Time) collegato a un gestore dominio master EST (Eastern Standard
Time) con l’ora di avvio del giorno impostata su 06:00 a.m., se non si abilita la
funzione fuso orario. Per eseguire questo flusso di lavoro ogni mattina dei giorni
feriali, è necessario pianificare l’esecuzione da domenica a giovedì e specificare le
parole chiave carryforward e at nel seguente modo:
Schedule FTA# PST_SCHEDULE1
On SU, weekdays except FR
CARRYFORWARD
AT 0330
.
.
job1
job2
END
Se non si specifica la parola chiave carryforward, il lavoro non potrebbe mai essere
eseguito perché FTA viene inizializzato ogni giorno alle 03:00 a.m.
Esecuzione di un flusso di lavoro con l’abilitazione del fuso
orario quando il master è in anticipo su FTA
Questa sezione mostra l’istruzione della definizione del flusso di lavoro per
eseguire un flusso di lavoro ogni giorno lavorativo su un FTA PST collegato a un
gestore dominio master EST con l’ora di avvio del giorno impostata su 06:00 a.m.,
se si abilita la funzione fuso orario. Per eseguire questo flusso di lavoro ogni
mattina dei giorni feriali, è necessario pianificarne l’esecuzione ogni giorno
lavorativo specificando la parole chiave at nel seguente modo:
Schedule FTA# PST_SCHEDULE2
On weekdays
AT 0330
.
.
job1
job2
END
Quando il gestore dominio master inizializza l’FTA PST alle 03:00, l’FTA avvia il
flusso di lavoro nello stesso giorno alle 03:00.
Esecuzione di un flusso di lavoro senza l’abilitazione del fuso
orario quando il gestore dominio master è in ritardo su FTA
Questa sezione mostra l’istruzione della definizione del flusso di lavoro per
eseguire un flusso di lavoro ogni giorno lavorativo su un FTA orientale collegato a
un gestore dominio master PST con l’ora di avvio del giorno impostata su 06:00
a.m., se non si abilita la funzione fuso orario. Per eseguire questo flusso di lavoro
ogni mattina dei giorni feriali, è necessario pianificare l’esecuzione da domenica a
giovedì e specificare la parola chiave carryforward e +1DAY per la parola chiave at
nella seguente istruzione:
332 IBM Tivoli Workload Scheduler - Manuale di riferimento
Schedule FTA1#EST_SCHEDULE1
On SU, weekdays except FR
AT 0800 + 1 DAY CARRYFORWARD
.
.
job1
job2
END
È necessario specificare la parola chiave carryforward perché altrimenti il flusso di
lavoro non viene selezionato per essere incluso nel piano che verrà eseguito il
giorno successivo. Senza la specifica di +1DAY, il flusso di lavoro verrebbe avviato
immediatamente dopo l’inizializzazione da parte del master occidentale alle 09:00.
Esecuzione di un flusso di lavoro con l’abilitazione del fuso
orario quando il gestore dominio master è in ritardo su FTA
Questa sezione mostra l’istruzione della definizione del flusso di lavoro per
eseguire un flusso di lavoro ogni giorno lavorativo su un FTA orientale collegato a
un master PST con l’ora di avvio del giorno impostata su 06:00 a.m., se si abilita la
funzione fuso orario. Per eseguire il flusso di lavoro ogni giorno mattina dei giorni
feriali, specificare la seguente istruzione:
Schedule FTA1#EST_SCHEDULE2
On SU, weekdays except FR
AT 0800
.
.
job1
job2
END
Quando l’FTA orientale viene inizializzato alle 09:00, eseguirà il flusso di lavoro
alle 08:00 del giorno successivo.
Inoltro ad hoc di un flusso di lavoro specificando una
dipendenza at
Questa sezione descrive come inoltrare ad hoc un flusso di lavoro specificando una
dipendenza at. Se si definisce un flusso di lavoro senza una dipendenza temporale,
specificare una dipendenza at utilizzando il programma Conman sul gestore
dominio master. Ad esempio, è stato definito il flusso di lavoro SCHED1 senza la
dipendenza at nel seguente modo:
Schedule FTA1#SCHED1
on request
.
.
job1
END
Per inoltrare il flusso di lavoro SCHED1 con una dipendenza at PST, eseguire il
seguente comando Conman sul gestore dominio master:
sbs FTA1#SCHED1 ;at=0400 TZ PST
Il gestore dominio master converte l’ora di inoltro ad esempio, 2:00 p.m. ECT nel
fuso orario (PST) specificato nel comando. Il gestore dominio master poi confronta
il valore specificato nella parola chiave at con quello risultante:
v Se il valore della dipendenza at è successivo o uguale a quello risultante, la
pianificazione verrà eseguita nello stesso giorno.
Appendice B. Gestione dei fusi orari 333
v Se il valore della dipendenza at è precedente o uguale a quello risultante, la
pianificazione verrà eseguita il giorno successivo.
La data ottenuta e l’ora specificata nel comando (4:00 a.m. PST) vengono convertite
dal gestore dominio master dal fuso orario (PST) indicato nel comando in quello
specificato sulla workstation FTA1.
Inoltro di un flusso di lavoro specificando una dipendenza at
con l’ora legale
Questa sezione descrive come inoltrare un flusso di lavoro specificando una
dipendenza at con l’ora legale. Si consideri un gestore dominio master definito con
il fuso orario ECT (GMT+1:00). La data è il 3 aprile, 2005. In questa data, il fuso
orario ECT utilizza già l’ora legale e quindi è GMT+2:00. Viene inoltrato un flusso
di lavoro con la dipendenza at per il fuso orario PST (GMT-8:00):
Schedule MDM#SCHED1
AT 0230 TZ PST
.
.
job1
job2
END
Nella fascia oraria PST del 3 aprile, 2005 alle 2:00 a.m. si verifica un cambiamento
dell’ora, da quella standard all’ora legale (DST), che viene spostata in avanti di
un’ora (3:00 a.m.) e il fuso orario viene modificato da GMT-8:00 in GMT-7:00. Il
gestore dominio master converte la dipendenza dell’ora AT 0230 TZ PST nella
fascia oraria dell’FTA su cui deve essere eseguito il lavoro, che in questo caso è il
fuso orario dello stesso gestore dominio master (ETC). Tutte le dipendenze dell’ora
comprese tra AT 0200 TZ PST e AT 0259 TZ PST vengono convertite in ECT 11:59,
perché tutti i minuti nella fascia oraria PST corrispondono ad un solo minuto in
quella ECT. Al di fuori di questo intervallo di dipendenze dell’ora, qualsiasi
dipendenza viene convertita seguendo le regole di conversione standard. Ad
esempio, la dipendenza dell’ora AT 03:00 TZ PST viene convertita in ECT 12:00. La
dipendenza AT 03:01 TZ PST viene convertita in ECT 12:01 e così via.
Elenco dei fusi orari
Questa sezione elenca i fusi orari supportati e le relative descrizioni.
Nome Descrizione Relativo a GMT
GMT GMT (Greenwich Mean Time) GMT
UTC Universal Coordinated Time GMT
ECT European Central Time GMT+1:00
EET EET (Eastern European Time) GMT+2:00
ART ART (Egypt Standard Time Arabic) GMT+2:00
EAT Eastern African Time GMT+3:00
MET Middle East Time GMT+3:30
NET Near East Time GMT+4:00
PLT Pakistan Lahore Time GMT+5:00
IST India Standard Time GMT+5:30
BST Bangladesh Standard Time GMT+6:00
VST Vietnam Standard Time GMT+7:00
334 IBM Tivoli Workload Scheduler - Manuale di riferimento
Nome Descrizione Relativo a GMT
CTT China Taiwan Time GMT+8:00
JST Japan Standard Time GMT+9:00
ACT Australia Central Time GMT+9:30
AET Australia Eastern Time GMT+10:00
SST Solomon Standard Time GMT+11:00
NST New Zealand Standard Time GMT+12:00
MIT Midway Islands Time GMT-11:00
HST Hawaii Standard Time GMT-10:00
AST Alaska Standard Time GMT-9:00
PST Pacific Standard Time GMT-8:00
PNT Phoenix Standard Time GMT-7:00
MST Mountain Standard Time GMT-7:00
CST Central Standard Time GMT-6:00
EST Eastern Standard Time GMT-5:00
IET Indiana Eastern Standard Time GMT-5:00
PRT Puerto Rico and US Virgin Islands Time GMT-4:00
CNT Canada Newfoundland Time GMT-3:30
AGT Argentina Standard Time GMT-3:00
BET Brazil Eastern Time GMT-3:00
CAT Central African Time GMT-1:00
Appendice B. Gestione dei fusi orari 335
Appendice C. Funzione di controllo
Una opzione di controllo è disponibile per tenere traccia delle modifiche sul
database e sul piano:
v Per il database, vengono registrate tutte le modifiche dell’utente. Tuttavia, il
delta delle modifiche, prima dell’immagine o dopo l’immagine, non verrà
registrato. Se si apre e si salva un oggetto, l’operazione verrà registrata anche nel
caso in cui non siano state apportate modifiche.
v Per quanto concerne il piano, tutte le modifiche dell’utente al piano vengono
registrate. Le azioni vengono registrate, a prescindere dal loro esito.
I log di verifica vengono creati nelle seguenti directory:
TWShome/audit/plan
TWShome/audit/database
I file di controllo vengono registrati su un file di testo flat su sistemi singoli nella
rete IBM Tivoli Workload Scheduler. Ciò riduce i rischi di errore di controllo dovuti
a problemi di rete ed abilita un approccio diretto alla scrittura della log. I formati
dei log sono identici sia nel piano che nel database in un senso generico. Il log è
formato da una parte di intestazione identica per tutti i record, un ID azione e una
sezione di dati che variano a seconda del tipo di azione. Tutti i dati sono
conservati in testo semplice e formattati per consentirne la lettura e la modifica con
un editor di testo come vi o Blocco note.
Nota: Per modificare i comandi, vengono create due voci nella log per le risorse,
per i calendari, i parametri e le richieste. Il comando di modifica viene
visualizzato nella log come i comandi di cancellazione e di aggiunta.
Abilitazione della funzione di controllo
L’opzione di controllo è abilitata da due voci nel file globalopts:
plan audit level = 0|1
database audit level = 0|1
Un valore pari a 1 abilita il controllo e un valore pari a 0 disabilita il controllo.
IBM Tivoli Workload Scheduler attualmente è impostato per default su 0 o la
modifica è disabilitata. Se queste opzioni non sono presenti nel file globalopts, il
controllo è disabilitato. La verifica viene disattivata per default durante
l’installazione del prodotto.
Per inizializzare il controllo del database, è necessario chiudere IBM Tivoli
Workload Scheduler completamente e utilizzare il comando wmaeutil per arrestare
l’istanza del connettore. Quando si riavviano il IBM Tivoli Workload Scheduler e
l’istanza del connettore, viene avviata la log di controllo del database. Il controllo
del piano diventa effettivo nel momento in cui viene eseguito Jnextday.
© Copyright IBM Corp. 1999, 2004 337
Formato del file di log di controllo
I formati della log di controllo sono fondamentalmente gli stessi per il piano e per
il database. La log è costituita da una parte di intestazione, da un ID dell’azione e
dalle sezioni dei dati che variano a seconda del tipo di azione. I dati sono in
formato testo chiaro e ogni voce dati è separata da una barra verticale ( | ).
Le voci del file di log avranno il seguente formato:
Log Type|GMT Date|GMT Time|Local Date|Local
Time|Object Type|Action Type|Workstation
Name|User ID|Framework User|Object Name|Action
Data fields
I file di log contengono le seguenti informazioni:
Tipo di log
Questo campo visualizza un valore di otto caratteri indicante l’origine del
record della log. Sono supportati i seguenti tipi di log:
HEADER
Intestazione del file di log
CONMAN
Testo comando conman
FILEAID
Comando che indica l’apertura di un file
PLAN Pianificazione dell’azione
STAGEMAN
Esecuzione stageman
RELEASE
Testo comando release
DATABASE
Azione database
PARMS
Testo comando parametro
MAKESEC
makesec run
DBEXPAND
dbexpand run
Data GMT
Questo campo visualizza la data GMT in cui è stata eseguita l’azione. Il
formato è yyyymmdd, dove yyyy è l’anno, mm è il mese e dd è il giorno.
Ora GMT
Questo campo visualizza l’ora GMT in cui è stata eseguita l’azione. Il
formato è hhmmss , dovehh è l’ora, mm indica i minuti e ss indica i secondi.
Data locale
Questo campo visualizza la data locale in cui è stata eseguita l’azione. La
data locale è definita dall’opzione del fuso orario della workstation. Il
formato è yyyymmdd, dove yyyy è l’anno, mm è il mese e dd è il giorno.
Ora locale
Questo campo visualizza l’ora locale in cui è stata eseguita l’azione. L’ora
338 IBM Tivoli Workload Scheduler - Manuale di riferimento
locale è definita dall’opzione del fuso orario della workstation. Il formato è
hhmmss, dove hh è l’ora, mm indica i minuti e ss indica i secondi.
Tipo di oggetto
Questo campo visualizza il tipo di oggetto interessato dall’azione. Il tipo di
oggetto è uno dei seguenti:
DATABASE
Definizione del database
DBWKSTN
Definizione workstation database
DBWKCLS
Definizione classe workstation database
DBDOMAIN
Definizione dominio database
DBUSER
Definizione utente database
DBJBSTRM
Definizione flusso di lavoro del database
DBJOB
Definizione lavoro database
DBCAL
Definizione calendario database
DBPROMPT
Definizione prompt database
DBPARM
Definizione parametro database
DBRES
Definizione risorsa database
DBSEC
Sicurezza database
PLAN Pianificazione
PLWKSTN
Pianificazione workstation
PLDOMAIN
Pianificazione dominio
PLJBSTRM
Pianificazione flusso di lavoro
PLJOB
Pianificazione lavoro
PLPROMPT
Pianificazione prompt
PLRES
Pianificazione risorsa
PLFILE
Pianificazione file
Appendice C. Funzione di controllo 339
Tipo di azione
Questo campo visualizza l’azione da eseguire riguardo l’oggetto. I valori
appropriati per questo campo dipendono dall’azione eseguita.
Per il database, il Tipo di azione può essere ADD, DELETE, MODIFY,
OPEN o INSTALL. IBM Tivoli Workload Scheduler registrerà le azioni
ADD, DELETE e MODIFY per le workstation, le classi di workstation, i
domini, gli utenti, i lavori, i flussi di lavoro, i calendari, le prompt, le
risorse e i parametri nel database. Il campo Tipo di azione registra anche
l’installazione di un nuovo file di sicurezza. Quando si esegue makesec,
IBM Tivoli Workload Scheduler la registra come azione INSTALL per gli
oggetti di definizione della sicurezza. Quando si esegue dbexpand, questa
viene registrata come azione EXPAND per un oggetto DATABASE. Le
azioni LIST e DISPLAY per gli oggetti non vengono registrate. Per fileaid
IBM Tivoli Workload Scheduler registrerà solo i comandi risultanti
dall’apertura di un file. Per i parametri, viene registrata la riga comandi
con gli argomenti.
Nome workstation
Questo campo visualizza la workstation IBM Tivoli Workload Scheduler da
cui l’utente esegue l’azione.
ID utente
Questo campo visualizza l’utente di logon che ha eseguito l’azione
particolare. Su piattaforme Win32 sarà il nome dominio completo
domain\user.
Utente framework
Questo campo visualizza l’ID utente riconosciuto da Tivoli Framework.
Questo è l’ID di login dell’utente Job Scheduling Console.
Nome oggetto
Questo campo visualizza il nome completo dell’oggetto. Il formato di
questo campo dipenderà dal tipo di oggetto come mostrato di seguito:
DATABASE
N/A
DBWKSTN
workstation
DBWKCLS
workstation_class
DBDOMAIN
dominio
DBUSER
[workstation#]user
DBJBSTRM
workstation#jobstream
DBJOB
workstation#job
DBCAL
calendario
DBPROMPT
prompt
340 IBM Tivoli Workload Scheduler - Manuale di riferimento
DBPARM
workstation#parameter
DBRES
workstation#resource
DBSEC
N/A
PLAN N/A
PLWKSTN
workstation
PLDOMAIN
dominio
PLJBSTRM
workstation#jobstream_instance
PLJOB
workstation#jobstream_instance.job
PLPROMPT
[workstation#]prompt
PLRES
workstation#resource
PLFILE
workstation#path(qualifier)
Dati dipendenti dall’azione
Questo campo visualizza i campi dei dati specifici per l’azione. Il formato
di questi dati dipende dal campo Tipo azione.
Intestazione del file di log di controllo
Ogni file di log verrà avviato con un record di intestazione che contiene
informazioni relative al momento in cui è stata creata la log e se è un piano o una
log del database.
Il contenuto della voce file di intestazione è:
Tipo di log
INTESTAZIONE
Data GMT
La data GMT in cui è stato creato il file di log.
Ora GMT
L’ora GMT in cui è stato creato il file di log.
Data locale
La data locale in cui è stato creato il file di log.
Ora locale
L’ora locale in cui è stato creato il file di log.
Nome workstation
Il nome della workstation IBM Tivoli Workload Scheduler per cui viene
creato questo file. Ogni workstation nella rete IBM Tivoli Workload
Scheduler crea una log propria.
Appendice C. Funzione di controllo 341
ID utente
L’ID utente IBM Tivoli Workload Scheduler che ha creato il file di log.
Tipo di oggetto
Questo campo legge DATABASE per un file di log del database e PLAN
per un piano del file di log.
Nome oggetto
N/A
Tipo di azione
N/A
Dati dipendenti dall’azione
Questo campo visualizza la versione del file.
Voci log di controllo di esempio
Di seguito vengono riportate le voci del file di log di esempio:
HEADER |19991202|201200|19991202|131200|DATABASE| |GANGES
|RIVERS\pyasa |||1.0
DATABASE|19991202|224504|19991202|154504|DBWKSTN |ADD
|GANGES |RIVERS\pyasa ||JAMUNA|
DATABASE|19991203|001400|19991202|171400|DBJOB |MODIFY |SINDHU
|RIVERS\tairak ||NARMADA#dubo|
342 IBM Tivoli Workload Scheduler - Manuale di riferimento
Informazioni particolari
Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati
Uniti. IBM potrebbe non offrire i prodotti, i servizi o le funzioni descritte in questo
documento in altri paesi. Rivolgersi al rappresentante IBM locale per informazioni
sui prodotti e i servizi disponibili nel proprio paese. Qualsiasi riferimento a un
prodotto, programma o servizio IBM non è inteso per affermare implicitamente o
esplicitamente che può essere utilizzato solo quel prodotto, programma o servizio.
Può essere utilizzato qualsiasi prodotto, programma o servizio equivalente che non
violi la proprietà intellettuale di IBM. Tuttavia, è responsabilità dell’utente finale
valutare e verificare il funzionamento di programmi, prodotti o servizi non IBM.
IBM può avere brevetti o domande di brevetti in corso relativi a quanto trattato
nella presente pubblicazione. La fornitura di questa pubblicazione non implica la
concessione di alcuna licenza su essi. È possibile inviare domande sulla licenza, per
iscritto, al seguente indirizzo:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785 U.S.A.
Per le domande sulla licenza relative a informazioni double-byte (DBCS), rivolgersi
al dipartimento della proprietà intellettuale IBM del proprio paese o inviare le
domande a:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
I seguenti paragrafi non si applicano al Regno Unito o a qualsiasi altro paese in
cui tali norme sono in contrasto con la legge locale:
INTERNATIONAL BUSINESS MACHINES CORPORATION FORNISCE QUESTA
PUBBLICAZIONE ″COSI’ COM’È″ SENZA GARANZIA DI ALCUN TIPO, CHE
SIA ESPRESSA O IMPLICITA, INCLUSE, MA NON LIMITATO A, LE GARANZIE
IMPLICITE DI NON VIOLAZIONE, COMMERCIABILITA’ O IDONEITA’ AD
UNO SCOPO PARTICOLARE.
Alcuni stati non consentono il disconoscimento di garanzie espresse o implicite in
alcune transazioni, pertanto queste dichiarazioni potrebbero non essere applicabili.
Queste informazioni possono includere imprecisioni tecniche o errori ortografici. Le
informazioni sono soggette a modifiche periodiche che saranno incorporate nelle
nuove edizioni della pubblicazione. IBM può apportare miglioramenti e/o
modifiche ai prodotti e/o ai programmi descritti in questa pubblicazione in
qualsiasi momento senza preavviso.
Qualsiasi riferimento presente in queste informazioni a siti Web non IBM è fornito
solo per utilità e non intende essere un’approvazione di tali siti. I materiali presenti
su tali siti Web non fanno parte dei materiali relativi a questo prodotto IBM e
l’utente utilizza i siti a proprio rischio.
© Copyright IBM Corp. 1999, 2004 343
IBM può utilizzare o distribuire qualsiasi informazione fornita in qualsiasi modo
ritenga appropriato senza incorrere in obblighi verso l’utente.
I possessori di licenza di questo programma che desiderano informazioni sul
programma stesso a scopo di consentire: (i) lo scambio di informazioni tra
programmi creati indipendentemente e altri programmi (incluso questo) e (ii) l’uso
reciproco di informazioni scambiate, si rivolgano a:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.
La disponibilità di tali informazioni può dipendete da termini e condizioni inclusa,
in alcuni casi, il pagamento di una tassa.
Il programma concesso su licenza descritto in questo documento e tutto il
materiale concesso su licenza ad esso relativo sono forniti da IBM nei termini
nell’accordo con il cliente, dell’accordo di licenza dei programmi internazionale o
di qualsiasi altro accordo equivalente dell’IBM.
Le informazioni relative a prodotti non IBM sono state ottenute dai fornitori di tali
prodotti. L’IBM non ha verificato tali prodotti e, pertanto, non può garantirne
l’accuratezza delle prestazioni. Eventuali commenti relativi alle prestazioni dei
prodotti non IBM devono essere indirizzati ai fornitori di tali prodotti.
Queste informazioni contengono esempi di dati e report di operazioni aziendali
quotidiane. Gli esempi includono i nomi di persone, società, marchi e prodotti.
Tutti questi nomi sono fittizi e qualsiasi similarità con nomi e indirizzi utilizzati da
società reali è puramente accidentale.
Marchi
IBM, il logo IBM, z/OS, Tivoli e il logo Tivoli sono marchi della International
Business Machines Corporation negli Stati Uniti e/o in altri paesi.
Microsoft e Windows NT sono marchi della Microsoft Corporation negli Stati Uniti
e/o in altri paesi.
UNIX è un marchio registrato di negli Stati Uniti e in altri paesi con licenza
esclusiva di The Open Group.
Nomi di altri prodotti, società e servizi menzionati in questo documento possono
essere marchi di altre società.
344 IBM Tivoli Workload Scheduler - Manuale di riferimento
Glossario
A
Metodo di accesso. Un metodo di accesso è un file
eseguibile utilizzato dagli agent estesi per collegarsi e
controllare l’esecuzione del lavoro su altri sistemi
operativi (ad esempio, MVS) e le applicazioni (ad
esempio, Applicazioni Oracle, Peoplesoft e Baan). Il
metodo di accesso deve essere specificato nella
definizione di workstation per l’agent esteso (XA)
B
Batchman. Il Batchman è un processo avviato
all’inizio di ogni giorno di elaborazione di Tivoli
Workload Scheduler per avviare i lavori in conformità
con le informazioni nel file Symphony.
C
Calendario. Un calendario è un oggetto definito nel
database del Tivoli Workload Scheduler che contiene un
elenco di date di pianificazione. Poiché è un oggetto
univoco definito nel database, può essere assegnato a
più flussi di lavoro. Quando si assegna un calendario
ad un flusso di lavoro, il flusso di lavoro viene eseguito
nei giorni specificati nel calendario. Tenere presente che
un calendario può essere utilizzato come ciclo di
esecuzione inclusivo o esclusivo.
Conman. Conman (gestore console) è un’applicazione
della riga comandi per la gestione dell’ambiente di
produzione. Il Conman esegue le seguenti attività:
avvia e arresta i processi di produzione, modifica e
visualizza le pianificazioni e i lavori nel piano e
controlla il collegamento della workstation in una rete.
Composer. Composer è un’applicazione della riga
comandi di eredità per la gestione delle definizioni
degli oggetti di pianificazione nel database.
D
Database. Il database contiene tutte le definizioni
create per gli oggetti di pianificazione (ad esempio,
lavori, flussi di lavoro, risorse, workstation, ecc). Nel
database vengono anche conservate altre importanti
informazioni, quali le statistiche su un lavoro e
sull’esecuzione del flusso di lavoro, le informazioni
sull’ID utente che ha creato un oggetto e l’indicazione
dell’ultima data in cui un oggetto è stato modificato. Al
contrario, il piano contiene solo quei lavori e flussi di
lavoro (che includono gli oggetti dipendenti) che
vengono specificati per l’esecuzione nella produzione
giornaliera.
Tempo limite. L’ultimo momento in cui è possibile
avviare l’esecuzione di un lavoro o di un flusso di
lavoro. Corrisponde a Fino all’ora nel Maestro di
eredità.
Dipendenza. Una dipendenza è un prerequisito che
deve essere soddisfatto prima che l’esecuzione di un
lavoro o flusso di lavoro possa procedere. Il numero
massimo di dipendenze consentite per un lavoro o
flusso di lavoro è 40. I quattro tipi di dipendenze
utilizzati da Tivoli Workload Scheduler son o le
dipendenze follows, resource, file e prompt.
Dominio. Un dominio è un gruppo denominato delle
workstation Tivoli Workload Scheduler composto da
uno o più agent e da un DM con funzione di hub di
gestione. Tutti i domini hanno un dominio parent
tranne il dominio master.
Gestore dominio. L’hub di gestione in un dominio
Tivoli Workload Scheduler. Tutte le comunicazioni da e
verso gli agent nel dominio vengono instradate tramite
il Gestore dominio.
Durata. Il tempo previsto per il completamento del
lavoro. Nella vista Tabella orari dei lavori nel database,
la durata viene rappresentata da una barra blu chiaro al
centro della barra delle attività o da un diamante blu
chiaro.
E
Ora precedente di avvio. L’ora prima della quale non
è possibile avviare il lavoro o il flusso di lavoro. La
prima ora di avvio viene stimata basandosi sulle
precedenti esperienze nell’esecuzione del lavoro o del
flusso di lavoro. Tuttavia, il lavoro o il flusso di lavoro
può iniziare dopo l’ora specificata, ammesso che siano
state soddisfatte tutte le altre dipendenze. Nella tabella
orari, l’ora di avvio è rappresentata dall’inizio (margine
sinistro) della barra delle attività blu navy. Per le
istanze di lavoro, l’ora di avvio calcolata da OPC viene
rappresentata da una barra blu chiaro. Consultare
anche“Ora di avvio reale” e “Ora di avvio
programmata”.
Ciclo di esecuzione o esclusivo. Un ciclo di
esecuzione che specifica i giorni in cui un flusso di
lavoro non può essere eseguito. I cicli di esecuzione o
esclusivi hanno la precedenza sui cicli di esecuzione o
inclusivi.
Database esteso. I database estesi consentono nomi
più lunghi per gli oggetti database come i lavori, flussi
di lavoro, workstation, domini e utenti. I database
estesi vengono configurati utilizzando il comando
© Copyright IBM Corp. 1999, 2004 345
dbexpand o un’opzione durante l’installazione. Non
espandere il database prima di aver compreso le
implicazioni e gli effetti di questo comando.
Agent estesi (XA). XA (Extended agents) vengono
utilizzati per integrare il dispositivo di controllo del
lavoro di Tivoli Workload Scheduler con altri sistemi
operativi (ad esempio, MVS) e applicazioni (ad
esempio, Applicazioni Oracle, Peoplesoft e Baan). Gli
agent estesi utilizzano degli script definiti metodi di
accesso per comunicare con sistemi esterni.
Lavoro esterno. Un lavoro proveniente da un flusso di
lavoro che è predecessore di un lavoro in un altro
flusso di lavoro. Un lavoro esterno viene rappresentato
da un’icona sostitutiva nella Vista grafica del flusso di
lavoro.
F
Agent a prova di errore. Una workstation dell’agent
nella rete di Tivoli Workload Scheduler capace di
risolvere le dipendenze locali e di inviare i relativi
lavori in assenza del Gestore dominio.
Contenitore. Il contenitore del lavoro è un controllo
master sull’esecuzione del lavoro su una workstation. Il
delimitatore lavoro è un livello di priorità che la
priorità del lavoro o flusso di lavoro deve superare
prima che possa iniziare l’esecuzione. Ad esempio, se il
delimitatore è stato impostato su 40, i lavori con
priorità inferiore a 40 non vengono avviati.
Flusso di lavoro finale. Il flusso di lavoro FINALE è
l’ultimo flusso di lavoro che viene eseguito nel giorno
di produzione. Contiene un lavoro che esegue il file di
script Jnextday.
Dipendenze Follows. Una dipendenza che impedisce
l’esecuzione di un lavoro o di un flusso di lavoro fino a
quando altri lavori o i flussi di lavoro non sono stati
completati.
G
Opzioni globali. Le opzioni globali vengono definite
sull’MDM (master domain manager) nel file globalopts
e si applicano a tutte le workstation della rete Tivoli
Workload Scheduler. Consultare inoltre “Opzioni
locali”.
H
Host. Una workstation Workload Scheduler richiesta
dagli agent estesi (XA). Può trattarsi di qualunque
workstation Tivoli Workload Scheduler ad eccezione di
un altro agent esteso (XA).
I
Ciclo di esecuzione o inclusivo. Un ciclo di
esecuzione o esclusivo che specifica che i giorni di un
flusso di lavoro siano pianificati per l’esecuzione. I cicli
di esecuzione o esclusivi hanno la precedenza sui cicli
di esecuzione o inclusivi.
Lavori interattivi. Un lavoro in esecuzione
interattivamente su un desktop Windows NT.
Stato interno. Lo stato interno riflette lo stato attuale
dei lavori e dei flussi di lavoro nel motore di Tivoli
Workload Scheduler. Lo stato interno è unico per Tivoli
Workload Scheduler. Consultare inoltre Stato.
Dipendenze INET (Internetwork). Una dipendenza
tra i lavori e i flussi di lavoro in reti separate di Tivoli
Workload Scheduler. Consultare inoltre “Agent di rete”.
Lavoro / flusso di lavoro INET (Internetwork). Un
lavoro o un flusso di lavoro da una rete Tivoli
Workload Scheduler remota che rappresenta un
predecessore per un lavoro in un flusso di lavoro nella
rete locale. Un lavoro Internetwork è rappresentato da
un’icona sostitutiva nella Vista grafica del flusso di
lavoro. Consultare inoltre “Agent di rete”.
J
Lavoro Jnextday. L’elaborazione di pre e
postproduzione può essere completamente
automatizzata pianificando il lavoro Jnextday per
l’esecuzione alla fine di ogni giorno. Un semplice
lavoro jnextday viene fornito come TWShome\Jnextday.
Il lavoro Jnextday consente di impostare l’elaborazione
del giorno successivo (contenuta nel file Symphony),
stampare i report, portare a termine i flussi di lavoro
non terminati, arrestare e riavviare Tivoli Workload
Scheduler.
Job. Un lavoro è un’unità di lavoro che viene
elaborato su una workstation. La definizione del lavoro
comprende un nome lavoro univoco nel database Tivoli
Workload Scheduler oltre alle informazioni necessarie
per eseguire il lavoro. Quando si aggiunge un lavoro
ad un flusso di lavoro, è possibile definirne le
dipendenze e le restrizioni temporali, quali l’ora di
inizio e il tempo limite previsti.
Istanza lavoro. Un lavoro la cui esecuzione è stata
pianificata per una data specifica del piano. Consultare
inoltre “Lavoro”.
Stato lavoro. Consultare “Stato”.
Flusso di lavoro. Un flusso di lavoro consiste in un
elenco di lavori che vengono eseguiti come una unità
(ad esempio, come un’applicazione di backup
settimanale), insieme agli orari, le priorità e le altre
dipendenze che determinano l’esatto ordine di
esecuzione dei lavori.
346 IBM Tivoli Workload Scheduler - Manuale di riferimento
Istanza del flusso di lavoro. Un flusso di lavoro
pianificato per una specifica data di esecuzione nel
piano. Controllare inoltre “Flusso di lavoro”.
L
Limite. I limiti lavoro forniscono un mezzo per
l’assegnazione di uno specifico numero di slot lavoro
nei quali è consentito a Tivoli Workload Scheduler di
lanciare i lavori. Un limite dei lavori può essere
impostato per ogni flusso di lavoro e per ogni
workstation. Ad esempio, impostando il limite di lavori
della workstation su 25, si consente a Tivoli Workload
Scheduler di avere non più di 25 lavori in esecuzione
contemporaneamente su quella workstation.
Elenco. Un elenco visualizza gli oggetti della
pianificazione lavoro. E’ necessario creare elenchi
separati per ogni oggetto di Pianificazione lavoro. Per
ogni oggetto della pianificazione lavoro, esistono due
tipi di elenchi: uno di definizioni nel database e
un’altro di istanze nel piano.
Opzioni locali. Le opzioni locali vengono definite nel
file localopts. Ogni workstation nella rete Tivoli
Workload Scheduler deve avere il file localopts. Le
impostazioni in questo file si applicano solo a tale
workstation. Consultare anche “Opzioni globali”.
M
Gestore dominio master. In una rete Tivoli Workload
Scheduler, l’MDM conserva i file utilizzati per
documentare gli oggetti di pianificazione. Crea il piano
all’inizio di ogni giorno ed esegue tutte le registrazioni
e i report per la rete.
N
Agent di rete. Un tipo di agent esteso utilizzato per
creare le dipendenze tra lavori e flussi di lavoro su reti
Tivoli Workload Scheduler separate. Consultare anche
“Dipendenza INET (Internetwork)”.
P
Parametro. I parametri vengono utilizzati per
sostituire i valori nei lavori e nei flussi di lavoro.
Quando si utilizza un parametro nello script di un
lavoro, il valore viene sostituito al momento
dell’esecuzione. In tal caso, il parametro deve essere
definito sulla workstation su cui verrà utilizzato. Non è
possibile utilizzare i parametri quando si esegue lo
script dei lavori dell’agent esteso (XA).
Piano. Il piano contiene tutte le attività di
pianificazione lavoro pianificate per un periodo di un
giorno. In Tivoli Workload Scheduler, il piano viene
creato ogni 24 ore e comprende tutti i lavori, i flussi di
lavoro e gli oggetti dipendenza la cui esecuzione è stata
pianificata per quel giorno. Tutti i flussi di lavoro per
cui sono stati creati dei cicli di esecuzione vengono
pianificati automaticamente e inclusi nel piano. Con il
progredire del ciclo di produzione, i lavori e i flussi di
lavoro presenti nel piano vengono eseguiti in base alle
restrizioni di orario e alle altre dipendenze previste.
Qualsiasi lavoro o flusso di lavoro che non è stato
eseguito con esito positivo, viene spostato nel piano del
giorno successivo.
Ora di avvio pianificata. L’ora prevista da Tivoli
Workload Scheduler per l’avvio dell’istanza di lavoro.
Questa stima si basa sulle ore di avvio delle esecuzioni
precedenti.
Predecessore. Un lavoro che deve essere completato
con esito positivo prima che i lavori successivi possano
avviare l’esecuzione.
Priorità. Tivoli Workload Scheduler possiede un
sistema di accodamento per i lavori e i flussi di lavoro
nel piano. Per ogni lavoro e flusso di lavoro è possibile
assegnare un livello di priorità compreso tra 0 e 101.
Specificando la priorità 0 l’esecuzione non avrà luogo.
Prompt. I prompt possono essere utilizzati come
dipendenze per i lavori e per i flussi di lavoro. Affinché
venga avviato un lavoro dipendente o un flusso di
lavoro è necessario che il prompt riceva una risposta
affermativa. Vi sono due tipi di prompt: predefinito e
ad hoc. Un prompt ad hoc viene definito nelle
proprietà di un lavoro o di un flusso di lavoro ed è
univoco in tale lavoro o flusso di lavoro. Un prompt
predefinito viene definito nel database Tivoli Workload
Scheduler e può essere utilizzato da qualsiasi lavoro o
flusso di lavoro.
R
Risorsa. Le risorse possono rappresentare le risorse sia
fisiche che logiche sul sistema. Una volta definite nel
database Tivoli Workload Scheduler, possono essere
utilizzate come dipendenze per i lavori e i flussi di
lavoro. Ad esempio, è possibile definire una risorsa
denominata ″nastri″ con un valore unità pari a due.
Quindi, è possibile definire i lavori che richiedono due
unità nastro disponibili come dipendenza. I lavori con
questa dipendenza non possono essere eseguiti
contemporaneamente perché ogni volta che viene
eseguito un lavoro la risorsa “nastri” risulta in uso.
Ciclo di esecuzione. Un ciclo di esecuzione specifica i
giorni in cui il lavoro è pianificato per essere eseguito.
In Tivoli Workload Scheduler esistono tre tipi di cicli di
esecuzione che possono essere specificati per un flusso
di lavoro: un ciclo di esecuzione semplice, un ciclo di
esecuzione settimanale oppure un ciclo di esecuzione
Calendario (comunemente chiamato Calendario).
Notare che ogni tipo di ciclo di esecuzione può essere
inclusivo o esclusivo. Ovvero, ciascun ciclo di
Glossario 347
esecuzione può definire i giorni in cui un flusso di
lavoro è incluso in un ciclo di produzione oppure i
giorni in cui un flusso di lavoro è escluso dal ciclo di
produzione. Quando si definiscono più cicli di lavoro
in un flusso di lavoro e i cicli di esecuzione di
inclusione o di esclusione specificano gli stessi giorni, i
cicli di esclusione hanno la precedenza.
S
Ciclo di esecuzione Semplice. Un ciclo di esecuzione
semplice è una serie specifica di giorni definiti
dall’utente in cui viene eseguito il flusso di lavoro. Un
ciclo di esecuzione semplice viene definito per un
flusso di lavoro specifico e non può essere utilizzato
per più flussi di lavoro. Per ulteriori informazioni
consultare Ciclo di esecuzione.
Stato. Lo stato riflette lo stato del lavoro o flusso di
lavoro attuale all’interno di Job Scheduling Console. Lo
stato di Job Scheduling Console è comune a Tivoli
Workload Scheduler e OPC. Vedere anche la voce Stato
interno.
File stdlist. Un file di elenco standard viene creato per
ogni lavoro lanciato da Tivoli Workload Scheduler. I file
di elenco standard contengono le intestazione di testa e
di coda, l’output dei comandi, gli errori e gli avvisi.
Questi file possono essere utilizzati per risolvere i
problemi durante l’esecuzione del lavoro.
Successore. Un lavoro che non può essere avviato fino
a quando tutti i lavori predecessori, da cui dipende,
non vengono completati con esito positivo.
File Symphony. Questo file contiene le informazioni
di pianificazione necessarie al processo di Controllo
produzione (batchman) per eseguire il piano. Il file
viene creato e caricato durante la fase precedente la
produzione. Durante la fase di produzione, viene
aggiornato continuamente indicando in tal modo lo
stato corrente del processo di produzione: lavoro
completato, lavoro in corso, lavoro da eseguire. Per
gestire l’elaborazione di produzione, il contenuto del
file Symphony (piano) può essere visualizzato e
modificato con la Job Scheduling console.
T
Restrizioni ora. Le restrizioni temporali possono
essere specificate sia per i lavori che per i flussi di
lavoro. E’ possibile specificare un orario per l’inizio
dell’esecuzione oppure un ora trascorsa la quale il
tentativo di esecuzione non verrà più effettuato. Se
vengono specificate entrambe, è possibile definire una
finestra all’interno della quale eseguire un lavoro o
flusso di lavoro. Per i lavori è anche possibile
specificare una frequenza di ripetizione. Ad esempio, è
possibile fare avviare lo stesso lavoro ogni 30 minuti
nel periodo di tempo compreso tra le 8:30 e le 13:30.
TMF (Tivoli Management Framework). Il software di
base richiesto per eseguire le applicazioni nell’insieme
di prodotti Tivoli. Questa infrastruttura di software
consente l’integrazione delle applicazioni di gestione
dei sistemi da Tivoli Systems Inc. e i partner Tivoli.
Tivoli Management Framework comprende i seguenti
elementi:
v Broker richiesta oggetto (oserv)
v Database oggetto distribuito
v Funzioni fondamentali di amministrazione
v Servizi applicativi fondamentali
v Servizi desktop fondamentali come la GUI
In un ambiente Tivoli, Tivoli Management Framework
viene installato su ciascun client e server. Tuttavia, il
server TMR è l’unico server che conserva il database
completo dell’oggetto.
TMR (Tivoli Management Region). In un ambiente
Tivoli, un server Tivoli e la serie di client ad esso
collegati. Una società può disporre di più di una TMR.
Una TMR è in relazione alla connettività fisica, mentre
un’area della politica all’organizzazione logica delle
risorse.
Visualizzazione ad albero. La vista nella parte sinistra
di Job Scheduling Console che visualizza il server Tvoli
Workload Scheduler, i gruppi di elenchi di default e i
gruppi di elenchi creati dall’utente.
U
Utente. Solo per Windows NT, il nome utente che
viene specificato in un campo “Logon” della
definizione lavoro deve avere una definizione utente
corrispondente. Le definizioni forniscono le password
utente richieste da Tivoli Workload Scheduler per
avviare i lavori.
Comandi di utilità. Un insieme di eseguibili di riga
comandi per la gestione di Tivoli Workload Scheduler.
W
Ciclo di esecuzione settimanale. Un ciclo di
esecuzione che specifica i giorni della settimana in cui
un flusso di lavoro viene eseguito. Ad esempio, è
possibile specificare che un flusso di lavoro deve essere
eseguito ogni lunedì, mercoledì e venerdì utilizzando
un ciclo di esecuzione settimanale. Un ciclo di
esecuzione settimanale viene definito per un flusso di
lavoro specifico e non può essere utilizzato da più
flussi di lavoro. Per ulteriori informazioni consultare
Ciclo di esecuzione.
Caratteri jolly. I caratteri jolly relativi a Tivoli
Workload Scheduler sono:
? Sostituisce un carattere alfanumerico.
% Sostituisce un carattere numerico.
348 IBM Tivoli Workload Scheduler - Manuale di riferimento
* Sostituisce zero o più caratteri alfanumerici sulla
console di Tivoli Job Scheduling.
@ Sostituisce zero o più caratteri alfanumerici sulla
riga comandi di Tivoli Workload Scheduler.
I caratteri jolly sono generalmente utilizzati per rendere
più selettiva la ricerca di uno o più oggetti nel
database. Ad esempio, se si desidera visualizzare tutte
le workstation, è possibile immettere il carattere jolly
rappresentato da un asterisco (*). Per avere un elenco
di workstation dal site1 al site8, immettere site%.
Workstation. Normalmente, una workstation è un
singolo computer sul quale vengono eseguiti lavori e
flussi di lavoro. Vengono definiti nel database Tivoli
Workload Scheduler come un oggetto univoco. Una
definizione di workstation è necessaria per ogni
computer che esegue i lavori o i flussi di lavoro nella
rete di Workload Scheduler.
Classe della workstation. Una classe di workstation è
un gruppo di workstation. E’ possibile inserire in una
classe un qualsiasi numero di workstation. E’ possibile
assegnare dei flussi di lavoro o dei lavori da eseguire in
una classe della workstation. In tal modo, la replica di
un lavoro o di un flusso di lavoro in molte workstation
diviene più semplice.
X
X-agent. Consultare “Agente esteso”.
Glossario 349
Indice analitico
Aagent di rete
dipendenza internetwork 302
esempio riga comandi
workstation 301
file delle opzioni 301
netmth 299
panoramica 299
workstation 299
agent estesodefinizione workstation 289
panoramica 289
riferimento 289
aggiornamento dei connettori 337
APARIY46485 18
IY46918 194
IY48317 289
IY49121.1 317
IY49333 62, 126, 316
IY52215 195, 197
IY52475 97
IY52493 242
IY53050 104
IY53064 308, 324
IY53459 195
IY53755 88
IY57906 313
IY58702 29
arresto dei processi scheduler 18, 212
assistenza clientivedere Assistenza software 328
Assistenza softwarecontatto 328
descrizione del problema per
l’assistenza IBM 329
determinazione impatto aziendale per
l’assistenza IBM 329
notifica del problema all’assistenza
IBM 329
attivazione controllo 337
Bbasi della conoscenza, ricerca delle
risoluzioni ai problemi software 327
batchman 10
behindfirewall 39
Ccaratteri di controllo 60
caratteri di controllo, conman 123
caratteri di controllo del composer 60
caratteri jolly 62, 126
caratteri speciali, composer 62
caratteri speciali, conman 126
centri informazioni, ricerca delle
risoluzioni ai problemi software 327
centro informazioni del software
Tivoli xvi
ciclo di produzione 9
automazione 15
comandiadd 65
adddep job 144
adddep sched 146
altpass 148
altpri 149
avvio 207
build 66
cancel job 150
cancel sched 152
compiler 10
confirm 154
console 155
continue 67, 156
create 68
deldep sched 159
delete 70
display 72, 161
dumpsec 308, 323
edit 75
elenco 72
exit 76, 162
fence 163
help 164
kill 165
lavoro deldep 157
limit cpu 166
limit sched 167
link 168
listsym 170
logman 10
makesec 308, 324
modify 77
new 79
print 72
recall 171
redo 80, 172
release job 174
release sched 176
rep1 279
rep11 282
rep2 279
rep3 279
rep4a 279
rep4b 279
rep7 280
rep8 281
replace 82
reply 178
reptr 283
rerun 179
resource 182
schedulr 10
setsym 183
showcpus 184
showdomain 188
showfiles 189
comandi (Continua)showjobs 191
showprompts 199
showresources 201
showschedules 203
shutdown 206
stageman 10
status 209
stop 210
stop ;progressive 212
submit docommand 213
submit file 215
submit job 217
submit sched 219
switchmgr 221
system, comando 222
tellop 223
unlink 224
validate 84
version 85, 226
xref 285
comandi di sistema, conman 123, 222
comandi di utilità 227
comandi non supportati 275
comando adddep sched 146
comando altpass 148
comando altpri 149
comando at 228
comando batch 228
comando cancel sched 152
comando caxtract 233
comando confirm 154
comando continue 156
comando cpuinfo 235
comando datecalc 236
comando dbexpand 240
comando deldep 157
comando deldep sched 159
comando delete 241
comando display 161
Comando evtsize 243
comando exit 162
comando fence 163
comando help 164
comando jbxtract 244
comando jobinfo 246
comando jobstdl 248
comando kill 165
comando killproc 275
comando lavoro adddep 144
comando lavoro cancel 151
comando limit cpu 166
comando limit sched 167
comando link 168
comando listproc 275
comando listsym 170
comando maestro 250
comando makecal 251
comando morestdl 254
comando parms 256
comando paxtract 257
© Copyright IBM Corp. 1999, 2004 351
comando prxtract 258
comando r11xtract 259
comando recall 171
comando redo 172
comando release 260
comando release job 174
comando release sched 176
comando reply 178
comando rerun 179
comando resource 182
comando rextract 262
comando rmstdlist 263
comando setsym 183
comando showcpus 184
comando showdomains 188
comando showexec 264
comando showfiles 189
comando showjobs 191
comando showprompts 200
comando showresources 201
Comando showschedules 203
Comando shutdown 206
Comando start 207
comando startup 265
Comando status 209
Comando stop 210
comando stop ;progressive 212
Comando submit file 215
Comando submit job 217
Comando submit sched 219
Comando switchmgr 221
comando tellop 223
comando unlink 224
comando wmaeutil 32, 268, 337
comando xrxtrct 270
compiler, comando 10
composer 9
Comunicazioni SSLenabled 39
force 39
on 39
conman 9
conman, esecuzione 123
connettore 308
console, comando 155
contatto e-mail xvii
controlloattivazione 337
file di log 337
formato di log 338
formato intestazione 341
voci log di esempio 342
convenzionitypeface xvii
convenzioni tipografiche xvii
correzioni 328
cpuname 37
creazione del file security 308
creazione di una dipendenza
internetwork 302
Ddefinizione calendario 54
definizione classe workstation 43
definizione dominio 44
definizione lavoro 46
definizione parametro 55
definizione prompt 57
definizione risorsa 59
definizione utente 52
definizione workstation 37
definizioni utente, sicurezza 308
delimitatori 62
delimitatori, conman 126
descrizioni comando composer 63
determinazione dei problemidescrizione del problema per
l’assistenza IBM 329
determinazione impatto aziendale per
l’assistenza IBM 329
notifica del problema all’assistenza
IBM 329
Difetti155861 46
169932 184
170660 115
dipendenzafile 133, 134, 140, 189
internetwork 299, 302
dipendenza file 133, 134, 140, 189
dipendenza internetwork 299, 302
dumpsec, comando 10, 308, 323
Eeditor, oggetto database 61
editor composer 61
editor oggetto database 61
elenco comandi conman 127
esecuzione conman 123
esecuzione del composer 60
Ffeedback sulle pubblicazioni xvii
file globaloptscaratteristica di controllo 337
file maschera, sicurezza 308
file securityaggiornamento 308
file security di esempio 319
firewallimpostazione 39
flusso di lavoro finaleaggiunta 16
personalizzazione 15
fuso orario 130
Ggestione dei fusi orari 331
gestione sicurezza 308
Iinterfacce utente 9
Internet, ricerca delle risoluzioni ai
problemi software 327, 328
istruzionevedere preparazione tecnica
Tivoli xvii
JJnextday
esecuzione 16
job launch 10
job scheduling console 9
jobman 10
jobmanrc 19
jobmon 10
Llibreria xii
libreria del prodotto xii
linguaggio di pianificazione 87
logman, comando 10
Mmailman 10
makesec 308
makesec, comando 10, 308, 324
manuali xii
vedere pubblicazioni xvi
metodo accesso netmth 299
metronome.pl command 253
Nnetman 10
nomi directory, notazione xviii
nomi percorso, notazione xviii
notazionenomi percorso xviii
typeface xviii
variabili ambiente xviii
Ooggetti di pianificazione 35
onuntil 120
ora di avvio 17
ora di avvio, ultima 17
ordine degli oggetti, file security 315
ordine degli utenti, file security 315
os_type 37
output del terminale 60, 124
output non in linea 124
output non in linea per UNIX 61
Pparola chiave absolute 130, 136, 137, 142
Parola chiave At 17, 89
parola chiave carryforward 17, 92
parola chiave comments 93
parola chiave confirmed 94
parola chiave deadline 95
parola chiave end 96
parola chiave every 97
parola chiave except 98
parola chiave follows 100
parola chiave freedays 101
parola chiave job statement 103
parola chiave keyjob 108
352 IBM Tivoli Workload Scheduler - Manuale di riferimento
parola chiave keysched 109
parola chiave limit 110
parola chiave needs 111
parola chiave on 17, 112
parola chiave onuntil 120
parola chiave opens 115
parola chiave priority 117
parola chiave prompt 118
parola chiave schedule 119
parola chiave until 120
parole chiaveabsolute 130, 136, 137, 142
tempo limite 95
parole chiave, linguaggio di
pianificazione 88
parole chiave linguaggio di
pianificazione 88
parole riservate 35
preparazione tecnica, Tivoli xvii
programma composer 60
progressive 212
prompt del comando 61
prompt del comando, conman 125
prompt del comando conman 125
prompt dell’utente 124
pubblicazioni xii
accesso in linea xvi
ordine xvi
pubblicazioni in lineaaccesso xvi
Rrccondsucc 47, 104
rep1, comando 279
rep11, comando 282
rep2, comando 279
rep3, comando 279
rep4a, comando 279
rep4b, comando 279
rep7, comando 280
rep8, comando 281
report di esempio 286
reptr, comando 283
richiesta pubblicazioni xvi
riferimento a conman 123
riferimento al composer 35
Sschedulr, comando 10
securitylevelenabled 39
force 39
on 39
selezione dei flussi di lavoro nei
comandi 137
selezione lavori nei comandi 129
setup_env 309
Sfinalaggiunta 16
sicurezzacentralizzata 307
creazione del file security 308
definizioni utente 309
dumpsec 308
sicurezza (Continua)file di esempio 319
file maschera 308
gestione 308
locale 307
makesec 308
ordine degli oggetti 315
ordine delle definizioni utente 315
sintassi file 309
superutente UNIX 316
variabili 315
sicurezza centralizzata 307
sicurezza locale 307
sintassi, file security 309
sintassi, linguaggio di pianificazione 87
sintassi comando, conman 125
sintassi comando composer 62
sintassi del comando conman 125
sito Web di supporto, ricerca delle
risoluzioni ai problemi software 327
stageman, comando 10
stati, lavori 135
stati lavoro 135
statotardi 95
stato di ritardo 95
struttura ad albero dei processi su
UNIX 11
struttura ad albero dei processi su
Windows 13
submit docommand 213
success condition 47, 104
superutente UNIX, sicurezza 316
Ttempo limite 17
Tivoli, preparazione tecnica xvii
Uultima ora di avvio 17
Vvariabili, file security 315
variabili, notazione per xviii
variabili ambiente, notazione xviii
versione comando 226, 266
voci database 35
voci log di esempio, controllo 342
Wwmaeutil 308
writer 10
Xxref, comando 285
Zzone morte 331
Indice analitico 353