TWS - IBMpublib.boulder.ibm.com/tividd/td/TWS/GC32-0422-00/... · Riavvio di TWS ..... 56 Script Customize..... 58 Come disinstallare TWS ..... 62

TWSManuale per l’installazione e lapianificazioneVersione 7.0

Manuale per l’installazione e la pianificazione di Tivoli Workload Scheduler (maggio2000)

Informazioni sul copyright

Copyright ©2000 di Tivoli Systems Inc., una società del gruppo IBM, relativo a questa documentazione e all’interosoftware. Tutti i diritti riservati. Può essere utilizzato solo in conformità con un Accordo di licenza della Tivoli SystemsSoftware o come Addendum a prodotti Tivoli per clienti IBM o Accordo di licenza. Non è consentito l’utilizzo o lariproduzione di nessuna parte di questa pubblicazione in qualsiasi forma e con qualunque mezzo, né l’archiviazione indatabase o in altri sistemi di archiviazione senza la preventiva autorizzazione scritta di Tivoli Systems. Il Tivoli Systemsconcede un’autorizzazione limitata per la copia su disco fisso o altre riproduzioni di qualsiasi documentazione leggibile dallamacchina per l’utilizzo personale; ogni riproduzione deve avere le informazioni sul copyright del Tivoli Systems. Nonvengono concessi altri diritti sotto il copyright senza la preventiva autorizzazione scritta da Tivoli Systems. Questapubblicazione non è destinata alla produzione e viene fornita “nello stato in cui si trova” senza alcuna garanzia.Tutte legaranzie in questa pubblicazione sono con la presente negate, comprese le garanzie di commerciabilità e idoneità peruno scopo particolare.

Marchi

I seguenti nomi di prodotto sono marchi di Tivoli Systems o di IBM Corporation: AIX, IBM, OPC, OS/390, e Tivoli.

Tivoli è un marchio o un marchio registrato del Tivoli Systems Inc. negli USA, in altri paesi o in entrambi. In Danimarca,Tivoli è un marchio autorizzato da Kjøbenhavns Sommer - Tivoli A/S.

I logo Microsoft, Windows, Windows NT e Windows sono marchi o marchi registrati della Microsoft Corporation in USA oin altri paesi o in entrambi.

UNIX è un marchio registrato negli Stati Uniti e in altri paesi con licenza esclusiva di Open Group.

Tutti i marchi Java e basati su Java o i logo sono marchi di Sun Microsystems, Inc. in USA, in altri paesi o in entrambi.

Altri nomi di società, prodotti e servizi menzionati in questa pubblicazione potrebbero essere marchi o marchi di servizio dialtri.

Informazioni particolari

I riferimenti contenuti in questa pubblicazione a prodotti, programmi o servizi Tivoli Systems o IBM non implicano cheTivoli Systems o IBM intendano renderli disponibili in tutti i paesi in cui operano. Qualsiasi riferimento a questi prodotti,programmi o servizi non implica che possano essere utilizzati soltanto i prodotti, i programmi o i servizi Tivoli Systems oIBM. In sostituzione di quelli forniti da Tivoli Systems o IBM possono essere usati programmi, prodotti o servizifunzionalmente equivalenti che non comportino violazione dei diritti di proprietà intellettuale o di altri diritti di TivoliSystems o IBM. E’ responsabilità dell’utente valutare e verificare la possibilità di utilizzare altri programmi e/o prodotti,fatta eccezione per quelli espressamente indicati da Tivoli Systems o IBM.

Tivoli Systems o IBM possono avere brevetti o domande di brevetti in corso relativi a quanto trattato nella presentepubblicazione. La fornitura di questa pubblicazione non implica la concessione di alcuna licenza su di essi. Chi desiderasseinviare domande relative a queste licenze può rivolgersi per iscritto a IBM Director of Licensing, IBM Corporation, NorthCastle Drive, Armonk, New York 10504-1785, U.S.A.

Indice

Prefazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixA chi è rivolto questo manuale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Prerequisiti e documenti correlati. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Contenuti di questo manuale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Informazioni specifiche sulla piattaforma. . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Come contattare l’assistenza clienti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Capitolo 1. Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Tivoli Workload Scheduler 7.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Novità in Tivoli Workload Scheduler 7.0. . . . . . . . . . . . . . . . . . . . . . . . 3

Pianificazione di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Panoramica della rete TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Funzionalità del dominio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Elaborazione localizzata nel dominio. . . . . . . . . . . . . . . . . . . . . . . . . . 10

Considerazioni sulla rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Rete a dominio singolo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Rete a più domini. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Come passare a un gestore dominio di backup (BDM). . . . . . . . . . . . . 16

Database espansi e nomi di oggetto estesi. . . . . . . . . . . . . . . . . . . . . . 17

Nomi della workstation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Panoramica sull’installazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Gruppi di prodotti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

File dei componenti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Home directory di Netman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Dopo l’installazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Capitolo 2. Installazione del motore TWS su WindowsNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

iiiTWS Manuale per l’installazione e la pianificazione

Requisiti di sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Preparazione di un aggiornamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Come scollegare e arrestare TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

File di backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Installazione del software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Programma Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Esecuzione di Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Dopo l’installazione o l’aggiornamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Come completare un aggiornamento. . . . . . . . . . . . . . . . . . . . . . . . . . 37

Impostazione della variabile PATH. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Directory e servizi TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Impostazione di una Amministrazione decentralizzata. . . . . . . . . . . . . . 39

Creazione manuale dell’account TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Tipi di Amministrazione TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Come disinstallare TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Utilizzo del tool Aggiungi/Rimuovi di Windows NT. . . . . . . . . . . . . . 44

Programma Uninstal.exe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Capitolo 3. Installazione del motore TWS su UNIX . . . . . 47Requisiti di sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Procedura di installazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Installazione di Tivoli Workload Scheduler Engine. . . . . . . . . . . . . . . . 48

Istruzioni di configurazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Aggiornamento di Tivoli Workload Scheduler. . . . . . . . . . . . . . . . . . . . . . . 53

Preparazione-Arresto di TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Aggiornamento del software ed esecuzione di Customize. . . . . . . . . . . 54

Aggiornamento del Profilo Security. . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Ripristino dei propri file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

iv Versione 7.0

Riavvio di TWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Script Customize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Come disinstallare TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Capitolo 4. Impostazione di TWS Security . . . . . . . . . . . . . . 65Modifica del file Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Capitolo 5. Installazione del connettore TWS . . . . . . . . . . . 79Prima dell’installazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Piattaforme supportate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Procedura di installazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Installazione di JSS (Job Scheduling Services). . . . . . . . . . . . . . . . . . . 81

Installazione del connettore TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Installazione delle patch JSS e del connettore TWS. . . . . . . . . . . . . . . 95

Aggiornamento di TWS Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Come disinstallare il connettore TWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Come disinstallare JSS Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Comandi utili della framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Capitolo 6. Installazione di Tivoli Job SchedulingConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Piattaforme supportate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Prerequisiti per HP-UX e AIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Installazione di Job Scheduling Console. . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Avvio di Job Scheduling Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Come disinstallare Job Scheduling Console. . . . . . . . . . . . . . . . . . . . . . . . 110

Come disinstallare UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

vTWS Manuale per l’installazione e la pianificazione

Come disinstallare Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Capitolo 7. Argomenti ulteriori per personalizzareTWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Impostazione delle opzioni globali. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Impostazione delle opzioni locali. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Come automatizzare il ciclo di produzione. . . . . . . . . . . . . . . . . . . . . . . . . 116

Personalizzazione del flusso di lavoro finale. . . . . . . . . . . . . . . . . . . . 117

Aggiunta di un flusso di lavoro finale. . . . . . . . . . . . . . . . . . . . . . . . 118

Avvio di un ciclo di produzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Gestione di un ambiente di produzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Scelta del giorno in cui avviare TWS. . . . . . . . . . . . . . . . . . . . . . . . . 119

Modifica del giorno stabilito per l’avvio. . . . . . . . . . . . . . . . . . . . . . 120

Creazione di un piano per date passate e future. . . . . . . . . . . . . . . . . 121

Appendice. Migrazione su TWS 7.0 . . . . . . . . . . . . . . . . . . . . 123Tivoli Management Framework per utenti non Tivoli. . . . . . . . . . . . . . . . . 123

Considerazioni sull’installazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Dove è possibile installare il client JS Console. . . . . . . . . . . . . . . . . . 125

Dove è possibile installare il connettore TWS. . . . . . . . . . . . . . . . . . 125

Considerazioni master di backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Master non appartenenti alla schiera 1 in una rete esistente del Maestro 127

Spostamento del master di backup. . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Creazione di un master di backup. . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Caricamento dei database del gestore domini master. . . . . . . . . . . . . . 129

Master di backup non appartenenti alla schiera 1 in una rete esistente delMaestro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Esecuzione di più finestre in JS Console. . . . . . . . . . . . . . . . . . . . . . . . . . 130

Attivare un file Security esistente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

vi Versione 7.0

Aggiunta di amministratori TME. . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Gestione sicurezza. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Arresto del connettore per implementare le modifiche. . . . . . . . . . . . 134

Restrizioni sulla GUI precedente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Utilizzo della GUI precedente su AIX 4.2. . . . . . . . . . . . . . . . . . . . . 135

Considerazioni sul fuso orario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Propagazione delle Preferenze dell’utente agli altri utenti (Personalizzavisualizzazioni/Query). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Backout di un database espanso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Migrazione su Windows NT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Migrazione dal Maestro 5.2 su agent Windows NT. . . . . . . . . . . . . . 141

Appendice. Creazione di una rete con MPE . . . . . . . . . . . 143Considerazioni sulla rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Considerazioni sulla pianificazione. . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Installazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Installazione e configurazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Impostazione di un agent UNIX con il master MPE. . . . . . . . . . . . . . 146

Impostazione di un FTA MPE con UNIX o Windows NT. . . . . . . . . . 147

Differenze operative tra piattaforme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Sul master MPE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Su FTA UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Su master UNIX o Windows NT. . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Su slave MPE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Indice analitico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

viiTWS Manuale per l’installazione e la pianificazione

viii Versione 7.0

Prefazione

Il Manuale per l’installazione e la pianificazione Tivoli WorkloadSchedulerfornisce informazioni relative all’installazione di una reteTivoli Workload Scheduler 7.0. Sono incluse le informazioni sullapianificazione di una rete, sull’installazione del motore TWS, sulsoftware del connettore e sulla GUI. Questo manuale contiene inoltrele istruzioni per la personalizzazione della sicurezza e delle opzioniTWS per avviare una rete TWS. Infine, fornisce suggerimenti einformazioni sulla migrazione dalle versioni precedenti del Maestro.

A chi è rivolto questo manualeQuesto manuale si rivolge alle figure seguenti:

¶ Amministratori TWS - coloro i quali pianificano il layout dellarete TWS.

¶ Installatori - coloro i quali installano i vari pacchetti software sucomputer che creano la rete TWS.

Prerequisiti e documenti correlatiQuelli riportati di seguito sono i documenti correlati:

¶ Manuale per l’utente Tivoli Workload Scheduler

Fornisce informazioni sulla configurazione e l’utilizzo di TivoliWorkload Scheduler. Inoltre, contiene informazioni relative allereti TWS, alla sicurezza, ai file di opzioni locali e globali, unapanoramica del ciclo di produzione e descrizioni di attività dipianificazione e di database.

¶ Manuale di riferimento Tivoli Workload Scheduler

Fornisce informazioni sulle interfacce della riga comandi TivoliWorkload Scheduler, inclusi composer, conman, la lingua dipianificazione e i comandi del programma di utilità.

ixTWS Manuale per l’installazione e la pianificazione

Contenuti di questo manualeIl Manuale per l’installazione e la pianificazione di TWS contiene iseguenti capitoli:

¶ Capitolo 1, “Introduzione”

Fornisce le informazioni sulla pianificazione dell’installazione diuna rete TWS e una panoramica del processo di installazione.

¶ Capitolo 2, “Installazione del motore TWS su Windows NT®”

Spiega il modo in cui installare il motore TWS su Windows NT.

¶ Capitolo 3, “Installazione del motore TWS su UNIX”

Spiega come installare il motore TWS su UNIX.

¶ Capitolo 4, “Impostazione di TWS Security

Spiega come personalizzare il file Security.

¶ Capitolo 5, “Installazione del connettore TWS”

Spiega come installare il connettore TWS.

¶ Capitolo 6, “Installazione di Job Scheduling Console”

Spiega come installare Job Scheduling Console.

¶ Capitolo 7, “Argomenti aggiuntivi per la personalizzazione diTWS”

Descrive le opzioni di personalizzazione per una rete TWS.

¶ Appendice A, “Migrazione su TWS 7.0”

Contiene informazioni utili per la migrazione dalle versioni delMaestro 5.x e 6.x.

Informazioni specifiche sulla piattaformaLa tabella seguente identifica le versioni supportate per ognipiattaforma elencata e nota al momento della pubblicazione. Perinformazioni più dettagliate e aggiornate, consultare leNote direlease Tivoli Workload Scheduler.

x Versione 7.0

Piattaforma Motore TWS ConnettoreTWS

JS Console

AIX 4.2 X X X

AIX 4.3 X X X

HP-UX 10.20 X X X

HP-UX 11.0 X X X

Solaris 2.6 X X X

Solaris 2.7 X X X

Windows NT 4.0w/ SP 4 o successiva

Windows 2000 X

Digital UNIX X

Piattaforme conformia Intel ABI

Piattaforme conformia MIPS ABI

Su AIX 4.3, è necessario installare la patchbos.rte.commands.4.3.1.1.bff. Per stabilire se questa patch èinstallata o meno sul sistema, eseguire il seguente comando:lslpp -l bos.rte.commands

Se il comando restituisce un valore inferiore a 4.3.1.1, ènecessario installare la patch .

Come contattare l’assistenza clientiSe si ha diritto al supporto Tivoli, è possibile trovare informazioniaggiornate sulla configurazione e l’utilizzo di prodotti Tivoli sullahome page Tivoli Customer Support, all’indirizzohttp://www.tivoli.com/support/ . Questo sito include i seguenticollegamenti:

xiTWS Manuale per l’installazione e la pianificazione

¶ Versioni aggiornate di queste note di release:http://www.tivoli.com/support/Prodman/html/RN.html

¶ Versioni aggiornate della documentazione Tivoli:http://www.tivoli.com/support/documents/

¶ Database di supporto da ricercare:http://www.tivoli.com/tivoli.ww.reg/rform?lang=english

¶ Accesso alle patch del prodotto:http://www.tivoli.com/support/patches/

¶ Accesso ai programmi per la formazione:http://www.tivoli.com/services/education/

¶ Accesso alla panoramica della documentazione Tivoli:http://www.tivoli.com/support/survey/

Per queste informazioni e per altri servizi, visitare il sito TivoliCustomer Support. Queste URL richiedono una password e un ID.Se non si dispone dei privilegi di accesso oppure se non si è certidel proprio ID o della password, inviare una e-mail aCustomer_Support_Web_Registration@tivoli.com. Inserire il proprionome e il nome della società di appartenenza in questacorrispondenza.

E’ possibile ordinare copie ulteriori della documentazione delprodotto inviando e-mail o chiamando una delle sedi seguenti:

¶ U.S. Customer E-mail: swdist@tivoli.com

¶ Recapito telefonico U.S.: 1-800-879-2755

¶ Recapito telefonico del Canada: 1-800-426-4968

¶ Recapito telefonico internazionale: (770) 863-1234

Fornire il titolo e il numero della versione del documento daordinare.

xii Versione 7.0

Introduzione

Questo manuale contiene istruzioni per l’installazione el’aggiornamento di Tivoli Workload Scheduler 7.0.

Tivoli Workload Scheduler 7.0Tivoli Workload Scheduler 7.0 è costituito da tre sezioni:

Motore TWSVersioni precedenti del Tivoli Maestro. Installare il motoreTWS sul Master e su tutte le CPU fisiche dell’agent.

ConnettoreDefinisce i comandi Job Scheduling Console per il motoreTWS. Installare il connettore TWS sul Master e su ogni FTA(Fault-Tolerant Agent) che si utilizzerà come macchina dibackup per la CPU master. Il connettore richiede unapreconfigurazione della TMF (Tivoli ManagementFramework) per un server TMR o per un nodo gestito.

Job Scheduling (JS) ConsoleUna GUI basata su Java™ per TWS. Installare JS Console suogni sistema da cui si desidera gestire gli oggetti deldatabase e la pianificazione TWS. JS Console non richiedeche il motore TWS o il connettore TWS siano installati sullastessa macchina. E’ possibile utilizzare JS Console da unaqualsiasi macchina, poiché ha un collegamento TCP/IP conla macchina che esegue il connettore TWS.

1TWS Manuale per l’installazione e la pianificazione

1.Introduzione

Una rete TWS è costituita da workstation o da CPU su cui vengonoeseguiti i lavori o i flussi di lavoro.

Fondamentalmente, le definizioni della workstation fanno riferimentoa workstation fisiche. Tuttavia, nel caso di agent di rete o estesi, leworkstation sono definizioni logiche che devono trovarsi su unaworkstation TWS fisica.

Una rete Tivoli Workload Scheduler 7.0 è costituita dai seguenti tipidi workstation:

Gestore dominio master (MDM)Il Gestore dominio nel dominio più alto di una rete TWS.Contiene i file di database centralizzati, utilizzati perdocumentare gli oggetti di pianificazione. Crea il piano diProduzione all’inizio di ogni giorno ed esegue tutte leregistrazioni e i report per la rete.

Master di backupUn FTA (Fault-Tolerant Agent) in grado di assumere leresponsabilità del gestore dominio master.

Gestore dominio (DM)L’hub di gestione in un dominio. Tutte le comunicazioni dae verso gli agent in un dominio vengono instradate tramite ilGestore dominio.

Gestore dominio di backup (BDM)Un FTA (Fault-Tolerant Agent) in grado di assumere leresponsabilità del proprio Gestore dominio.

FTA (Fault-tolerant Agent)Una workstation in grado di risolvere dipendenze locali e diavviare i lavori in assenza del Gestore dominio.

SA (Standard Agent)Una workstation che avvia i lavori solo dopo la supervisionedel relativo Gestore dominio.

XA (Extended Agent)Una definizione logica della workstation che consente di

Tivoli Workload Scheduler 7.0

2 Versione 7.0

avviare e controllare i lavori su altri sistemi e applicazioni,ad esempio Baan, Peoplesoft, Applicazioni Oracle, SAP,MVS JES2 e JES3.

Agent di reteUna definizione logica della workstation per la creazione didipendenze tra i lavori e i flussi di lavoro in reti TWSseparate.

Client JS ConsoleOgni workstation che esegue la GUI da cui gli scheduler egli operatori possono gestire gli oggetti del database e unapianificazione TWS.

Nella tabella seguente vengono elencati i componenti di TWS 7.0 eil relativo tipo di workstation:

Tipo di workstation Motore TWS Connettore TMF/TWS JS Console

Gestore dominio master Sì Sì Facoltativo

Master di backup Sì Sì Facoltativo

Gestore dominio (DM) Sì Facoltativo Facoltativo

Gestore dominio dibackup

Sì Facoltativo Facoltativo

FTA (Fault-tolerantAgent)

Sì Facoltativo Facoltativo

SA (Standard Agent) Sì No Facoltativo

XA (Extended Agent) Non applicabile Non applicabile Non applicabile

Agent di rete Non applicabile Non applicabile Non applicabile

Client JS Console No No Sì

Novità in Tivoli Workload Scheduler 7.0Le nuove caratteristiche di TWS 7.0 vengono riportate di seguito:

¶ Integrazione con la TMR (Tivoli Management Region)

¶ Utilizzo di una nuova GUI

¶ Controllo

¶ Internazionalizzazione

1.Introduzione

¶ Fusi orari

Tivoli Management FrameworkLa nuova versione di TWS richiede l’installazione di TivoliManagement Framework almeno sulla CPU Master e sull’FTAindicato come copia di backup. Questo per due motivi fondamentali:

1. Il Connettore è un prodotto basato sulla framework. Si basa sulJSS (Job Scheduling Services), che fornisce un’interfaccia dellaframework comune alle applicazioni job scheduling. I Connettoriper TWS e OPC condividono una base JSS comune che, a suavolta, si basa su Tivoli Management Framework. Questoconsente agli utenti di TWS e di OPC di accedere ai sistemi dipianificazione del lavoro attraverso un’interfaccia comune, la JSConsole.

2. Poiché il Master e almeno un FTA di backup devono essereinstallati sulle macchine che eseguono TMF, la rete TWS traebenefici della gestione d’impresa basata sulla Framework. E’possibile stabilire se installare il Master su un server TMRautonomo o su un nodo gestito appartenente a una TMR piùgrande. In questo caso, il nodo gestito può essere il client di unaserie di altri servizi Tivoli nelle aree di sviluppo, diamministrazione o di disponibilità. In ogni caso, il Master el’FTA di backup trarranno profitto dalle funzioni amministrativee di sicurezza di Tivoli Management Framework.

Job Scheduling ConsoleJob Scheduling Console è una GUI da cui è possibile gestire lapianificazione e gli oggetti del database. Essa fornisce, attraverso ilconnettore TWS, le funzioni Conman e Composer. Può essereeseguita indipendentemente da o contemporaneamente alla CLI(Command line Interface).

Mentre l’utilizzo dei comandi CLI è limitato alle CPU di TWS, èpossibile installare JS Console su macchine esterne alla rete TWS.Per avviare JS Console, è necessario semplicemente effettuare illogin alla CPU di TWS che esegue il Connettore. Ciò indica che èpossibile gestire gli oggetti del database e la pianificazione non solodal Master o dalle CPU dell’Agent, ma anche da un qualsiasi altro

4 Versione 7.0

sistema, incluso un portatile, su cui è installata la JS Console e dacui è possibile raggiungere via TCP/IP il Master o l’FTA che esegueil Connettore.

Dalla stessa JSC (Job Scheduling Console) è possibile inoltre gestiregli oggetti di database e la pianificazione OPC Tivoli, purché siapossibile effettuare il login a una macchina che esegue il connettoreOPC.

La procedura di installazione di JS Console viene spiegata neidettagli in “Installazione di Tivoli Job Scheduling Console” apagina 99.

La figura seguente mostra le relazioni tra Tivoli ManagementFramework, Job Scheduling Service, TWS e i sistemi dipianificazione del lavoro OPC e la JS Console.

Terminologia JS ConsoleLa terminologia utilizzata in Job Scheduling Console è diversa daquella utilizzata nella riga comandi e nelle versioni precedenti diWorkload Scheduler. La tabella seguente elenca i vecchi termini e iloro equivalenti in Job Scheduling Console. Per ulteriori definizionifare riferimento al glossario.

1.Introduzione

Riga comandi Job SchedulingConsole

Definizione

Pianificazione Flusso di lavoro Una unità di lavoro costituita da unaserie di lavori e relative dipendenze.

Istanza flusso di lavoro La ricorrenza di un flusso di lavoro nelpiano.

Lavoro Lavoro Un file eseguibile, un’attività o uncomando e i relativi attributi. Deveessere eseguito come parte di un flussodi lavoro.

Istanza di lavoro La ricorrenza di un lavoro nellapianificazione.

Cpu Workstation Un processore logico–generalmente uncomputer–che esegue i lavori. I tipi diworkstation includono Gestoridominio, Gestori dominio di backup,FTA (Fault-Tolerant Agent), SA(Standard Agent) e XA (ExtendedAgent).

File Mozart Database Una collezione di oggetti dipianificazione che include lavori, flussidi lavoro, parametri, calendari erisorse. E’ possibile accedervi tramitecomposer, noto precedentemente comegcomposer.

File Symphony Piano L’attività pianificata per un periodo,generalmente di 24 ore. Lapianificazione viene aggiornatacontinuamente per mostrare lo statocorrente di tutte le attività WorkloadScheduler. E’ possibile accedervitramiteconman, noto precedentementecomegconman.

Ora AT Ora di inizio L’ora originale in cui comincerà unlavoro o un flusso di lavori.

Ora UNTIL Ora di scadenza L’ora dell’ultima esecuzione di unlavoro o di un flusso di lavori.

6 Versione 7.0

Riga comandi Job SchedulingConsole

Definizione

Date ON ed EXCEPT Cicli di esecuzione Le date in cui un flusso di lavoroviene eseguito o viene esclusodall’esecuzione.

VerificaUn’opzione di verifica è stata implementata per tracciare lemodifiche al database e al piano:

¶ Per il database, vengono registrate tutte le modifiche dell’utente.Comunque, il delta delle modifiche o l’immagine precedente esuccessiva non verranno registrati. Se un oggetto viene aperto esalvato, l’operazione verrà registrata anche nel caso in cui nonvenga apportata alcuna modifica.

¶ Per il piano vengono registrate tutte le modifiche dell’utente. Leoperazioni vengono registrate indifferentemente dal loro esito.

Le registrazioni di verifica vengono create nelle seguenti directory:TWShome/audit/plan

TWShome/audit/database

I file di verifica vengono registrati in un file di testo flat sumacchine singole nella rete TWS. Ciò riduce il rischio di un esitonegativo della verifica a causa di emissioni di rete e consente discrivere la registrazione in modo semplice. I formati dellaregistrazione sono gli stessi sia per il piano che per il database insenso generale. Le registrazioni sono composte da una parteprincipale che è la stessa per tutti i record, un “ID di azione” e unasezione di dati che varia a seconda del tipo di azione. Tutti i dativengono conservati in un testo chiaro e vengono formattati in mododa renderli leggibili e modificabili da un editor di testo come vi onotepad.

Consultare ilManuale per l’utente TWSper i dettaglisull’impostazione della funzione di verifica.

1.Introduzione

InternazionalizzazioneOltre che in inglese, il TWS 7.0 viene tradotto in varie lingue. Cioè:tedesco, francese, italiano, spagnolo, portoghese brasiliano, cinese,coreano e giapponese.

Considerazioni sul fuso orarioIl supporto del fuso orario è una funzione che può essere abilitata odisabilitata. I fusi orari vengono abilitati se l’indicatoreabilita fusoorario nel file globalopts è impostato susì e se la workstationprincipale ha una definizione di fuso orario.

I fusi orari vengono disabilitati per default al momentodell’installazione del prodotto.

Se i fusi orari sono abilitati, i campi del fuso orario in JobScheduling Console sono attivi. Se il campo del fuso orario didefinizione della workstation è vuoto, viene impostato per default sulfuso orario della workstation del gestore dominio master (MDM).

Se i fuso orari sono disabilitati, tutti i campi del fuso orario vengonodisabilitati in tutta l’applicazione. In composer e conman, è possibilericevere un messaggio di errore se si tenta di specificare un fusoorario insieme a un’ora. In Job Scheduling Console, i campi del fusoorario sono disabilitati sia per il database che per il piano. La solaeccezione a ciò sono le workstation nel database, che hanno sempreil fuso orario abilitato.

Quando si abilita il fuso orario per la workstation master, si consigliadi immettere un fuso orario per ogni FTA che non ha lo stesso fusoorario della workstation master. Si presume che un campo del fusoorario FTA vuoto sia come quello del fuso orario del master.

Una volta abilitati i fusi orari, è possibile immettere un fuso orariocon un’ora in conman, in composer o in Job Scheduling Console. Sesi immette un’ora senza fuso orario, questo verrà preso dallaworkstation su cui si esegue il lavoro o il flusso di lavori oppure daun fuso orario di una workstation master se il campo del fuso orariodella workstation in esecuzione è vuoto.

8 Versione 7.0

Pianificazione di retePrima di cominciare l’installazione di Tivoli Workload Scheduler, ènecessario rispondere alle domande riportate di seguito. Le sezionisuccessive forniscono informazioni per determinare le risposte chemeglio si adattano alle richieste dell’utente.

1. Si utilizzerà una struttura a più domini o una struttura a dominiosingolo?

2. Se vengono utilizzati più domini, come è possibile raggrupparli?

¶ Per ubicazione geografica, ad esempio i domini di Londra eParigi?

¶ Per fuso orario, ad esempio PST (Pacific Standard Time) edEST (Eastern Standard Time)?

¶ Per unità aziendale, ad esempio marketing e accounting?

3. Si utilizzeranno database espansi o non espansi?

4. Sarà possibile attivare la funzione del fuso orario?

Panoramica della rete TWSUna rete Workload Scheduler contiene almeno un dominio WorkloadScheduler, il dominio master, in cui il gestore dominio master èl’hub di gestione. E’ possibile utilizzare domini ulteriori per dividereuna rete ampiamente distribuita in gruppi più piccoli gestitilocalmente.

L’utilizzo di più domini riduce la quantità di traffico di rete,riducendo così anche le comunicazioni tra il Gestore dominio mastere gli altri computer.

In una configurazione a dominio singolo, il gestore dominio mastergestisce le comunicazioni con tutte le workstation della reteWorkload Scheduler.

In una configurazione a più domini, il gestore dominio mastercomunica con le workstation del proprio dominio e con i gestoridominio subordinati. I gestori dominio subordinati, a loro volta,comunicano con le workstation nei propri domini e con i gestori

Pianificazione di rete

1.Introduzione

dominio subordinati. Più domini forniscono anche un FTA, limitandoi problemi causati dalla perdita di un Gestore dominio per undominio singolo. Per limitare ulteriormente gli effetti, è possibileindicare i Gestori dominio di backup da controllare se i Gestoridominio a essi relativi riportano esito negativo.

Funzionalità del dominioQuando si definisce un nuovo dominio, è necessario identificare ildominio parent e il gestore dominio. Il dominio parent è il dominioche si trova immediatamente al di sopra del nuovo dominio nellagerarchia dei domini. Tutte le comunicazioni da e verso un dominiovengono instradate attraverso un gestore dominio parent.

Prima dell’avvio giornaliero, il gestore dominio master crea un filedi controllo della produzione, denominato Symphony. TivoliWorkload Scheduler, dunque, viene riavviato nella rete e il gestoredominio master invia una copia del nuovo file Symphony a ognunodegli agent collegati automaticamente e ai Gestori dominiosubordinati. I Gestori dominio, a loro volta, inviano copie ai loroagent collegati automaticamente e ai Gestori dominio subordinati.

Una volta avviata la rete, i messaggi di pianificazione come gli avviie i completamenti dei lavori, vengono inviati dagli agent ai loroGestori dominio attraverso i Gestori dominio parent al gestoredominio master. Il gestore dominio master trasmette i messaggiall’albero della gerarchia per aggiornare i file Symphony dei Gestoridominio e degli FTA in esecuzione in modalità Stato completo.

Elaborazione localizzata nel dominioUna chiave, che consente di stabilire il modo in cui impostare idomini Tivoli Workload Scheduler, è il concetto di elaborazionelocalizzata. L’idea è di separare o di localizzare le proprie necessitàdi pianificazione in base a una serie di caratteristiche comuni.

Esempi di caratteristiche comuni sono posizioni geografiche,funzioni aziendali e raggruppamenti di applicazione. Ilraggruppamento dell’elaborazione correlata può limitare la quantitàdi informazioni di interdipendenza che devono essere comunicate trai domini. I benefici dell’elaborazione localizzata nei domini sono:

10 Versione 7.0

¶ Diminuzione del traffico di rete. Se l’elaborazione restalocalizzata nei domini, non sono più necessarie comunicazionifrequenti tra domini.

¶ Fornisce una soluzione utile per limitare la sicurezza esemplificare l’amministrazione. E’ possibile definire sul dominioe limitare, a livello del dominio, la sicurezza el’amministrazione. E’ possibile amministrare un dominio, invecedi amministrare nello specifico una workstation o l’intera rete.

¶ E’ possibile ottimizzare l’FTA di rete e della workstation. In unarete TWS di più domini, è possibile definire le copie di backupper ogni Gestore dominio, in modo che i problemi in un dominionon interrompano le operazioni in altri domini.

Considerazioni sulla reteLe domande seguenti saranno utili per l’installazione della rete TWS.Alcune riguardano gli aspetti della rete e altre le applicazionicontrollate da TWS. Per risolvere determinati problemi, potrebbeessere necessario consultare altre persone della propria società.

¶ Quanto è grande la rete TWS? Quanti computer la compongono?Quanti lavori e applicazioni vengono eseguiti in essa?

E’ importante conoscere la dimensione della rete per stabilire seutilizzare una struttura a dominio singolo o a più domini. Se visono pochi computer o poche applicazioni da controllare conTivoli Workload Scheduler, potrebbe non essere necessaria unastruttura a più domini.

¶ Quante zone geografiche sono coperte dalla rete TWS? Quantosono attendibili ed efficienti le comunicazioni tra le ubicazioni?

Questo è uno dei motivi principali per scegliere una struttura apiù domini. Un dominio per ogni localizzazione geografica è unaconfigurazione comune. Se si sceglie una struttura a dominiosingolo, la gestione di un’elaborazione continua sulla reterisulterà più sicura.

¶ Si desidera una gestione centralizzata o decentralizzata di TWS?

Una rete TWS, con un dominio singolo o con più domini,consente di gestire TWS da un nodo singolo, il gestore dominiomaster. Se si desidera gestire separatamente più ubicazioni, è

1.Introduzione

possibile considerare l’installazione di una rete separata TWS suogni ubicazione. Notare che alcuni livelli di gestionedecentralizzata sono possibili solo in una rete TWS autonomacaricando o condividendo i file system.

¶ Vi sono più entità logiche o fisiche su un solo sito? Edificidiversi e più piani in ogni edificio? Dipartimenti o funzioniaziendali differenti? Applicazioni differenti?

Questi potrebbero essere i motivi per scegliere unaconfigurazione a più domini. Ad esempio, un dominio per ogniedificio, dipartimento, funzione aziendale o ogni applicazione(produzione, finanziaria, ingegneria ecc.).

¶ Si eseguono applicazioni come SAP R/3 o Baan cheutilizzeranno Tivoli Workload Scheduler?

Se sono separate da altre applicazioni, è possibile scegliere diintrodurle in un dominio Tivoli Workload Scheduler separato.

¶ Si desidera che i domini Tivoli Workload Scheduler effettuino ilmirror dei domini Windows NT?

Ciò non è necessario, ma potrebbe essere utile.

¶ Si desidera isolare o differenziare una serie di sistemi basatisulle prestazioni o su altri criteri?

Questo potrebbe essere un altro motivo per definire più dominiTivoli Workload Scheduler per localizzare i sistemi in base alleprestazioni o al tipo di piattaforma.

¶ Qual è, adesso, l’intensità di traffico di rete?

Se il traffico di rete è gestibile, non è strettamente necessarioavere più domini.

¶ Le dipendenze Lavoro superano i limiti del sistema, i limitigeografici o delle applicazioni? Ad esempio, l’avvio di Lavoro1sulla CPU3 dipende dal completamento di Lavoro2 inesecuzione sulla CPU4?

Il livello di interdipendenza tra i lavori è una considerazioneimportante quando si crea una rete TWS. Se si utilizzano piùdomini, è necessario tenere oggetti interdipendenti nello stessodominio. In questo modo viene ridotto il traffico di rete e siottengono prestazioni migliori della struttura del dominio.

12 Versione 7.0

¶ Quale livello di FT è necessario?

Uno svantaggio ovvio di una configurazione a dominio singolo èil fare affidamento su un Gestore dominio singolo. In una rete apiù domini, la perdita di un Gestore dominio singolo riguardasolo gli agent in quel dominio.

Rete a dominio singoloUna rete TWS a dominio singolo consiste solo di un Gestoredominio master e di un qualsiasi numero di agent. Il diagrammariportato di seguito mostra un esempio di rete a dominio singolo.Una rete a dominio singolo è adatta alle società con poche sedi efunzioni aziendali. Tutte le comunicazioni nella rete vengonoinstradate attraverso il Gestore dominio master. Con una ubicazionesingola, l’utente deve preoccuparsi solo dell’affidabilità della retelocale e della quantità di traffico che essa è in grado di gestire.

E’ importante notare che le reti a domini singoli possono esserecombinate con altre reti, a domini singoli o a più domini, persoddisfare le richieste di più siti.

TWS supporta dipendenze tra più reti tra i lavori in esecuzione sureti TWS differenti.

1.Introduzione

L’esempio riportato nella figura in alto a sinistra mostra una rete adominio singolo. Il gestore dominio master (MDM) si trova adAtlanta, con più agent. Vi sono anche agent ubicati a Denver. Lasoluzione di tutte le dipendenze tra agent da parte degli agent diDenver dipende dal gestore dominio master (MDM) di Atlanta,anche se le dipendenze possono trovarsi sui lavori in esecuzione aDenver. Un’alternativa sarebbe quella di creare reti TWS a dominiosingolo ad Atlanta e Denver, come è possibile constatarenell’esempio riportato nella figura a destra.

I vantaggi delle reti a dominio singolo sono:

¶ Struttura più semplice.

¶ Gestione e controllo centralizzati.

Gli svantaggi di reti a dominio singolo sono:

¶ Tutte le comunicazioni devono passare attraverso il gestoredominio master. Ciò può provocare un sovraccarico in una reteampiamente distribuita.

¶ L’errore del gestore dominio master si ripercuote su tutta la reteTWS.

14 Versione 7.0

Rete a più dominiLe reti a più domini sono particolarmente adatte alle società con piùfunzioni aziendali, dipartimenti o sedi. Una rete TWS a più dominiconsiste di un gestore dominio master, di un qualsiasi numero diGestori dominio della schiera inferiore e di un qualsiasi numero diagent in ogni dominio. Gli agent comunicano solo con i propriGestori dominio e i Gestori dominio comunicano solo con i propriGestori dominio parent.

Il diagramma mostra un esempio di rete a più domini. Questodiagramma è stato creato in base all’esempio riportato per le reti conun solo dominio. Il gestore dominio master (MDM) si trova adAtlanta; esso dispone dei file di database utilizzati per documentaregli oggetti di pianificazione e distribuisce il file Symphony agliagent e ai Gestori dominio di Denver e di Los Angeles. I gestoridominio di Denver e di Los Angeles distribuiscono quindi il fileSymphony ai propri agent e ai gestori dominio subordinati inBoulder, Aurora e Burbank. Il gestore dominio (DM) di Atlanta èresponsabile della trasmissione delle informazioni tra domini nellarete.

1.Introduzione

Tutte le comunicazioni da e verso il gestore dominio di Bouldervengono instradate nel gestore dominio parent di Denver. Se vi sonopianificazioni o lavori nel dominio di Boulder che dipendono dallepianificazioni o dai lavori nel dominio di Aurora, quelle dipendenzevengono determinate dal gestore dominio di Denver. Più dipendenzetra agent vengono gestite localmente dal gestore dominio dellaschiera inferiore, riducendo notevolmente il traffico sulla WAN(Wide Area Network).

Vantaggi di reti a più domini:

¶ Le pianificazioni e i lavori adhoc possono essere inoltrati dalgestore dominio master oppure da un qualsiasi altro gestoredominio o agent che abbia accesso ai file di database sul gestoredominio master.

¶ Traffico di rete ridotto per l’elaborazione localizzata.

¶ Risoluzione locale delle dipendenze tra agent.

¶ Sicurezza e amministrazione localizzate.

¶ Topologia flessibile definita sul modello aziendale.

¶ Switchover consentito per il gestore dominio di backup.

Come passare a un gestore dominio di backup (BDM)Ogni dominio ha un gestore dominio e, facoltativamente, uno o piùgestori domini di backup. Un gestore dominio di backup devetrovarsi nello stesso dominio del gestore dominio di cui effettua unacopia di backup. I gestori dominio di backup devono essere FTA cheeseguono Tivoli Workload Scheduler 7.x e devono avere le opzioniRisolvi dipendenze e Stato completo abilitate nelle definizioni dellaworkstation.

Se un gestore dominio non riesce durante il giorno di produzione, èpossibile utilizzare Job Scheduling Console o il comandoswitchmgrnella riga comandi Console Manager (conman), per passare a ungestore dominio di backup. Un’azione Switch Manager può essereeseguita da chiunque abbia l’autorizzazione all’avvio o all’arrestodelle workstation del gestore dominio e del gestore dominio dibackup.

16 Versione 7.0

Un’operazione di passaggio al gestore arresta il gestore dominio, poilo riavvia come nuovo gestore dominio e converte il gestore dominioprecedente in FTA. Le identità dei gestori dominio correnti vengonoportate nel file Symphony da un giorno di elaborazione all’altro,quindi ogni switch rimane attivo fino a che non si ritorna al gestoredominio d’origine.

Database espansi e nomi di oggetto estesiI database Tivoli Workload Scheduler e il file Symphony sono statiespansi per contenere più record e nomi di oggetti più lunghi. Ciòconsente una maggiore flessibilità quando si denominano gli oggettidi pianificazione, specialmente con i pacchetti tipo SAP R/3, Baan,ecc.

¶ I database espansi sono un valore di default in Tivoli WorkloadScheduler 7.0. In questo modo è possibile utilizzare nomi estesiper gli oggetti di pianificazione -- ad esempio, i nomi del lavoropossono contenere un massimo di quaranta caratteri invece degliotto caratteri delle versioni precedenti.

¶ I database non espansi vengono utilizzati in modo da rimanerecompatibili con le workstation del Maestro 5.x che nonsupportano i database espansi.

1. E’ consigliabile che il master esegua una versione di TWSuguale o precedente agli FTA nel dominio.

2. Se si dispone di agent MPE (HP3000), non eseguire databasenon espansi.

Creazione del databasePer le nuove installazioni, i database Tivoli Workload Schedulervengono creati sul gestore dominio master la prima volta in cui siavvia il motore TWS. Il tipo di database creato, espanso o nonespanso, viene determinato verificando le Opzioni globaliexpandedversion = [yes|no]. Questa opzione viene impostata dallo scriptcustomize al momento dell’installazione del motore TWS. Il valoredi default è espanso, impostato suyes.

1.Introduzione

E’ possibile selezionare i database non espansi, se si installa primaTWS 7.0, quindi espanderli. Per espandere i database, eseguire ilcomandodbexpand sul gestore dominio master. Il programmaimposta la versione espansa di Opzione globale su yes, effettua copiedi backup dei database esistenti ed espande i database per accettare inomi estesi degli oggetti. Eseguire dbexpand una sola volta,altrimenti la copia di backup dei database esistenti verrà persa. Lecopie di backup si trovano in una directory denominatamozart.oldnella directory mozart.

Nomi della workstationLa pianificazione del lavoro in una rete Tivoli Workload Schedulerviene distribuita tra più computer. Per tenere traccia di lavori,pianificazioni e altri oggetti, a ogni computer viene fornito un nomedi workstation univoco. I nomi possono essere uguali ai nomi deinodi di rete, poiché si adattano alle regole di denominazione diTivoli Workload Scheduler:

¶ Per reti non espanse, i nomi della workstation possono contenereun numero massimo di otto caratteri alfanumerici, trattini (-) eunderscore (_) con una lettera iniziale.

¶ Per reti espanse, la lunghezza massima è di sedici caratterialfanumerici, trattini (-) e underscore (_) con una lettera iniziale.

Panoramica sull’installazioneQuello riportato di seguito è un riepilogo del processo d’installazionedi TWS 7.0. Questo manuale fornisce informazioni dettagliate perogni fase.

1. Su tutti i gestori domini (inclusi Master e di backup), seguirequest’ordine:

a. Se si sta installando una versione precedente del Maestro o diTWS, scollegare le altre workstation nel dominio e arrestareil Maestro o il TWS. Consultare “Come scollegare e arrestareTWS” a pagina 24 per NT e “Aggiornamento di TivoliWorkload Scheduler” a pagina 53 per UNIX.

Installare TWS 7.0 Engine. Consultare “Installazione delmotore TWS su Windows NT” a pagina 23 o “Installazione

18 Versione 7.0

del motore TWS su UNIX” a pagina 47. E’ possibile invertirel’ordine di esecuzione di questa e della prossima istruzione.

b. Installare Tivoli Management Framework. Se nella propriasocietà non esiste già una TMR, installarla come server TMR.Se esiste già una TMR, è possibile scegliere di installarlacome nodo gestito. Per i dettagli, consultare ladocumentazione sull’installazione di TMF.

c. Installare Job Scheduling Services e il connettore TWS suTivoli Framework. Consultare “Installazione del connettoreTWS” a pagina 79.

d. Dal desktop Tivoli, creare un Amministratore Tivoli perTWS. In altre parole, aggiungere l’utente del TWS o delMaestro come login all’amministratore TMF oppure creare unnuovo amministratore TMF con il login al TWS o al Maestro.

e. Aggiornare la sicurezza TWS per includere l’AmministratoreTivoli.

¶ Su NT, è necessario arrestare TWS prima di eseguire ilcomandomakesec.

¶ Su UNIX, è possibile eseguiremakesecsenza primaarrestare il TWS, ma è necessario arrestare e riavviareTWS per attivare una funzione di sicurezza.

f. Facoltativamente, installare Job Scheduling Console.Consultare “Installazione di Tivoli Job Scheduling Console” apagina 99.

2. Installare quanto segue su ogni workstation che si desideraincludere come agent alla rete TWS:

¶ TWS 7.0 Engine.

¶ Job Scheduling Console (facoltativo). E’ possibile installareJS Console anche su workstation che non si trovano nellarete TWS che hanno una connessione TCP/IP con un gestoredomini che esegue il connettore TWS.

3. Effettuare il login a Job Scheduling Console e definire leworkstation nella rete TWS per il database TWS.

Panoramica sull’installazione

1.Introduzione

4. E’ possibile utilizzare Job Scheduling Console per definire ilavori, i flussi di lavoro e altri oggetti di pianificazione.

Gruppi di prodottiI prodotti Tivoli sono organizzati in gruppi. Ogni gruppo ha unprocesso Netman per gestire i servizi necessari per tutti i prodotti delgruppo. Ciò consente inoltre che più copie di un prodotto sianoinstallate su un solo computer indicando un gruppo differente perogni copia.

File dei componentiI gruppi dei prodotti vengono definiti nel file dei componenti. Se ilfile non esiste prima dell’installazione, esso viene creato dallo scriptCustomizesu UNIX o sul programmaSetupsu Windows NT. Segueun esempio UNIX:

MaestroDestinyNetman

5.1.11.0.23.3.5

/opt/maestro/opt/destiny/opt/netman

productionproductionproduction

Le voci nel file vengono create e aggiornate automaticamente dalloscript Customize o da Setup. Se non viene specificato un altrogruppo, il gruppo del prodottoworkstation_userviene utilizzatocome valore di default su NT.

Su UNIX, il nome del file dei componenti è definito nella variabile:UNISON_COMPONENT_FILE

Se la variabile non è impostata, customize utilizza il nome file:/usr/unison/components

Su Windows NT, il nome del file dei componenti,netmanhome\components, viene archiviato nel registro la prima voltain cui si installa questa versione di Workload Scheduler. Consultare“Home directory di Netman” a pagina 21.

Panoramica sull’installazione

20 Versione 7.0

Visualizzazione del file dei componentiDopo l’installazione o l’aggiornamento, è possibile visualizzare icontenuti del file dei componenti con il programmaucomp in questomodo:ucomp -l

Home directory di NetmanUna opzione nello scriptcustomizesu UNIX e un pannelloSetup suWindows NT consentono di specificare una home directory perNetman. Se ignorato, il valore di default su UNIX è la homedirectory di Workload Scheduler, mentre su Windows NT il valore didefault è:c:\win32app\unison\netman.

Opzioni locali di NetmanSe la home directory di Netman non è la stessa di WorkloadScheduler, le seguenti opzioni locali vengono spostate dal filelocalopts dello Scheduler su un file localopts separato nella directoryNetman:nm mortalnm portnm readnm retrymerge stdlistsstdlist widthsyslog local

Inoltre, se necessario, è possibile aggiungere le opzioni seguenti:nm invalidate

Consultare la sezione 2 nel Manuale per l’amministratore TivoliWorkload Scheduler per ulteriori informazioni sulle opzioni locali.

Dopo l’installazioneDopo l’installazione di Workload Scheduler, fare riferimento alManuale per l’utente Tivoli Workload Schedulerper laconfigurazione e l’impostazione delle informazioni.

Gruppi di prodotti

1.Introduzione

22 Versione 7.0

Installazione del motore TWS suWindows NT

Questo capitolo descrive il processo d’installazione di TivoliWorkload Scheduler (TWS) su sistemi e reti Windows NT.

Requisiti di sistemaI seguenti sono requisiti di sistema TWS per sistemi Windows NT.

¶ Windows NT versione 4.0 con Service Pack 4 o versionesuccessiva.

¶ L’unità CD-ROM per l’installazione.

¶ Partizione NTFS per installare TWS.

¶ Approssimativamente 100 MB di spazio libero su disco per iGestori dominio e per gli FTA. Approssimativamente 40 MB pergli SA (Standard Agent). Inoltre, TWS produce file di log e filetemporanei ubicati sull’unità fissa locale. La quantità di spazionecessario dipende dal numero di lavori gestiti dal TWS e daltempo specificato per la conservazione dei log.

¶ 128 MB di RAM e 128 MB di spazio swap per Gestori dominied FTA. Gli SA ne richiedono una quantità minore.

¶ Comunicazioni di rete TCP/IP.

¶ E’ necessario un account utente TWS per una installazioneadeguata. E’ possibile creare l’account in anticipo oppure farlocreare dal programma Setup.

2.Installazione

delmotore

Window

Prima di continuare, consultare leNote di release Tivoli WorkloadSchedulerper informazioni sugli ultimi requisiti di sistema e suquestioni specifiche della piattaforma.

Preparazione di un aggiornamentoSe si tratta di un aggiornamento di una installazione esistente diTWS, leggere queste istruzioni prima di eseguire il programmaSetup. Al termine, fare riferimento a “Come completare unaggiornamento” a pagina 37 per importanti informazionipostinstallazione.

Nota: L’approccio standard per l’aggiornamento di una rete TWS èquello di aggiornare prima gli SA e gli FTA, quindi il gestoredominio master. Tuttavia, prima di decidere il modo in cuiaggiornare una rete TWS, fare riferimento alleNote di releaseTivoli Workload Schedulerper le ultime informazioni sullamigrazione relative alla nuova versione del software.

Come scollegare e arrestare TWSPrima di avviare un aggiornamento di TWS, seguire le istruzioniriportate più avanti per scollegare le workstation e per arrestare iprocessi TWS. Tenere presente che questa procedura è utile pereffettuare un aggiornamento da una versione precedente di TWSoppure del Maestro 6.x o 5.x.

1. Sulla workstation di destinazione, effettuare il login comemaestro se si sta effettuando l’aggiornamento dal Maestro 5.2oppure comeAmministratore se si sta effettuandol’aggiornamento dal Maestro 6.x. Eseguire il Console Manager.

2. Fare clic sull’icona della workstation o selezionare le CPU dalmenu Oggetti.

3. Nella finestra Visualizza CPU:

a. Se si sta aggiornando il gestore dominio master, selezionaretutti gli FTA e gli SA e selezionare Scollega dal menu Azioni.

b. Se si sta aggiornando una workstation FTA o SA, selezionareil gestore dominio master, quindi selezionare Scollega dalmenu Azioni.

Requisiti di sistema

24 Versione 7.0

4. Selezionare la workstation da aggiornare, quindi selezionareArresta dal menu Azioni.

5. Uscire dal Console Manager.

6. Alla prompt dei comandi, eseguire la riga comandi daTWShomee immettere il seguente comando per arrestare i servizi TWS:conman “shutdown;wait”

File di backupIl programmaSetup di TWS sposterà le copie di Sfinal, Jnextday,NetConf, StartUp e le directory dei metodi su una directorydenominata:TWShome\config.old

Spesso questi file vengono personalizzati per rispondere alle richiestespecifiche dell’utente ed è possibile utilizzare le copie salvate perinserire le modifiche che seguono l’aggiornamento. Il programmaSetup non sostituisce i file nelle directory mozart, stdlist o unisoninstallate dopo l’installazione di TWS.

Se non vi sono altri file da proteggere durante l’aggiornamento,copiarli o ridenominarli. Come precauzione ulteriore, effettuare ilbackup dell’intera directoryTWShome.

Ora è possibile eseguire il programma Setup. Consultare“Installazione del software”.

Installazione del softwareUtilizzare il programma Setup per installare il motore TWS suWindows NT.

Programma SetupIl programmaSetup installa o aggiorna il TWS. Tale programmaesegue queste funzioni:

¶ Nuova installazione di TWS: installare TWS e Netman. Crea unfile dei componenti con nuove voci.

Preparazione di un aggiornamento

2.Installazione

delmotore

Window

¶ Primo aggiornamento di TWS versione 6.0 e precedenti:aggiorna TWS e Netman, se necessario. Crea un file deicomponenti con nuove voci.

¶ Successivi aggiornamenti di TWS: aggiornare TWS e Netman, senecessario. Aggiornare le voci nel file dei componenti.

Esecuzione di Setup1. Verificare di disporre dei privilegi dell’amministratore locale

sulla workstation su cui si deve installare il TWS.

2. Chiudere le applicazioni Windows aperte, incluso Windows NTExplorer.

3. Inserire il CD TWS.

4. Eseguire il programma TWSSetup:d:\tivoli\i386\maestro\setup.exe

doved è la lettera dell’unità CD.

5. Viene visualizzata la finestra Seleziona lingua installazione.Selezionare la lingua desiderata e fare clic suOK .

Installazione del software

26 Versione 7.0

6. Viene visualizzata la finestra di Benvenuto.

7. Per continuare, fare clic suAvanti > sulla finestra Benvenuto.Viene visualizzata la finestra Process Warning. Per continuare,fare clic suAvanti > . Se si sta aggiornando TWS, verificare chetutti i processi TWS siano stati arrestati, inclusi i serviziTivoli.Se si è disinstallato TWS prima di eseguire Setup, ènecessario riavviare il computer prima di continuare (consultare“Come disinstallare TWS” a pagina 44 per i dettagli sulladisinstallazione). Per svolgere queste attività, uscire da Setup

2.Installazione

delmotore

Window

facendo clic suAnnulla .

8. Sulla finestra Opzioni di installazione, selezionare il tipo diinstallazione e fare clic suAvanti > .

Copia file e personalizzaCopia i file Netman dal CD e personalizzal’installazione. Questa opzione deve essere selezionataper nuove installazioni e aggiornamenti.

28 Versione 7.0

Sola personalizzazionePersonalizza i file esistenti. I permessi vengonoimpostati nuovamente sui valori di default.

9. Sulla finestra Informazioni account, immettere le informazioniseguenti e fare clic suAvanti > :

Account

Il nome dell’utente TWS (generalmentetwsuseromaestro). Il software viene installato oppure aggiornatoin questa home directory dell’utente. E’ possibileincludere il dominio, se applicabile - ad esempio:hqtrs\twsuser. Se si omette il dominio, Setup ricerca unaccount corrispondente: 1) localmente, 2) nel dominiooppure 3) in un dominio trusted.

Se necessario,Setup crea automaticamente l’account, lahome directory e concede i diritti necessari.

PasswordPassword di account.

Conferma passwordImmettere nuovamente la password di account.

Nota: Se si sta installando più di una istanza di TWS su uncomputer, notare che ogni installazione tenterà di

2.Installazione

delmotore

Window

collocare i file nella directoryTWShome\..\unison. Perevitare conflitti, verificare che le directory parent sianodifferenti. Ad esempio,c:\apps\maestroec:\apps1\maestro.

10. Selezionare la directory di destinazione in cui si desiderainstallare TWS. Se si desidera un valore che non sia quello didefault, fare clic suSfoglia per specificare una scelta differente.Al termine, fare clic suAvanti per continuare.

30 Versione 7.0

11. Dalla finestra Determina estensione del database selezionare unadelle seguenti opzioni e fare clic suAvanti > :

Database espansi (Supporta Nomi oggetto estesi)Utilizza i database espansi disponibili solo in Maestro6.0 e versioni precedenti.

Database non espansi (Compatibili con Maestro 5.x)Utilizza database non espansi. Deve essere utilizzato perinstallare TWS sul gestore dominio master di una retecontenente workstation che eseguono una versione TWSprecedente alla 6.0 oppure ogni versione di Maestro perMPE. I database possono essere espansi utilizzando ilcomandodbexpand. Fare riferimento alManuale perl’utente Tivoli Workload Schedulerper ulterioriinformazioni sul comandodbexpand.

Nota: Se la rete include workstation MPE, è necessarioutilizzare la modalitàunexpanded. Le workstation MPEnon possono essere incluse alle retiespanseTWS.

2.Installazione

delmotore

Window

12. Dalla finestra Informazioni di configurazione immettere leinformazioni seguenti e fare clic suAvanti > :

SocietàIl nome della propria società.

Questa CPUIl nome TWS di questa workstation. Per la versione nonespansa di TWS, questo può contenere fino a ottocaratteri alfanumerici, trattini (-) o underscore (_) conuna lettera iniziale. Per la versione espansa, lalunghezza è di sedici caratteri. Questo nome deve essereutilizzato in seguito per definire formalmente laworkstation in TWS.

CPU masterIl nome TWS del gestore dominio master. Se questo è ilgestore dominio master o una workstation autonoma, ilnome è lo stesso di questa CPU. Per la versione nonespansa di TWS, questo può contenere fino a ottocaratteri alfanumerici, trattini (-) o underscore (_) conuna lettera iniziale. Per la versione espansa, lalunghezza è di sedici caratteri. Se si sta effettuando unainstallazione sul gestore dominio master, Setup creaautomaticamente la definizione della propriaworkstation.

32 Versione 7.0

Gruppo di prodottiIl nome del gruppo di prodotti per questoaggiornamento o questa installazione. Il valore didefault è″workstation_user″.

Nota: Se Netman non è installato nel gruppo di prodotti, neviene richiesta l’installazione. L’installazione di Netmanè necessaria nel gruppo di prodotti prima di potereseguire TWS con esito positivo. Se Netman è giàinstallato nel gruppo di prodotti, vengono ignorate laprompt e le successive istruzioni di Netman Setup.

13. Netman Setup. Sulla finestra di Benvenuto fare clic suAvanti> per installare Netman.

Nota: Se la finestra di Benvenuto non appare, utilizzare labarra di attività di Windows NT per portarla in primopiano.

2.Installazione

delmotore

Window

14. Netman Setup. Sulla finestra Opzioni di installazione,selezionare il tipo di installazione e fare clic suAvanti > .

Copia file e personalizzaCopia i file Netman dal CD e personalizzal’installazione. Questa opzione deve essere selezionataper nuove installazioni e aggiornamenti.

Sola personalizzazionePersonalizza i file esistenti. I permessi vengonoimpostati nuovamente sui valori di default.

15. Netman Setup. Sulla finestra Directory di destinazioneselezionare la directory per installare Netman e fare clic suAvanti > . Il valore di default è:c:\win32app\unison\netman

Per selezionare una directory differente fare clic suSfoglia eselezionare una directory. Se la directory non esiste, vienerichiesto di crearla. Inoltre, se il file dei componenti non esiste,

34 Versione 7.0

viene creato in questa directory.

16. Netman Setup. Sulla finestra Porta Netman immettere ilnumero di porta Netman e fare clic suAvanti > . Il valore didefault è 31111.

17. Netman Setup. La finestra Informazioni Setup riepiloga leinformazioni utilizzate da Setup per l’installazione di Netman.Fare clic su< Indietro per visualizzare nuovamente omodificare le informazioni oppure fare clic suAvanti > per

2.Installazione

delmotore

Window

continuare.

Dopo aver fatto clic suAvanti , viene visualizzata una finestrache indica lo stato dell’installazione dei file di Netman.

18. Infine, la finestra Informazioni Setup riepiloga le informazioniutilizzate da Setup per l’installazione di TWS. Fare clic su<Indietro per visualizzare nuovamente o modificare leinformazioni oppure fare clic suAvanti > per installare oaggiornare TWS e uscire.

36 Versione 7.0

19. L’installazione del motore TWS e Netman è terminata. Lafinestra Riavvia chiede di riavviare la workstation.

Esecuzione separata di Netman SetupE’ possibile eseguire il programma Netman Setup indipendentementedal prodotto TWS per installare o aggiornare i file Netman. Pereseguire il programma Netman Setup:

1. Inserire il CD TWS.

2. Eseguire il programma Netman Setup:d:\maestro\i386\netman\setup.exe

Dopo l’installazione o l’aggiornamentoEffettuare le seguenti attività dopo l’installazione o l’aggiornamentodi TWS.

Come completare un aggiornamentoSe si tratta di un aggiornamento di una applicazione esistente,seguire queste istruzioni:

1. Su ogni workstation aggiornata, utilizzando come riferimento ifile protetti in “Preparazione di un aggiornamento” a pagina 24,applicare le proprie modifiche alle nuove versioni dei file.

2.Installazione

delmotore

Window

2. Sul gestore dominio master, riavviare TWS.

Il processo di aggiornamento del TWS è completo.

Impostazione della variabile PATHEffettuare il login come utente al gruppo Amministratori localioppure al gruppo Amministratori del dominio. Nell’ambiente delsistema, aggiungere le directoryTWShomee TWShome\bin allavariabile PATH. Ad esempio:other_directories;C:\win32app\maestro;C:\win32app\maestro\bin

Directory e servizi TWSSetup installa i file TWS inTWShomee TWShome\..\unisonutilizzata anche per altri prodotti Tivoli. Ad esempio, seTWShomeèc:\win32app\maestro, viene creata anche la directoryc:\win32app\unison.

Setup registra inoltre i seguenti servizi con Service ControlManager:

¶ Tivoli MAESTRO per l’utente

¶ Tivoli Netman perwkstn_user

¶ Tivoli Token Service per l’utente

Notare che Service Control Manager gestisce il proprio databasedelle password utente. Perciò, se la passwordTWSuservienemodificata in base all’installazione, è necessario utilizzare l’appletdei Servizi nel Pannello di controllo per assegnare la nuovapassword al Token Service e Netman.

Servizio JOBMONIl servizio Jobmon viene eseguito nell’account SYSTEM conl’autorizzazione″Consenti al servizio di interagire con il desktop″.E’ possibile rimuovere l’autorizzazione per motivi di sicurezza.Tuttavia, ciò impedirà al servizio di avviare i lavori interattivi inesecuzione in una finestra sul desktop dell’utente. Non è possibileaccedere a questi lavori; questi non dispongono dei diritti di accesso

Dopo l’installazione e l’aggiornamento

38 Versione 7.0

alle risorse del desktop. Ne risulta che essi possono essere eseguiticontinuamente oppure che possono registrare una chiusura anomalaper una mancanza di risorse.

Impostazione di una Amministrazione decentralizzataE’ possibile amministrare gli oggetti di pianificazione del TWS dacomputer diversi dal gestore dominio master di TWS su cui si trovail database.

Se si intende gestire gli oggetti di pianificazione in questo modo, ènecessario creare condivisioni per le directory nel gestore dominiomaster e definire una serie di opzioni locali su altri computer.

Condivisione delle directory masterRendere condivisibili le seguenti directory sul gestore dominiomaster e impostare i permessi per fornire un controllo totaleall’utente del dominio, delTWS o del maestro:TWShome\mozartTWShome\..\unison\network

Condivisione dei parametri TWSGeneralmente, i parametri di sostituzione TWS sono specifici delcomputer e vengono gestiti separatamente su ogni computer. Se sidesidera che i parametri siano comuni a tutti i computer e sianoamministrati da un qualsiasi computer, è possibile condividere ladirectoryTWShomecome descritto in precedenza per le altredirectory oppure copiare i parametri del database, ogni volta chequesto viene modificato, dal gestore dominio master per ognunodegli altri computer. I file di database sono:TWShome\parameters

TWShome\parameters.KEY

Utilizzo di una condivisione singolaUn’alternativa di condivisione di directory differenti è quella dispostare tutti i file di database differenti su una directory comune,condividere la directory e impostare le opzioni locali sul nome dellacondivisione. I file di database vengono elencati di seguito.

In TWShome\..\unison\ :

2.Installazione

delmotore

Window

cpudatacpudata.KEYuserdatauserdata.KEY

In TWShome\mozart\ :calendari, calendarcalendars.KEYjob.schedjob.sched.KEYlavori, jobjobs.KEYmastskedmastsked.KEYrichieste, promptprompts.KEYrisorse, resourceresources.KEY

In TWShome:parameterparameters.KEY

I file vengono creati come richiesto da TWS. Se non esistono, èpossibile semplicemente impostare le opzioni locali sulle directorycondivise come descritto di seguito.

Impostazione delle opzioni localiPer accedere ai database master condivisi, impostare le opzioni localisu ogni computer da cui si desidera amministrare gli oggetti dipianificazione TWS. Le opzioni qui riportate vengono descritte conla relativa procedura di modifica.

E’ possibile impostare ogni opzione su un nome convenzionale(drive:\share) o su un nome UNC (\\node\share). Se una opzione èimpostata su un nome convenzionale, l’utente del maestro deveconnettersi automaticamente alla condivisione. Se l’opzione èimpostata su un nome UNC, non è necessario effettuare unaconnessione esplicita. Le opzioni locali sono:

directory mozartDefinisce il nome della directory mozart condivisa delmaster.

40 Versione 7.0

directory di rete unisonDefinisce il nome della directory condivisa unison delmaster.

parametri della directoryDefinisce il nome della directory masterTWShomecondivisa.

Su ogni computer, impostare le opzioni nel modo seguente:

1. Utilizzare un editor delle opzioni per aprire o modificare il fileTWShome\localopts.

2. Le opzioni valgono come commenti nel file fornito da Tivoli. Perimpostare un’opzione, rimuovere il segno # nella colonna 1 emodificare il valore nella directory corretta. Ad esempio, peraccedere agli oggetti, ma non ai parametri:mozart directory = \\hub\mozartunison network directory = \\hub\unison# parameters directory = d:\maestro

3. Salvare il file e uscire.

4. Arrestare e riavviare il TWS (incluso Netman) per rendere attivele modifiche.

Se un’opzione non è impostata o non esiste, il programma TWSComposer tenta di accedere ai file di database sul computer locale.

Impostazione di opzioni locali sul masterSe i file di database sono stati spostati dalle directory di default,come spiegato in Utilizzo di una sola condivisione, è necessarioimpostare le opzioni locali presenti sul gestore dominio master sullanuova ubicazione. Consultare Impostazione delle opzioni locali.

Creazione manuale dell’account TWSLe nuove installazioni di TWS richiedono un account utente, conautorizzazione specifica, in cui installare il software. Il programmaSetup crea automaticamente questo utente. Se si desidera crearemanualmente un account, seguire le istruzioni riportatesuccessivamente.

2.Installazione

delmotore

Window

Nota: Le procedure seguenti richiedono la conoscenza della gestionedell’account di Windows NT, inclusa la possibilità di creareaccount e di assegnare diritti all’utente. In caso contrario,consultare l’amministratore Windows NT oppure fareriferimento alla documentazione Microsoft e alla guida inlinea Windows NT.

Tipi di Amministrazione TWSI database contenenti gli oggetti di pianificazione TWS risiedono sulcomputer definito come gestore dominio master. E’ possibileamministrare gli oggetti di pianificazione in uno dei seguenti modi:

1) centralizzato, solo dal gestore dominio master oppure

2) decentralizzato, da più di un computer TWS.

Scegliere la procedura appropriata in base al modo in cui si desideragestire gli oggetti di pianificazione TWS.

Amministrazione centralizzataSe gli oggetti di pianificazione vengono gestiti solo dal gestoredominio master, utilizzare la procedura seguente per creare l’utenteTWS o maestro.

1. Creare un account utente locale denominatoTWSo maestro sulcomputer che si utilizzerà come gestore dominio master. Notareche questo nome deve essere utilizzato su tutti i computer nellarete TWS, inclusi i computer UNIX.

Nota: E’ possibile utilizzare un account utente esistente.Verificare, tuttavia, che questo utente si trovi nel gruppodi Amministratori NT.

2. Assegnare una home directory all’utenteTWS o maestro. Adesempio:C:\win32app\maestro

Non specificare la directory root di una unità. Il software TWSverrà installato nella home directory di quest’utente. Nelladocumentazione la directory viene definita comeTWShome.

Creazione manuale dell’account TWS

42 Versione 7.0

3. Concedere all’utente delTWS o del maestro i seguenti dirittiavanzati:

Comportarsi come parte del sistema operativoAumenta quotasLogon come lavoro batchLogon come servizioLogon localeSostituire un token al livello del processo

Ora è possibile eseguire il programma Setup. Fare riferimento a“Installazione del software” a pagina 25.

Amministrazione decentralizzataSe gli oggetti di pianificazione vengono gestiti da più di uncomputer TWS, oltre al gestore dominio master utilizzare laprocedura seguente per creare un utenteTWS o maestro.

Nota: Dopo avere installato il software, sarà necessario crearecondivisioni per consentire l’accesso ai database sul gestoredominio master. Questo viene discusso in “Condivisione delledirectory master” a pagina 39.

1. Creare un account di dominio denominatoTWS o maestro neldominio di computer che si utilizzerà come gestore dominiomaster di TWS. Notare che questo nome deve essere utilizzatoanche su tutti i computer UNIX nella rete TWS.

Nota: E’ possibile utilizzare un account utente esistente.Verificare, tuttavia, che questo utente si trovi nel gruppodi Amministratori NT.

2. Assegnare una home directory all’utenteTWS o maestro. Adesempio:C:\win32app\maestro

Non specificare la directory root di una unità. Il software TWSverrà installato nella home directory di quest’utente. Nelladocumentazione la directory viene definita comeTWShome.

2.Installazione

delmotore

Window

3. Su ogni computer da cui verrà gestito il TWS, concedereall’utente delTWSo del maestro i seguenti diritti avanzati:

Comportarsi come parte del sistema operativoAumenta quotasLogon come lavoro batchLogon come servizioLogon localeSostituire un token al livello del processo

Ora è possibile eseguire il programma Setup. Fare riferimento a“Installazione del software” a pagina 25.

Come disinstallare TWSIl programma di disinstallazione rimuoverà i file del prodotto, lechiavi di registro, i servizi e i gruppi di programmi. Notare che conla disinstallazione non verranno eliminati tutti i file creati dopol’installazione di TWS, né i file aperti al momento delladisinstallazione.

Vi sono due modi per disinstallare il motore TWS e Netman da unsistema Windows NT:

¶ Utilizzo del tool Aggiungi/Rimuovi di Windows NT

¶ Utilizzo del programma Uninstall da una prompt comandi

Entrambi i metodi vengono descritti nelle seguenti sezioni.

Utilizzo del tool Aggiungi/Rimuovi di Windows NTPer disinstallare TWS o il servizio Netman su Windows NT 4.0, ènecessario essere un utente delTWS o del maestro con i dirittidell’amministratore Windows NT.

Utilizzare la procedura seguente:

1. Arrestare TWS e tutti i servizi TWS. Consultare “Comescollegare e arrestare TWS” a pagina 24 per dettagli.

2. Dalla cartella Pannello di controllo, eseguire Aggiungi/Rimuoviprogramma.

44 Versione 7.0

3. Sul separatore Installa/Disinstalla, selezionare Tivoli Maestro(Utente=nome utente) per rimuovere il Maestro o il TivoliNetman (Gruppo=gruppo) per rimuovere il servizio Netman.

4. Fare clic sul pulsante Aggiungi/Rimuovi. Nella casella didialogo, fare clic su Sì.

5. Uscire da Aggiungi/Rimuovi programmi.

6. Chiudere e riavviare il computer. In questo modo verrannoriavviati i servizi Maestro e Netman.

Nota: Il processo di disinstallazione non rimuoverà alcuni file,cartelle o voci di registro.

I file creati durante l’installazione dei prodotti vengono rimossi conla disinstallazione. Tuttavia, tutti i file creati o modificati dalmomento dell’installazione non verranno rimossi. Potrebbe esserenecessario conservare questi file per utilizzarli con una installazionesuccessiva di TWS.

Come disinstallare NetmanNetman è un prodotto indipendente di TWS. Nonostante sia possibileinstallarlo e aggiornarlo con TWS, è necessario disinstallarloseparatamente. Per disinstallare Netman, NON cancellare i file.Utilizzare sempre la funzione Aggiungi/Rimuovi programma nelpannello di controllo Windows NT. I file seguenti vengono utilizzatida altri prodotti e non vengono rimossi con la disinstallazione diNetman:netmanhome\components

netmanhome\bin\ucomp.exe

Programma Uninstal.exeIl programmaUninstal viene utilizzato per rimuovereun’installazione di Tivoli Workload Scheduler o di Netman service.Si trova nella directory<maestro home>\setup.

Sintassi

Uninstal.exe -V|-U

Uninstal.exe -p prodotto[-r versione] [ -l utente] [ -s ] [ -g gruppo]

Come disinstallare TWS

2.Installazione

delmotore

Window

Variabili-V Visualizza il livello patch del programma.

-U Visualizza le informazioni sull’utilizzo del programma.

-p Il nome del prodotto:

maestroIl prodotto TWS.

netmanIl servizio Netman.

-r La versione del prodotto; ad esempio: 6.1.0

-l L’account utente per cui è stato installato il prodotto. E’valido solo per-p maestro.

-s Esegue in modalità non presidiata. Se omesso, il programmaemette richieste e messaggi di avanzamento.

-g Il gruppo di prodotti. Il gruppo di default è DEFAULT. E’valido solo per-p netman.

Esempi1. Rimozione del software TWS:

uninstal -p maestro

2. Rimozione del software TWS installato per l’utentetwsuser:uninstal -p maestro -l twsuser

3. Rimozione non presidiata di Netman installato nel gruppo test:uninstal -p netman -s -g test

46 Versione 7.0

Installazione del motore TWS suUNIX

Questa sezione spiega il processo di installazione Tivoli WorkloadScheduler per reti e sistemi UNIX.

Requisiti di sistemaI seguenti sono requisiti del sistema TWS per computer UNIX.

¶ Approssimativamente 120 MB di spazio libero su disco pergestori dominio e FTA (Fault-Tolerant Agent).Approssimativamente 80 MB per gli Standard agent (SA).

¶ Inoltre, TWS produce file di log e file temporanei ubicatisull’unità fissa locale. La quantità di spazio utilizzato dipendedal numero di lavori gestiti dal TWS e dal tempo specificato perla conservazione dei file di log.

¶ 32 MB di RAM e 48MB di spazio swap per gestori dominio eper FTA. Gli SA ne richiedono una quantità minore.

¶ Gli FTA di TWS possono, facoltativamente, caricare delledirectory dal gestore dominio master. Ciò richiede un NFS(Network File System). Consultare gli amministratori di sistemae di rete e fare riferimento alManuale per l’utente TivoliWorkload Schedulerper ulteriori informazioni.

3.Installazione

delmotore

Prima di continuare, consultareNote di release Tivoli WorkloadSchedulerper ulteriori informazioni.

Procedura di installazioneSeguire queste istruzioni sui computer UNIX se si sta installandoTWS per la prima volta o se TWS è stato disinstallatocompletamente. Per computer Windows NT, fare riferimento a“Installazione del motore TWS su Windows NT” a pagina 23.

Installazione di Tivoli Workload Scheduler EngineSeguire queste istruzioni per installare TWS su un computer UNIX.

1. Creare l’utente TWS. Il software è installato nella home directorydell’utente, a cui è stato fatto riferimento cometwshome.

Utente:maestro

Gruppo:tivoli

Home:twshome(ad esempio: /opt/maestro)

Nota: Se si sta installando più di un’istanza di TWS su uncomputer, notare che ogni installazione ubicherà i filenella directorytwshome/../unison. Per evitare conflitti,verificare che le directory parent siano differenti. Adesempio, /opt/maestro, and /opt/maestro2.

2. Caricare il nastro o il CD d’installazione e ripristinare ilsoftware.

a. Effettuare il login come root e modificare la directory intwshome.

b. Estrarre il software:tar -xvf cd/TIVOLI/piattaforma/MAESTRO.TAR

cd Il nome del percorso dell’unità CD.

48 Versione 7.0

piattaformaIl tipo di piattaforma. Uno dei seguenti:

AIX (per IBM)

DECUX (per Digital UNIX)

DGUX (per Data General UNIX)

HPUX (per Hewlett Packard UNIX)

INTEL (per Intel-based UNIX)

MIPS (per MIPS-based UNIX)

SOLARIS (per Sun Solaris)

3. Eseguire lo scriptCustomize.

Ad esempio, uno script Customize campione per una workstationdel gestore dominio master./bin/sh customize -new -thiscpu mdm -master mdm [other_opts]

Ad esempio, uno script Customize campione per una workstationFTA:/bin/sh customize -new -thiscpu dm1 -master mdm [opzioni]

Se si sta utilizzando un sistema HP-UX 10.x, la shell bournepotrebbe trovarsi nella directory/usr. In questo caso utilizzare lasintassi seguente:/usr/bin/sh customize -new -thiscpu mdm -master mdm [other_opts]

Per ulteriori informazioni sugli argomenti di personalizzazione eper ulteriori esempi, fare riferimento a “Script Customize” apagina 58.

4. Creare un file .profile per l’utente maestro, se non esiste già(twshome/.profile). Modificare il file e la variabile PATH perincluderetwshomee twshome/bin. Ad esempio:PATH=/bin:/usr/bin:/usr/local/bin:/opt/maestro:/opt/maestro/bin

Se l’istruzione PATH termina con un punto (.) si consiglia disostituire il punto con i percorsi precedenti o di inserire i percorsi

Procedura di installazione

3.Installazione

delmotore

prima del punto. Se non c’è il punto nell’istruzione PATH, èsufficiente aggiungere i percorsi alla fine.

5. Per avviare automaticamente come un daemon il processo digestione della rete TWS, Netman, ogni volta che si avvia unsistema, aggiungere una delle seguenti istruzioni al file /etc/rc oil file adatto al proprio sistema. Per avviare solo Netman:if [-x twshome/StartUp]thenecho "netman started..."/bin/su - maestro -c " twshome/StartUp"fi

Oppure, per avviare tutto l’albero del processo TWS:if [-x twshome/bin/conman]thenecho "Workload Scheduler started..."/bin/su - maestro -c " twshome/bin/conman start"fi

Il processo di installazione TWS è completo.

Istruzioni di configurazionePer le installazioni UNIX svolgere le seguenti attività diconfigurazione. Queste attività devono essere eseguite dalle CLIComposere Conman di TWS.

Una volta configurato il gestore dominio master è possibile utilizzareil Job Scheduling Console per configurare le altre workstation e glioggetti job scheduling nella rete TWS. Fare riferimento alManualedi riferimento Tivoli Workload Schedulerper dettagli sui comandiutilizzati di seguito. Consultare ilManuale per l’utente TivoliWorkload Schedulerper informazioni sull’utilizzo di Job SchedulingConsole per configurare altre workstation nella rete.

Configurazione di un gestore dominio master dopol’installazione

1. Login alla workstation del gestore dominio master comemaestro. E’ la variabile ID tws_user, impostata per default suUNIX per maestro. L’ID UNIX tws_userpuò essere modificatoutilizzando l’argomento-uconfig.

50 Versione 7.0

2. Creare la definizione della workstation del gestore dominiomaster nel database TWS utilizzando la riga comandi TWScomposer. Aprire una finestra della riga comandi UNIX eimmettere i comandi seguenti:composer

3. In questo modo si apre un editor di testo in cui è possibile crearela definizione della workstation del gestore dominio master neldatabase TWS.Quello riportato di seguito è un esempio didefinizione di workstation per un gestore dominio master. Perulteriori informazioni sulle definizioni di workstation, fareriferimento alManuale di riferimento Tivoli Workload Scheduler.cpuname gestore dominio master

os UNIX

node master.santaclara.tivoli.com

descrizione "Master Domain Manager"

per Maestro

autolink on

resolvedep on

fullstatus on

4. Creare un nuovo file Symphony che includa la definizione dellaworkstation del gestore dominio master. Per questa operazione,aggiungere il flusso di lavorofinal al ciclo di produzione. Questoflusso di lavoro contiene il lavoroJnextday che automatizza lacreazione del file Symphony.composer “add Sfinal”

5. Avvio dei processi TWS.conman start

6. Eseguire il lavoro Jnextday:Jnextday

7. Al termine del lavoro Jnextday verificare lo stato di TWS:stato conman

3.Installazione

delmotore

Se il TWS è stato riavviato correttamente, lo stato deve essereBatchman=LIVES.

8. Aumentare il limite per consentire l’esecuzione dei lavori. Illimite di default del lavoro dopo l’installazione è impostata suzero. Ciò indica che non verranno eseguiti i lavori, quindi sarànecessario aumentare il limite:conman “limit;10”

E’ possibile cominciare a definire ulteriori oggetti di pianificazionenella CLI, inclusi i lavori, i flussi di lavoro e le workstation oppure èpossibile continuare a installare il Job Scheduling Console e ilConnettore. Notare che i nuovi oggetti non sono riconosciuti fino ache il lavoro Jnextday non viene eseguito nel flusso di lavorofinale.Per default, il flusso di lavorofinale viene eseguito alle 5:59am (èpossibile modificare questo valore di default; consultare “Modificadel giorno stabilito per l’avvio” a pagina 120 per i dettagli). Se sidesidera inserire al più presto nuovi oggetti di pianificazione, èpossibile eseguire Jnextday manualmente come nell’istruzione 6 outilizzare il comandosubmit. Per ulteriori informazioni sulladefinizione degli oggetti di pianificazione, fare riferimento alManuale per l’utente Tivoli Workload Scheduler.

Configurazione di un FTA dopo l’installazione1. Login alla workstation FTA comemaestro. E’ la variabile ID

tws_user, impostata per default su UNIX permaestro. L’IDUNIX tws_userpuò essere modificato utilizzando l’argomento-uconfig.

2. Creare la definizione della workstation FTA nel database TWSutilizzando la riga comandi TWS composer. Aprire una finestradella riga comandi UNIX e immettere i comandi seguenti:composer

3. In questo modo si apre un editor di testo in cui è possibile crearela definizione della workstation FTA nel database TWS. Quelloriportato di seguito è un esempio di definizione di workstation

52 Versione 7.0

per un FTA. Per ulteriori informazioni sulle definizioni diworkstation, fare riferimento alManuale di riferimento TivoliWorkload Scheduler.cpuname Gestore dominio 1

os UNIX

node domain1.santaclara.tivoli.com

descrizione "Domain Manager"

per Maestro

autolink on

4. Eseguire il comandoStartUp per avviare Netman.conman StartUp

5. Creare un nuovo file Symphony che includa la definizione dellaworkstation FTA. Per questo eseguire il lavoro Jnextday sulgestore dominio master che automatizza la creazione di un nuovofile Symphony:Jnextday

6. Immettere il comando Link dal gestore dominio master pereffettuare il collegamento con l’FTA e per scaricare il fileSynphony su esso:conman “link ftaname”

Aggiornamento di Tivoli Workload SchedulerUtilizzare questo procedimento per aggiornare le installazioni diTWS esistenti su computer UNIX. La sequenza consigliata perl’aggiornamento di una rete TWS è di aggiornare prima tutte leworkstation dell’agent, poi di aggiornare il gestore dominio master.

Nota: Leggere leNote di release Tivoli Workload Schedulerperulteriori informazioni sull’aggiornamento del softwareesistente.

Gli argomenti dell’aggiornamento riportati di seguito vengonopresentati nella sequenza in cui verranno eseguiti.

3.Installazione

delmotore

Preparazione-Arresto di TWS1. Da Job Scheduling Console, scollegare le workstation di

destinazione dalle altre workstation nella rete. Altrimenti, dallariga comandi utilizzare il comando seguente:conman "unlink workstationname;noask"

2. Da Job Scheduling Console, arrestare e chiudere la workstationdi destinazione. Dalla riga comandi, utilizzare i comandiseguenti:conman “shut;wait”

3. Se si sta aggiornando un agent, rimuovere (scaricare) tutte ledirectory NFS caricate dal gestore dominio master.

BackupLo script customizedi TWS sposterà le copie attive diSfinal,Jnextday, NetConf e StartUp su una directory denominatatwshome/config.old. Spesso questi file vengono personalizzati perrispondere alle richieste specifiche dell’utente ed è possibileutilizzare le copie salvate per inserire le modifiche che seguonol’aggiornamento. Lo scriptCustomizenon sostituirà tutti i file nelledirectorymozart, stdlist o unison che erano state modificate dopol’installazione di TWS.

Se non vi sono altri file da proteggere durante l’aggiornamento,copiarli o ridenominarli. Come precauzione ulteriore, effettuare ilbackup di:

¶ Directory twshome.

¶ La home directory Netman (twshome/../Unison)

¶ Il file dei componenti (generalmente,/usr/unison/components)

Aggiornamento del software ed esecuzione diCustomize

1. Caricare il nastro o il CD d’installazione e ripristinare ilsoftware.

a. Effettuare il login come root e modificare la directory intwshome.

Aggiornamento di Tivoli Workload Scheduler

54 Versione 7.0

b. Estrarre il software:tar xvf cd/TIVOLI/platform/MAESTRO.TAR

cd Il nome del percorso dell’unità CD.

piattaformaIl tipo di piattaforma. Uno dei seguenti:

AIX (per IBM)

DECUX (per Digital UNIX)

HPUX (per Hewlett Packard UNIX)

INTEL (per Intel ABI basata su UNIX)

MIPS (per MIPS ABI basata su UNIX)

SOLARIS (per Sun Solaris)

2. Eseguire lo scriptCustomize.

Ad esempio, uno script Customize campione per una workstationdel gestore dominio master./bin/sh customize -update -thiscpu mdm [other_opts]

Ad esempio, uno script Customize campione per una workstationFTA:/bin/sh customize -update -thiscpu dm1 [opzioni]

Se si sta utilizzando un sistema HP-UX 10.x, la shell bournepotrebbe trovarsi nella directory/usr. In questo caso utilizzare lasintassi seguente:/usr/bin/sh customize -update -thiscpu mdm [other_opts]

Per ulteriori informazioni sugli argomenti di personalizzazione eper ulteriori esempi, fare riferimento a “Script Customize” apagina 58.

3.Installazione

delmotore

Aggiornamento del Profilo SecurityPer la migrazione da 6.0 a 7.0, è necessario aggiungere unadefinizione ulteriore dell’Utente del Maestro al file security. L’IDtme_region_administratordeve essere aggiunto al file Security.

1. Login comeMaestro.

2. Eseguire il comandodumpsecper creare una copia temporaneamodificabile del file security:dumpsec >tempsec

3. Modificare il file security. Nella sezione USER MAESTROaggiungere l’ID dell’amministratore dell’area TME:USER MAESTRO

root, maestro, amministratore, tme_region_admin

4. Eseguire il comandomakesecper compilare il file temporaneo inun nuovo file security:makesec

tempsec Per ulteriori informazioni sui comandiMakeseceDumpsecfare riferimento alManuale per l’utente TivoliWorkload Scheduler.

Ripristino dei propri fileUtilizzando come riferimento i file protetti, applicare le modifichealle nuove versioni dei file.

Riavvio di TWSPer riavviare Tivoli Workload Scheduler:

1. Effettuare il login come utenteTWS o maestro.

2. Eseguire il comandostart:conman start

3. Eseguire il comandolink:

¶ Per un gestore dominio master:conman “link @”

¶ Per una workstation FTA:conman “link domainname”

56 Versione 7.0

L’aggiornamento del software è completo su questa workstation.

Script Customize

3.Installazione

delmotore

Script CustomizeUtilizzare lo scriptcustomizeper installare e aggiornare TivoliWorkload Scheduler su piattaforme UNIX.

Sintesicustomize -new -thiscpuwkstationname-masterwkstationname[-company ″ companyname″] [ -group groupname][-nmhome netmanhome] [ -noexp] [ -nolinks|-execpathpathname][-unameusername]

customize -update[-company ″ companyname″] [ -groupgroupname][-nmhome netmanhome] [ -unameusername]

DescrizioneLo script Customize installa o aggiorna il TWS. Utilizzarlo pereseguire queste funzioni:

¶ Nuova installazione di TWS: installare TWS e Netman. Crea unfile dei componenti con nuove voci.

¶ Ora del primo aggiornamento della versione precedente di 7.0TWS: aggiornare TWS e Netman, se necessario. Crea un file deicomponenti con nuove voci.

¶ Successivi aggiornamenti di TWS: aggiornare TWS e Netman, senecessario. Aggiornare le voci nel file dei componenti.Utilizzarlo anche per impostare nuovamente i permessi sui lorovalori di default purché il file MAESTRO.TAR di origine non sitrovi nella directorytwshome.

Argomenti-new Una nuova installazione.

-updateUn aggiornamento di una installazione esistente. Notare chel’aggiornamento del software non modificherà il tipo didatabase utilizzato da TWS.

-thiscpuIl nome di questa workstation. Per la versione non espansa

Script Customize

58 Versione 7.0

di TWS, il nome può contenere fino a otto caratterialfanumerici, trattini (-) o underscore (_) con una letterainiziale. Per la versione espansa, la lunghezza è di sedicicaratteri. Questo nome deve essere utilizzato in seguito perdefinire formalmente la workstation in TWS.

-masterIl nome del gestore dominio master. Per la versione nonespansa di TWS, il nome può contenere fino a otto caratterialfanumerici, trattini (-) o underscore (_) con una letterainiziale. Per la versione espansa, la lunghezza è di sedicicaratteri. Se questo computer è il gestore dominio master ouna workstation autonoma, immettere lo stesso nome di-thiscpu. Questo nome deve essere utilizzato in seguito perdefinire formalmente la workstation in TWS.

-companyIl nome della società, tra virgolette (fino a 40 caratteri). Ilnome appare nell’intestazione e nei report del programma.

-groupIl nome del gruppo di prodotti con cui si desidera installareo aggiornare il TWS. Può contenere un massimo di 36caratteri, con una lettera iniziale. Se omesso per una nuovainstallazione o un primo aggiornamento di una versioneprecedente di TWS, il nome è impostato per default suDEFAULT . Se incluso in un aggiornamento, diversodall’aggiornamento di una versione precedente di TWS,questo nome viene sostituito con il gruppo dal file deicomponenti, utilizzando la home directory dell’utente comeriferimento. Per ulteriori informazioni, consultare “Gruppi diprodotti” a pagina 20.

-nmhomeLa home directory di Netman. Se omessa, Netman vieneinstallato nella home directory di TWS (twshome). Perulteriori informazioni, fare riferimento a “Home directory diNetman” a pagina 21. Per gli aggiornamenti, questa opzioneè utile solo per i primi aggiornamenti delle versioniprecedenti la 6.0 di TWS. Negli aggiornamenti successivi,viene ignorata.

Script Customize

3.Installazione

delmotore

-noexpUtilizza database non espansi. In questo modo vieneimpostata l’opzione globaleversione espansasu no eVENGANO creati i database non espansi. Poiché le versioniprecedenti non supportano i database espansi, utilizzarequesta parola chiave per installare TWS 7.0 in una retecontenente computer che eseguono una versione TWSprecedente alla 6.0 oppure ogni versione di TWS per MPE.Una volta che su tutti i computer nella rete è stato installatoTWS 6.0 o la versione successiva, i database possono essereespansi eseguendo il comandodbexpand sul gestoredominio master. Per ulteriori informazioni, fare riferimento alcomandodbexpand nel Manuale di riferimento TivoliWorkload Scheduler. Se omesso, la versione espansadell’opzione globale è impostata su Sì e vengono creati idatabase espansi.

[-nolinks|-execpathpathname]L’opzione Collega determina il percorso utilizzato dalloscript Customize per creare i collegamenti per i comandi delprogramma di utilità di TWS. Se si include -nolinks, nonviene creato alcun collegamento. Se si include -execpath, icollegamenti vengono creati dal percorso specificato. Se siomettono tutte le linkopt, vengono creati i collegamenti nelmodo seguente:

usr/bin/mat twshome/bin/at

usr/bin/mbatch twshome/bin/batch

usr/bin/datecalc twshome/bin/datecalc

usr/bin/jobstdl twshome/bin/jobstdl

usr/bin/maestro twshome/bin/maestro

usr/bin/mdemon twshome/bin/mdemon

usr/bin/morestdl twshome/bin/morestdl

usr/bin/muser twshome/bin/muser

usr/bin/parms twshome/bin/parms

-unameIl nome dell’utente per cui verrà installato o aggiornato il

Script Customize

60 Versione 7.0

TWS. Il software viene installato o aggiornato in questahome directory dell’utente. Se omesso, il nome utente didefault èmaestro.

Script Customize

3.Installazione

delmotore

Come disinstallare TWSSeguire queste istruzioni per disinstallare TWS da un sistema UNIX:

1. Prima di disinstallare il TWS, effettuare il kill di tutte le istanzeesistenti del connettore TWS create su questo sistema UNIXparticolare.

2. Sul sistema UNIX, effettuare il login come root.

3. Effettuare il backup di ogni file del database TWS che sidesidera riutilizzare. I file di database TWS vengono archiviatinella home directory dell’utente TWS e sono:¶ /parameters¶ /parameters.KEY¶ /mozart/calendars¶ /mozart/calendars.KEY¶ /mozart/jobs¶ /mozart/jobs.KEY¶ /mozart/mastsked¶ /mozart/mastsked.KEY¶ /mozart/prompts¶ /mozart/prompts.KEY¶ /mozart/resources¶ /mozart/resources.KEY¶ /../unison/network/cpudata¶ /../unison/network/cpudata.KEY¶ /../unison/network/userdata¶ /../unison/network/userdata.KEY

Nota: Il database job.sched viene ricreato automaticamente. Nonè necessario salvarlo.

4. Rivedere il contenuto del file denominato/usr/unison/components. Se il file contiene più voci checorrispondono a differenti account Maestro/TWS (gruppi diprodotto), modificare il file cancellando le righe corrispondentiall’istanza che si desidera rimuovere.

Ad esempio, supporre che/usr/unison/componentscontenga leseguenti voci:netman 1.5 /opt/maestro DEFAULT

62 Versione 7.0

maestro 7.0 /opt/maestro DEFAULT

netman 1.3 /home/maestro dev_test

maestro 6.1 /home/maestro dev_test

Se si pianifica di rimuovere l’istanza ubicata sotto/home/maestro,cancellare le ultime due righe.

Se /usr/unison/componentscontiene solo l’istanza che si desiderarimuovere, cancellare l’intero file.

5. Rimuovere i link, se applicabili, per la directory/usr/bin. Ilprocesso di installazione TWS fornisce l’opzione per collegaregli eseguibili TWS a una directory comune. Il valore di default è/usr/bin. Rimuovere i seguenti file:¶ /usr/bin/maestro¶ /usr/bin/mat¶ /usr/bin/mbatch¶ /usr/bin/datecalc¶ /usr/bin/morestdl¶ /usr/bin/jobstdl¶ /usr/bin/parms

6. Infine, rimuovere tutto l’account Maestro/TWS utilizzando iseguenti comandi:rm -rf <twshome>/../unison

rm -rf <twshome>

Se il comando di avvio del proprio sistema è stato modificato perincludere un comandoconman″start″ o un comando<twshome>/StartUp, è necessario rimuovere anche quelle voci.

3.Installazione

delmotore

64 Versione 7.0

Impostazione di TWS Security

Dopo aver installato il motore TWS e prima di procedere conl’installazione di JS Console, è necessario impostare TWS security.

Ogni workstation in una rete Workload Scheduler (gestore dominio,fta e SA) dispone di un proprio fileSecurity.

Il file Security contiene una o più definizioni dell’utente. Ognidefinizione dell’utente identifica una serie di utenti, gli oggetti a cuiè consentito l’accesso e i tipi di azioni da eseguire. I programmi e icomandi Workload Scheduler determinano le possibilità dell’utente,confrontando il nome dell’utente con le definizioni dell’utente nelfile Security.

E’ possibile gestire un file su ogni workstation oppure è possibilecreare un file Security sul gestore dominio master e copiarlo su ognigestore dominio, FTA e SA.

Con il software viene fornito un file maschera denominatoTWShome/config/Security. Durante l’installazione viene installatauna copia del file di maschera comeTWShome/Security e una copiacompilata e operativa viene installata comeTWShome/../unison/Security.

Per impostare TWS security:

1. Creare le definizioni dell’utente. Nonostante la definizione didefault dell’utente si adatti abbastanza alle richieste, è necessariocomunque aggiungere almeno una definizione dell’utente per

postazionediT

Security

l’amministratore Tivoli Management Framework sul master osull’FTA che esegue il connettore TWS. Per questo, modificare ilfile Security. Si consiglia di creare una copia attiva del fileSecurity tutte le volte in cui si aggiunge una nuova definizionedell’utente. Non modificare la maschera di origine inTWShomeoin TWShome/config. Per creare una definizione dell’utente:

a. Utilizzare il comandodumpsecper creare una copiamodificabile del file security operazionale:dumpsec>mysec

b. Modificaremysecper aggiungere, cancellare o modificare ledefinizioni dell’utente.

2. Utilizzare il comandomakesecper compilare e installare ilnuovo file Security operativo:makesec mysec

Utilizzare dumpsece makesectutte le volte in cui si desideramodificare il file Security. Le modifiche apportate al file Securitydiventano effettive quando viene arrestato e riavviato uno deiseguenti programmi Workload Scheduler:¶ conman¶ gconman¶ composer¶ gcomposer¶ Connettore TWS

Uscire dai programmi. La volta successiva in cui vengonoeseguiti, verranno riconosciute le nuove definizioni sul filesecurity. Per i connettori TWS, utilizzare il comandowmaeutilper arrestarli. Verranno riavviati automaticamente con unaggiornamento delle query in Job Scheduling Console.

Impostazione di TWS Security

66 Versione 7.0

Modifica del file SecurityLa maschera Security di default installata sul sistema dell’utenteconcede tutte le autorizzazioni per l’oggetto all’utente sotto cui èinstallato TWS, al root UNIX o all’utente amministratore NT. E’possibile dover modificare il file Security per aggiungere nuoviutenti con autorizzazioni minori.

Quando si modifica il file Security, ricordare quanto segue:

¶ Nel qualificare gli utenti che accedono agli oggetti WorkloadScheduler, gli attributi effettivi dell’utente vengono confrontaticon le definizioni dell’utente nell’ordine in cui le definizionivengono immesse nel file Security. La prima definizionecorrispondente all’utente, determina le capacità dell’utente. Perquesto motivo, è importante mettere in ordine le definizionidell’utente dalla più specifica alla meno specifica.

¶ In una definizione dell’utente, è possibile utilizzare più istruzioniper un tipo di oggetto singolo per assegnare capacità di accessoa differenti serie di oggetti. Poiché viene utilizzata la primaistruzione corrispondente, l’ordine delle istruzioni dell’oggetto èimportante. Esse devono essere messe in ordine dalla piùspecifica alla meno specifica.

¶ La definizione dell’utente del file Security, creata dal processod’installazione TWS, concede un accesso completo a tutti glioggetti di pianificazione. Quando si aggiungono nuovedefinizioni dell’utente, è più semplice copiarle sull’ubicazioneappropriata del file Security. Quindi, è possibile modificare ilnome della definizione e degli attributi utente, infine è possibilepersonalizzare o rimuovere gli oggetti di pianificazione.

La sintassi del file Security è la seguente:

# comment]user def-name user-attributesbegin [* comment]object-type[object-attributes] access[=action[,...]][object-type... ][end]

Modifica del file Security

postazionediT

Security

Le istruzioni per la personalizzazione riportate di seguito sonoelencate su una base generale. Consultare ilManuale per l’utenteTWSper esempi e dettagli delle variabili del file Security.

1. In alternativa, all’inizio del file immettere un commento dopo ilsegno cancelletto (#) o asterisco (*). I commenti non vengonocopiati nel file operativo Security installato dal comandomakesec.

2. Dopo la parola chiaveuser, specificare il nome della definizionedell’utente. Deve cominciare con una lettera.

3. Specificare uno o più attributi che identificano una serie di utentia cui si applica la definizione. Specificare gli attributi dell’utentenel modo che segue:

user-attribute[{ + | x} user-attribute[...]]

Utilizzare un segno più (+) per aggiungere un attributo chel’utente deve avere. Utilizzare una tilde (x) per aggiungere unattributo non necessario all’utente. Unuser-attributepuò essereuno dei seguenti:

cpu=workstation|$framework|@ [,...]dove:

workstationSpecifica la workstation o la classe diworkstation a cui l’utente è collegato. Utilizzareuna delle seguenti variabili Tivoli WorkloadScheduler:

$masterL’utente è collegato al gestore dominiomaster TWS.

$remotesL’utente è collegato a ogni SA di TWS.

$slavesL’utente è collegato a ogni FTA di TWS.

68 Versione 7.0

$thiscpuL’utente è collegato alla workstationTWS su cui è in esecuzione ilprogramma protetto.

$frameworkSpecifica che l’utente accede al TWS con TivoliJob Scheduling Console. L’attributologon=specifica il gruppo di amministratori TME di cuil’utente è membro.

@ Specifica che l’utente accede a Tivoli WorkloadScheduler con la workstation Tivoli JobScheduling Console o è collegato a tutti i TivoliWorkload Scheduler.

group=groupname[,...]Applicare solo agli utenti UNIX. Non utilizzare questoargomento per gli utenti Tivoli Job Scheduling Console.Specifica il gruppo UNIX di cui l’utente è membro.

logon=username|tme-admin|@ [,...]dove:

usernameSpecifica il nome con cui l’utente è collegato suuna workstation TWS. L’attributocpu= deveessere impostato su un nome di workstation o su@.

tme-adminSpecifica il nome del gruppo di amministratoriTME a cui appartiene l’utente. L’attributocpu=deve essere impostato su$framework o su@.

@ Specifica che l’utente è collegato con un nomequalsiasi oppure è un membro di un qualsiasigruppo di amministratori TME.

4. Tra le parole chiavebegin ed end, immettere un elenco dei tipidi oggetto a cui possono accedere gli utenti specificati inuser.L’omissione di un tipo di oggetto impedisce l’accesso a tutti glioggetti di quel tipo. I tipi di oggetti sono:

postazionediT

Security

calendarCalendari utenti.

cpu Workstation, domini e classi di workstation.file File di database Workload Scheduler.job Lavori pianificati.parameter

Parametri utente.prompt

Richieste globali.resource

Risorse di pianificazione.schedule

Flussi di lavoro.userobj

Oggetti utente.

5. Specificare uno o più attributi identificando ogni oggetto elencatonell’istruzione precedente. Quando non vengono specificatiattributi, è possibile accedere a tutti gli oggetti che appartengonoa un tipo particolare. Specificare gli attributi degli oggetti nelmodo riportato di seguito:

object-attribute[{ + | x} object-attribute[...]]

Utilizzare un segno più (+) per aggiungere a un attributo glioggetti necessari. Utilizzare una tilde (x) per aggiungere unattributo che gli oggetti non dovrebbero avere. E’ possibileutilizzare caratteri jolly. Quando si immettono più nomi per unattributo, separarli con delle virgole. Unobject-attributepuòessere uno qualsiasi dei seguenti:

¶ Per il tipo di oggettocalendar:

name=calendar-name[,...]Specifica uno o più nomi di calendario. Se omesso,vengono elencati tutti i calendari.

¶ Per il tipo di oggettocpu (workstation):

cpu=wkstation[,...]Specifica una o più workstation, domini o nomiclasse di workstation. Se omesso, vengono elencate

70 Versione 7.0

tutte le workstation. Sono consentite le seguentivariabili Tivoli Workload Scheduler:$master,$remotes, $slavese $thiscpu.

¶ Per il tipo di oggettofile:

name=filename[,...]Specifica i nomi dei file di database WorkloadScheduler. Se omesso, vengono elencati tutti i file. Inomi file sono i seguenti:calendar

Contiene calendari.cpudata

Contiene workstation, classi di workstation edomini.

job Contiene lavori.mastsked

Contiene flussi di lavoro.parameter

Contiene parametri.prodsked

Contiene la pianificazione della produzione.prompt

Contiene richieste.resource

Contiene risorse.security

File security.Symphony

Contiene il piano di produzione.

¶ Per il tipo di oggettojob:

cpu=wkstationSpecifica il nome della workstation o della classeworkstation sulla quale viene eseguito il lavoro. Seomesso, vengono elencate tutte le workstation. Sonoconsentite le seguenti variabili Tivoli WorkloadScheduler:$master, $remotes, $slavese $thiscpu.

postazionediT

Security

jcl= ’path’ | ’cmd’Specifica il comando o il nome del percorso del fileeseguibile del lavoro. Il comando o il percorso deveessere compreso tra apici (‘). Se omesso, tutti i filedel lavoro e alla qualifica dei comandi.

logon=username[,...]Specifica i nomi utenti sotto cui viene eseguito illavoro. Se omesso, vengono specificati tutti i nomi.Sono consentite le seguenti variabili Tivoli WorkloadScheduler:$jclowner, $owner e $user.

name=[jobstream.]job[,...]Specifica il nome lavoro del Workload Scheduler. Ilnome del flusso di lavoro del lavoro è facoltativo. Seomesso, vengono specificati tutti i nomi lavoro.

¶ Per il tipo di oggettoparameter:

cpu=wkstationSpecifica il nome della workstation su cui sonodefiniti i parametri. Se omesso, vengono elencatetutte le workstation. Sono consentite le seguentivariabili Tivoli Workload Scheduler:$master,$remotes, $slavese $thiscpu.

name=parameter[,...]Specifica uno o più nomi di parametro. Se omesso,vengono elencati tutti i parametri.

¶ Per il tipo di oggettoprompt :

name=prompt[,...]Specifica uno o più nomi per la prompt. Se omesso,vengono elencate tutte le prompt.

¶ Per il tipo di oggettoresource:

cpu=wkstation[,...]Specifica il nome della workstation o classeworkstation sulla quale vengono definite le risorse.Se omesso, vengono elencate tutte le workstation.Sono consentite le seguenti variabili Tivoli WorkloadScheduler:$master, $remotes, $slavese $thiscpu.

72 Versione 7.0

name=resource[,...]Specifica uno o più nomi della risorsa. Se omesso,vengono elencate tutte le risorse.

¶ Per il tipo di oggettoschedule(flusso di lavoro):

cpu=wkstationSpecifica il nome della workstation o della classeworkstation sulla quale viene eseguito il flusso dilavoro. Se omesso, vengono elencate tutte leworkstation. Sono consentite le seguenti variabiliTivoli Workload Scheduler:$master, $remotes,$slavese $thiscpu.

name=jobstream[,...]Specifica uno o più nomi di flussi di lavoro. Seomesso, vengono specificati tutti i flussi di lavoro.

¶ Per il tipo di oggettouserobj:

cpu=wkstationSpecifica il nome della workstation sulla quale èdefinito l’utente. Se omesso, vengono elencate tuttele workstation. Sono consentite le seguenti variabiliTivoli Workload Scheduler:$master, $remotes,$slavese $thiscpu.

logon=username[,...]Specifica uno o più nomi utente. Se omesso,vengono elencati tutti gli utenti.

6. Specificare quali delle azioni, definite nei punti 2 e 3,possonoessere eseguite sugli oggetti elencati nei punti 4 e 5. Piùazionidevono essere separate dalle virgole. Se non vengono specificateazioni, nessuna di esse è consentita. Immettendoaccess=@, gliutenti possono eseguire tutte le azioni. Le azioni possono essere:

¶ Per il tipo di oggettocalendar:

add Aggiunge e salva i nuovi calendari nel database.

delete Cancella i calendari dal database.

displayVisualizza i calendari nel database.

postazionediT

Security

modifyModifica i calendari nel database.

use Utilizza i calendari per pianificare i flussi di lavoro.

¶ Per il tipo di oggettocpu, che include workstation, classi diworkstation e domini:

add Aggiunge e salva nuove workstation, classi diworkstation e domini nel database.

consoleVisualizza e modifica la console Workload Scheduler.

delete Cancella workstation, classi di workstation e dominidal database.

displayVisualizza workstation, classi di workstation edomini nel database.

fence Modifica i delimitatori di lavoro della workstationnel piano di produzione.

limit Modifica i limiti di lavoro della workstation nelpiano di produzione.

link Apre i collegamenti della workstation.

modifyModifica workstation, classi di workstation e domininel database.

shutdownChiusura elaborazione Shutdown WorkloadScheduler. Questa azione è disponibile solo nella rigacomandi.

start Avvia l’elaborazione Workload Scheduler.

stop Arresta l’elaborazione Workload Scheduler.

unlinkChiude i collegamenti della workstation.

74 Versione 7.0

Affinché un utente possa convertire una funzione gestoredomini su una workstation, deve avere l’accesso astart estop alla workstation.

¶ Per il tipo di oggettofile:

build Crea i file di database di Workload Scheduler. Questaazione è disponibile solo nella riga comandi.

delete Non ancora implementato.

displayAccede al file Security con il comandodumpsec.

modifyAccede al file Security con il comandomakesec.Modifica anche i calendari, i parametri, le richieste ei file master delle risorse. Queste azioni sonodisponibili solo nella riga comandi.

¶ Per il tipo di oggettojob:

add Aggiunge e salva i nuovi lavori nel database.

adddepAggiunge le dipendenze ai lavori nel piano diproduzione.

altpri Modifica la priorità dei lavori nel piano diproduzione.

cancel Annulla i lavori nel piano di produzione.

confirmConferma il completamento dei lavori nel piano diproduzione.

deldepCancella tutte le dipendenze dai lavori nel piano diproduzione.

delete Cancella i lavori dal database.

displayVisualizza i lavori nel database.

kill Esegue il kill dei lavori nel piano di produzione.

postazionediT

Security

modifyModifica i lavori nel database.

releaseRilascia i lavori dalle dipendenze nel piano diproduzione.

reply Risponde alle richieste del lavoro nel piano diproduzione.

rerun Riavvia i lavori nel piano di produzione.

submitInoltra i lavori nel piano di produzione.

use Aggiunge i lavori ai flussi di lavoro nel database.

¶ Per il tipo di oggettoparameter:

add Aggiunge e salva i nuovi parametri nel database.

delete Cancella i parametri dal database.

displayVisualizza i parametri nel database.

modifyModifica e sostituisce i parametri nel database.

¶ Per il tipo di oggettoprompt :

add Aggiunge e salva le nuove richieste nel database.

delete Cancella le richieste dal database.

displayVisualizza le richieste nel database.

modifyModifica e sostituisce le richieste nel database.

use Aggiunge le richieste ai flussi di lavoro nel databasee ai lavori e flussi di lavoro nel piano di produzione.

¶ Per il tipo di oggettoresource:

add Aggiunge e salva le nuove risorse nel database.

delete Cancella le risorse del database.

76 Versione 7.0

displayVisualizza le risorse nel database.

modifyModifica e sostituisce le risorse nel database.

use Aggiunge le risorse ai flussi di lavoro nel database eai lavori e flussi di lavoro nel piano di produzione.

¶ Per il tipo di oggettoschedule(flusso di lavoro):

add Aggiunge e salva i nuovi flussi di lavoro neldatabase.

adddepAggiunge le dipendenze ai flussi di lavoro nel pianodi produzione.

altpri Modifica la priorità dei flussi di lavoro nel piano diproduzione.

cancel Annulla i flussi di lavoro nel piano di produzione.

deldepCancella le dipendenze dai flussi di lavoro nel pianodi produzione.

delete Cancella i flussi di lavoro dal database.

displayVisualizza i flussi di lavoro nel database.

limit Modifica il limite di lavoro dei flussi di lavoro nelpiano di produzione.

modifyModifica i flussi di lavoro nel database.

releaseRilascia i flussi di lavoro dalle dipendenze nel pianodi produzione.

reply Risponde alle richieste del flusso di lavoro nel pianodi produzione.

submitInoltra i flussi di lavoro nel piano di produzione.

postazionediT

Security

¶ Per il tipo di oggettouserobj:

add Aggiunge nuovi utenti al database.

delete Cancella gli utenti dal database.

displayVisualizza gli utenti nel database.

modifyModifica e sostituisce gli utenti nel database.

altpassModifica le password dell’utente nel database.

7. A seconda delle necessità, richiedere le istruzioni di cui sopra perdefinire tutti gli utenti necessari, gli oggetti che essi possonoutilizzare e il tipo di accesso.

Nota: Ricordare di aggiornare il file security per aggiungerel’amministratore Tivoli, dopo aver installato TivoliManagement Framework e il connettore TWS. Consultare“Aggiornamento di TWS Security” a pagina 96 perdettagli.

78 Versione 7.0

Installazione del connettore TWS

Questo capitolo descrive il modo in cui installare il connettore TWS.

Prima dell’installazioneLeggere queste informazioni prima di procedere con l’installazionedel connettore TWS.

Il connettore TWS richiede che Job Scheduling Services (JSS) siainstallato nell’ambiente Tivoli dell’utente.

L’installazione e la personalizzazione del connettore TWS variano aseconda che il TWS Master si trovi su un server TMR o su un nodogestito.

¶ Quando TWS Master si trova su un server TMR, è necessarioinstallare sia JSS che il connettore TWS sul server TMR delproprio ambiente. Inoltre, è necessario creare un’istanza delconnettore TWS per il server TMR. Questa operazione puòessere effettuata durante l’installazione, utilizzando la casella dispuntaCrea istanzae completando i campi richiesti.

¶ Quando TWS Master si trova su un nodo gestito, è necessarioinstallare JSS su un server TMR e su un nodo gestito su cui èubicato un Master. Quindi, è necessario installare il connettoreTWS sul server TMR e sugli stessi Nodi su cui è stato installatoil JSS. Prestare attenzione a non selezionare la casella di spuntaCrea istanza.

5.Installazione

delconnettore

Se si dispone di più di un nodo su cui si desidera installare ilconnettore (ad esempio, se si desidera accedere ai dati locali diun FTA attraverso Job Scheduling Console), è possibile installareil connettore su più macchine. Tuttavia, in questo caso, ènecessario deselezionare la casella di spuntaCrea istanza,poiché ogni istanza deve avere un nome univoco nella rete TWS.

Dopo aver installato il connettore sulle workstation nella rete, èpossibile procedere con la creazione di un’istanza del connettoreTWS sulle macchine a cui si desidera che TWS acceda tramiteJob Scheduling Console. Ogni nome dell’istanza del connettoreTWS deve essere univoco nella rete TWS, in questo modo ènecessario creare separatamente ogni istanza. Si suggerisce diutilizzare il nome dell’agent TWS come nome dell’istanza.

Gli FTA TWS a cui è necessario accedere attraverso Job SchedulingConsole per verificare i dati locali, devono avere installati JSS e unconnettore TWS, più un’istanza del connettore TWS univoca perogni installazione TWS a cui è necessario accedere tramite JobScheduling Console.

Nota: Ogni nome dell’istanza del connettore TWS deve essereunivoco nella rete TWS.

Requisiti di sistemaIl connettore TWS ha i seguenti requisiti di sistema:

¶ Tivoli Management Framework, Versione 3.6.1 o successiva

¶ Motore di base Tivoli Workload Scheduler 7.0

¶ Approssimativamente 100 MB di spazio libero su disco per iGestori dominio e per gli FTA. Approssimativamente 40 MB pergli SA (Standard Agent). Inoltre, TWS produce file di log e filetemporanei ubicati sull’unità fissa locale. La quantità di spazionecessario dipende dal numero di lavori gestiti dal TWS e daltempo specificato per la conservazione dei log.

¶ 128 MB di RAM e 128 MB di spazio swap per Gestori dominied FTA. Gli SA ne richiedono una quantità minore.

Prima dell’installazione

80 Versione 7.0

¶ E’ necessario un account utente TWS per una installazioneadeguata. E’ possibile creare l’account in anticipo oppure farlocreare dal programma Setup.

Piattaforme supportateIl connettore TWS è disponibile per i seguenti sistemi operativi:

¶ Microsoft Windows NT® Versione 4.0 con Service Pack 4 oversione successiva

¶ AIX 4.2.1 o 4.3

¶ Sun Solaris 2.6 o 2.7

¶ HP-UX 10.x o 11.0

Procedura di installazioneL’installazione del connettore TWS è divisa in tre sezioni:

¶ Installazione di JSS (Job Scheduling Services). Ignorare questafase se JSS è già installato su Tivoli Management Framework.Notare che JSS deve essere installato prima del connettore sulserver TMR.

¶ Installazione del connettore TWS. Il connettore TWS deve essereinstallato sul server TMR.

¶ Creazione dell’istanza del connettore TWS. Deve esistereun’istanza per ogni motore TWS a cui si desidera accedereattraverso Job Scheduling Console. Il nome dell’istanza delconnettore TWS deve essere univoco nella rete TWS.

E’ possibile effettuare l’installazione nel desktop Tivoli oppure dauna shell della riga comandi con le variabili d’ambiente Tivoliconfigurate.

Installazione di JSS (Job Scheduling Services)Per installare JSS, è possibile utilizzare il desktop Tivoli oppure lariga comandi. Entrambe le procedure vengono descritte qui.

5.Installazione

delconnettore

Dove effettuare l’installazioneInstallare JSS Services sul server TMR e su ogni nodo gestito su cuiverrà installato il connettore TWS.

Installazione di JSS utilizzando il desktop Tivoli1. Login come root o come amministratore.

2. Impostare l’ambiente Tivoli,

¶ Da una riga comandi UNIX:./etc/Tivoli/setup_env.sh

¶ Da una riga comandi Windows NT:%SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd

3. Aprire il desktop Tivoli.

4. Dal menu Desktop selezionareInstalla -> Installa prodotto . Inquesto modo si apre la finestra Installa prodotto.

Nota: Potrebbe essere visualizzata una finestra di errore cheattesta che il percorso per i file d’installazione è errato.Ignorare questa finestra. Chiuderla e continuare con il

82 Versione 7.0

passo successivo.

5. Fare clic sul pulsanteSeleziona supporti...per selezionare ilpercorso o la directory contenente il file CONTENTS.LST. In

5.Installazione

delconnettore

questo modo viene aperta la finestra Sfoglia file.

84 Versione 7.0

6. Fare clic sul pulsanteImposta supporto & Chiudi . In questomodo si ritorna alla finestra Installa prodotto.

7. Dall’elencoSelezionare prodotto da installare, selezionareTivoli Job Scheduling Services.

8. Dall’elencoClient disponibili , selezionare i nodi da installare espostarli sull’elencoClient su cui effettuare l’installazione. E’necessario installare JSS sul server Tivoli Management. Saràpossibile installare il connettore TWS solo su nodi gestiti su cuiè installato il JSS.

5.Installazione

delconnettore

9. Fare clic sul pulsanteInstalla & Chiudi . Viene visualizzata lafinestraInstallazione prodotto.

10. La finestra Installazione prodotto mostra lo statodell’installazione. Fare clic sul pulsanteContinua installazioneper continuare l’installazione oppure fare clic sul pulsanteAnnulla per annullare l’installazione.

11. Quando viene visualizzato il messaggioInstallazione delprodotto terminata , fare clic sul pulsanteChiudi .

Installazione di JSS utilizzando la riga comandi1. Impostare l’ambiente Tivoli,

2. Effettuare una delle seguenti operazioni:

86 Versione 7.0

¶ Per l’installazione su tutti i nodi gestiti:winstall -c installdir -i TMF_JSS

¶ Per l’installazione su un solo nodo gestito:winstall -c installdir -I TMF_JSS node

dove install-dir è il nome del percorso contenente i file diimmagini d’installazione enodoè il nome del nodo gestitosu cui effettuare l’installazione.

Installazione del connettore TWSPer installare il connettore TWS, è possibile utilizzare il desktopTivoli o la riga comandi. Entrambe le procedure vengono descrittequi.

Nota: Se si desidera installare nuovamente il connettore TWS, ènecessario disinstallare quello esistente prima di cominciarel’operazione. Consultare “Come disinstallare il connettoreTWS” a pagina 97 per riferimento.

Dove effettuare l’installazioneInstallare il connettore TWS sul server TMR oppure sul nodo gestitosu cui è installato TWS Master.

E’ possibile installare il connettore su un FTA, se si desideraaccedere ai dati locali sull’FTA da Job Scheduling Console.

Installazione del connettore TWS utilizzando il desktopTivoli

1. Login come root o come amministratore.

5.Installazione

delconnettore

4. Dal menu Desktop selezionareInstalla -> Installa prodotto . Inquesto modo si apre la finestra Installa prodotto.

5. Fare clic sul pulsanteSeleziona supporti...per selezionare ladirectory contenente il file CONTENTS.LST. In questo modo

88 Versione 7.0

viene aperta la finestra Sfoglia file.

5.Installazione

delconnettore

6. Fare clic sul pulsanteImposta supporto & Chiudi . In questomodo si ritorna alla finestra Installa prodotto.

7. Dall’elencoSelezionare prodotto da installare, selezionareConnettore TWS. Viene visualizzata la finestraInstallaopzioni.

8. Questo pannello consente di:

¶ Installare solo il connettore TWS.

¶ Installare il connettore TWS e creare un’istanza per ilconnettore TWS

90 Versione 7.0

9. Per installare il connettore TWS senza creare l’istanza per ilconnettore TWS non selezionare la casella di spunta Createinstance e lasciare vuoto il campo Opzioni generalid’installazione. Questi campi vengono utilizzati solo durante lacreazione dell’istanza del connettore TWS.

10. Per installare il connettore TWS e creare un’istanza per ilconnettore TWS:

a. Selezionare la casella di spunta Create instance.

b. Nel campo TWS Directory, specificare la directory su cui èinstallato TWS.

c. Nel campo nome istanza TWS, specificare un nome perl’istanza TWS su un nodo gestito.

Nota: Questo nome deve essere univoco nella rete TWS.Se si decide di non creare l’istanza adesso, è possibilecrearla successivamente utilizzando il programma di utilitàwtwsconn dalla riga comandi. Fare riferimento a Creazioneistanze del connettore TWS utilizzando la riga comandi. Lacreazione successiva dell’istanza del connettore TWS èconsigliata quando si installa il connettore TWS su più nodi,poiché è possibile effettuare l’installazionecontemporaneamente su tutti i nodi durante la creazionelocale dell’istanzawtwsconn.

5.Installazione

delconnettore

11. Fare clic sul pulsanteImposta, per chiudere questa finestra etornare al pannello Installa prodotto.

12. Nell’elenco Client disponibili, selezionare i nodi da installare espostarli sull’elenco Client su cui effettuare l’installazione.

E’ necessario installare il connettore TWS almeno sul server digestione Tivoli. E’ possibile anche installare il connettore TWSsui nodi gestiti su cui è installato JSS.

Nota: Se si decide di creare un’Istanza per il connettore TWSdurante l’installazione, è necessario selezionare un solonodo dall’elenco, poiché il nome dell’istanza deve essereunivoco nella rete TWS.

13. Nella finestra Installa prodotto, fare clic sul pulsanteInstalla &Chiudi . Viene visualizzata la finestraInstallazione prodotto.

14. La finestra Installazione prodotto mostra lo statodell’installazione. Fare clic sul pulsanteContinua installazioneper continuare l’installazione oppure fare clic sul pulsanteAnnulla per annullare l’installazione.

92 Versione 7.0

15. Quando viene visualizzato il messaggioInstallazione delprodotto terminata , fare clic sul pulsanteChiudi .

Installazione del connettore TWS utilizzando la riga comandi1. Login come root o come amministratore.

3. Immettere la stringa seguente su una riga singola come comando:

¶ Per l’installazione su tutti i nodi gestiti:winstall -c install-dir -i TWS_CONN twsdir=/users/maestroiname=Maestro owner=maestro

¶ Per l’installazione su un solo nodo gestito:winstall -c installdir -I TWS_CONN node twsdir=/users/maestroiname=Maestro owner=maestro createinst=1

dove installdir è il nome del percorso che contiene i filed’immagine di installazione enodoè il nome del nodogestito su cui eseguire l’installazione.

Creazione di Istanze per il connettore TWS utilizzando lariga comandi

Creare un’istanza per il connettore TWS per ogni motore TWS a cuisi desidera accedere con JS Console. Per creare un’Istanza per ilconnettore TWS, è necessario essere un amministratore Tivoli conruoli di autorizzazioneadmin, senior o super. Per ulterioriinformazioni fare riferimento ai Ruoli di autorizzazione riportati diseguito.

Per creare un’istanza, immettere il comando seguente sul serverTMR o sul nodo gestito su cui è stato installato il connettore TWS acui si desidera accedere tramite JS Console:wtwsconn -create -h [node] -n [instance_name] -t [TWS_directory]

5.Installazione

delconnettore

-h nodoSpecifica ilnodosu cui viene creata l’istanza. Se nonspecificato, viene impostato per default sulnododove vieneeseguito il file script.

-n istanzaIl nome della nuova istanza. Questo nome identificherà ilnododel motore TWS nell’albero Job Scheduling di JSConsole. Notare che questo nome deve essere univoco nellarete TWS.

-t twsdirSpecifica il valore per l’attributoTWSdir. Questa è ladirectory di installazione TWSnodospecificato.

Ruoli di autorizzazione necessari per le istanzePer gestire le istanze per il connettore TWS da un server TMR o unnodo gestito, è necessario essere un amministratore Tivoli.

Ogni amministratore Tivoli ha uno o più ruoli. Per utilizzare ogestire le istanze del connettore TWS, sono necessari i seguentiruoli:

¶ utente

Per utilizzare queste istanze.

Per visualizzare le impostazioni delle istanze.

¶ admin, senior o super

Per eseguire tutte le azioni disponibili al ruolo user.

Per creare o rimuovere le istanze.

Per modificare le impostazioni dell’istanza.

Per avviare e arrestare le istanze.

Gestione delle istanze del connettore TWSUtilizzare il programma di utilitàwtwsconn per creare, rimuovere egestire le istanze del connettore TWS. Questo programma vienescaricato quando si installa il connettore TWS.

94 Versione 7.0

La tabella seguente descrive il modo in cui utilizzarewtwsconnnella riga comandi per gestire le istanze del connettore TWS.

Azione Sintassi

Creare un’istanza wtwsconn.sh -create [-hnodo] -n istanza-t twsdir

Arrestare un’istanza wtwsconn.sh -stop -nistanza| -t twsdir

Due azioni di arresto sono supportate.

Quando viene specificata l’istanza-n, viene arrestatal’istanza con quel nome.

Quando viene specificato -ttwsdir, tutte le istanze su questonodo (il nodo su cui viene eseguito lo script), il cui attributoTWSdircorrisponde a twsdir, vengono arrestate.

Rimuovere un’istanza wtwsconn.sh -remove -nistanza

Visualizzare le impostazionidi un’istanza.

wtwsconn.sh -view -nistanza

Modificare le impostazioni diun’istanza.

wtwsconn.sh -set -nistanza-t twsdir

nodo Specifica il nodo su cui è creata l’istanza. Se non specificato,viene impostato per default sul nodo da cui viene eseguito loscript.

istanzaIl nome della nuova istanza. Questo nome identificherà ilmotore TWS del nodo nell’albero Job Scheduling di JSConsole.Nota:questo nome deve essere univoco nella reteTWS

twsdir Specifica il valore per l’attributo TWS dir. Questa è ladirectory d’installazione TWS nel nodo.

Installazione delle patch JSS e del connettore TWSPer installare patch:

5.Installazione

delconnettore

4. Dal menu Desktop selezionareInstalla ->Installa patch. Inquesto modo si apre la Finestra Installa patch.

5. Seguire una procedura simile per Installa prodotto.

Aggiornamento di TWS SecurityPrima di aggiornare TWS security è necessario aggiungere l’utenteTWS come amministratore Tivoli sul desktop Tivoli. Per effettuareciò:

1. Aprire il desktop Tivoli

2. Effettuare una delle seguenti operazioni:

¶ Aggiungere il logon utente TWS alla finestra Modifica loginper gli amministratori Tivoli.

¶ Creare un amministratore Tivoli con il logon dell’utenteTWS.

Aggiornare il file TWS Security nel modo seguente:

1. Login come utente TWS (generalmente,TWSusero maestro).

2. Modificare la directory inTWS home.

3. Eseguire il comandodumpsecin questo modo:dumpsec >tempsec

4. Modificare il file tempsecaffinché contenga il nome TMFAdmin. Per avere il nome Admin, aprire il desktop Tivoli e faredoppio clic suAmministratori . Il nome Admin è il gruppo degliAmministratori a cui appartiene il login. Generalmente il nomeappare comeRoot_dallas-region. Se il nome Admin contieneuno spazio, racchiuderlo tra virgolette.

5. Eseguiwmaeutil per arrestare il connettore TWS.

96 Versione 7.0

6. Eseguire il comandomakesecin questo modo:makesec tempsec

Come disinstallare il connettore TWS1. Login come root o come amministratore.

3. Eseguire il comandowuninst:

¶ Su UNIX:wuninst TWSConnector <node> -rmfiles

¶ Su Windows NT:$bash

wuninst TWSConnector <node> -rmfiles

Dove nodeè il nome del sistema da cui si desidera rimuovere ilconnettore TWS.

Ciò effettuerà il kill dei processi il connettore TWS e rimuoveràfile d’installazione e classi del connettore TWS.

Come disinstallare JSS ServerPrima di disinstallare Job Scheduling Services, accertarsi di averdisinstallato il connettore TWS e, se applicabile, il connettore OPC.

5.Installazione

delconnettore

3. Eseguire il comandowuninst:

¶ Su UNIX:wuninst TMF_JSS node -rmfiles

¶ Su Windows NT:bash

wuninst TMF_JSS node -rmfiles

Dove nodeè il nome del sistema da cui si desidera rimuovereJSS.

In questo modo verranno rimossi file d’installazione e classi JSS.

Comandi utili della frameworkQuesti comandi possono essere utilizzati per verificare il proprioambiente Framework. Fare riferimento alManuale di riferimentoTivoli Frameworkper ulteriori dettagli.

Comando Descrizione

wlookup -ar ProductInfo Elenca i prodotti installati nella TMR.

wlookup -ar PatchInfo Elenca le patch installate nella TMR.

wlookup -ar MaestroEngine Mostra le istanze di questo tipo di classe (ugualiper le altre classi). Questo restituisce le seguentiinformazioni:

barb 1318267480.2.19#Maestro::Engine# Ilnumero prima di 1st . (dot) è l’area # , il 2°numero è l’ID del ManagedNode (se è 1 sitrattadi un server TMR). In questo modo, in unambiente a più TMR, se è necessario conosceredove è installata una particolare istanza, èpossibile configurarlo considerando questo numeropoiché tutte le aree TMR avranno un ID univoco.

wuninst -list Mostra tutti i prodotti da disinstallare.

wuninst {ProductName} -list Mostra i nodi gestiti su cui è installato unprodotto.

Come disinstallare JSS Server

98 Versione 7.0

Installazione di Tivoli JobScheduling Console

Questo capitolo descrive il processo d’installazione per Tivoli JobScheduling Console.

Requisiti di sistemaJob Scheduling Console ha i seguenti requisiti di sistema:

¶ Approssimativamente 10 MB.

¶ 128 MB di RAM.

Piattaforme supportateTivoli Job Scheduling console è disponibile per i seguenti sistemioperativi:

¶ Microsoft Windows NT® Versione 4.0 con Service Pack 4 oversione successiva

¶ Windows 2000

¶ Windows 98

¶ AIX 4.2.1 o 4.3

¶ Sun Solaris 2.6 o 2.7

6.Installazione

diTivoliJob

Scheduling

Console

¶ HP-UX 10.x o 11.0

Prerequisiti per HP-UX e AIXPrima di installare Job Scheduling Console su piattaforme HP-UX oAIX, è necessario installare Java 1.1.8 per queste due piattaforme.Sono messe a disposizione dai siti web Hewlett-Packard o IBM. Java1.1.8 deve essere installato con esito positivo prima di installare JobScheduling Console. Annotare il percorso di installazione. E’necessario immetterlo nel punto in cui è stato installato il javadurante l’installazione di Job Scheduling Console.

Installazione di Job Scheduling ConsoleSeguire queste istruzioni per installare Job Scheduling Console:

2. Inserire il CD-ROM di Tivoli Job Scheduling Console nell’unitàCD-ROM del sistema o caricare il CD-ROM da una unità su unsistema remoto. In questo esempio, il CD-ROM è l’unitàD.

3. Eseguire il comando d’installazione:

¶ Su Windows:

v Dal menuAvvio, selezionare l’opzioneEsegui...pervisualizzare la finestra di dialogo Esegui.

v Immettered:\jsgui\windows\install.exenel campoApri .

¶ Su Sun Solaris, AIX e HPUX: andare sul CD-ROM diinstallazione o sul contenitore di fine d’immagine eimmettere:sh install.bin

Nota: Su AIX e HPUX, verificare che la variabileCLASSPATH sia stata impostata nell’ubicazione incui risiede il file classes.zip (per JDK) o rt.jar (perJRE) prima di eseguireinstall.bin.

Piattaforme supportate

100 Versione 7.0

Viene visualizzata la finestra seguente.

4. In questa finestra, fare clic sulla freccia rivolta verso il bassonel campo relativo alla lingua. Viene visualizzato un elenco adiscesa contenente tutte le lingue disponibili in cui effettuarel’installazione.

5. Selezionare la lingua e fare clic suOK nella finestra acomparsa.

Viene visualizzata la finestraIntroduzione.

Questa finestra è utile nel processo d’installazione, poichécontiene una serie di finestre di opzioni che consentonoall’utente di fornire una serie di informazioni. E’ possibileutilizzare i pulsantiIndietro , Avanti o Esci, se abilitati, perspostarsi tra queste finestre.

Installazione di Job Scheduling Console

6.Installazione

diTivoliJob

Scheduling

Console

6. Fare clic sul pulsanteAvanti per cercare la finestraSelezionacartella d’installazione, visualizzata nella figura successiva.

I percorsi di default per l’installazione sono:

¶ Per Windows: C:\Program Files\JSConsole

¶ Per AIX, Sun Solaris e HPUX: /JSConsole

7. Immettere il percorso in cui installare Job Scheduling Console.Se necessario, modificare l’ubicazione di default fornita nelcampo oppure selezionare il pulsanteSeleziona...per aprire lafinestraSeleziona cartellada cui è possibile specificare un’altraubicazione.

8. Solo per sistemi Windows e Sun Solaris: fare clic suAvanti percontinuare fino alla finestraSelezionare il percorso per lescelte rapide. La figura successiva mostra la versione diWindows della finestra Selezionare il percorso per le scelterapide. La versione Sun Solaris è simile, ma contiene opzioni

102 Versione 7.0

differenti.

9. Solo per i sistemi Windows e Sun Solaris: fare clic su uno deipallini disponibili per specificare il punto in cui inserire le iconedi Job Scheduling Console.

10. Fare clic suAvanti per continuare a cercare la finestraSelezionare il pacchetto d’installazione, riportata nella figurasuccessiva.

6.Installazione

diTivoliJob

Scheduling

Console

11. In questa finestra, scegliere se installare Job Scheduling Consolein tutte le lingue disponibili (pacchetto completo) o o solo nellelingue selezionate (Installazione personalizzata). In entrambi icasi, viene installata automaticamente la versione inglese.

¶ Se si sceglie un Pacchetto completo, fare clic suInstallaper installare Job Scheduling Console.

¶ Se si sceglie l’Installazione personalizzata:

a. Fare clic suPersonalizzaper aprire la finestraPersonalizzazione dell’installazione, come mostratonella figura successiva.

b. Nella finestra Personalizzazione dell’installazione,selezionare le lingue, oltre l’inglese, in cui si desiderainstallare Job Scheduling Console e fare clic suInstalla.

1) Job Scheduling Console verrà visualizzata nellalingua selezionata, solo se la lingua corrisponde alleimpostazioni regionali del computer. Se ciò nonaccade, l’inglese sarà la lingua di default.

2) Job Scheduling Console si adatterà automaticamentealle impostazioni della Nazione, della lingua e delfuso orario del proprio sistema o della shell UNIX.

104 Versione 7.0

Viene visualizzata una finestra contenente un indicatore diavanzamento, riportata nella figura successiva.

12. Quando la finestraInstallazione completaviene visualizzatanella figura successiva, fare clic sul pulsanteEseguitoperchiuderla e per completare l’installazione.

6.Installazione

diTivoliJob

Scheduling

Console

13. Se JS Console è stata installata su AIX o HPUX, è necessarioaggiornare il file AIXconsole.sh o HPconsole.sh con il percorsoin cui è stato installato Java Development Kit (JDK) 1.1.8. Pereffettuare ciò:

¶ Andare alla sottodirectory /bin/java della directory in cui èstato installato JS Console.

¶ Aprire AIXconsole.sh o HPconsole.sh in modalità dimodifica.

¶ Ricercare la seguente variabile e modificarla in:

JAVAPATH=usr/jdk1.1.8/J1.1.8

¶ Modificare il valore JAVAPATH con il percorso per JDK1.1.8.

¶ Salvare le modifiche e uscire dall’editor. E’ possibileavviare Tivoli Job Scheduling Console.

Avvio di Job Scheduling Console1. A seconda della piattaforma, avviare JS Console nel modo

seguente:

¶ Su Windows, a seconda della posizione della scelta rapidaspecificata durante l’installazione, fare clic sull’icona JSConsole o selezionare la voce corrispondente nel menuAvvio. Una finestra MS-DOS, come quella visualizzata nellafigura successiva, si apre sullo sfondo.

106 Versione 7.0

Su Windows 95 e Windows 98, è possibile avviare anche JSConsole da una riga comandi. Immettere solo RUNCONdalla sottodirectory \bin\java del percorso d’installazione.

¶ Sulle altre piattaforme:

a. Modificare la directory ininstallazione path/bin/java

b. Immettere il comando d’avvio:

v Su AIX, immettere:./AIXconsole.sh

v Su Sun Solaris, immettere:./SUNconsole.sh

v Su HPUX, immettere:./HPconsole.sh

Avvio di Job Scheduling Console

6.Installazione

diTivoliJob

Scheduling

Console

Viene visualizzata una finestra di avvioTivoli Job SchedulingConsolecome quella visualizzata nella figura successiva.

2. Immettere le seguenti informazioni e fare clic sul pulsanteOKper proseguire:

Sistema host Il nome del server TMR o del nodo gestito cheesegue il connettore TWS.

Nome utente Il nome utente TWS o qualsiasi altro loginconcesso con i diritti dell’amministratore Tivoli eche si trova nel file TWS security.

Password La password per il sistema host che esegue ilconnettore TWS.

3. Se si sta effettuando il login al nodo gestito delSistema hostperla prima volta, vengono visualizzate informazioni a comparsa,come quelle riportate nella figura riportata più avanti, cheindicano il modo in cui specificare un file di preferenzadell’utente per l’inizializzazione, se esiste.

108 Versione 7.0

Leggere le informazioni e fare clic suOK per continuare finoalla finestraApri ubicazione.

4. Utilizzare questa finestra per eseguire una di queste operazioni:

¶ Specificare una URL in cui sono definite le preferenzedell’utente. Immettere l’URL e selezionare il pulsanteCaricada URL.

¶ Selezionare il pulsantePrendi dal file per aprire una finestrada cui è possibile scegliere un file contenente i dati diinizializzazione.

¶ Selezionare il pulsanteAnnulla per utilizzare le preferenzedi default dell’utente.

5. Effettuare la selezione. Viene visualizzata la finestra diBenvenuto, riportata nella figura successiva. La finestra TivoliJob Scheduling Console viene visualizzata sullo sfondo.

6. Nella finestra di benvenuto, selezionare un pallino, quindi fareclic su OK per cominciare a utilizzare Job Scheduling Console.

6.Installazione

diTivoliJob

Scheduling

Console

Oppure fare clic suAnnulla per chiudere la finestra diBenvenuto e utilizzare la Job Scheduling Console senzaun’assistenza in linea.

Come disinstallare Job Scheduling ConsoleQuesta sezione fornisce istruzioni per la disinstallazione di JobScheduling Console su UNIX e Windows.

Come disinstallare UNIXPer disinstallare Job Scheduling Console su AIX, HP-UX e SunSolaris, andare alla sottodirectory /UninstallerData del percorso diinstallazione e immettere il seguente comando:./Uninstall_JSConsole

Nota: Prima di eseguire ./Uninstall_JSConsole accertare di avereimpostato la variabile PATH. Ad esempio:export PATH=$PATH:/usr/jdk1.1.8/J1.1.8

Come disinstallare WindowsPer disinstallare Tivoli Job Scheduling Console su Windows:

1. Andare sull’ubicazione della scelta rapida specificata durantel’installazione e fare clic sull’iconaDisinstalla Tivoli JobScheduling Console. Viene visualizzata la finestraProgrammadi disinstallazione di InstallAnywhere.

110 Versione 7.0

2. Fare clic suDisinstalla. Viene visualizzato un indicatore diavanzamento. Al termine della disinstallazione, esso elenca tutti ifile che il programma non è stato in grado di installare. Sarànecessario cancellarli manualmente.

3. Fare clic suEsci per chiudere la finestra di dialogo e perterminare il processo di disinstallazione.

Nota: Il processo di disinstallazione non cancella i file contenutinella sottocartelladat.

Come disinstallare Job Scheduling Console

6.Installazione

diTivoliJob

Scheduling

Console

Come disinstallare Job Scheduling Console

112 Versione 7.0

Argomenti ulteriori perpersonalizzare TWS

Dopo aver installato TWS, potrebbe essere necessario adattarlo alleproprie necessità. Questo capitolo fornisce ulteriori informazioni perla personalizzazione dell’installazione di TWS.

Impostazione delle opzioni globaliLe opzioni globali sono i parametri di personalizzazione chespecificano il modo in cui lavorerà l’intera rete TWS. L’utente lidefinisce sul proprio Gestore dominio master, ma possono essereapplicate a tutte le workstation nella rete TWS.

La maschera del file Opzioni globali, contenente le impostazioni didefault Tivoli, è ubicata inTWShome/config/globalopts.

Durante il processo d’installazione, una copia attiva del file Opzioniglobali è installata comeTWShome/mozart/globalopts.Personalizzare la copia attiva con un editor di testo per adattarla alleproprie necessità, quindi salvarla. Poi, arrestare e avviare il TWS. E’possibile apportare modifiche in un qualsiasi momento, ma questenon diventeranno effettive fino all’arresto e al riavvio di WorkloadScheduler o fino all’inizio di un nuovo giorno di produzione.Consultare ilManuale per l’utente Tivoli Workstation Schedulerper idettagli sulla personalizzazione del fileglobalopts. Alcuni esempi diopzioni globali sono:

rgomentiulterioriper

personalizzareT

¶ Concedere automaticamente, agli utenti, il logon ai lavoriWindows NT con il diritto di effettuare il Logon come lavorobatch.

¶ Assegnazione di una priorità specifica ai flussi di lavoro creatiper lavori non pianificati.

¶ Determinare, in base allo stato, i lavori da includere ai flussi dilavoro avviati.

¶ Determinare se i flussi di lavoro non completi vengono avviatidal vecchio al nuovo piano di produzione o meno.

¶ Abilitare la verifica del database.

¶ Stabilire il numero di giorni di conservazione delle statistiche dellavoro.

¶ Determinare se i calendari dell’utente vengono copiati nel nuovofile Controllo produzione.

¶ Stabilire se abilitare o disabilitare il controllo del piano.

¶ Determinare se i lavori riavviati con il comando conmanmanterranno i loro nomi originari.

¶ Modificare l’ora di avvio di default del giorno di elaborazione diTWS.

¶ Stabilire se abilitare o disabilitare l’opzione del Fuso orario.

Impostazione delle opzioni localiLe opzioni locali sono i parametri di personalizzazione chespecificano il modo in cui TWS lavorerà su una workstationparticolare. Le preferenze delle opzioni locali in un filelocalopts suuna workstation particolare.

Una maschera del file Opzioni locali, contenente le impostazioni didefault Tivoli, è ubicata inTWShome/config/localopts.

Durante il processo d’installazione, una copia attiva del file Opzionilocali è installata comeTWShome/localopts. Personalizzare la copiaattiva con un editor di testo e salvarla. Poi, arrestare e avviare il

Impostazione delle opzioni globali

114 Versione 7.0

TWS. E’ possibile apportare modifiche in un qualsiasi momento, maqueste non diventeranno effettive fino all’arresto e al riavvio diWorkload Scheduler. Consultare ilManuale per l’utente TivoliWorkstation Schedulerper i dettagli sulla personalizzazione del filelocalopts. Alcuni esempi di opzioni locali sono:

¶ Definire il numero minimo di secondi che Batchman attenderàprima di verificare l’esistenza di un file utilizzato comedipendenza.

¶ Definire il numero di secondi che Batchman attenderà prima diverificare lo stato di una dipendenza tra reti.

¶ Definire il numero massimo di secondi che Batchman attenderàprima di documentare la scadenza di un’Ora Until per un lavoroo per un flusso di lavoro.

¶ Definire il numero minimo di secondi che Batchman attenderàprima di effettuare la scansione e l’aggiornamento del fileControllo produzione

¶ Definire il numero massimo di secondi che Batchman attenderàprima di ricevere un messaggio nel relativo file di messaggi

¶ Specificare se Batchman invierà le statistiche di avvio e dichiusura al file di elenco standard.

¶ Specificare se Batchman invierà i messaggi sullo stato del lavoroal file di elenco standard.

¶ Definire la dimensione della tabella lavori utilizzata da Jobman.

¶ Impedire che Jobman avvii i lavoriroot in UNIX.

¶ Applicare il valorenice ai valori avviati da Jobman in UNIX.

¶ Definire il numero massimo di secondi che Jobman attenderàprima di ricevere un messaggio nel relativo file di messaggi

¶ Specificare se tutti i processi di controllo Workload Scheduler,tranne Netman, invieranno i propri messaggi di console a un filedi elenco singolo standard.

¶ Specificare la velocità, in secondi, con cui Mailman controlla lacasella di posta per i messaggi.

Impostazione delle opzioni locali

personalizzareT

¶ Specificare il numero massimo di secondi che Mailman attenderàprima di ricevere una risposta che documenti che unaworkstation non risponde.

¶ Specificare il numero massimo di secondi che Mailmanattenderà, dopo essersi scollegato da una workstation che nonrisponde, prima di tentare il nuovo collegamento allaworkstation.

¶ Specificare il modo in cui Mailman risponderà al comandoconmantellop ? .

¶ Specificare il numero massimo di secondi che Mailman attenderàprima di scollegarsi da una workstation che non risponde.

¶ Specificare che Netman uscirà nel momento in cui tutti i relativiprocessi child verranno arrestati.

¶ Modificare il numero di porta TCP a cui risponde Netman su uncomputer locale.

¶ Definire il numero massimo di secondi che Netman attenderàprima che una richiesta di connessione verifichi la sua codamessaggi per i comandiarresta e avvia.

¶ Specificare il numero massimo di secondi che Netman attenderàprima di tentare nuovamente la connessione non riuscita.

¶ Definire la lunghezza massima dei messaggi della console TWS.

¶ Definire il numero di secondi che il processo Writer attenderàper ricevere un messaggio prima di verificare una richiesta dichiusura da Netman.

¶ Definire il numero di secondi che il processo Writer attenderàprima di uscire se non riceve alcun messaggio.

Come automatizzare il ciclo di produzioneL’elaborazione pre e postproduzione può essere automatizzatacompletamente aggiungendo il flusso di lavorofinale fornito daTivoli o uno equivalente fornito dall’utente, al database TWSinsieme ad altri flussi di lavoro. Una copia di flusso di lavoro fornitoda Tivoli può essere trovata inTWShome/Sfinal e una copia dello

Impostazione delle opzioni locali

116 Versione 7.0

script di lavoro può essere trovata inTWShome/ Jnextday. Potrebbeessere utile avere copie cartacee per supportare il processo disostituzione.

Il flusso di lavorofinale si trova in produzione ogni giorno e risultanell’esecuzione di un lavoro denominatoJnextday che precedel’avvio di un giorno nuovo. Il lavoro compie le seguenti attività:

1. Si collega a tutte le workstation per accertare che l’Gestoredominio master sia stato aggiornato con l’ultima informazione dipianificazione.

2. Esegue il comandoschedulr per selezionare i flussi di lavoro peril piano di produzione del nuovo giorno.

3. Esegue il comandocompiler per compilare il piano diproduzione.

4. Esegue il comandoreptr per stampare i report di preproduzione.

5. Arresta il TWS.

6. Esegue il comandostagemanper portare avanti i flussi di lavoroincompiuti, registrare il vecchio piano di produzione e installareil nuovo.

7. Avvia il TWS per il nuovo giorno.

8. Esegue i comandireptr e rep8 per stampare i reportpostproduzione per il giorno precedente.

9. Esegue il comandologman per registrare le statistiche di lavoroper il giorno precedente.

Nell’impostazione manuale di TWS, i terminifinale e Jnextdayvengono utilizzati per fare riferimento alle versioni fornite da Tivolie a tutti gli equivalenti forniti dall’utente.

Personalizzazione del flusso di lavoro finalePrima di utilizzare il flusso di lavorofinale, è possibile modificarloper adattarlo alle proprie necessità oppure è possibile crearne unodifferente da utilizzare al suo posto.

Come automatizzare il ciclo di produzione

personalizzareT

Quando si crea un flusso di lavoro proprio, adattarlo in base a quellofornito da Tivoli. Se si decide di effettuare questa operazione, tenerepresente quanto segue:

¶ Se si decide di modificare la procedura con cuistagemancrea inomi del file di log, ricordare chereptr e logman devonoutilizzare gli stessi nomi.

¶ Se si desidera stampare i report di preproduzione prima di unnuovo giorno, è possibile dividere il lavoroJnextday in due. Ilprimo lavoro esegueschedulr, compiler e reptr . Il secondoarresta TWS, eseguestageman, avvia TWS ed eseguereptr elogman. Il primo lavoro, dunque, può essere pianificato peressere eseguito in un qualsiasi momento prima della fine di ungiorno, mentre il secondo lavoro deve essere eseguito appenaprima della fine di un giorno.

Aggiunta di un flusso di lavoro finaleSeguendo le istruzioni spiegate in “Configurazione di un gestoredominio master dopo l’installazione” a pagina 50 su UNIX oppure seè stato installato il TWS tramite il programma Setup in NT, il flussodi lavoro finale è già stato aggiunto al database. Altrimenti, seguirequeste istruzioni per aggiungere il flusso di lavorofinale o unequivalente fornito da un utente.

1. Effettuare il login come utenteTWS o maestro sul gestoredominio master.

2. Alla prompt del comando, immettere il seguente comando suUNIX:composer “add Sfinal”

o il comando seguente su Windows NT:composer “add Sfinal”

Per aggiungere un flusso di lavoro proprio, utilizzare il nome alposto diSfinal.

118 Versione 7.0

Avvio di un ciclo di produzioneSe non è stato avviato oppure se diviene necessario avviare unnuovo giorno di produzione in un momento diverso da quellodefinito di un giorno, seguire queste istruzioni:

1. Effettuare il login come utente delmaestro sul gestore dominiomaster.

2. Alla prompt del comando, eseguire il lavoroJnextdayimmettendo questo comando:Jnextday

In questo modo verrà eseguita l’elaborazione di preproduzione el’avvio dei processi di produzione del TWS.

Gestione di un ambiente di produzioneQuesta sezione fornisce informazioni relative alla modifica delgiorno di avvio per il TWS e alla creazione di un piano perpianificare l’elaborazione dei giorni futuri o passati.

Scelta del giorno in cui avviare TWSVi sono tre opzioni comuni per l’avvio di un giorno di produzione.

¶ mattina

¶ tardo pomeriggio

¶ mezzanotte

Queste sono le implicazioni minime della pianificazione:

Ora di avvio e di tempo limite

Le Ore di avvio specificate (parola chiaveAT) sono sempre inrelazione con l’ora di avvio del giorno di produzione TWS. E’possibile che sia necessario aggiungere “+ 1 giorno” ai flussi dilavoro i cui lavori vengono elaborati durante i giorni di produzione.Verificare anche che il tempo limite ( parola chiaveUNTIL) siafissato dopo l’ora di avviom.

Parola chiave ON

personalizzareT

I giorni di produzione e del calendario non devono essere gli stessi.Se il giorno di produzione comincia alle 06:00 a.m. (impostazione didefault), 05:59 a.m. sarà l’ultimo minuto del giorno di produzione.Se un flusso di lavoro deve essere eseguito ON MONDAY alle05:30 verrà selezionato Lunedì e verrà eseguito il martedì alle 5:30a.m.

Parola chiave Rinvia

Fissando l’ora di avvio intorno a mezzanotte, in modo checorrisponda al giorno del calendario, verrà avviata una serie di flussidi lavoro. Questo aumenta la complessità di gestione del centro dati.

Modifica del giorno stabilito per l’avvioIn TWS, l’inizio di un giorno è il momento in cui viene pianificatal’esecuzione di un flusso di lavoro finale e il momento in cuivengono arrestati e riavviati i processi TWS. Per specificare l’iniziodi un giorno per TWS:

1. Modificare l’opzioneavvio nel file Globalopts. Questa è l’ora diavvio del giorno di elaborazione di TWS in formato 24 ore:hhmm(0000-2359). L’ora di avvio di default è 6:00 A.M.

2. Modificare l’ora di avvio (parola chiaveAT) del flusso di lavorofinale per programmare l’esecuzione un minuto prima della finedel giorno.

Se si desidera impostare l’inizio del giorno di produzione sumezzanotte:

1. Impostare l’ora di avvio del flusso di lavorofinale sumezzanotte.

2. Impostare su 0001 l’opzionestart nel file Globalopts.

Altrimenti, con l’opzionestart impostata su 0000 e conJnextdayimpostata su 2359, si rischia di selezionare pianificazioni o flussi dilavoro per il giorno appena terminato, poiché il comandoschedulrutilizza la data di sistema e perché nelle una reti piccole è semprepossibile eseguireschedulr prima di mezzanotte.

Gestione di un ambiente di produzione

120 Versione 7.0

Creazione di un piano per date passate e futureE’ possibile creare un piano che esegua l’elaborazione normalmentepianificata per un giorno passato o futuro. Questa crea nuovamenteuna procedura per ogni giorno di elaborazione specificato. Puòessere necessario utilizzare questa procedura se si perde un giorno dielaborazione per un’emergenza.

1. Scollegare e arrestare tutte le workstation nella rete TWS con iseguenti comandi:conman “unlink @!@;noask”

conman “stop @!@;wait”

Questo arresta tutti i processi in una rete.

2. Eseguire il comandoschedulr con l’opzione della data per creareun file prodsked:schedulr -date MM/DD/YY

Con l’opzione della data è possibile specificare di creare unpiano in base a un giorno di elaborazione passato o futuro.

3. Eseguire il comandocompiler per creare un filesymnew:compiler (-date MM/DD/YY)

E’ possibile utilizzare l’opzione della data con il compiler perspecificare la data odierna o la data del giorno che si sta tentandodi di ricreare. Questa opzione può essere necessaria se si disponedi flussi di lavoro contenenti parametri di input sensibili alladata. Il parametroscheddatee escluso dalla data specificata conil comandocompiler. Se non si specifica una data, questa vieneimpostata per default sul comandoschedulr.

4. Eseguire console manager per arrestare i processi TWS:conman stop @!@

5. Eseguire stageman per creare un nuovo file symphony:stageman

6. Eseguire il console manager per avviare i processi TWS:conman start

Gestione di un ambiente di produzione

personalizzareT

122 Versione 7.0

Migrazione su TWS 7.0

Le informazioni contenute in quest’appendice possono essere utilidurante la migrazione dalle versioni del Maestro 5.x o 6.x su TivoliWorkload Scheduler 7.0

Tivoli Management Framework per utenti non TivoliTivoli Management Framework è una framework aperta, orientataall’oggetto che include una serie di gestori, broker e agent conformialla specifica Object Management Group/Common Object RequestBroker Architecture (OMG/CORBA). La tecnologia OMG/CORBAriconosce ulteriori differenze tra i sistemi operativi da nascondereagli utenti e consente i servizi chiave da includere agli oggetti chepossono essere utilizzati da applicazioni di gestione multipla. TivoliManagement Framework fornisce indipendenza di piattaforma, unastruttura unica per tutte le applicazioni e una serie di API che sonostate adottate da DMTF (Desktop Management Task Force) e OpenGroup (formerly X/Open) come base per la framework di gestionedei sistemi. Le API Tivoli forniscono una rete comune e servizi digestione dei sistemi, inclusa la pianificazione, il supporto dellatransazione, i profili di configurazione e una funzione genericadell’utente del database dell’oggetto.

L’unità di base della funzionalità Tivoli Management Framework èlaTivoli Management Region. Una TMR consiste di TivoliManagement Server e di client gestiti da un server. Un server TMRcongela il database per quella TMR. A seconda della dimensione edei requisiti di un ambiente, è possibile definire più di una TMR. Se

Migrazione

esistono più TMR, possono essere autonome o collegate percondividere informazioni e risorse. Gli amministratori con un ruoloadeguato possono gestire tutte le risorse in una serie di TMRconnesse da un sistema singolo, come se le risorse fossero tutte nellaTMR del sistema locale. In generale, un server TMR può supportarefino a 200 nodi gestiti. Con il release di Tivoli ManagementFramework 3.6, i nuovi servizi vengono ubicati sul server TMR e sualcuni nodi gestiti per consentire a quei nodi di agire come gatewayper centinaia di nodi finali. In questo modo aumentasignificativamente l’ambito di una TMR singola.

Tivoli Management Framework fornisce un’implementazione basatasul server di un ORB CORBA e di un BOA (basic object adapter).Fornisce inoltre servizi del desktop, di gestione e correlati all’oggettoe include un’implementazione delle API adottate da Open Group peruna framework di gestione del sistema. Il dispatcher dell’oggettooserv) è il componente principale dell’ora di esecuzione dellaframework. Viene implementato come un singolo processomulti-threaded e viene eseguito sullo sfondo di ogni client Tivoli inuna TMR e in un Tivoli Management Server per quella TMR. Ildispatcher dell’oggetto è costituito da una serie di ORB (objectrequest broker), BOA e di servizi correlati. Il dispatcher dell’oggettoin esecuzione sul Tivoli Management Server fornisce ulterioriservizi, inclusa le risoluzione di eredità d’implementazione e lasicurezza.

Un nodo gestito Tivoli esegue lo stesso software su un server TMR.Da un nodo gestito è possibile eseguire il desktop Tivoli e gestiredirettamente altre risorse gestite Tivoli. Un nodo gestito ha unproprio serviziooserv che viene eseguito continuamente e checomunica con il serviziooserv sul server TMR. Un nodo gestitogestisce inoltre il database proprio del client. La differenza principaletra un nodo gestito e un server TMR è la dimensione del database.Inoltre, è impossibile disporre di un nodo gestito senza un serverTMR in una Tivoli Management Region.

Tivoli Management Framework per utenti non Tivoli

124 Versione 7.0

Considerazioni sull’installazioneWorkload Scheduler engine viene separato completamente da TivoliManagement Framework. Non si tratta di un’applicazione di TivoliManagement Framework. Tuttavia, il connettore TWS èun’applicazione Tivoli Management Framework. Il Il connettoreTWS è necessario se si desidera utilizzare Job Scheduling Console,la nuova GUI. Tivoli Workload Scheduler 7.0 include anche la GUIdi eredità, ma solo JS Console ha il supporto del fuso orario. Inoltre,JS Console è necessaria se si desidera utilizzare OPC ( OperationPlanning and Control) e del motore TWS dalla stessa interfacciautente.

Dove è possibile installare il client JS ConsoleJob Scheduling Console fornisce le funzionalità gcomposer egconman attraverso una reale interfaccia utente. Può essere installatosu Sun Solaris, AIX, HP-UX, Windows NT, 95 e 98. Non ènecessario che Tivoli Management Framework o Tivoli WorkloadScheduler siano installati sul client. Il solo prerequisito è che ilsistema client deve essere connesso tramite TCP/IP ad almeno unodei nodi che eseguono connettore TWS.

Dove è possibile installare il connettore TWSIl connettore TWS è un servizio Tivoli Management Framework checonsente ai client JS Console di comunicare con il motore TWS. Ilconnettore TWS può essere installato su sistemi Sun Solaris, AIX,HP-UX o Windows NT che devono essere anche un server TMR oun nodo gestito Tivoli.

Se si desidera installare il connettore TWS nel dominio TWS, manon ci sono TMR esistenti e non si ritiene opportuno implementareun ambiente di gestione Tivoli, è necessario installare TivoliManagement Framework come TMR unica (quindi installarlo comeserver TMR) su ogni nodo che eseguirà il connettore TWS.

E’ possibile installare il connettore TWS su workstation diverse dalgestore domini master. Questo consentirà di visualizzare la versionedelfile Symphony di questa particolare workstation. Ciò può essereimportante per utilizzare JS Console per gestire il database deiparametri locali oppure il comandosubmit direttamente sulla

Considerazioni sull’installazione

Migrazione

workstation piuttosto che inoltrarlo tramite il master. La workstationdeve essere un nodo gestito o un server TMR nell’area della politicaper installare i connettore su una workstation.

Installazione del connettore TWS sugli FTAUtenti dell’ambiente non Tivoli:

¶ quando si crea un FTA, verificare che il motore TWS vengainstallato prima dell’installazione del connettore TWS.

¶ Prima di cominciare, verificare che Tivoli ManagementFramework sia installato sull’FTA e che il sistema si trovinell’elenco di piattaforme supportate per connettore TWS(consultare “Piattaforme supportate” a pagina 81).

¶ Seguire le istruzioni sull’installazione descritte in “Installazionedel connettore TWS” a pagina 79.

Utenti dell’ambiente Tivoli:

¶ Generalmente, il gestore domini master di TWS si trova su unnodo gestito. E’ necessario installare prima le classi delconnettore Job Scheduling Services/TWS sul server TMR.

¶ E’ fondamentale non creare un’istanza su un nodo gestito chenon ha il motore TWS installato.

Tutti gli utenti:

¶ Durante il processo d’installazione del connettore TWS verràrichiesto il nome dell’istanza TWS. Questo nome verràvisualizzato nell’albero Job Scheduling di JS Console. Perevitare confusione, è necessario utilizzare un nome che include ilnome dell’FTA.

¶ Se si sta installando il connettore TWS su più FTA in una rete,ricordare che i nomi dell’istanza devono essere univoci sia nellarete TWS che nella TMR.

Considerazioni sull’installazione

126 Versione 7.0

Considerazioni master di backupSe si desidera installare il connettore TWS sul master di backup, nonesistono TMR e non si è interessati a implementare un ambiente digestione Tivoli, potrebbe essere necessario installare un nuovo serverTMR sul master di backup.

Se sul master di backup si installa un server TMR differente dalmaster, si raccomanda di abilitare le stesse voci del master, cioè:

¶ Avvio

¶ Livelli di verifica del database e di pianificazione

¶ Abilita fuso orario

Master non appartenenti alla schiera 1 in una reteesistente del Maestro

Se il proprio gestore domini master non viene eseguito su unapiattaforma supportata per installare la TMF e il connettore TWS esi desidera utilizzare Job Scheduling Console, è possibile scegliereuna delle seguenti opzioni:

¶ Spostare il gestore domini master su una delle piattaformesupportate.

¶ Creare un master di backup su una piattaforma supportata.

¶ NFS carica i database master per un FTA.

Spostamento del master di backupPer spostare il gestore domini master (da UNIX a UNIX):

1. Selezionare un FTA esistente nella rete o crearne uno. Se si creaun FTA, definirlo con Dipendenze Risolvi e Stato completoattivate.

2. Sul gestore domini master, comprimeremaestro/mozart/*emaestro/../unison/network/*.

3. Decomprimere questi file nell’FTA in directory con lo stessonome.

Considerazioni master di backup

Migrazione

4. Non copiare iparametrio parameters.KEYdalla home directoryoppure sostituire i parametri univoci per l’FTA. Creare unelenco di parametri da entrambi i sistemi, aggiungendo quellirichiesti all’FTA.

5. Sull’FTA, modificare il file globaloptsper modificare il nomedel master in quello dell’FTA.

6. Sul master precedente, utilizzare il comandoswitchmgr perconvertirlo nel nuovo master.

7. Cancellare la pianificazione esistentefinale nel giorno diproduzione corrente.

8. Aggiungere la pianificazionefinale al nuovo master (utilizzarecomposer “modify sched=oldmastername#final”

e modificare l’ID della workstation sulla linea dipianificazione).

9. Dopo il salvataggio e l’aggiunta, cancellare la pianificazioneoldmastername#final con il comando:composer “delete sched=oldmastername#final”

10. Inoltrare la nuova pianificazionefinale alla produzionegiornaliera.

11. Sul master precedente, modificare il fileglobaloptsper riflettereil nome del nuovo master.

Nota: Non è necessario modificare le opzioni globali per ogniworkstation nella rete. I nodi riconosceranno il nuovomaster la volta successiva in cui Jnextday il master liinizializza.

Creazione di un master di backupPer creare un master di backup:

1. Installare Tivoli Management Framework. Consultare ilManualeper l’installazione Tivoli Enterpriseper riferimento.

2. Installare il motore TWS. Consultare “Installazione del motoreTWS su Windows NT” a pagina 23 o “Installazione del motoreTWS su UNIX” a pagina 47.

Master non appartenenti alla schiera 1 in una rete esistente del Maestro

128 Versione 7.0

3. Installare il connettore TWS. Consultare “Installazione delconnettore TWS” a pagina 79.

4. Personalizzare la workstation con TWS security e le opzionilocali. Consultare “Impostazione di TWS Security” a pagina 65 e“Argomenti ulteriori per personalizzare TWS” a pagina 113.

5. Definire la workstation nella rete TWS. Utilizzare ilcomandocpunamedel Composer o la finestraCrea Workstationin Job Scheduling Console. Definirla con Risolvi dipendenze eStato completo abilitate. Consultare ilManuale di riferimentoTivoli Workload Scheduleroppure ilManuale per l’utente TivoliWorkload Scheduler.

Caricamento dei database del gestore domini masterE’ possibile che NFS cariche i seguenti database master su un FTAeseguito su una piattaforma supportata:

¶ /usr/lib/maestro/mozart/globalopts(copia attiva)

¶ /usr/lib/unison/network/cpudata

L’FTA deve avere abilitate Stato completo e Risolvi dipendenzenella definizione di workstation.

Prima di caricare i database, verificare che il file system contenentele directory richieste sia stato incluso al file/etc/exportssullaworkstation master. Se si sceglie di controllare la disponibilità delfile system, inserire le voci appropriate nel file/etc/hostso/etc/netgroupnel master.

Il punto di caricamento sull’FTA deve essere lo stesso del master. Adesempio, sull’FTA:

cd twshome/etc/mount mastername:mozart mozart/etc/mount mastername:../unison/network ../unison/network

Affinché i database siano caricati automaticamente, è possibileimmettere i caricamenti nel file/etc/checklist.

Migrazione

Se si utilizza questa soluzione, verificare che i parametri deldatabase nell’FTA non siano una copia del Master ma una copialocale. Questo diviene un problema se si utilizzano i parametri comeparte delle definizioni del lavoro (nell’attività o nel nome di login),poiché all’ora Jnextday tutti i parametri, cui è stato fatto riferimentocon il simbolo^(carat) nelle definizioni del lavoro, vengono espansinel database dei parametri nel Master. Esistono due possibilisoluzioni per questo problema:

¶ Creare uno script che carichi e modifichi i valori del parametrodall’FTA al master. Eseguire questo script appena primaJnextday. Se Jnextday dipende da esso, si avrà la certezza che iparametri verranno caricati con esito positivo prima che Jnextdayimposti la produzione per il giorno successivo.

¶ Sulla cpu master, spostare il database dei parametri sulladirectorymozart. Creare un collegamento dal master per la homedirectory. Quindi, sull’FTA creare un collegamento dal databasedei parametri inmozartsu twshome.

Se si desidera abilitare la funzione del fuso orario in Job SchedulingConsole, è necessario anche modificare il file localeglobaloptssull’FTA per impostare la voceAbilita fuso orario.

Master di backup non appartenenti alla schiera 1 inuna rete esistente del Maestro

E’ possibile mantenere il master di backup esistente se esso non èsupportato nelle piattaforme (schiera 1). Ricordare, tuttavia, che ciòimpedirà di utilizzare Job Scheduling Console in quell’ambiente.Seguire le istruzioni della sezione precedente per decidere secommutare i sistemi.

Esecuzione di più finestre in JS ConsoleSe sono necessarie più di sette finestre JS Console attive su ogniclient, installare un’altra istanza di Job Scheduling Console su quelsistema. Durante l’installazione, verificare di aver selezionato unaubicazione univoca per la seconda istanza. Su Windows NT, anchel’ubicazione della shortcut deve essere univoca.

130 Versione 7.0

Attivare un file Security esistentePer preservare la struttura di un file Security esistente durante lamigrazione su TWS 7.0 è necessario creare un amministratore Tivoli(TME) nel server Tivoli Management Framework per ognidefinizione di sicurezza disponibile del Maestro, quindi includereuna definizione per questo amministratore nel file Security.Consultare la documentazione Tivoli Management Framework perdettagli sulla creazione di un amministratore TME. Consultare“Impostazione di TWS Security” a pagina 65 oppure ilManuale perl’utente Tivoli Workload Schedulerper dettagli sul modo in cuimodificare il file Security.

Aggiunta di amministratori TMEConsiderare di dover spostare la propria rete del Maestro su TWS7.0 e che il sistema su cui si trova attualmente il gestore dominimaster sia una delle piattaforme supportate. Si desidera installare ilconnettore TWS su esso, in modo da avere una serie di client JSConsole. Installare prima Tivoli Management Framework. Supporredi installare un server TMR.

Il file Security corrente sul master è il seguente:############################################################ Security File############################################################ (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE# MASTER DOMAIN MANAGERuser mastersm cpu=$master + logon=maestro,rootbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job access=@schedule access=@resource access=@prompt access=@file access=@calendar access=@cpu access=@parameter name=@ x 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.

Attivare un file Security esistente

Migrazione

user sm logon=maestro,rootbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job cpu=$thiscpu access=@schedule cpu=$thiscpu access=@resource cpu=$thiscpu access=@prompt access=@file access=@calendar access=@cpu cpu=$thiscpu access=@parameter cpu=$thiscpu

x name=r@ access=@end###########################################################

Supporre di voler fare utilizzare JS Console a entrambi gli utenti.Dopo aver installato il software TMF creare, nel desktop Tivoli, unulteriore amministratore TME (oltre quello di default creato dalprocesso di installazione) per ogni utente del Maestro. Uno sichiameràmastersm, l’altro sm. Quindi, aggiungere le rispettivedefinizioni in modo che il file Security appaia nel modo seguente:############################################################ Security File############################################################ (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE# MASTER DOMAIN MANAGERuser mastersm cpu=$master + logon=maestro,rootbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job access=@schedule access=@resource access=@prompt access=@file access=@calendar access=@cpu access=@parameter name=@ x name=r@ access=@userobj cpu=@ + logon=@ access=@end############################################################ (2) TME ADMINISTATOR DEFINITION FOR MAESTRO OR ROOT USERSLOGGED IN ON THE# MASTER DOMAIN MANAGERuser mastersm cpu=$framework + logon=mastersmbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES

132 Versione 7.0

# ---------- ------------ ----------------------job access=@schedule access=@resource access=@prompt access=@file access=@calendar access=@cpu access=@parameter name=@ x name=r@ access=@userobj cpu=@ + logon=@ access=@end####################################################################################################################### (3) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.user sm logon=maestro,rootbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job cpu=$thiscpu access=@schedule cpu=$thiscpu access=@resource cpu=$thiscpu access=@prompt access=@file access=@calendar access=@cpu cpu=$thiscpu access=@parameter cpu=$thiscpu

x name=r@ access=@end##############################################################(4) TME ADMINISTRATOR DEFINITION FOR MAESTRO ORROOT USERS LOGGED IN ON ANY

# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.user sm cpu=$framework + logon=smbegin# OBJECT ATTRIBUTES ACCESS CAPABILITIES# ---------- ------------ ----------------------job cpu=$thiscpu access=@schedule cpu=$thiscpu access=@resource cpu=$thiscpu access=@prompt access=@file access=@calendar access=@cpu cpu=$thiscpu access=@parameter cpu=$thiscpu

x name=r@ access=@end##########################################################

Migrazione

Il nuovo file Security concede gli stessi privilegi agli utenti d’origineanche su Job Scheduling Console.

Inoltre, sul server TMR è possibile aggiungere due nuovi login perl’amministratore TMEmastersm:

maestro@rome.production.commaestro@london.production.com

In questo modo ogni utente autorizzato che si collega aromeolondoncomemaestro otterrà i privilegi concessi amastersm.

Gestione sicurezzaLe modifiche apportate al file Security diventano effettive quandoviene arrestato e riavviato uno dei seguenti programmi WorkloadScheduler:¶ conman¶ gconman¶ composer¶ gcomposer¶ Connettore TWS

Uscire dai programmi. La volta successiva in cui vengono eseguiti,verranno riconosciute le nuove definizioni sul file security. Per iconnettori TWS, utilizzare il comandowmaeutil per arrestarli.Verranno riavviati automaticamente con un aggiornamento dellequery in Job Scheduling Console.

Arresto del connettore per implementare le modificheIl connettore TWS si avvia automaticamente al momento dell’inviodi un comando da JS Console. Tuttavia, è necessario arrestarlomanualmente. Su Windows NT, è necessario arrestare il connettoreTWS prima di eseguire ilcomandomakesec. Su UNIX, è possibilearrestarlo prima o dopo l’esecuzione del comandomakesec.

Utilizzare il comandowmaeutil per arrestare il connettore TWS.

134 Versione 7.0

Esecuzione di WMAEUTILPer eseguire il comando wmaeutil:

1. Impostare l’ambiente Tivoli:

¶ Da una riga comandi UNIX: ./etc/Tivoli/setup_env.sh

2. Immettere il seguente comando:wmaeutil ALL -stop

Restrizioni sulla GUI precedenteLa GUI precedente non ha il supporto del fuso orario. Dalla GUIprecedente, non è possibile modificare una workstation o unapianificazione che abbia il supporto del fuso orario aggiunto dallaCLI (command line interface) o dalla JS Console.

Utilizzo della GUI precedente su AIX 4.2Se si esegue AIX Versione 4.2, potrebbe essere necessario installarela patchxlC.rte.3.6.6.0per utilizzare la GUI precedente.

Per sapere se installare questa patch, eseguire questo comando:lslpp -l xlC.rte

Il comando dovrebbe restituire le informazioni seguenti:Fileset

Path:/usr/lib/objrepos xlC.rteLivello

3.6.6.0Stato COMMITTEDDescrizione

C Set ++ per AIX Application Runtime

Se il Livello è inferiore a 3.6.6.0, è necessario applicare la patch.

Gestione sicurezza

Migrazione

Considerazioni sul fuso orarioQuello che segue è il metodo corretto di implementazione:

1. Caricare TWS Versione 7.0.

L’impostazione di default è sul fuso orario non abilitato(attivazione fuso orario in globaloptions). Il database consentiràai fusi orari di essere specificati per le workstation, ma non sulleore di avvio e tempo limitenei flussi di lavoro del database. Lacreazione del piano (Jnextday) ignora i fusi orari presenti neldatabase. Non sarà possibile specificare i fusi orari in un puntoqualsiasi del piano.

2. Definire i fusi orari della workstation.

Impostare il fuso orario della workstation master, del master dibackup e di ogni FTA in un fuso orario diverso dal master. Nonsarà possibile attivare il fuso orario nel database per le ore diavvio e di tempo limite. Non saranno attivi i fusi orari in nessunpunto del piano, perché la voceabilita fuso orario inglobaloptionsè ancora impostata su NO.

3. Quando i fusi orari della workstation sono stati impostaticorrettamente, impostareAbilita fuso orario su YES nel fileglobaloptions. Questa impostazione e la definizione di fusoorario nella workstation master abilitano la rete TWS per trarrevantaggio dal supporto del fuso orario.

A questo punto, tutti gli utenti potranno utilizzare i fusi orari inun punto qualsiasi del database, nonostante debbano attenderel’esecuzione successiva di Jnextday per utilizzarli sulle ore diavvio e tempo limite. Fino a che non viene eseguito Jnextday,essi non saranno in grado di utilizzare i fusi orari del piano. Lavolta successiva in cui verrà eseguito Jnextday, i fusi orariverranno portati sul piano e JS Console e il backendconsentiranno le specifiche del fuso orario in un punto qualsiasidel piano.

4. Cominciare ad utilizzare i fusi orari sulle orestart e until quandosono necessari.

E’ possibile utilizzare tutti i riferimenti dei fusi orari nel databasee nel piano sia in JS Console che nella CLI.

Considerazioni sul fuso orario

136 Versione 7.0

Per gli FTA MPE e per gli LFTA AS400 (Versione 6.1) èpossibile utilizzare le informazioni sul fuso orario solo da JSConsole.

Propagazione delle Preferenze dell’utente agli altriutenti (Personalizza visualizzazioni/Query)

Questa opzione, disponibile in Job Scheduling Console, consenteall’utente di JS Console di copiare altre preferenze dell’utente. E’possibile anche diffondere una serie di preferenze a più utenti.

Le preferenze dell’utente vengono archiviate in un file denominatoGlobalPreferences.ser. Il file contiene i nomi e i dettagli, inclusi ifiltri, di tutte le query (o elenchi) salvati durante una sessione. Tuttele volte in cui si chiude JS Console, GlobalPreferences vieneaggiornato con le query salvate in, o cancellate dall’albero JobScheduling.

GlobalPreferences viene salvato localmente in una directorydell’utente in...\JSConsole\dat\.tmeconsolesu Windows o in$HOME/.tmeconsolesu UNIX. La directory dell’utente ha un nomecomposto che corrisponde a:

¶ Al nome dell’Amministratore TME associato al connettore TWSa cui accede l’utente. Viene seguito dal segnoat (@).

¶ Al nome del sistema che esegue il connettore TWS seguito dalsegnoundescore(_).

¶ Alle impostazioni regionali del sistema operativo su cui èinstallato il connettore TWS. L’ID viene modificato in mododinamico se l’utente si collega allo stesso connettore e trova chele impostazioni regionali sono state modificate.

Nota: I primi due sono i nomi immessi nella finestra Avvia JobScheduling Console per avviare JS Console.

Ad esempio, supporre che, per avviare JS Console, ci si colleghi perla prima volta al sistemafta12,su cui l’amministratore TMEtws12admha installato il connettore TWS. Una directory dell’utente

Considerazioni sul fuso orario

Migrazione

denominatatws12adm@fta12_en(doveen indica l’impostazioneregionale English) viene creata con il percorso descritto nellaworkstation.

Ogni volta in cui ci si collega a un connettore differente, vieneaggiunta una nuova directory dell’utente. Ogni volta in cui si chiudeJS Console, viene creato o aggiornato unGlobalPreferences.sernelladirectory dell’utente che corrisponde alla connessione.

Quando gli utenti si collegano al connettore per la prima volta, lafinestra Apri ubicazione chiede se si desidera utilizzare il fileGlobalPreferences.seresistente da una unità di rete connessa o da unURL. Se si desidera propagare una serie specifica di query ai nuoviutenti, rendere disponibile primaGlobalPreferences.ser, quindichiedere all’utente di specificare il file o l’URL nella finestra Apriubicazione. Se si desidera propagare un file di preferenza agli utentiesistenti, fare in modo che vengano sostituiti i propriGlobalPreferences.sercon quelli preparati.

Nota: Esiste un fileGlobalPreferences.serdifferente in...\JSConsole\dat\.tmeconsole\TivoliConsolesu Windows o in$HOME/.tmeconsole/TivoliConsolesu UNIX. Questo filecontiene preferenze che riguardano solo la presentazione JSConsole e che non devono essere propagate.

Backout di un database espansoMaestro 6.0 introduce l’uso dei database espansi. Se si utilizzanoancora reti Maestro 5.x e si desidera migrarle in TWS Versione 7.0,non è necessario espandere i database, a meno che non si desiderifarlo. Consultare “Creazione del database” a pagina 17 perspiegazioni relative a come espandere il database esistente.

Se si desidera un backout di un database espanso, è possibilescegliere uno dei due metodi riportati di seguito.

¶ Utilizzare questo metodo se non sono stati creati o modificatioggetti di pianificazione dal momento in cui è stato espanso ildatabase. Se gli oggetti sono stati creati, possono essere aggiuntimanualmente al database, dopo essere stati riportati allo stato

Propagazione delle preferenze dell’utente agli altri utenti (Personalizzavisualizzazione/Query)

138 Versione 7.0

non espanso. Se sono state apportate delle modifiche, essi nondevono essere riapplicati. Seguire queste istruzioni:

1. Sul master, ripristinare i file di backup nella directorymozart.oldsulle directorymozarte unison/network:

a. Spostare i seguenti file nella directoryunison/network:

v cpudata

v cpudata.key

v userdata

v userdata.key

b. Spostare tutti gli altri file sulla directorymozart.

2. Verificare che laversione espansa di Opzioni globalisiaimpostata su NO.

3. Verificare che i nomi della cpu inglobaloptse localoptssono di un massimo di otto caratteri.

¶ Utilizzare questo metodo se sono stati creati o modificati oggettidi pianificazione dal momento in cui è stato espanso il database.Utilizzare questo metodo anche se si desidera il backout deldatabase espanso e se gli oggetti di pianificazione non hannonomi estesi.

1. Immettere i seguenti comandicomposerper creare i filecontenenti tutte le informazioni sul database per gli oggetti dipianificazione. I file verranno creati solo se quegli oggettiesistono nel database:crea cpu.txt da cpu=@

crea jobs.txt da jobs=@#@

crea sched.txt da sched=@#@

crea cal.txt da calendari

crea prompt.txt da prompt

crea parms.txt da parms

crea param.txt da parametri

2. Spostare i file di oggetto nelle directorymozarteunison/mozartin una directory temporanea. Il fileglobaloptse i file runmsgnorimangono nella directorymozart. In

Backout di un database espanso

Migrazione

globaloptsverificare che il nome della cpu contenga unmassimo di otto caratteri e che laversione espansasiaimpostata su NO. Inoltre, verificare che inlocaloptsil nomedella cpu abbia un massimo di otto caratteri.

3. Modificare i seguenti file creati nella prima istruzione:

v cpu.txt

v jobs.txt

v sched.txt

Modificare tutti i nomi cpu, dominio, lavoro, pianificazione eutente in modo che contengano un massimo di otto caratteri.Inoltre verificare la lunghezza dei comandi e dei nomi file.

4. Rinominare i seguenti file nella directoryunison/network:

v cpudata

v cpudata.key

v userdata

v userdata.key

5. Immettere i seguenti comandi composer per popolare ilnuovo database non espanso con gli oggetti di pianificazione:aggiungi cpu.txt

aggiungi jobs.txt

aggiungi sched.txt

sostituisci cal.txt

sostituisci prompt.txt

sostituisci parms.txt

sostituisci param.txt

6. Rinominare il file Symphony prima di avviare Jnextday.

Backout di un database espanso

140 Versione 7.0

Migrazione su Windows NTSe su workstation Windows NT si sta effettuando una migrazioneTWS 7.0 dal Maestro 5.2, effettuare il login come utentemaestro.Se si sta effettuando una migrazione dal Maestro 6.x, effettuare illogin comeAmministratore .

Migrazione dal Maestro 5.2 su agent Windows NTSe si sta effettuando una migrazione dal Maestro 5.2, verificare che iseguenti programmi abbiano i livelli minimi di revisione indicati diseguito:

Programma Revisione

mailman 3.34.1.17.1.1

writer 3.31.1.11.1.1

Per ottenere queste informazioni, eseguire i programmi con l’opzione-v come riportato di seguito:mailman -v

writer -v

Se i livelli di revisione sono inferiori a questi valori, è necessarioapplicare una patch5.2-MAE-0054 (correzione dell’ordine dei byte)prima di effettuare la migrazione su TWS 7.0. Questa patch consenteun’esecuzione corretta di Batchman quando viene utilizzato dopo alamigrazione.

Migrazione su Windows NT

Migrazione

142 Versione 7.0

Creazione di una rete con MPE

Quest’appendice descrive le operazioni e i requisiti di configurazionedelle reti Tivoli Workload Scheduler/Maestro contenenti una serie dicomputer MPE, UNIX e Windows NT. Le reti sono conformi allagerarchia TWS standard delle cpu del master, dell’FTA (slave) edell’SA, caratterizzate nel modo seguente:

¶ La workstation master può essere un computer MPE iX*, UNIXo Windows NT. Essa costituisce l’hub amministrativo in unarete. Contiene i file di pianificazione del master Maestro edeffettua tutte le elaborazioni di preproduzione (inizio del giorno)e di postproduzione (fine del giorno) per la rete. All’inizio di unnuovo giorno di produzione, il master elabora le propriepianificazioni e quelle delle cpu di SA. Esso avvia i lavori edinvia richieste per l’esecuzione dei lavori su SA. Quandovengono utilizzati master UNIX o NT, il master può essereanche il gestore dominio Master. *MPEiX non può essere unmaster su un computer Windows NT poiché non esiste undatabase USERDATA equivalente sul prodotto MPE in cuiarchiviare le definizioni della password dell’utente NT.

¶ Le cpu slave MPE sono l’equivalente di FTA UNIX e WindowsNT. Per funzioni amministrative, esse si trovano sullaworkstation master. All’inizio di un nuovo giorno di produzione,essi elaborano pianificazioni e avviano lavori propri.

¶ Le cpu dell’SA sono computer UNIX o Windows NT. Per scopiamministrativi, esse si trovano sulla workstation master.All’inizio di un nuovo giorno di produzione, eseguono lavori

Creazione

diunarete

solo in risposta all’avvio di richieste dal gestore dominio(Gestore dominio master per default).

Considerazioni sulla reteE’ necessario consultare approfonditamente quest’appendice prima didecidere di configurare una rete TWS/Maestro mista. Segue unriepilogo delle considerazioni di base:

¶ Le definizioni dell’oggetto e la pianificazione degli slave e degliFTA devono essere effettuate sul gestore dominio master se glislave e gli FTA non sono la stessa piattaforma del master.

¶ Se necessario, il gestore dominio master in standby deve esserela stessa piattaforma del gestore dominio master.

¶ Le considerazioni sulla sicurezza sono diverse per ognipiattaforma: MPE, UNIX e Windows NT.

¶ I gestori dominio master UNIX ed NT supportano un layoutgerarchico in cui possono trovarsi più gestori dominio secondari,con ogni tipo di agent di piattaforma supportato. I master MPEsupportano solo una struttura ‘flat”. I sistemi MPE possonoessere utilizzati come FTA (slave) in ogni layout di dominiogerarchico.

¶ Una cpu master MPE può collegarsi agli slave MPE tramite NSo TCP/IP. Una cpu master UNIX o Windows NT utilizza soloTCP/IP.

Considerazioni sulla pianificazioneTenere presente che:

¶ Ogni combinazione in una rete TWS/maestro, che include unaworkstation MPE, richiede che le controparti UNIX/NT operinoin modalità non espansa (impossibile utilizzare nomi oggetto dipianificazione con più di otto caratteri).

¶ Poiché la sicurezza dell’FTA di UNIX o di Windows NT èindipendente dal master MPE, può essere impostata in modalitàstato completo ed essere utilizzata per la gestione centrale dellaconsole della rete. Ciò consentirà agli utenti di trarre vantaggiodalle interfacce grafiche e fornirà serie di comandi più flessibili

Creazione di una rete con MPE

144 Versione 7.0

ed efficaci. Tuttavia, l’FTA è ancora soggetto a determinatelimitazioni per determinati comandi Conman. Queste limitazionisono:

v Impossibile inoltrare i lavori utilizzando il comandoCONMAN SUBMIT JOB.

v Impossibile inoltrare le pianificazioni utilizzando il comandoCONMAN SUBMIT SCHEDULE.

v Impossibile rieseguire i lavori utilizzando le opzioniCONMAN RERUN ;FROM e ;FILE.

v Impossibile aggiungere dipendenze prompt predefinite (oglobali) con il comando ADDDEP.

v Impossibile utilizzare il comando CONMAN ADDDEP peraggiungere dipendenze prompt globali (predefinite).

v Impossibile utilizzare il comando CONMAN DISPLAY perlavori e pianificazioni.

¶ La funzionedocommandè ampiamente funzionale in UNIX eWindows NT per le definizioni del lavoro e per il comandoconman submit. Questa funzione non è supportata nell’MPE.

¶ Il composer di UNIX e Windows NT è in grado di aggiungere edi modificare tutti gli oggetti di pianificazione (inclusi lavori epianificazioni) da un singolo file di modifica.

¶ Le dipendenze INET non sono consentite per il master MPE. Ledipendenze INET, comunque, possono fare riferimento agli FTAMPE se il gestore domini viene eseguito su UNIX o suWindows NT.

InstallazioneQuesto manuale contiene anche le istruzioni relative all’installazioneper TWS su UNIX e su Windows NT. Per installare il Maestro perMPE per la prima volta, fare riferimento alla sezione 2 delMaestroUser Guide for the MPE System User.

Considerazioni sulla rete

Creazione

diunarete

Installazione e configurazioneQuesta sezione mette in evidenza le istruzioni necessarie perinstallare reti TWS/Maestro dopo l’installazione con agent UNIXsotto MPE, e agent MPE sotto workstation master UNIX o WindowsNT.

Nota: Per dettagli relativi a comandi e transazioni specifiche,consultare questo manuale e ilMaestro User Guide for theMPE System User.

Impostazione di un agent UNIX con il master MPESul master MPE, utilizzare il programma ARRANGER per leseguenti operazioni:

1. Utilizzare la transazione ACPU per creare una definizione cpuper cpu UNIX nella rete.

2. Utilizzare la transazione CSYS per definire questa cpu comemaster.

3. Utilizzare la transazione ALNK per definire i seguenticollegamenti:

a. Da master a master: definire un collegamento con comandiTCP/IP.

b. Da master a UNIX: definire un collegamento con i comandiTCP/IP.

4. Dopo aver completato le attività dell’agent UNIX riportate diseguito, gli agent verranno inizializzate e avviate all’esecuzionesuccessiva di Jnextday sul gestore dominio master.

Su ogni FTA e ogni SA UNIX , svolgere le seguenti operazioni:

1. Modificare i file di opzione locali e globali per soddisfare leproprie richieste. I valori di default, adatti alla maggior partedelle applicazioni, vengono inseriti dai programmi Setup eCustomize.

2. Modificare e installare il file Security. Se si desidera, è possibilesvolgere questa operazione su un computer e copiare il file sututti gli altri sistemi UNIX.

Installazione e configurazione

146 Versione 7.0

3. Emettere il comando StartUp su ogni agent UNIX per avviare ildaemon netman (se non già avviato).

Impostazione di un FTA MPE con UNIX o Windows NTUna rete TWS contenente computer MPE deve essere installata inmodalità “non espansa”. Dopo aver installato il software, seguire leistruzioni riportate di seguito per configurare ogni cpu nella rete.

Su master UNIX o Windows NT, seguire queste istruzioni:

1. Utilizzare la GUI JS Console o CLI composer per crearedefinizioni di workstation per tutte le workstation. Le definizioniincludono anche le informazioni sul collegamento (combinazionedella transazione ACPU e ALNK di Arranger).

2. Modificare i file di opzione globali per soddisfare le proprierichieste. Le seguenti opzioni globali prendono il posto deiparametri ARRANGER CTP1 per gli slave MPE. Esse non sitrovano per default nel file globalopts e, se necessario,dovrebbero essere aggiunte:

modalità regole={yes|no}Sostituisce la modalità di controllo CTP1-Complete. Seviene impostato suyes, è necessario che anchebatchman schedulesia impostato suyes.

tutti gli userjobs in userjobs schedule={yes|no}Sostituisce tutti gli userjobs CTP1-Place nellapianificazione USERJOBS. E’ necessario che siaimpostato suno se rules modeè impostato suyes.

impostare mpe job pri su zero={yes|no}Sostituisce la priorità MPE CTP1-Force con 0 per tuttigli userjobs. E’ necessario che sia impostato suno setutti gli userjobs in userjobs schedulesono impostati suyes.

pianificazione batchman={yes|no}Sostituisce la priorità 10 CTP1-Assign per lepianificazioni create da Batchman. Questo interessaanche le workstation UNIX e Windows NT.

Creazione

diunarete

3. Dopo aver completato le attività dell’agent MPE riportate diseguito, gli agent verranno inizializzate e avviate al momentodell’esecuzione successiva di Jnextday sul gestore dominiomaster.

Su ogni slave MPE, utilizzare il programma ARRANGER per leseguenti operazioni:

1. Utilizzare la transazione per creare le definizioni per questa cpu eper il master.

2. Utilizzare le transazioni CSYS per identificare questa cpu e ilmaster.

3. Utilizzare la transazione ALNK per definire un collegamento daslave a master contenente i comandi TCP/IP.

4. Utilizzare le transazioni CTP2 e CTP3 per definire i parametriCONMAN e BATCHMAN.

5. I comandi Mstream o stream consentono a un lavoroJBATCHMN.MAESTRO.CCC di attivare il processo NETMAN.Per essere avviato con esito positivo e inizializzato con ilTCP/IP, il processo NETMAN deve già essere in esecuzionesullo slave MPE.

Differenze operative tra piattaformeQuesta sezione descrive le eccezioni che si applicano in una rete diworkstation MPE, UNIX e Windows NT con una workstation MPE,UNIX o Windows NT definita come master. Per ulterioriinformazioni sulle operazioni di rete, fare riferimento alManuale diriferimento Tivoli Workload Scheduler, al Manuale per l’installazionee la pianificazione TWS, e il Maestro User Guide for the MPESystem User(disponibile da ROCsoftware).

Sul master MPE

Arranger e Composer¶ Tutte le definizioni dell’oggetto e la pianificazione per SA e

FTA UNIX devono essere effettuate con COMPOSER eARRANGER sul master MPE.

148 Versione 7.0

¶ L’MPE COMPOSER non supporta la funzionedocommandnelle istruzioni di lavoro per pianificazioni eseguite su SA edFTA UNIX e Windows NT.

¶ Le opzioni di recupero per lavori UNIX e Windows NT devonoessere documentate con la transazione ARRANGER XJOB.

¶ Nel linguaggio di pianificazione MPE,scriptname non è unaparola chiave valida. Utilizzare, invece,jobfilename per definirescript di lavoro UNIX e Windows NT. Ad esempio:jobfilename " pathname" streamlogon user

Conman¶ L’opzione docommandnon è disponibile nel comandosubmit

per immettere i comandi per l’esecuzione su una cpu UNIX oWindows NT.

¶ I parametri Wildcard e Selectionset per determinati comandiconman non sono supportati dal master MPE ma possono essereutilizzati da uno stato completo di FTA UNIX.

Su FTA UNIX

ComposerE’ possibile utilizzare Composer solo per documentare, modificare ecancellare i parametri del Maestro (parms) che sono locali su ogniworkstation.

ConmanLe seguenti operazioni CONMAN non sono consentite:¶ Inoltrare i lavori utilizzando il comando CONMAN SUBMIT

JOB.¶ Inoltrare le pianificazioni utilizzando il comando CONMAN

SUBMIT SCHEDULE.¶ Aggiungere dipendenze prompt predefinite (o globali) con il

comando ADDDEP.¶ Utilizzare le opzioni ;FROM e ;FILE nel comando RERUN.¶ Visualizzare i lavori e le pianificazioni utilizzando il comando

DISPLAY.

Differenze operative tra piattaforme

Creazione

diunarete

Su master UNIX o Windows NT

Composer¶ Tutte le definizioni e le pianificazioni dell’oggetto per gli slave

MPE devono essere effettuate con JS GUI Console o nelcomposer CLI su master UNIX o Windows NT.

¶ Per una documentazione automatica relativa al lavoro,l’istruzione del lavoro della lingua di pianificazione UNIX eWindows NT accetta parole chiave specifiche MPE e i nomiutente e file MPE. Ad esempio:jobfilename file.grp.acct [streamlogon user.acct[, grp]]

oisuserjob [= jobname] streamlogon user.acct[, grp]

¶ La parola chiaveopensdel linguaggio di pianificazione UNIX eWindows NT accetta i nomi file MPE. Ad esempio:opens [ cpu#]" pathname"| file.grp.acct[( qualifiers)] [,...]

Conman¶ Il comando showjob visualizza informazioni specifiche per MPE:

[userjob]

>> alias è

>> rieseguire come

¶ Il comandosubmit docommandnon è valido se indirizzato auna cpu MPE, anche se può essere eseguito su master UNIX oWindows NT.

Su slave MPE

ArrangerLe uniche transazioni valide ARRANGER sono: CTP2, CTP3,xCPU, xLNK, xPRM, xPAS, xSYS.

ComposerE’ impossibile eseguire il COMPOSER con esito positivo.

150 Versione 7.0

ConmanLe seguenti operazioni CONMAN non sono consentite:¶ Inoltrare i lavori utilizzando il comando CONMAN SUBMIT

JOB.¶ Inoltrare le pianificazioni utilizzando il comando CONMAN

SUBMIT SCHEDULE.¶ Aggiungere dipendenze prompt predefinite (o globali) con il

comando ADDDEP.¶ Utilizzare le opzioni ;FROM e ;FILE nel comando RERUN.¶ Visualizzare i lavori e le pianificazioni utilizzando il comando

DISPLAY.

Creazione

diunarete

152 Versione 7.0

Glossario

Metodo di accessoUn eseguibile utilizzato dagli XA (extended agent) per connettersi e controllarel’esecuzione del lavoro su altri sistemi operativi (ad esempio, MVS) e applicazioni(ad esempio, Applicazioni Oracle, Peoplesoft e Baan). Il metodo di accesso deveessere specificato nella definizione di workstation per l’XA (extended agent).

BatchmanUn processo avviato all’inizio di ogni giorno di elaborazione TWS per avviare ilavori secondo le informazioni contenute nel file symphony.

CalendarUn oggetto definito nel database Tivoli Workload Scheduler contenente un elenco didate di pianificazione. Poiché si tratta di un oggetto univoco definito nel database,può essere assegnato a più flussi di lavoro. L’assegnazione di un calendario ad unflusso di lavoro causa l’esecuzione del flusso di lavoro nei giorni specificati nelcalendario. Notare che un calendario può essere utilizzato come un ciclo diesecuzione a inclusione o a esclusione.

ConmanUn’applicazione della riga comandi di eredità per la gestione dell’ambiente diproduzione. Conman (Console Manager) esegue queste attività: avvia e arresta iprocessi di produzione, modifica e visualizza le pianificazioni e i lavori nel piano econtrolla il collegamento della workstation in una rete.

ComposerUn’applicazione della riga comandi di eredità per la gestione delle definizioni deipropri oggetti di pianificazione nel database.

DatabaseUn database che contiene tutte le definizioni create per gli oggetti di pianificazione(ad esempio lavori, flussi di lavoro, risorse, workstation, ecc.). Inoltre contiene altreinformazioni importanti come statistiche di esecuzione del lavoro o del flusso dilavoro, informazioni sull’ID utente che ha creato l’oggetto e la data dell’ultima

Glossario

modifica dell’oggetto. Al contrario, il piano contiene solo quei lavori e flussi dilavoro the (inclusi gli oggetti dipendenti) pianificati per l’esecuzione dellaproduzione quotidiana.

Tempo limiteL’ultima ora in cui è possibile avviare l’esecuzione di un lavoro o di un flusso dilavoro. Questa corrisponde all’ora Until delle versioni precedenti del Maestro.

DipendenzaUn prerequisito che deve essere soddisfatto prima che l’esecuzione di un lavoro oflusso di lavoro possa procedere. Il numero massimo di dipendenze consentite perun lavoro o flusso di lavoro è 40. I quattro tipi di dipendenze utilizzate da TivoliWorkload Scheduler sono Dipendenze di successione, risorsa, file e prompt.

DominioUn gruppo denominato di workstation TWS, composto da uno o più agent e da unGestore dominio con funzione di hub di gestione. Tutti i domini hanno un dominioparent, tranne il dominio master.

Gestore dominio (DM)L’hub di gestione in un dominio Tivoli Workload Scheduler. Tutte le comunicazionida e verso gli agent nel dominio vengono instradate tramite il Gestore dominio.

DurataIl tempo previsto per il completamento del lavoro. Nella visualizzazione Tabellaorari dei lavori nel database, la durata viene rappresentata da una barra blu chiaro alcentro della barra delle attività o da un diamante blu chiaro.

Prima ora di avvioL’ora prima della quale non è possibile avviare il lavoro o il flusso di lavoro. Laprima ora di avvio è una stima basata sull’esperienza precedente dell’utente cheesegue il lavoro o il flusso di lavoro. Comunque, il lavoro o il flusso di lavoro puòiniziare dopo l’ora specificata ammesso che siano state soddisfatte tutte le altredipendenze. Nella tabella orari, l’ora di avvio viene rappresentata dall’inizio(margine sinistro) della barra delle attività blu navy. Per le istanze di lavoro, l’ora diavvio calcolata da OPC viene rappresentata da una barra blu chiaro. Vedere anche“Ora di avvio reale” e “Ora di avvio pianificata”.

Ciclo di esecuzione ad esclusioneUn ciclo di esecuzione che specifica i giorni in cui non è possibile eseguire unflusso di lavoro. I cicli di esecuzione di esclusione hanno la precedenza sui cicli diesecuzione di inclusione.

154 Versione 7.0

Database espansoUn database che consente nomi più lunghi per gli oggetti del database come ilavori, flussi di lavoro, workstation, domini e utenti. I database espansi vengonoconfigurati utilizzando il comando dbexpand oppure come un’opzione durantel’installazione. Non espandere il database prima di aver capito le implicazioni e glieffetti di questo comando.

XA (Extended agent)Utilizzato per integrare la funzione di controllo del lavoro di Tivoli WorkloadScheduler con altri sistemi operativi (ad esempio, MVS) e applicazioni (ad esempio,Oracle Application, Peoplesoft e Baan). Gli agent estesi utilizzano script chiamatimetodi di accesso per comunicare con i sistemi esterni.

Lavoro esternoUn lavoro da un flusso di lavoro che è predecessore di un lavoro in un altro flussodi lavoro. Un lavoro esterno viene rappresentato da un’icona place holder nellavisualizzazione Grafica del flusso di lavoro.

FTA (Fault-tolerant agent)Una workstation agent nella rete Tivoli Workload Scheduler in grado di risolvere ledipendenze locali e di lanciare i relativi lavori in assenza di un Gestore dominio.

DelimitatoreIl delimitatore dei lavori è un controllo master dell’esecuzione dei lavori su unaworkstation. Il delimitatore dei lavori è un livello di priorità che deve esseresuperato da un lavoro o da un flusso di lavori prima di essere eseguito. Ad esempio,impostando il delimitatore su 40 si impedisce ai lavori con priorità uguale oinferiore a 40 di essere avviati.

Flusso di lavoro finaleL’ultimo flusso di lavoro eseguito in un giorno di produzione. Contiene un lavoroche esegue il file script Jnextday.

Dipendenza di successioneUna dipendenza in cui un lavoro o un flusso di lavori non può cominciarel’esecuzione fino al completamento riuscito di un altro lavoro o di un altro flusso dilavori.

Opzioni globaliLe opzioni che si applicano a tutte le workstation di una rete TWS. Esse vengonodefinite nel fileglobaloptssul Gestore dominio master. Vedere anche “Opzionilocali”.

Glossario

HostUna workstation Workload Scheduler richiesta dagli XA (extended agent). Puòessere una qualsiasi workstation TWS, tranne un altro XA (extended agent).

Ciclo di esecuzione a inclusioneUn ciclo di esecuzione che specifica i giorni in cui si pianifica di eseguire un flussodi lavoro. I cicli di esecuzione di esclusione hanno la precedenza sui cicli diesecuzione di inclusione.

Lavori interattiviUn lavoro che viene eseguito in modo interattivo su un desktop Windows NT.

Stato internoRiflette lo stato corrente dei lavori o del flusso di lavori nel motore TWS. Lo statointerno è unico per TWS. Vedere anche la voce Stato.

Dipendenze Internetwork (INET)Una dipendenza tra i lavori o flussi di lavoro in diverse reti Tivoli WorkloadScheduler. Vedere anche “Agent di rete”.

Lavoro/flusso di lavori Internetwork (INET)Un lavoro o un flusso di lavoro da una rete remota Tivoli Workload Scheduler che èun predecessore di un lavoro o di un flusso di lavoro nella rete locale. Un lavoroInternetwork viene rappresentato da un’icona place holder nella visualizzazioneGrafica del flusso di lavoro. Vedere anche “Agent di rete”.

Lavoro JnextdayUn lavoro che viene eseguito alla fine di ogni giorno per un’elaborazione pre epostproduzione completamente automatizzata. Un esempio di lavoro jnextdaypotrebbe essereTWShome\Jnextday.Jnextday effettua la seguente procedura:imposta l’elaborazione del giorno successivo (contenuta nel file symphony), stampai report, porta avanti i flussi di lavoro incompiuti e arresta e riavvia il TWS.

LavoroUna unità di lavoro elaborata su una workstation. La definizione del lavoro consistedi un nome lavoro univoco nel database di TWS e di informazioni necessarie pereseguire il lavoro. Quando si aggiunge un lavoro a un flusso di lavori, è possibiledefinirne le dipendenze e le restrizioni temporali, come l’ora di avvio stimata e iltempo limite.

156 Versione 7.0

Istanza lavoroUn lavoro pianificato per una specifica data di esecuzione nel piano. Vedere anche“Lavoro”.

Stato lavoroVedere la voce “Stato”.

Flusso di lavoroUn elenco di lavori eseguiti come una unità (ad esempio un’applicazione di backupsettimanale), insieme all’ora, le priorità e le altre dipendenze che determinanol’ordine esatto dell’esecuzione dei lavori.

Istanza flusso di lavoroUn flusso di lavoro pianificato per una specifica data di esecuzione nel piano.Vedere anche “Flusso di lavoro”.

LimiteUn limite di lavoro che fornisce un mezzo per l’assegnazione di un numerospecifico di slot di lavori in cui Tivoli Workload Scheduler può avviare i lavori. Unlimite lavoro può essere impostato per ogni flusso di lavoro e per ogni workstation.Ad esempio, impostando il limite di lavoro della workstation su 25 è possibile cheTWS abbia non più di 25 lavori eseguiti contemporaneamente sulla workstation.

ElencoUn elenco che visualizza gli oggetti di pianificazione del lavoro. E’ necessariocreare elenchi diversi per ogni oggetto Job Scheduling. Per ogni oggetto JobScheduling, esistono due tipi di elenchi: uno di definizioni nel database e un altro diistanze nel piano.

Opzioni localiLe opzioni che si applicano solo alla workstation su cui sono definiti. Esse vengonodefinite nel file localoptssu ogni workstation di una rete Tivoli Workload Scheduler.Vedere anche “Opzioni globali”.

Gestore dominio master (MDM)La workstation che gestisce i file utilizzati per documentare gli oggetti dipianificazione di una rete Tivoli Workload Scheduler. Crea il piano all’inizio di ognigiorno ed esegue tutte le registrazioni e i report per la rete.

Glossario

Agent di reteUn tipo di XA (extended agent) utilizzato per creare le dipendenze tra lavori e flussidi lavoro su diverse reti Tivoli Workload Scheduler. Vedere anche “DipendenzaInternetwork (INET)”.

ParametroUn parametro utilizzato per sostituire i valori nei lavori e nei flussi di lavoro.Quando si utilizza un parametro in uno script lavoro, il valore viene sostituitonell’ora di esecuzione. In questo caso, il parametro deve essere definito sullaworkstation su cui verrà utilizzato. Non è possibile utilizzare i parametri quando siesegue lo script dei lavori XA (extended agent).

PianoUna procedura contenente tutte le attività di pianificazione del lavoro per il periododi un giorno. In TWS, il piano viene creato ogni 24 ore e consiste di tutti i lavori, iflussi di lavoro e gli oggetti di dipendenza che si prevede di eseguire queldeterminato giorno. Tutti i flussi di lavoro per i quali sono stati creati cicli diesecuzione vengono automaticamente pianificati e inclusi nel piano. Al progrediredel ciclo di produzione, i lavori e i flussi di lavoro nel piano vengono eseguitisecondo le limitazioni temporali e le altre dipendenze. Tutti i lavori o i flussi dilavoro vengono eseguiti con esito negativo che non vengono spostati in unapianificazione successiva.

Ora di avvio pianificataL’ora in cui TWS prevede che inizierà un’istanza di lavoro. Questa stima è basatasull’ora di avvio delle esecuzioni precedenti.

PredecessoreUn lavoro che deve essere completato con esito positivo prima dell’esecuzione deilavori successivi.

PrioritàUn’ora preferenziale per l’esecuzione dei lavori e dei flussi di lavoro TWSnell’ordine stabilito dal piano. E’ possibile assegnare un livello di priorità a ognilavoro o flusso di lavori compreso tra0 a 101. Una priorità0 non viene eseguita.

PromptUn oggetto che può essere utilizzato come dipendenza per i lavori e per i flussi dilavoro. E’ necessario rispondere affermativamente a una prompt per avviare lavori oflussi di lavoro dipendenti. Esistono due tipi di richieste: predefinite e adhoc. Unaprompt adhoc viene definita nelle proprietà di un lavoro o di un flusso di lavoro ed

158 Versione 7.0

è univoca in tale lavoro o flusso di lavoro. Una prompt predefinita viene definita neldatabase TWS e può essere utilizzata da qualsiasi lavoro o flusso di lavoro.

RisorsaUn oggetto che rappresenta risorse fisiche o logiche sul sistema. Una volta definitenel database Tivoli Workload Scheduler, le risorse possono essere utilizzate comedipendenze per i lavori e per i flussi di lavoro. Ad esempio, è possibile definire unarisorsa denominata″nastri″ con un valore di unità uguale a due. Quindi, definire ilavori che richiedono unità nastro disponibili come dipendenza. I lavori con questadipendenza non possono essere eseguiti contemporaneamente poiché, ogni volta incui viene eseguito un lavoro, la risorsa “nastro” è in uso.

Ciclo di esecuzioneUn ciclo che specifica i giorni in cui è pianificata l’esecuzione di un lavoro. InTWS è possibile specificare tre tipi di cicli di esecuzione per un flusso di lavoro: unciclo di esecuzione semplice, un ciclo di esecuzione settimanale o un ciclo diesecuzione Calendario (comunemente chiamato Calendario). Notare che ogni tipo diciclo di esecuzione può essere a inclusione o a esclusione. Cioè, ogni ciclo diesecuzione può definire i giorni in cui un flusso di lavoro è incluso nel ciclo diproduzione oppure i giorni in cui un flusso di lavoro viene escluso dal ciclo diproduzione. Quando si definiscono più cicli di esecuzione per un flusso di lavoro e icicli di esecuzione di inclusione e di esclusione specificano gli stessi giorni, i ciclidi esecuzione di esclusione hanno la precedenza.

Ciclo di esecuzione sempliceUna serie specifica di giorni definiti dall’utente in cui viene eseguito un flusso dilavoro. Un ciclo di esecuzione semplice viene definito per un flusso di lavorospecifico e non può essere utilizzato per più flussi di lavoro. Per ulterioriinformazioni consultare Ciclo di esecuzione.

StatoRiflette lo stato corrente del lavoro o del flusso di lavoro in Job SchedulingConsole. Lo stato di Job Scheduling Console è comune a TWS e OPC. Vedereanche la voce Stato interno.

File stdlistUn file di elenco standard creato per ogni lavoro avviato da Tivoli WorkloadScheduler. I file di elenco standard contengono identificativi iniziali e finali,comandi echoed, errori e avvertenze. Questi file possono essere utilizzati per larisoluzione dei problemi nell’esecuzione del lavoro.

Glossario

SuccessoreUn lavoro che non può iniziare finché tutti i lavori predecessori sui quali ha unadipendenza non vengono completati.

File SymphonyUn file contente le informazioni di pianificazione necessarie al processo di Controlloproduzione (batchman) per l’esecuzione del piano. Il file viene creato e caricatodurante la fase di preproduzione. Durante la fase di produzione esso vienecontinuamente aggiornato per indicare lo stato corrente dell’elaborazione diproduzione: lavoro completato, lavoro in corso, lavoro da eseguire. Per gestirel’elaborazione della produzione, il contenuto del file symphony (piano) può esserevisualizzato e modificato con la Job Scheduling console.

Restrizioni temporaliPossono essere specificate sia per i lavori che per i flussi di lavoro. E’ possibilespecificare l’ora in cui comincerà l’esecuzione o l’ora dopo la quale l’esecuzionenon verrà tentata. Specificandole entrambe, è possibile definire una finestraall’interno della quale un lavoro o un flusso di lavoro verranno eseguiti. Per i lavoriè possibile specificare, inoltre, una velocità di ripetizione. Ad esempio, è possibileche TWS avvii lo stesso lavoro ogni 30 minuti tra le 8:30 a.m. e l’1:30 p.m.

Tivoli Management Framework (TMF)Il software di base necessario per eseguire le applicazioni nella suite dei prodottiTivoli. L’infrastruttura del software consente l’integrazione delle applicazioni digestione dei sistemi da Tivoli Systems Inc. e dai Partner Tivoli. Tivoli ManagementFramework include:vbroker di richiesta dell’oggetto (oserv)vdatabase dell’oggettodistribuito vfunzioni di amministrazione di basevservizi di applicazione di basevservizi desktop di base, ad es. la GUI In un ambiente Tivoli, Tivoli ManagementFramework viene installata su tutti i client e server. Tuttavia, il server TMR è il soloserver che congela il database degli oggetti completo.

Tivoli Management Region (TMR)In ambiente Tivoli, un server Tivoli e la serie di client da esso serviti.Un’organizzazione può disporre di più TMR. Un TMR indirizza alla connettivitàfisica delle risorse, mentre un’area della politica indirizza l’organizzazione logicadelle risorse.

Visualizzazione ad alberoLa finestra a sinistra di Job Scheduling Console, che visualizza il server TWS,raggruppa gli elenchi di default e gli elenchi creati dall’utente.

160 Versione 7.0

UtenteSolo per Windows NT, il nome utente specificato nel campo “Logon” delladefinizione del lavoro deve avere una definizione utente corrispondente. Ledefinizioni forniscono all’utente le password richieste da Tivoli Workload Schedulerper avviare i lavori.

Comandi di utilitàUn insieme di eseguibili di riga comando per la gestione di Tivoli WorkloadScheduler.

Ciclo di esecuzione SettimanaleUn ciclo di esecuzione che specifica i giorni della settimana in cui viene eseguito unflusso di lavoro. Ad esempio, è possibile fissare l’esecuzione di un flusso di lavoroper ogni lunedì, mercoledì e venerdì, utilizzando un ciclo di esecuzione settimanale.Un ciclo di esecuzione settimanale viene definito per un flusso di lavoro specifico enon può essere utilizzato per più flussi di lavoro. Per ulteriori informazioniconsultare Ciclo di esecuzione.

Caratteri jollyI caratteri jolly relativi a Tivoli Workload Scheduler sono: ? Sostituisce un caratterealfa. % Sostituisce un numero. * Sostituisce zero o più caratteri alfanumerici. Icaratteri jolly sono generalmente utilizzati per raffinare una ricerca per uno o piùoggetti nel database. Ad esempio, se si desidera visualizzare tutte le workstation, èpossibile immettere il carattere jolly asterisco (*). Per avere un elenco diworkstation dal site1 al site8, immettere site%.

WorkstationGeneralmente un computer singolo su cui vengono eseguiti i lavori e i flussi dilavoro. Essi vengono definiti nel database Tivoli Workload Scheduler come oggettiunivoci. Una definizione di workstation viene richiesta per ogni computer cheesegue i lavori o i flussi di lavoro nella rete Workload Scheduler.

Classe di workstationUn gruppo di workstation. E’ possibile inserire in una classe un qualsiasi numero diworkstation. I flussi di lavoro e i lavori possono possono essere assegnati perl’esecuzione su una classe di workstation. Questo semplifica la replica di un lavoroo di un flusso di lavori su più workstation.

X-agentVedere “XA (Extended agent)”.

Glossario

162 Versione 7.0

Indice analitico

Caratteri speciali$framework 69$jclowner 72$master 68, 72$owner 72$remote 72$remotes 68$slaves 68, 72$thiscpu 69, 72$user 72/usr/unison/components 63

Aabilita fuso orario 130, 136adddep 75AIXconsole.sh 106altpri 75Amministratore TME 66, 131avvio 119, 120, 136

Bbatchman 115

Ccalendari, calendar 71calendario, calendar 70, 73caricamento NFS 127classi JSS 98Client JS Console 3

compiler 117, 121connettore

prerequisiti 80connettore TWS 1, 125

classi 97istanze 126

controllo piano 114cpu 69, 70, 71cpudata 71cpuname 129

except 7il 7

database job.sched 62deldep 75desktop Tivoli 124dipendenze resolve 127dispatcher dell’oggetto 124dumpsec 66, 96

Ffence 74file 70, 71, 75file Controllo produzione 114file dei componenti 20file dei componenti, visualizzazione 21file security 131finale 116, 128finestra

Apri ubicazione 109, 138Crea Workstation 129

Indiceanalitico

finestra (Continua)Installa patch 96Installa prodotto 82, 88Personalizzazione dell’installazione 104Seleziona cartella d’installazione 102Selezionare il percorse per le scelte

rapide 102flusso di lavoro 6, 73fuso orario 114, 125, 135

Ggcomposer 125gconman 125Gestore dominio master (MDM) 2globalopts 113, 128, 139GlobalPreferences.ser 137gruppi di prodotti 20gruppo 69GUI precedenti 135

HHPconsole.sh 106

JJAVAPATH 106jcl 72Jnextday 117job scheduling console 100, 125

finestra di avvio 108finestra di dialogo di avvio

Nome utente 108password 108sistema host 108

installazioneinstallazione personalizzata 104pacchetto completo 104

jobman 115

Kkill 75

Llavori, job 71lavoro, job 6, 70, 75localopts 114, 139logman 117logon 69, 72

Mmaestro

5.x 1236.x 123

mailman 115makesec 66, 134master di backup 127mastsked 71mozart 130mozart.old 139

Nnetman 20, 115

home directory 21opzioni locali 21

nodo gestito 124numero di porta TCP 116

164 Versione 7.0

OOPC 125ora until 115oserv 124

Ppanoramica sull’installazione 18parameter 71, 128parameters.KEY 128parametro, parameter 70, 72, 76parola chiave AT 119, 120parola chiave UNTIL 119pianificazione, schedule 70, 73, 77prodsked 71prompt 70, 72, 76

Rrep8 117report preproduzione 118reptr 117rerun 76richieste, prompt 71rinvio 120risorsa, resource 70, 72, 76risorse, resource 71RUNCON 107runmsgno 139

Sscheddate 121schedulr 117, 121security 71, 96

file 65maschera 65

setup_env 82, 86, 93Sfinal 116

shutdown 74stageman 117stato completo 127submit 76, 125supporto del fuso orario 8switchmgr 128Symphony 71, 125

Ttempo limite 119, 136tempsec 96Tivoli Management Region 123Tivoli Management Server 123

Uuserobj 70, 73, 78

Vvalore nice 115verifica del database 114versione espansa 139

Wwinstall 87, 93wmaeutil 96, 134wtwsconn 93wuninst 98

Indiceanalitico

166 Versione 7.0

Printed in Denmark by IBM Danmark A/S

GC13-2888-00

TWS - IBMpublib.boulder.ibm.com/tividd/td/TWS/GC32-0422-00/... · Riavvio di TWS ..... 56 Script Customize..... 58 Come disinstallare TWS ..... 62

Documents

TWS Fetyko Complete

Digitalic n.3 - Riavvio

TWS Brochure

TWS GAMING EARBUDS

-' tWS-Weldi

ANTRIEB - TWS€¦ · TWS, sorgt für einen reibungslosen.....

TWS GEARGUIDE 2010

8.4 tws small

TWS Style Guide

Tws products june2012

Linee di indirizzo per il riavvio delle attività ...

Tws presentation final_mp

Disinstallare BetterMarkit Ads Per garantire la Windows

TWS 2013 Agenda

TWS Newsletter

TWS 8.5 New