T l Tivoli Workload -...

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


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


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


dominio master è in ritardo su FTA . . . . . 332

Esecuzione di un flusso di lavoro con


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

vi IBM Tivoli Workload Scheduler - Manuale di riferimento

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

viii IBM Tivoli Workload Scheduler - Manuale di riferimento

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

x IBM Tivoli Workload Scheduler - Manuale di riferimento

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

http://www.ibm.com/software/tivoli/products/scheduler/

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

http://www.ibm.com/software/tivoli/products/scheduler-zos/

http://www.ibm.com/software/tivoli/products/scheduler-apps/

http://www.ibm.com/software/info/ecatalog/en_US/products/Y614224T20392S50.html

http://www.ibm.com/software/info/ecatalog/en_US/products/Y614224T20392S50.html


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).



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).



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



http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm

http://www.ibm.com/software/tivoli/library/

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

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

http://www.ibm.com/software/tivoli/order-lit/

http://www.ibm.com/software/tivoli/education

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

xx IBM Tivoli Workload Scheduler - Manuale di riferimento

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


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.


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.


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 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.


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.


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


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:


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


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.


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"


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


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.


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


UNISON_JCL Il nome del percorso del file script del

lavoro.

UNISON_STDLIST Il nome del percorso del file di elenco

standard del lavoro.


Tabella 3. Variabili di jobmanrc (Continua)


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.


Tabella 3. Variabili di jobmanrc (Continua)


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


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.


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”):


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


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



-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.


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


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


-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:


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:


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


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



-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


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.


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.


-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 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:


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


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


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:


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


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.


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


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



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.


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


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


la sezione relativa alla creazione di una classe workstation nel manuale Guida per

l’utente di IBM Tivoli Workload Scheduler Job Scheduling Console.


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


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.


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


Vedere anche


la sezione relativa alla creazione di un dominio nel manuale Guida per l’utente di

IBM Tivoli Workload Scheduler Job Scheduling Console.


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 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.


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


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.


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


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.


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.


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.


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


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


è 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.


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


la sezione relativa alla creazione di una definizione di lavoro nel manuale Guida per



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


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.


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


la sezione relativa alla creazione di un utente Windows nel manuale Guida per



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


la sezione relativa alla creazione di un calendario del manuale Guida per l’utente di



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



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^"


streamlogon "^gllogon^"

opens "^glpath^/datafile"

prompt ":^glpath^ started by ^gllogon^"

end

Vedere anche


la sezione relativa alla creazione di un parametro del manuale Guida per l’utente di



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



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:


$prompt

prmt1 "ready for job4? (y/n)"

prmt2 ":job4 launched"

prmt3 "!continue?"

Vedere anche


la sezione relativa alla creazione di un prompt nel manuale Guida per l’utente di



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



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


la sezione relativa alla creazione di una risorsa distribuita nel manuale Guida per



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.


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


$MAESTROLPCOLUMNS


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,


2-dmy, 3-NLS.

composer prompt = -

conman prompt = %

switch sym prompt = <n>%

#----------------------------------------------------------------------------


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


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


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.


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.


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


la sezione relativa al controllo delle attività nel manuale Guida per l’utente di IBM

Tivoli Workload Scheduler Job Scheduling Console.


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


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=@"


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


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.


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.


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





delete

Cancella le definizioni oggetto dal database. E’ necessario disporre dell’accesso

delete agli oggetti che vengono cancellati.

Sintesi

delete cpu={wkstation | wkstationclass | domain} |




Argomenti

cpu Elimina workstation, classi di workstation o domini.

wkstation


wkstationclass



jobs Elimina i lavori.

wkstation




jobname


sched Elimina i flussi di lavoro.

wkstation




Composer.


users Elimina gli utenti.

wkstation




username



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


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





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} |




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


wkstationclass



jobs Visualizza un lavoro.

wkstation




jobname


sched Visualizza un flusso di lavoro.

wkstation




Composer.


users Visualizza un utente. (Il campo della password non è stato copiato per

motivi di sicurezza.)

wkstation





username


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:


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.


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.


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,


di sched=site2#@;offline

Vedere anche


la sezione relativa alla gestione degli elenchi di oggetti nel manuale Guida per



edit

Modifica un file.

Sintesi

edit filename


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





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


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} |




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


wkstationclass



jobs Modifica un lavoro.

wkstation




jobname


sched Modifica un flusso di lavoro.

wkstation




Composer.


users Modifica un utente.

wkstation




username




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,


m sched=site1#sked9

Vedere anche





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


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:


redo

display site1#sa@

r2

display site2#sa@


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


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


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,


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.


version

Visualizza il banner del programma Composer.

Synopsis

version

Examples

Per visualizzare il banner del programma Composer, eseguire il comando:

version

o:

v


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


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


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.


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.


sfran#schedule sked8 on fr at 1000 + 1 day :

job1

job2 at 1400 tz est

nycity#job3 at 1600

end


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


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


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


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



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


end

Indica la fine di un flusso di lavoro.

Synopsis

end

Esempi

schedule test1 on monthend

:

job1

job2

job3

end << end of job stream >>


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


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:


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:


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


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.@


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


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


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 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.


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


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


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.


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.


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.



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.


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.


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


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


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


Synopsis

keysched

Esempi

Il seguente esempio:

SCHEDULE cpu1#sched1

ON everyday

KEYSCHED

AT 0100

cpu1#myjob1 KEYJOB

END


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 :


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:


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


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.


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ì:


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:



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


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:


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.


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


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.


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:


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


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:


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


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



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ì:


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 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.


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


$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.


|| 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


$MAESTROLPCOLUMNS


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>%

#----------------------------------------------------------------------------


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.



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


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


Comando

Forma


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


Workload Scheduler.

M,F,A 209

stop Arresta i processi di


Workload Scheduler.

M,F,A 210

stop ;progressive Arresta i processi di


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


Comando

Forma


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.


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:



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.



+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


stesso formato di time. Vengono selezionati i lavori con tempo

limite impostato sull’ora pianificata o successivo ad essa.

hightime


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).


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]


date La ricorrenza successiva di hhmm sulla data, espressa come

mm/dd/yy.

timezone|tz tzname



lowtime


stesso formato di time. Vengono selezionati i lavori terminati in

quell’ora o successivamente.

hightime


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


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.


wkstation

Specifica il nome della workstation su cui si trovano i file. Sono


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


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.


time Specifica l’ora esatta in cui vengono avviati i lavori, espressa nel

modo seguente:




mm/dd/yy.

timezone|tz tzname



lowtime


stesso formato di time. Vengono selezionati i lavori avviati in

quell’ora o successivamente.

hightime


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.


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:



+n days



mm/dd/yy.

timezone|tz tzname



lowtime


stesso formato di time. Vengono selezionati i lavori con ora di

avvio uguale o successivaa quella specificata.

hightime


nello stesso formato di time. Vengono selezionati i lavori con ore di

chiusura pianificate o con ore precedenti a quelle specificate.

absolute | abs





















Se until viene utilizzato da solo, l’intervallo è open-ended e, se è stata

pianificata l’ora di chiusura, i lavori vengono selezionati o esclusi.


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:



+n days



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:


– 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


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


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:




mm/dd/yy.

timezone|tz tzname



nomi validi.

lowtime


stesso formato di time. Vengono selezionati i flussi di lavoro che

vengono terminati all’ora prestabilita o successivamente.

hightime




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.


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.


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


filename

Specifica il nome del file. Il nome deve essere racchiuso tra apici (″)




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



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


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:




mm/dd/yy.

timezone|tz tzname



nomi validi.

lowtime


stesso formato di time. Vengono selezionati i flussi di lavoro avviati

A quell’ora o successivamente.

hightime



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.


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:



+n days



mm/dd/yy.

timezone|tz tzname



nomi validi.

lowtime


stesso formato di time. Vengono selezionati i flussi di lavoro con

ore di chiusura pianificate o con ore successive a quelle specificate.

hightime



con ore di chiusura pianificate o con ore precedenti a quelle

specificate.

absolute | abs






















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.


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.


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,


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


Vedere anche


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



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



limit=limit




until time [timezone|tz tzname][+n day[s] | [absolute | abs]] [onuntil

action]


l’operazione su ogni flusso di lavoro di qualificazione.


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:


ads sked4;follows=sked3;limit=2

Vedere anche


la sezione relativa alla creazione delle dipendenze tra i flussi di lavoro nel manuale



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 (″″).


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,


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


la sezione relativa alla modifica delle password utente di Windows nel manuale



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


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


cancel job

Annulla un lavoro.

E’ necessario disporre dell’accesso cancel al lavoro.

Sintesi

cj jobselect[;pend][;noask]

Argomenti


pend Annulla il lavoro solo dopo che vengono risolte le sue dipendenze.




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.


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,


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


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.


cancel sched

Annulla un flusso di lavoro.

E’ necessario disporre dell’accesso cancel al flusso di lavoro.

Sintesi

cs jstreamselect[;pend][;noask]

Argomenti


137.

pend Annulla il flusso di lavoro solo dopo che vengono risolte le

dipendenze.




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


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


la sezione relativa all’eliminazione dei flussi di lavoro del manuale Guida per



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


succ Conferma che il lavoro è stato terminato con esito positivo.

abend Conferma che il lavoro è stato terminato con esito negativo.



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,


confirm misdly.job3;succ

Per emettere una conferma abend per il lavoro 234, eseguire il comando:

conf 234;abend


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.


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"


lavoro deldep

Cancella le dipendenze da un lavoro.

E’ necessario disporre dell’accesso deldep al lavoro.

Sintesi

ddj jobselect;dependency[;...][;noask]

Argomenti

jobselect


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]]




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,


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


Vedere anche


la sezione relativa alla gestione dei lavori nel manuale Guida per l’utente di IBM



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


dependency

Il tipo di dipendenza. Specificare almeno uno dei seguenti. E’ possibile


promptname.


carryforward



limit



priority






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


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


Vedere anche


la sezione relativa alla gestione dei flussi di lavoro del manuale Guida per l’utente di



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 (-),


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


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.


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


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.


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,


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


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.


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


kill

Arresta un lavoro di esecuzione. Su UNIX, questo viene effettuato con un comando

UNIX kill.

Synopsis

kill jobselect[;noask]

Arguments




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


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.




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


lc ;12

Per modificare il limite di lavori sulla workstation rx12, eseguire il comando:

lc rx12;6

Vedere anche


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.


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


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.



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


la sezione relativa alla gestione dei flussi di lavoro del manuale Guida per l’utente di



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.


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.



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.


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


listsym

Elenca i file di log (Symphony) del piano di produzione.

E’ necessario disporre dell’accesso display al file Symphony.

Synopsis

listsym [;offline]

Arguments



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


lis ;off


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.



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


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:


redo

setsym 4

5

setsym 5


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


promptname.


confirmed


every




priority






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,


release job=ap.job3

Per rilasciare il lavoro job2 nel flusso di lavoro skedr da tutte le sue dipendenze

opens, eseguire il comando:


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


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.


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.


carryforward



limit



priority






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


143.

Esempi

Per rilasciare il flusso di lavoro ap da tutte le dipendenze, eseguire il comando:

release sched=ap


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


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.


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.


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


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:


+n days


date La ricorrenza successiva di hhmm su date, espressa come mm/dd/yy.

timezone|tz tzname



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”.





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.


Esempi

Per ripetere il lavoro job4 nel flusso di lavoro sked1 sulla workstation main,


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,


rr sked2.job5;from=jobx;at=1830;pri=25

Per ripetere il lavoro job3 nel flusso di lavoro sked4 utilizzando il nome jstep2,


rr sked4.job3;step=jstep2

Vedere anche


la sezione relativa alla ripetizione dell’istanza di un lavoro nel manuale Guida per



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.


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


la sezione relativa alla gestione delle risorse del database nel manuale Guida per



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


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.



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.


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


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


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.


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


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



gestore dominio o superiore è attiva ma almeno una delle connessioni

secondarie non lo è, si riceverà il seguente output:




FTA3 360 WNT MANAGER 10 0 12/04/03 13:48 FTI JW DOMAIN1


FTA5 360 WNT FTA 10 0 12/04/03 13:48 L I DOMAIN1






gestore dominio o superiore e tutte le connessioni secondarie sono attive, si

riceverà il seguente output:




FTA3 360 WNT MANAGER 10 0 12/04/03 13:48 FTI JW DOMAIN1



FTA5 360 WNT FTA 10 0 12/04/03 13:48 F I DOMAIN1





Vedere anche





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.



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


la sezione relativa alla visualizzazione e alla modifica delle proprietà del dominio


Console.


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


file Specifica il nome del file. Il nome deve essere racchiuso tra apici (″)


barre (/), barre retroverse (\) e caratteri di sottolineatura (_). Il

valore di default è di visualizzare tutte le dipendenze file. Sono


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.



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


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,


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


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


wkstation Il nome della workstation su cui è in esecuzione il lavoro. Sono


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.


comando.


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.



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.



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.


Schedule


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.


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.




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.


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.


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:


Schedule


Lavoro


>> rerun as

Un lavoro che è stato rieseguito con il comando rerun o come


>> 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.



Schedule


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


>> 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:


Schedule


Lavoro


>> rerun as

Un lavoro che è stato rieseguito con il comandorerun o come


>> 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


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


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,


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


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



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





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


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.


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.

Output del comando



Formato standard:

Stato Lo stato del prompt.

Messaggio o Prompt

Per i prompt denominati, il numero di messaggio, il nome e il testo del


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


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


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


la sezione relativa alla visualizzazione e alla modifica delle proprietà dei prompt


Console.


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.


comando.







a pagina 124.

Output del comando



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.


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


showresources

Per visualizzare le informazioni sulla risorsa dbase sulla workstation main nel

formato deps, eseguire il comando:

sr main#dbase;deps

Vedere anche


la sezione relativa alla visualizzazione delle proprietà delle risorse nel manuale



showschedules

Visualizza le informazioni sui flussi di lavoro.

Sintesi

ss [jstreamselect][;keys][;offline]

ss [jstreamselect][;deps[;keys | info | logon]][;offline]

Argomenti


137.


comando.







a pagina 124.

Output del comando



Formato standard:

CPU La workstation su cui è in esecuzione il flusso di lavoro.

Schedule


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.




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.


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.


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.


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


Esempi

Per visualizzare lo stato di tutti i flussi di lavoro hold sulla workstation su cui è in


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-7 SUCC 10 09/03 0:02 2 2

TWS820A #SCHED-8 READY 10 ( 0:01) 1 0

Vedere anche


la sezione relativa alla visualizzazione di un flusso di lavoro nel manuale Guida per



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


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.



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


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:


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


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)


5698-WKB



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


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


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.



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



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.


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


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


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


submit docommand

Inoltra un comando da avviare come lavoro dello scheduler.

E’ necessario disporre dell’accesso submit al lavoro. Per includere le dipendenze


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


every=rate


follows=[netagent::][wkstation#]jstream{.job | @} |

job[;nocheck][;wait=time][,...]

interactive

logon=user




rccondsucc″Success Condition″

recovery=stop | continue | rerun




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


submit file

Inoltra un file da avviare come un lavoro dello scheduler.



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:



lavoro viene aggiunto ad un flusso di lavoro definito JOBS.

joboption



confirmed

deadline=time[timezone | tz tzname][+n days | mm/dd/yy]

every=rate


interactive

logon=user










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,


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


submit job

Inoltra un lavoro che deve essere avviato dallo scheduler.



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:



lavoro viene aggiunto ad un flusso di lavoro definito jobs.

joboption



confirmed


every=rate












action]


l’operazione relativa ad ogni lavoro di qualificazione.



è 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


la sezione relativa all’inoltro dei lavori nel manuale Guida per l’utente di IBM Tivoli

Workload Scheduler Job Scheduling Console.


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:


carryforward




limit=joblimit





action]


l’operazione relativa ad ogni flusso di lavoro di qualificazione.




è 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


la sezione relativa alla pianificazione delle workstation distribuite nel manuale



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,


switchmgr masterdm,orca

Per commutare il gestore dominio sulla workstation ruby nel dominio bldg2,


switchmgr bldg2,ruby


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


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>//


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.



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



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.


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


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


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


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.


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


(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,


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,


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.,


at -s sked-mis 17h30

command <Return>

...

<Control d>


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.


caxtract

Estrae informazioni sui calendari dal database dello scheduler.

Synopsis

caxtract [-v | -u] [-o file]

Arguments



-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


cpuinfo

Restituisce le informazioni da una definizione di workstation.

Synopsis

cpuinfo -v | -u

cpuinfo wkstation [infotype] [...]

Arguments



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.


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


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



base-date


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


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:


+ | > 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.


^|/ 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


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



-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à.


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



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.


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



-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)


5698-WKB



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


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


jbxtract

Estrarre le informazioni sui lavori dal database dello scheduler.

Synopsis

jbxtract [-v | -u] [-j job] [-c wkstat] [-o file]

Arguments



-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.


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


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


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


jobinfo

Utilizzato nello script del lavoro per rieseguire le informazioni sul lavoro.

Synopsis

jobinfo -v | -u

jobinfo job-option [...]

Arguments



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.


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


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



-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:


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,


jobstdl 455

Per stampare il contenuto del file di elenco standard per il lavoro numero 455,


cd `maestro`/bin

lp -p 6 `jobstdl 455`


maestro

Restituisce il nome del lavoro della directory home dello scheduler, a cui ci si

riferisce come TWShome.

Synopsis

maestro [-v | -u]

Arguments



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`


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



-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



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é


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,


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


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.


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



-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:


morestdl 455 | lp -p 6


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



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>


paxtract

Estrarre le informazioni sui parametri dal database dello scheduler.

Synopsis

paxtract [-v | -u] [-o file]

Arguments




Command Output

Ogni record di parametro contiene campi a lunghezza variabile, delimitati dal


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


prxtract

Estrarre le informazioni sui prompt dal database dello scheduler.

Synopsis

prxtract [-v | -u] [-o file]

Arguments




Command Output

Ogni record del prompt contiene campi a lunghezza variabile, delimitati dal


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


r11xtr

Estrarre le informazioni sui flussi di lavoro dal database dello scheduler.

Synopsis

prxtract [-v | -u] [-m mm[yy]] [-c wkstat] [-o file]

Arguments



-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.


Command Output






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)


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


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



-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.


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

...


rextract

Estrarre le informazioni sulle risorse dal database dello scheduler.

Synopsis

rextract [-v | -u] [-o file]

Arguments




Command Output

Ogni record della risorsa contiene campi a lunghezza variabile, delimitati dal


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


rmstdlist

Rimuove o visualizza file di elenco standard in base alla durata del file.

Synopsis

rmstdlist -v | -u

rmstdlist [-p] [age]

Arguments



-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,


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


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



-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:


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:


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


StartUp

Avvia il processo di gestione della rete dello scheduler, Netman. E’ necessario

disporre dell’accesso start alla workstation.

Synopsis

StartUp [-v | -u]

Arguments



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


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.


-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.


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


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


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 *


xrxtrct

Estrarre le informazioni sui riferimenti incrociati dal database dello scheduler.

Synopsis

xrxtrct [-v | -u]

Arguments



Command Output






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


3 nome lavoro 40


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.


1 08 2




3 nome lavoro 120






9 non utilizzato 6

10 non utilizzato 6

11 non utilizzato 8


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.


1 02 2






7 non utilizzato 8

8 non utilizzato 8

9 non utilizzato 6

10 non utilizzato 6

11 non utilizzato 8


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.


1 07 2


3 nome file 256







8 non utilizzato 6

9 non utilizzato 6

10 non utilizzato 8


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.


1 04 2


3 nome lavoro 40


5 nome workstation flusso di lavoro 16


7 non utilizzato 8

8 non utilizzato 8

9 non utilizzato 6

10 non utilizzato 6

11 non utilizzato 8


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


seguente.


1 05 2


3 nome prompt o testo 20






9 non utilizzato 6

10 non utilizzato 6

11 non utilizzato 8



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


seguente.


1 06 2


3 nome risorsa 8






9 unità assegnate 6

10 non utilizzato 6

11 non utilizzato 8


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.


1 00 2




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


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


seguente.


1 01 2


3 nome o data ON/EXCEPT 8



4 indicatore except (*=EXCEPT) 1




8 non utilizzato 8

9 non utilizzato 8

10 non utilizzato 6

11 num. offset 6

12 unità scostamento 8


Examples

Per estrarre le informazioni su tutti i riferimenti incrociati, eseguire il comando:

xrxtrct


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 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.


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.


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



-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


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



-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


Comando rep11

Questo comando stampa Report 11-Pianificazione produzione.

Synopsis

rep11 -v|-u

rep11 [-m mm[yy] [...]] [-c wkstat [...]] [-o file]

Arguments



-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


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



-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


file Symphony.


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


che dipendono da ogni prompt.

-resource


che dipendono da ogni risorsa.

-schedules


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


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:


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


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:


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




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










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:


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.


-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.


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.


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.


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


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.


CF Exit code=0 Imposta lo stato del file su YES.

Exit code=non-zero Imposta lo stato del file suNO.


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.


Le risposte del metodo vengono riepilogate nella seguente tabella:


GS %CJ state [jobid] Imposta lo stato del lavoro state e include

jobid in ogni attività GS successiva.


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.


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 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:


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.


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


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.


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


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


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.


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.


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


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


la sezione relativa alla creazione dei flussi di lavoro del manuale Guida per l’utente

di IBM Tivoli Workload Scheduler Job Scheduling Console.


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.


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.


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


$remotes

L’utente è collegato a ogni Agent standard IBM


$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.


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.


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


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 è




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 è





console Visualizzare e modificare la console IBM


deldep Cancella tutte le dipendenze dai lavori nel

piano di produzione. Questa azione non è




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 è




reply Risponde alle richieste del lavoro nel piano

di produzione.

rerun Riavvia i lavori nel piano di produzione.





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.





unlink Chiude i collegamenti della workstation.


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:


$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


$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 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.


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


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


display conman display composer display

list conman showjobs

kill conman kill


release conman release

reply conman reply

rerun conman rerun

submit conman submit (docommand, file, job)

use composer - use job in schedule


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


reply conman reply

use composer - use prompt in job stream;

conman - add dependency

resource add nd

delete nd


list conman showresources


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


display composer display, create conman display

elenco conman showschedules

limit conman limit


release conman release

reply conman reply

submit conman submit sched

userjob add composer add, new


display composer display (password non

visualizzata)

modify composer modify

altpass conman altpass


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


# ---------- ------------ ----------------------

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


# ---------- ------------ ----------------------

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,


rerun,submit,use


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=@


end

###########################################################

# (4) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON ANY

# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER

user op group=sys

begin


# ---------- ------------ ----------------------

job cpu=$thiscpu

+ logon=$user access=@

job cpu=$thiscpu

+ logon=root access=adddep,altpri,cancel,



job cpu=$thiscpu

~ logon=root access=adddep,altpri,cancel,




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


end

###########################################################

# (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON

# ANY WORKSTATION OR FRAMEWORK.

user misusers group=mis

begin


# ---------- ------------ ----------------------

job cpu=$thiscpu


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


# ---------- ------------ ----------------------

job cpu=$thiscpu



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.


# (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.


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


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:


makesec tempsec

Il seguente comando compila definizioni utente dalla serie di file userdef* e

sostituisce il file Security operativo:

makesec userdef*


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.


http://www.ibm.com/software/support/

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


http://www.ibm.com/software/support/

http://techsupport.services.ibm.com/guides/handbook.html

http://www.lotus.com/services/passport.nsf/WebDocs/Passport_Advantage_Home

http://www.lotus.com/services/passport.nsf/WebDocs/Passport_Advantage_Home

http://techsupport.services.ibm.com/guides/contacts.html

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

http://www.ibm.com/servers/eserver/techsupport.html


http://www.ibm.com/software/support/probsub.html

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.



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


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


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


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:


Schedule FTA1#EST_SCHEDULE1


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


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


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.


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


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 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.


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


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


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


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.


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|


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.


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à.


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


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.


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 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


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


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


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


determinazione impatto aziendale per


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


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


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

��

Numero programma: 5698-WSH

Printed in Denmark by IBM Danmark A/S

SC32-1274-02

T l Tivoli Workload -...

Documents

Transcript of T l Tivoli Workload -...