Tivoli Workload Scheduler Guide de planification et d installation. Version 8.1 SH

Transcription

1 Tivoli Workload Scheduler Guide de planification et d installation Version 8.1 SH

2

3 Tivoli Workload Scheduler Guide de planification et d installation Version 8.1 SH

4 Tivoli Workload Scheduler Guide de planification et d installation, Version Première édition - décembre 2001 Réf. US : SH Notice de copyright Copyright IBM France Tous droits réservés. Copyright 2001 Tivoli Systems Inc., filiale d IBM Corporation, y compris cette documentation et tout logiciel associé. Tous droits réservés. Ne peut être utilisé que dans le cadre d un contrat de licence logiciel de Tivoli Systems ou d un contrat de licence logiciel d IBM comportant un addendum relatif aux produits Tivoli. Aucune partie de cette publication ne doit être reproduite, transmise, transcrite, conservée dans un système d archivage ou convertie en un quelconque langage machine, sous quelque forme ou quelque moyen que ce soit, électronique, mécanique, magnétique, optique, chimique, manuel ou autre, sans autorisation écrite antérieure de Tivoli Systems. Tivoli Systems vous accorde des droits limités vous autorisant à imprimer ou à effectuer d autres reproductions de toute documentation informatique pour votre propre utilisation, dans la mesure où ces reproductions comportent la mention de copyright de Tivoli Systems. Nul autre droit sous copyright n est accordé sans autorisation écrite antérieure de Tivoli Systems. Le présent document est livré en l état. IBM et Tivoli Systems déclinent toute responsabilité, expresse ou implicite, relative aux informations qui y sont contenues, y compris en ce qui concerne les garanties de qualité marchande ou d adaptation à vos besoins. Marques IBM, Tivoli, le logo Tivoli, AIX, AS/400, BookManager, Dynix, OS/390 et Sequent sont des marques d International Business Machines Corporation ou de Tivoli Systems Inc. dans certains pays. Intel est une marque d Intel Corporation. Microsoft, Windows et Windows NT sont des marques de Microsoft Corporation dans certains pays. UNIX est une marque enregistrée de The Open Group dans certains pays. Java et toutes les marques et logos incluant Java sont des marques de Sun Microsystems, Inc. dans certains pays. D autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient apparaître dans ce document. Remarques Le présent document peut contenir des informations ou des références concernant certains produits, logiciels ou services Tivoli Systems ou IBM non annoncés dans ce pays. Cela ne signifie pas que Tivoli Systems ou IBM ait l intention de les y annoncer. Toute référence à un produit, logiciel ou service Tivoli Systems ou IBM n implique pas que seul ce produit, logiciel ou service puisse être utilisé. Sous réserve de toute propriété intellectuelle en vigueur chez Tivoli Systems ou IBM ou de tout autre droit pouvant être légalement protégé, tout produit, programme ou service fonctionnellement équivalent peut remplacer un produit, un programme ou un service auquel il est fait référence. Il est de la responsabilité de l utilisateur d évaluer et de vérifier lui-même les installations et applications réalisées avec des produits, logiciels ou services, non expressément référencés par Tivoli Systems ou IBM. Tivoli Systems ou IBM peut détenir des brevets ou des demandes de brevets couvrant les produits mentionnés dans le présent document. La remise de ce document ne vous donne aucun droit de licence sur ces brevets ou demandes de brevets. Si vous désirez recevoir des informations concernant l acquisition de licences, veuillez en faire la demande par écrit à l adresse suivante : IBM EMEA Director of Licensing, IBM Europe Middle-East Africa, Tour Descartes, Paris-La Défense Cedex 50.

5 Pour plus de détails, pour toute demande d ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial. Vous pouvez également consulter les serveurs Internet suivants : (serveur IBM en France) (serveur IBM au Canada) (serveur IBM aux Etats-Unis) IBM EMEA Director of Licensing IBM Europe Middle-East Africa Tour Descartes La Défense 5 2, avenue Gambetta Paris-La Défense CEDEX France Pour le Canada, veuillez adresser votre courrier à : IBM Director of Commercial Relations IBM Canada Ltd Steeles Avenue East Markham, Ontario L3R 9Z7 Canada Certification ISO 9001 Ce produit a été développé avec un système ayant reçu la certification qualité ISO La certification a été accordée par le groupe italien de certification des systèmes de qualité, CSQ (Numéro de certification CISQ/CSQ 9150.IBM7). CSQ est membre de l organisation européenne ITQS, dont la mission est d évaluer et de certifier les systèmes de qualité des sociétés informatiques. Tivoli Workload Scheduler - Guide de planification et d installation iii

6 iv Version 8.1

7 Table des matières Avis aux lecteurs canadiens... xi Avant-propos... xiii A qui s adresse ce guide.... xiii Organisation de ce guide... xiii Publications... xiv Publications Tivoli Workload Scheduler... xiv Publications connexes.... xiv Documentation en ligne pour Tivoli Workload Scheduler pour z/os... xv Accès aux publications en ligne.... xv Commande de publications... xv Commentaires sur les publications... xvi Informations spécifiques à des plateformes... xvi Comment prendre contact avec le service client... xvii Conventions utilisées dans ce guide... xvii Chapitre 1. Introduction... 1 Nouveautés de cette version... 1 Plusieurs calendriers des congés... 1 Règle des jours chômés Amélioration des performances... 2 Améliorations de l installation... 3 Support Linux... 3 Planification de bout en bout... 3 Intégration à Tivoli Business Systems Manager... 4 Fonctionnalités supprimées... 4 Tivoli Workload Scheduler... 5 Job Scheduling Console Terminologie relative à JS Console... 7 Remarques relatives aux fuseaux horaires... 8 Planification du réseau... 9 Présentation du réseau Tivoli Workload Scheduler... 9 Fonctionnalités des domaines Traitement localisé dans votre domaine Remarques relatives au réseau Réseau à un seul domaine Réseau à plusieurs domaines Tivoli Workload Scheduler - Guide de planification et d installation v

8 Basculement vers un gestionnaire de domaine de sauvegarde Base de données étendue et noms d objet longs Création de bases de données Noms des postes de travail Présentation de l installation Groupes de produits Fichier des composants Affichage du fichier des composants Répertoire principal de Netman Options locales de Netman Après l installation Chapitre 2. Installation sous Windows NT Configuration requise Installation pour la planification de bout en bout Préparation en vue d une mise à jour Suppression et arrêt de Tivoli Workload Scheduler Fichiers de sauvegarde Installation du logiciel Le programme d installation Exécution du programme d installation Après l installation et la mise à jour Achèvement de la mise à jour Définition de la variable PATH Répertoires et services Tivoli Workload Scheduler Service Tivoli Workload Scheduler Configuration de l administration décentralisée Partage des répertoires principaux Partage des paramètres Tivoli Workload Scheduler Utilisation d un seul partage Définition des options locales Définition des options locales sur l unité maître Création manuelle du compte Tivoli Workload Scheduler Types d administration Tivoli Workload Scheduler Administration centralisée Administration décentralisée Désinstallation de Tivoli Workload Scheduler Utilisation de l outil Ajout/Suppression de Windows NT vi Version 8.1

9 Chapitre 3. Installation sous UNIX Configuration requise Installation pour la planification de bout en bout Procédure d installation Installation du moteur Tivoli Workload Scheduler Etapes de configuration Configuration d un gestionnaire de domaine principal après l installation Configuration d un agent tolérant les pannes après l installation Mise à jour de Tivoli Workload Scheduler Préparation-arrêt de Tivoli Workload Scheduler Sauvegarde Mise à jour du logiciel et exécution du script de personnalisation Mise à jour du profil de sécurité Restauration de vos fichiers Redémarrage de Tivoli Workload Scheduler Le script de personnalisation Désinstallation de Tivoli Workload Scheduler Chapitre 4. Définition de la sécurité Le fichier de sécurité Création du fichier de sécurité Gestion de la sécurité dans un réseau Définition de la sécurité pour l administrateur Tivoli Syntaxe du fichier de sécurité Définitions d utilisateur Syntaxe Variables Ordre de qualification des utilisateurs Ordre de qualification des objets Variables fournies par Tivoli Caractères génériques Le superutilisateur sous UNIX Exemple de fichier de sécurité Explication de l exemple de fichier de sécurité La commande dumpsec La commande makesec Chapitre 5. Etapes de personnalisation facultatives Options globales Tivoli Workload Scheduler - Guide de planification et d installation vii

10 Définition des options globales Exemple de fichier des options globales Présentation des options de report Définition des options globales pour les agents MPE Options locales Définition des options locales Exemple de fichier d options locales Définition des options locales Netman Définition des options pour l administration centralisée sous Windows NT Invites et messages d écran de Tivoli Workload Scheduler Définition de sysloglocal sous UNIX Commande console Automatisation du cycle de production Personnalisation du flux de travaux final Ajout du flux de travaux final Démarrage d un cycle de production Gestion de l environnement de production Choix du début de la journée Modification du début de la journée Création d un plan pour les dates ultérieures ou antérieures Utilisation des scripts de configuration Script de configuration standard - jobmanrc Script de configuration local - $HOME/.jobmanrc Annexe A. Fuseaux horaires et audit Fuseaux horaires Activation de la fonction de fuseau horaire Nom et description des fuseaux horaires Audit Activation de la fonction d audit Format du journal d audit En-tête du journal d audit Exemple d entrées du journal d audit Annexe B. Réseaux Tivoli Workload Scheduler Définitions Tivoli Workload Scheduler pour MPE Communications réseau Liaisons réseau viii Version 8.1

11 Fonctionnement du réseau Processus du réseau Agents étendus Agents étendus UNIX Méthode d accès Local UNIX Méthode d accès Remote UNIX Gestion de la production pour les agents étendus Echec du lancement de travaux sur un agent étendu Fichier de configuration Netman Validation de l adresse IP du réseau Configuration système (UNIX uniquement) Messages d erreur/d avertissement Reprise du réseau Problèmes d initialisation Problèmes de liaison réseau Remarques Configuration d un gestionnaire de domaine en veille Pour un gestionnaire de domaine principal en veille Remarque sur la sécurité du réseau Perte d un gestionnaire de domaine Remplacement d un gestionnaire de domaine Perte prolongée du gestionnaire de domaine principal Annexe C. Gestion de réseau avec MPE Remarques relatives au réseau Remarques relatives à la planification Installation Configuration Configuration d un agent UNIX avec un maître MPE Configuration d un agent FTA MPE avec UNIX ou Windows NT Différences opérationnelles entre les plateformes Sur le maître MPE Arranger et Composer Conman Sur les agents tolérant les pannes UNIX Composer Conman Sur le maître UNIX ou Windows NT Composer Tivoli Workload Scheduler - Guide de planification et d installation ix

12 Conman Sur les esclaves MPE Arranger Composer Conman Annexe D. Migration vers Tivoli Workload Scheduler Tivoli Management Framework pour utilisateurs non Tivoli Remarques sur l installation Où installer le client JS Console Où installer les connecteurs Installation des connecteurs sur des agents FTA Remarques par rapport au maître de secours Gestion des maîtres n appartenant pas aux plateformes de niveau 1 dans un réseau Maestro existant Déplacement du maître de secours Création d un maître de secours Montages de bases de données MDM Gestion des maîtres de secours n appartenant pas aux plateformes de niveau 1 dans un réseau Maestro existant Exécution de plusieurs fenêtres dans JS Console Préservation d un fichier de sécurité existant Ajout d administrateurs Tivoli Gestion de la sécurité Arrêt des connecteurs en vue d implémenter les modifications Exécution de WMAEUTIL Remarques sur les fuseaux horaires Transmission des préférences utilisateur à d autres utilisateurs (Vues/Requêtes personnalisées) Retour à une base de données non étendue Migration sous Windows NT Glossaire Index x Version 8.1

13 Avis aux lecteurs canadiens Le présent document a été traduit en France. Voici les principales différences et particularités dont vous devez tenir compte. Illustrations Les illustrations sont fournies à titre d exemple. Certaines peuvent contenir des données propres à la France. Terminologie La terminologie des titres IBM peut différer d un pays à l autre. Reportez-vous au tableau ci-dessous, au besoin. IBM France ingénieur commercial agence commerciale ingénieur technico-commercial inspecteur IBM Canada représentant succursale informaticien technicien du matériel Claviers Les lettres sont disposées différemment : le clavier français est de type AZERTY, et le clavier français-canadien de type QWERTY. OS/2 et Windows - Paramètres canadiens Au Canada, on utilise : les pages de codes 850 (multilingue) et 863 (français-canadien), le code pays 002, le code clavier CF. Nomenclature Les touches présentées dans le tableau d équivalence suivant sont libellées différemment selon qu il s agit du clavier de la France, du clavier du Canada ou du clavier des États-Unis. Reportez-vous à ce tableau pour faire correspondre les touches françaises figurant dans le présent document aux touches de votre clavier. Tivoli Workload Scheduler - Guide de planification et d installation xi

14 Brevets Il est possible qu IBM détienne des brevets ou qu elle ait déposé des demandes de brevets portant sur certains sujets abordés dans ce document. Le fait qu IBM vous fournisse le présent document ne signifie pas qu elle vous accorde un permis d utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos demandes de renseignements relatives aux permis d utilisation au directeur général des relations commerciales d IBM, 3600 Steeles Avenue East, Markham, Ontario, L3R 9Z7. Assistance téléphonique Si vous avez besoin d assistance ou si vous voulez commander du matériel, des logiciels et des publications IBM, contactez IBM direct au xii Version 8.1

15 Avant-propos Le manuel Tivoli Workload Scheduler - Guide de planification et d installation fournit des informations sur l installation d un réseau Tivoli Workload Scheduler 8.1. Il explique notamment comment planifier un réseau, installer le moteur Tivoli Workload Scheduler, le logiciel connecteur et l interface graphique. Il fournit également des instructions concernant la personnalisation des options Tivoli Workload Scheduler et de la sécurité en vue de démarrer un réseau. Finalement, il fournit des conseils et des informations sur le processus de migration à partir de versions antérieures de Maestro. A qui s adresse ce guide Le présent document s adresse au public suivant : Les administrateurs Tivoli Workload Scheduler, qui sont chargés de planifier l agencement du réseau Tivoli Workload Scheduler. Les installateurs, qui sont chargés d installer les différents progiciels sur les ordinateurs qui composent le réseau Tivoli Workload Scheduler. Organisation de ce guide Le document Tivoli Workload Scheduler - Guide d installation et de planification comprend les chapitres suivants : Chapitre 1, «Introduction» à la page 1 Fournit des informations de planification en vue de configurer un réseau Tivoli Workload Scheduler ainsi qu une présentation du processus d installation. Chapitre 2, «Installation sous Windows NT» à la page 19 Explique comment installer le moteur Tivoli Workload Scheduler sous Windows NT. Chapitre 3, «Installation sous UNIX» à la page 33 Explique comment installer le moteur Tivoli Workload Scheduler sous UNIX. Chapitre 4, «Définition de la sécurité» à la page 47 Explique comment personnaliser le fichier de sécurité. Chapitre 5, «Etapes de personnalisation facultatives» à la page 67 Explique comment personnaliser votre réseau et votre poste de travail une fois l installation terminée. Annexe A, «Fuseaux horaires et audit» à la page 89 Explique comment paramétrer les fonctions de fuseau horaire et d audit. Annexe B, «Réseaux Tivoli Workload Scheduler» à la page 99 Explique les mécanismes sous-jacents d un réseau Tivoli Workload Scheduler. Annexe C, «Gestion de réseau avec MPE» à la page 113 Explique comment configurer votre réseau s il contient des postes MPE. Annexe D, «Migration vers Tivoli Workload Scheduler» à la page 119 Fournit des informations utiles pour effectuer une migration à partir de Maestro. Tivoli Workload Scheduler - Guide de planification et d installation xiii

16 Publications Publications Cette section répertorie les publications disponibles dans la bibliothèque Tivoli Workload Scheduler ainsi que tous les autres documents connexes. Elle décrit également la façon d accéder aux documents Tivoli en ligne, de commander des publications Tivoli et de transmettre vos commentaires sur les publications Tivoli. Publications Tivoli Workload Scheduler Le présent manuel fait partie d une bibliothèque Tivoli Workload Scheduler complète. Les manuels suivants peuvent vous aider à utiliser Tivoli Workload Scheduler plus efficacement : Tableau 1. Liste des publications Tivoli Workload Scheduler Tâche Publication Référence de la commande Planification et installation de Tivoli Workload Scheduler. Utilisation de la ligne de commande Tivoli Workload Scheduler, compréhension du fonctionnement des agents étendus et des agents réseau et intégration de Tivoli Workload Scheduler à NetView et à Tivoli Business Systems Manager. Interprétation des messages d erreur Tivoli Workload Scheduler. Installation, configuration et utilisation des agents tolérant les pannes Tivoli Workload Scheduler sous AS/400. Configuration et utilisation du module Plus de Tivoli Workload Scheduler. Informations de dernière minute concernant Tivoli Workload Scheduler. Tivoli Workload Scheduler - Guide de planification et d installation Tivoli Workload Scheduler - Guide de référence Tivoli Workload Scheduler - Messages d erreur Tivoli Workload Scheduler - Agent tolérant les pannes pour AS/400 - Guide de l utilisateur Tivoli Workload Scheduler Guide de l utilisateur du module Plus Tivoli Workload Scheduler Release Notes SH SH SH SH SH GI Publications connexes Les documents suivants contiennent également des informations utiles concernant le produit et la fonction de planification de bout en bout : Tableau 2. Liste des publications connexes Tâche Publication Référence de la commande Comprendre la suite Tivoli Workload Scheduling Planification de Tivoli Workload Scheduler pour z/os Tivoli Workload Scheduler for z/os General Information Licensed Program Specifications GH GH Aide-mémoire Tivoli Workload Scheduler for z/os Quick Reference GH Explication des concepts et de la Tivoli Workload Scheduler for z/os Getting Started SH terminologie Installation de Tivoli Workload Scheduler pour z/os Tivoli Workload Scheduler for z/os Installation Guide SH xiv Version 8.1

17 Publications Tableau 2. Liste des publications connexes (suite) Tâche Publication Référence de la commande Planification de la charge de travail Personnalisation et adaptation de Tivoli Workload Scheduler pour z/os Ecriture de programmes d application Contrôle et surveillance du plan actuel Interprétation des messages et des codes Utilisation de l interface graphique Java - modifications de dernière minute Utilisation de l Interface graphique Java Tivoli Workload Scheduler for z/os Planning and Scheduling the Workload Tivoli Workload Scheduler for z/os Customization and Tuning Tivoli Workload Scheduler for z/os Programming Interfaces Tivoli Workload Scheduler for z/os Controlling and Monitoring the Workload Tivoli Workload Scheduler for z/os Messages and Codes Tivoli Job Scheduling Console Release Notes Tivoli Job Scheduling Console - Guide de l utilisateur SH SH SH SH SH GI SH Documentation en ligne pour Tivoli Workload Scheduler pour z/os Tous les manuels de la bibliothèque Tivoli Workload Scheduler pour z/os, à l exception des publications sous licence, sont disponibles sous forme électronique sur CD-ROM dans le Softcopy Collection Kit suivant : OS/390, SK2T-6951 Vous pouvez lire ces manuels électroniques sur CD-ROM à l aide des programmes sous licence IBM suivants : BookManager READ/2 BookManager READ/DOS BookManager READ/6000 Tous les programmes BookManager nécessitent un poste de travail doté d un lecteur de CD-ROM (capable de lire les disques formatés conformément à la norme ISO 9660), ainsi que d un adaptateur et d un câble appropriés. Pour plus de détails sur la configuration matérielle et logicielle, reportez-vous à la documentation du produit BookManager spécifique que vous utilisez. Les mises à jour des manuels intervenant entre deux éditions sont uniquement fournies sous forme de copie électronique. Accès aux publications en ligne La plupart des publications Tivoli sont accessibles en ligne sur le site du Service clientèle Tivoli : Ces publications sont disponibles au format PDF ou HTML, ou dans ces deux formats. Des documents traduits sont également disponibles pour certains produits. Commande de publications Vous pouvez commander la plupart des publications en ligne sur le site Web suivant : (ou en appelant le numéro , pour le Canada). Tivoli Workload Scheduler - Guide de planification et d installation xv

18 Publications Commentaires sur les publications Vos commentaires nous permettent d améliorer la qualité de nos documents et produits Tivoli. Si vous avez des observations à formuler sur cette documentation, veuillez nous les envoyer : Par courrier électronique à [email protected]. En adressant le formulaire d observations fourni à l adresse : Informations spécifiques à des plateformes Le tableau suivant indique les versions prises en charge pour chacune des plateformes répertoriées connues au moment de la publication. Pour plus de détails et pour obtenir des informations à jour, veuillez vous reporter au document Tivoli Workload Scheduler - Release Notes. Plate-forme Maître Agent FTA Connecteur JS Console AIX 4.3.3s, 5.1 X X X X HP-UX 11.0, 11i X X X X Solaris 2.7, 2.8 X X X X Microsoft Windows NT 4.0 X X X X avec SP5 ou SP6a Microsoft Windows Professionnel, Server, Advanced Server 2000 avec SP1 ou SP2 X X Microsoft Windows 98, X Millennium Compaq Tru X (anciennes versions OSF) SGI Irix 6.5 X IBM Sequent Dynix 4.5 X Linux/INTEL Red Hat 7.1 X X X X Linux/390 SuSE 7.0 X Remarques : 1. Un nombre limité d agents tolérant les pannes sont également pris en charge sur la plateforme AS/ La liste des plateformes prises en charge pour Job Scheduling Console se limite au support et à la disponibilité de Java Runtime Environment (JRE) Version 1.3. xvi Version 8.1

19 Comment prendre contact avec le service client Si vous rencontrez des difficultés avec un produit Tivoli, vous pouvez contacter le Service clientèle Tivoli. Veuillez consulter le guide Tivoli Customer Support Handbook sur le site Web suivant : Ce guide fournit des informations sur la façon de contacter le Service clientèle Tivoli en fonction de la gravité de votre problème, ainsi que les renseignements suivants : Enregistrement et admissibilité Les numéros de téléphone et les adresses électroniques correspondant à votre pays de résidence Les informations à rassembler avant de contacter le service clientèle Conventions utilisées dans ce guide Plusieurs conventions typographiques sont associées à des actions et à des termes particuliers. Ces conventions sont les suivantes : Type d information Convention de style Exemple Commandes Tout en majuscule CREATE Les références dans le texte aux Tout en majuscule QUANTITY zones d écran Le texte à entrer dans les zones Police à espacement simple d écran MYAPPLICATION Première apparition d un nouveau terme Italique Comment prendre contact avec le service client Application Tivoli Workload Scheduler - Guide de planification et d installation xvii

20 Conventions utilisées dans ce guide xviii Version 8.1

21 1 1. Introduction Introduction Le présent guide contient des instructions d installation et de mise à jour pour Tivoli Workload Scheduler Version 8.1. Nouveautés de cette version Tivoli Workload Scheduler Version 8.1 intègre les améliorations suivantes : Plusieurs calendriers des congés Règle des jours chômés Amélioration des performances Amélioration de l installation Support Linux Planification de bout en bout Intégration à Tivoli Business Systems Manager Plusieurs calendriers des congés Le calendrier des jours chômés (un jour chômé étant l opposé d un jour ouvré) étend désormais le rôle du calendrier des congés en ce sens qu il vous permet de personnaliser la signification des jours ouvrés au sein de Tivoli Workload Scheduler. Dans les versions antérieures, la définition des jours ouvrés était fixe et effectuée en fonction du calendrier des congés (lorsque ce dernier existait). Cette nouvelle fonction vous permet de choisir si un flux de travaux ou une commande doit utiliser les définitions par défaut des jours ouvrés, basées sur le calendrier des congés, ou utiliser une définition personnalisée des jours ouvrés qui est déterminée par un calendrier spécifique des jours chômés. Si vous décidez d utiliser votre propre calendrier des jours chômés pour un flux de travaux ou une commande spécifique, la nouvelle signification des jours ouvrés, telle qu elle découle du calendrier des jours chômés, se limite à ce flux de travaux ou à cette commande spécifique. Lorsque vous ne définissez pas de calendrier des jours chômés pour un flux de travaux ou une commande, c est le calendrier des congés qui est utilisé et les jours ouvrés conservent leur signification traditionnelle. Par défaut, le mot clé workdays est défini comme suit : workdays = everyday except Saturday, Sunday and all dates that appear in the Holidays calendar Tivoli Workload Scheduler - Guide de planification et d installation 1

22 Nouveautés de cette version Si vous indiquez un calendrier des jours chômés dans une définition de flux de travaux, le mot clé workdays pour ce flux de travaux sera basé sur ce calendrier et non sur le calendrier des congés. Chaque occurrence du mot clé workdays dans ce flux de travaux sera interprété comme suit : workdays = everyday except Saturday, Sunday and all the dates in the freedays calendar Par défaut, le samedi et le dimanche ne sont pas considérés comme des jours ouvrés, mais vous pouvez indiquer s ils peuvent être considérés comme des jours ouvrés. Si vous n indiquez pas de calendrier des jours chômés dans la définition du flux de travaux, c est la définition par défaut qui est utilisée pour le mot clé workdays, à savoir : workdays =everyday except Saturday, Sunday and all the dates in the Holidays calendar Vous pouvez définir des calendriers des jours chômés à partir de l interface de ligne de commande de Tivoli Workload Scheduler ou à partir de Job Scheduling Console. Règle des jours chômés Vous pouvez indiquer une règle des jours chômés lorsque vous définissez un cycle d exécution pour un flux de travaux. La règle détermine ce que le planificateur doit faire lorsque l exécution d un flux de travaux tombe un jour chômé. Si la date de l agenda coïncide avec un jour chômé, Tivoli Workload Scheduler peut : Exécuter le flux de travaux Ne pas exécuter le flux de travaux Exécuter le flux de travaux le jour ouvré précédant immédiatement ce jour chômé Exécuter le flux de travaux le jour ouvré suivant immédiatement ce jour chômé La règle des jours chômés est étroitement liée à l utilisation de plusieurs clauses ON et EXCEPT dans le langage de planification. A toutes fins utiles, l utilisation des clauses ON ou EXCEPT dans la définition (agenda) d un flux de travaux implique la définition d un cycle d exécution pour ce dernier. Si vous n indiquez pas de règle des jours chômés, Tivoli Workload Scheduler applique son mécanisme par défaut et exécute le flux de travaux même lorsque la date d exécution sélectionnée est un jours chômé. Tivoli Workload Scheduler ne replanifie pas le même flux de travaux plus d une fois un jour de production donné si sa date d exécution a été déplacée du fait de l application de la règle des jours chômés. Pour plus de détails, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence ou au manuel Tivoli Job Scheduling Console User s Guide. Amélioration des performances Les nouvelles améliorations des performances seront particulièrement appréciées dans les réseaux Tivoli Workload Scheduler comptant un grand nombre de postes de travail, utilisant des plans de planification importants et des relations complexes entre les objets de planification. Ces améliorations concernent les domaines suivants : Création de plan quotidien : Jnextday s exécute plus rapidement et, par conséquent, le gestionnaire de domaine principal peut démarrer ses tâches de production plus tôt. Distribution du plan quotidien : l administrateur Tivoli Workload Scheduler peut désormais activer la compression du fichier Symphony de sorte que le plan quotidien peut être distribué à d autres noeuds plus rapidement. 2 Version 8.1

23 Nouveautés de cette version Optimisation d E/S : Tivoli Workload Scheduler exécute des accès moins fréquents aux fichiers et optimise l utilisation des ressources du système. Ces améliorations se reflètent de la façon suivante : v Fichiers d événements : le temps de réponse par rapport aux événements est amélioré, d où une accélération du flux de messages. v Plan quotidien : l accès au fichier Symphony est plus rapide, à la fois en lecture et en écriture. Le plan quotidien peut donc être mis à jour dans un délai plus court que précédemment. Pour plus d informations sur l implémentation de ces améliorations, reportez-vous à la section «Options locales» à la page 73. Améliorations de l installation Sous Windows NT, l installation de Netman n est plus un processus séparé. Elle fait désormais partie des étapes d installation du produit. Support Linux La version 8.1 de Tivoli Workload Scheduler assure le support des plateformes Linux suivantes : Linux pour Intel en tant que gestionnaire de domaine principal et agent tolérant les pannes. Linux pour S/390 en tant qu agent tolérant les pannes. Planification de bout en bout La planification de bout en bout vous permet de planifier et de contrôler des travaux dans des environnements de grand système, Windows et UNIX et d obtenir ainsi une planification véritablement répartie. Dans la configuration de bout en bout, Tivoli Workload Scheduler pour z/os sert de planificateur pour l environnement de planification des travaux. Les gestionnaires de domaine et les agents tolérant les pannes de Tivoli Workload Scheduler sont utilisés pour effectuer des planifications sur les plateformes réparties. La planification de bout en bout repose sur la possibilité de connecter un gestionnaire de domaine Tivoli Workload Scheduler et ses agents et domaines sous-jacents au moteur Tivoli Workload Scheduler pour z/os. Le moteur Tivoli Workload Scheduler pour z/os crée également le plan de production pour le réseau réparti et l envoie au gestionnaire de domaine. Le gestionnaire de domaine envoie une copie du plan à chacun de ses agents connectés et de ses gestionnaires de domaine subordonnés en vue de son exécution. Le gestionnaire de domaine fait office de système répartiteur pour l ensemble du réseau réparti en résolvant toutes ses dépendances. Il envoie ses mises à jour (sous forme d événements) à Tivoli Workload Scheduler pour z/os de façon à ce que le plan puisse être mis à jour en conséquence. Tivoli Workload Scheduler pour z/os gère ses propres travaux et notifie le gestionnaire de domaine de tous les changements de statut des travaux Tivoli Workload Scheduler pour z/os qui font appel au plan Tivoli Workload Scheduler. Dans cette configuration, le gestionnaire de domaine et l ensemble des agents répartis reconnaissent Tivoli Workload Scheduler pour z/os comme étant le gestionnaire de domaine principal et le notifient de toutes les modifications pouvant survenir dans leurs propres plans. En même temps, le agents ne sont pas autorisés à interférer avec les travaux Tivoli Workload Scheduler pour z/os étant donné que ces derniers sont considérés comme s exécutant sur le système maître qui est le seul noeud autorisé à gérer ces travaux. 1. Introduction Tivoli Workload Scheduler - Guide de planification et d installation 3

24 Nouveautés de cette version L implémentation de la planification de bout en bout s effectue essentiellement sous Tivoli Workload Scheduler pour z/os. Les agents tolérant les pannes (FTA) de Tivoli Workload Scheduler ne nécessitent que la définition des options décrites dans le Chapitre 2, «Installation sous Windows NT» à la page 19 et dans le Chapitre 3, «Installation sous UNIX» à la page 33. Intégration à Tivoli Business Systems Manager Tivoli Business Systems Manager est une application de gestion des systèmes orientée objet permettant la surveillance et la gestion par événements des ressources, des applications et des sous-systèmes de l entreprise avec l objectif d assurer une disponibilité permanente. La surveillance des plans quotidiens Tivoli Workload Scheduler à l aide de Tivoli Business Systems Manager permet d identifier rapidement les incidents susceptibles de compromettre l exécution correcte des agendas. L intégration de Tivoli Workload Scheduler à Tivoli Business Systems Manager offre la possibilité de gérer les agendas du point de vue unique des systèmes de gestion. L intégration est accomplie par les éléments suivants : Un indicateur spécial (indicateur clé) de Tivoli Workload Scheduler marquant les travaux ou les flux de travaux dont vous souhaitez que Tivoli Business Systems Manager assure une surveillance plus complète. Les informations relatives à ces objets clé sont envoyées sous forme d événements. Un mécanisme de reconnaissance en bloc qui envoie à Tivoli Business Systems Manager des informations relatives à l ensemble des travaux prioritaires et des flux de travaux. Un mécanisme de reconnaissance delta qui envoie à Tivoli Business Systems Manager les modifications apportées aux plans quotidiens pour les travaux prioritaires et les flux de travaux. Pour plus de détails, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence. Fonctionnalités supprimées Les fonctionnalités suivantes ne sont plus disponibles : Les interfaces graphiques Maestro existantes, notamment GCONMAN et GCOMPOSER. Visual Maestro Remote Console Le support HP OpenView IT Operation (anciennement HP OpC) Tivoli GEM Instrumentation 4 Version 8.1

25 Tivoli Workload Scheduler Tivoli Workload Scheduler Tivoli Workload Scheduler est composé de trois parties : Le moteur Tivoli Workload Scheduler Le moteur s exécute sur différentes versions de Microsoft Windows et des systèmes d exploitation UNIX. Installez le moteur sur le système maître et sur toutes les CPU des agents physiques. Le connecteur Tivoli Workload Scheduler Il effectue une mise en correspondance entre les commandes Job Scheduling Console et le moteur Tivoli Workload Scheduler. Installez le connecteur sur le système maître et sur tous les agents tolérants les pannes (FTA) que vous allez utiliser en tant qu unités de secours pour la CPU principale. Le connecteur requiert que Tivoli Management Framework soit préalablement configuré pour un serveur ou un noeud géré Tivoli. Job Scheduling (JS) Console Une interface graphique Java pour Tivoli Workload Scheduler. Installez JS Console sur chaque machine à partir de laquelle vous souhaitez gérer des objets de plan et de base de données. JS Console ne nécessite pas que le moteur ou le connecteur Tivoli Workload Scheduler soient installés sur la même machine. Vous pouvez également utiliser JS Console à partir de n importe quelle machine sous réserve que celle-ci possède une liaison TCP/IP avec la machine qui exécute le connecteur Tivoli Workload Scheduler. Un réseau Tivoli Workload Scheduler comprend les postes de travail, ou CPU, sur lesquels des travaux et des flux de travaux sont exécutés. Les définitions des postes de travail font essentiellement référence à des postes de travail physiques. Toutefois, dans le cas d agents étendus et d agents réseau, les postes de travail correspondent à des définitions logiques qui doivent être hébergées par un poste de travail Tivoli Workload Scheduler physique. Un réseau Tivoli Workload Scheduler comprend les types de postes de travail suivants : Gestionnaire de domaine principal (MDM) Le gestionnaire du domaine supérieur d un réseau Tivoli Workload Scheduler. Il contient les fichiers de base de données centralisés servant à documenter les objets de planification. Il crée le plan de production au début de chaque journée et exécute l ensemble des opérations de journalisation et de génération d états pour le réseau. Maître de secours Un agent tolérant les pannes capable d assumer les responsabilités du gestionnaire de domaine principal. Gestionnaire de domaine Le concentrateur de gestion d un domaine. Toutes les communications à destination et en provenance des agents d un domaine sont acheminées à travers le gestionnaire de domaine. Gestionnaire de domaine de sauvegarde Un agent tolérant les pannes capable d assumer les responsabilités de son gestionnaire de domaine. Agent tolérant les pannes (FTA) Un poste de travail capable de résoudre les dépendances locales et de lancer ses travaux en l absence d un gestionnaire de domaine. 1. Introduction Tivoli Workload Scheduler - Guide de planification et d installation 5

26 Tivoli Workload Scheduler Agent standard Un poste de travail qui ne lance des travaux que sous la direction de son gestionnaire de domaine. Agent étendu Une définition de poste de travail logique vous permettant de lancer et de contrôler des travaux sur d autres système et des applications, telles que Baan, Peoplesoft, Oracle, SAP, ainsi que JES2 et JES3 de z/os. Agent réseau Une définition de poste de travail logique permettant de créer des dépendances entre les travaux et les flux de travaux dans des réseaux Tivoli Workload Scheduler distincts. Client JS Console Tout poste de travail exécutant l interface graphique à partir de laquelle les planificateurs et les opérateurs peuvent gérer les objets de plan et de base de données. Le tableau suivant résume la correspondance entre les composants et les types de poste de travail sur lesquels ils doivent être installés : Type de poste de travail Moteur Connecteur JS Console Gestionnaire de domaine Oui Oui Facultatif principal Maître de secours Oui Oui Facultatif Gestionnaire de domaine Oui Facultatif Facultatif Gestionnaire de domaine de Oui Facultatif Facultatif sauvegarde Agent tolérant les pannes Oui Facultatif Facultatif Agent standard Oui Non Facultatif Agent étendu Non disponible Non disponible Non disponible Agent réseau Non disponible Non disponible Non disponible Client JS Console Non Non Oui Job Scheduling Console Job Scheduling Console est une interface graphique à partir de laquelle vous pouvez gérer les objets de plan et de base de données. Elle offre les fonctionnalités de Conman et de Composer via le connecteur Tivoli Workload Scheduler. Elle peut s exécuter de façon indépendante ou en même temps que les interfaces de ligne de commande. Tandis que l utilisation des commandes d interface de ligne de commande est limitée aux postes de travail Tivoli Workload Scheduler, vous pouvez installer JS Console sur des machine extérieures au réseau Tivoli Workload Scheduler. Pour exécuter JS Console, vous devez simplement pouvoir vous connecter à un poste de travail Tivoli Workload Scheduler exécutant le connecteur. Cela signifie que vous pouvez gérer des objets de plan et de base de données non seulement à partir du système maître ou de postes de travail d agents, mais aussi à partir de tout système, y compris un ordinateur portable, sur lequel JS Console est installé et qui est connecté par liaison TCP/IP au système maître ou au FTA qui exécute le connecteur. 6 Version 8.1

27 Job Scheduling Console A partir de la même interface Job Scheduling Console, vous pouvez également gérer des objets de plan et de base de données Tivoli Workload Scheduler pour z/os, sous réserve que vous pouvez vous connecter à une machine exécutant le connecteur Tivoli Workload Scheduler pour z/os. L installation de JS Console est expliquée en détails dans le document Tivoli Job Scheduling Console - Guide de l utilisateur. La figure suivante illustre les relations entre Tivoli Framework, Job Scheduling Services, les moteurs de planification de travaux Tivoli Workload Scheduler et Tivoli Workload Scheduler pour z/os et JS Console. 1. Introduction L interface Job Scheduling Console améliore l intégration entre les deux moteurs de planification du fait qu elle fournit un point d accès unique aux objets de plan et de base de données sur le grand système ou sur les plateformes réparties. Cela s avère particulièrement utile si vous utilisez la fonction de planification de bout en bout de Tivoli Workload Scheduler pour z/os. Terminologie relative à JS Console La terminologie utilisée dans Job Scheduling Console diffère de celle qui est utilisée dans la ligne de commande et dans les versions Maestro existantes. Le tableau suivant répertorie les anciens termes et leurs équivalents dans Job Scheduling Console. Reportez-vous au glossaire pour obtenir davantage de définitions. Ligne de commande Job Scheduling Console Définition Agenda Flux de travaux Une unité de travail comprenant un ensemble de travaux et leurs dépendances. Instance de flux de travaux L occurrence d un flux de travaux dans le plan. Travail Travail Un fichier exécutable, une tâche ou une commande et ses attributs. Un travail est planifié pour s exécuter dans le cadre d un flux de travaux. Instance de travail L occurrence d un travail dans le plan. Tivoli Workload Scheduler - Guide de planification et d installation 7

28 Job Scheduling Console Ligne de commande Job Scheduling Console Définition CPU Poste de travail Un processeur logique, généralement un ordinateur, exécutant des travaux. Les types de postes de travail sont notamment les gestionnaires de domaine, les gestionnaires de domaine de sauvegarde, les agents tolérant les pannes, les agents standard et les agents étendus. Fichiers Mozart Base de données Une collection d objets de planification comprenant des travaux, des flux de travaux, des paramètres, des calendriers et des ressources. Il est accessible par composer, anciennement appelé gcomposer. Fichier Symphony Plan L activité planifiée sur une période, généralement 24 heures. Le plan est mis à jour en permanence de façon à indiquer le statut en cours de l ensemble des activités de Workload Scheduler. Il est accessible par conman, anciennement appelé gconman. Heure AT Heure de début L heure à laquelle un travail ou un flux de travaux va commencer au plus tôt. Heure UNTIL Echéance L heure à laquelle un travail ou un flux de travaux va commencer au plus tard. Dates ON et EXCEPT Cycles d exécution Les dates auxquelles un flux de travaux s exécute ou non. Remarques relatives aux fuseaux horaires Le support des fuseaux horaires est une fonctionnalité qui peut être activée ou désactivée. Les fuseaux horaires sont activés si l indicateur timezone enable du fichier globalopts a pour valeur yes et si le poste de travail principal possède une définition de fuseau horaire. Les fuseaux horaires sont désactivés par défaut lors de l installation du produit. Si les fuseaux horaires sont activés, les zones de fuseaux horaires de Job Scheduling Console sont activés. Si vous ne renseignez pas la zone de fuseau horaire de la définition d un poste de travail, cette zone prendra par défaut la valeur de fuseau horaire du poste de travail gestionnaire de domaine principal. Si les fuseaux horaires sont désactivés, alors toutes les zones de fuseau horaire sont désactivées dans l ensemble de l application. Dans Composer et Conman, une erreur survient si vous essayez de définir un fuseau horaire en même temps qu une heure. Dans Job Scheduling Console, les zones de fuseau horaire sont désactivées à la fois pour la base de données et pour le plan. La seule exception à cela sont les postes de travail de la base de données pour lesquels les fuseaux horaires sont toujours activés. Lors de l activation du fuseau horaire pour le poste de travail principal, nous vous recommandons d entrer un fuseau horaire pour tous les agents tolérant les pannes (FTA) se trouvant dans un fuseau horaire différent. Lorsqu un fuseau horaire FTA est vide, on considère qu il est identique au fuseau horaire principal. 8 Version 8.1

29 Remarques relatives aux fuseaux horaires Une fois que les fuseaux horaires sont activés, vous pouvez entrer un fuseau horaire en même temps qu une heure dans Conman, Composer ou Job Scheduling Console. Si vous entrez une heure sans fuseau horaire, le fuseau horaire sera extrait du poste de travail sur lequel est exécuté le travail ou le flux de travaux, ou du fuseau horaire du poste de travail principal si le fuseau horaire du poste de travail d exécution est vide. Planification du réseau Avant de commencer l installation de Tivoli Workload Scheduler, déterminez les réponses aux questions suivantes. Les sections suivantes du présent chapitre contiennent des informations qui vous aideront à déterminer les réponses les mieux adaptées à vos besoins. 1. Allez-vous utiliser plusieurs domaines ou une structure de réseau à un seul domaine? 2. Si vous utilisez plusieurs domaines, comment allez-vous les diviser? par emplacement géographique, par exemple, les domaines Londres et Paris? par fuseau horaire, par exemple, Heure d hiver côte pacifique et Heure d hiver côte est? par division, par exemple, marketing et comptabilité? 3. Allez-vous utiliser des bases de données étendues ou non étendues? 4. Allez-vous activer la fonction de fuseau horaire? Présentation du réseau Tivoli Workload Scheduler Un réseau Workload Scheduler contient au moins un domaine Workload Scheduler, le domaine principal, dans lequel le gestionnaire de domaine principal fait office de concentrateur de gestion. Des domaines supplémentaires peuvent être utilisés afin de diviser un réseau largement réparti en groupes plus petits gérés localement. L utilisation de plusieurs domaines diminue la quantité de trafic réseau en réduisant les communications entre le gestionnaire de domaine principal et les autres ordinateurs. Dans une configuration à un seul domaine, le gestionnaire de domaine principal gère les communications avec l ensemble des postes de travail du réseau Workload Scheduler. Dans une configuration à plusieurs domaines, le gestionnaire de domaine principal communique avec les postes de travail de son domaine et avec les gestionnaires de domaine subordonnés. A leur tour, les gestionnaires de domaine subordonnés communiquent avec les postes de travail de leur domaine et avec les gestionnaires de domaine subordonnés. Plusieurs domaines offrent également une capacité de tolérance aux pannes en limitant les incidents résultant de la défaillance d un gestionnaire de domaine dans un seul domaine. Pour limiter davantage les effets de tels incidents, vous pouvez désigner des gestionnaires de domaine de sauvegarde chargés de prendre la main en cas de défaillance de leur gestionnaire de domaine. Fonctionnalités des domaines Lorsque vous définissez un nouveau domaine, vous devez identifier le domaine parent et le gestionnaire de domaine. Le domaine parent est le domaine situé directement au-dessus du nouveau domaine dans la hiérarchie des domaines. Toutes les communications à destination et en provenance d un domaine sont acheminées via le gestionnaire de domaine parent. Chaque jour, en début de journée, le gestionnaire de domaine principal crée un fichier de contrôle de production intitulé Symphony. Tivoli Workload Scheduler est alors redémarré dans le réseau et le gestionnaire de domaine principal envoie une copie du nouveau fichier 1. Introduction Tivoli Workload Scheduler - Guide de planification et d installation 9

30 Planification du réseau Symphony à chacun des agents et des gestionnaires de domaine subordonnés auxquels il est automatiquement relié. A leur tour, les gestionnaires de domaine envoient des copies du fichier aux agents et aux gestionnaires de domaine subordonnés auxquels ils sont automatiquement reliés. Une fois que le réseau est démarré, des messages de planification tels que les débuts et fin de travaux sont transmis depuis les agents vers leurs gestionnaires de domaine, en passant par les gestionnaires de domaine parents et jusqu au gestionnaire de domaine principal. Le gestionnaire de domaine principal diffuse alors les messages à travers l ensemble de l arborescence des domaines afin de mettre à jour les fichiers Symphony des gestionnaires de domaine et des agents tolérant les pannes qui s exécutent en mode Statut intégral. Traitement localisé dans votre domaine Le concept de traitement localisé peut vous aider à choisir la façon de configurer vos domaines Tivoli Workload Scheduler. L idée consiste à diviser ou à localiser vos besoins de planification en fonction d un ensemble de caractéristiques commun. Les caractéristiques communes sont des propriétés telles que les emplacements géographiques, les fonctions liées aux activités et les regroupements d applications. Un traitement lié au regroupement peut limiter la quantité d informations d interdépendance devant être communiquée entre les domaines. Les avantages de la localisation du traitement dans les domaines sont les suivants : Réduction du trafic réseau. Le fait de maintenir le traitement localisé par rapport aux domaines élimine le besoin de fréquentes communications interdomaines. Offre un moyen pratique de renforcer la sécurité et de simplifier l administration. La sécurité et l administration peuvent être définies et se limiter au niveau du domaine. Au lieu d effectuer une administration à l échelle du réseau ou spécifique au poste de travail, vous pouvez effectuer une administration à l échelle du domaine. La capacité de tolérance aux pannes du réseau et des postes de travail peut être optimisée. Dans un réseau Tivoli Workload Scheduler à plusieurs domaines, vous pouvez définir des unités de secours pour chaque gestionnaire de domaine, de sorte que les incidents survenant dans un domaine n affectent pas les opérations des autres domaines. Remarques relatives au réseau Les questions suivantes vous aideront à prendre des décisions concernant la façon de configurer le réseau Tivoli Workload Scheduler. Certaines questions concernent certains aspects de votre réseau, et d autres concernent les applications contrôlées par Tivoli Workload Scheduler. Vous pourrez avoir besoin de consulter d autres personnes de votre entreprise pour résoudre certains problèmes. Quelle est la taille de votre réseau Tivoli Workload Scheduler? Combien d ordinateurs comporte-t-il? Combien d applications et de travaux s y exécutent? La taille de votre réseau vous aidera à décider d utiliser une architecture à un seul ou à plusieurs domaines. Si vous disposez d un petit nombre d ordinateurs ou d applications à contrôler à l aide de Tivoli Workload Scheduler, vous n avez pas forcément besoin de plusieurs domaines. Combien d emplacements géographiques sont couverts dans votre réseau Tivoli Workload Scheduler? Quelle est la fiabilité et l efficacité des communications entre ces emplacements? Il s agit-là de l une des principales considérations déterminant le choix d une architecture à plusieurs domaines. La configuration courante consiste à définir un 10 Version 8.1

31 Planification du réseau domaine pour chaque emplacement géographique. Si vous choisissez une architecture à un seul domaine, vous serez plus tributaire du réseau pour assurer la continuité du traitement. Avez-vous besoin d une gestion centralisée ou décentralisée de Tivoli Workload Scheduler? Un réseau Tivoli Workload Scheduler, comportant un seul ou plusieurs domaines, vous permet de gérer Tivoli Workload Scheduler à partir d un noeud unique, le gestionnaire de domaine principal. Si vous souhaitez gérer plusieurs emplacements séparément, vous pouvez envisager l installation d un réseau Tivoli Workload Scheduler distinct au niveau de chaque emplacement. Notez qu un certain degré de gestion décentralisée est possible dans un réseau Tivoli Workload Scheduler autonome grâce au montage et au partage de systèmes de fichiers. 1. Introduction Utilisez-vous plusieurs entités physiques ou logiques au niveau d un même site? Le réseau couvre-t-il plusieurs bâtiments et plusieurs étages dans chaque bâtiment? Utilisez-vous différents services ou fonctions commerciales? Utilisez-vous différentes applications? Ces considérations peuvent déterminer le choix d une configuration à plusieurs domaines. Par exemple, un domaine pour chaque bâtiment, service, fonction commerciale ou pour chaque application (fabrication, finances, ingénierie, etc.). Exécutez-vous des applications telles que SAP R/3 ou Baan qui vont fonctionner avec Tivoli Workload Scheduler? Si ces applications sont discrètes et séparées des autres applications, vous pouvez choisir de les placer dans un domaine Tivoli Workload Scheduler distinct. Souhaitez-vous que vos domaines Tivoli Workload Scheduler offrent une image miroir de vos domaines Windows NT? Ce n est pas obligatoire, mais peut s avérer utile. Souhaitez-vous isoler ou différencier un ensemble de systèmes en fonction de critères de performances ou d autres critères? Cette considération peut également motiver la définition de plusieurs domaines Tivoli Workload Scheduler afin de localiser des systèmes en fonction de leurs performances ou du type de plateforme. Quel est votre trafic réseau actuel? Si votre trafic réseau est facile à gérer, le besoin de plusieurs domaines est moins important. Est-ce que vos dépendances de travail traversent des limites de systèmes, des limites géographiques ou des limites d applications? Par exemple, est-ce que le début du travail Job1 sur CPU3 dépend de l aboutissement du travail Job2 s exécutant sur CPU4? Le degré d interdépendances entre les travaux est une considération importante lors de l agencement de votre réseau Tivoli Workload Scheduler. Si vous utilisez plusieurs domaines, vous devriez essayer de maintenir les objets interdépendants dans le même domaine. Cela permettra de réduire le trafic réseau et de mieux tirer parti de l architecture de domaine. Tivoli Workload Scheduler - Guide de planification et d installation 11

32 Planification du réseau De quel niveau de tolérance aux pannes avez-vous besoin? Une configuration à un seul domaine présente l inconvénient évident de ne reposer que sur un seul gestionnaire de domaine. Dans un réseau à plusieurs domaines, la défaillance d un seul gestionnaire de domaine affecte uniquement les agents appartenant au même domaine. Réseau à un seul domaine Un réseau Tivoli Workload Scheduler à un seul domaine est composé d un gestionnaire de domaine principal et d un certain nombre d agents. Le diagramme ci-dessous illustre un exemple de réseau à un seul domaine. Un réseau à un seul domaine est bien adapté aux entreprises utilisant peu d emplacements et de fonctions commerciales. Toutes les communications du réseau sont acheminées via le gestionnaire de domaine principal. Lorsque le réseau couvre un seul emplacement, vous ne vous préoccupez que de la fiabilité de votre réseau local et de la quantité de trafic qu il peut gérer. Il est important de noter que les réseaux à un seul domaine peuvent être combinés à d autres réseaux, à un seul ou à plusieurs domaines, afin de répondre aux besoins de plusieurs sites. Tivoli Workload Scheduler prend en charge les dépendances interréseau entre des travaux s exécutant sur des réseaux Tivoli Workload Scheduler différents. Le premier exemple montre un réseau à un seul domaine. Le gestionnaire de domaine principal se trouve à Atlanta, avec plusieurs agents. Des agents se trouvent également à Denver. Les agents de Denver dépendent du gestionnaire de domaine principal d Atlanta pour résoudre toutes les dépendances inter-agents, même si ces dépendances concernent des 12 Version 8.1

33 Planification du réseau travaux s exécutant à Denver. Une alternative consisterait à créer des réseaux Tivoli Workload Scheduler à un seul domaine séparés à Atlanta et à Denver, comme l illustre le deuxième exemple. Les réseaux à un seul domaine présentent les avantages suivants : Une architecture plus simple. Un contrôle et une gestion centralisés. Les réseaux à un seul domaine présentent les inconvénients suivants : Toutes les communications doivent passer par le gestionnaire de domaine principal. Cela peut se traduire par une charge importante sur un réseau largement réparti. La défaillance du gestionnaire de domaine principal affecte l ensemble du réseau Tivoli Workload Scheduler. Réseau à plusieurs domaines Les réseaux à plusieurs domaines sont particulièrement adaptés aux entreprises réparties sur plusieurs emplacements, utilisant plusieurs services ou plusieurs fonctions commerciales. Un réseau Tivoli Workload Scheduler à plusieurs domaines est composé d un gestionnaire de domaine principal, d un certain nombre de gestionnaires de domaine de niveau inférieur et d un certain nombre d agents dans chaque domaine. Les agents communiquent uniquement avec leurs gestionnaires de domaine, et les gestionnaires de domaine communiquent avec leurs gestionnaires de domaine parents. 1. Introduction Ce diagramme illustre un exemple de réseau à plusieurs domaines. Ce diagramme se base sur l exemple illustrant les réseaux à un seul domaine. Le gestionnaire de domaine principal se trouve à Atlanta ; il contient les fichiers de base de données utilisés pour documenter les objets de planification et il distribue le fichier Symphony à ses agents et aux gestionnaires de domaine situés à Denver et à Los Angeles. Les gestionnaires de domaine situés à Denver et à Los Angeles distribuent ensuite le fichier Symphony à leurs propres agents et aux gestionnaires de domaine subordonnés situés à Boulder, Aurora et Burbank. Le gestionnaire de domaine principal d Atlanta est chargé de diffuser les informations interdomaines à travers le réseau. Toutes les communications à destination et en provenance du gestionnaire de domaine de Boulder sont acheminées via son gestionnaire de domaine parent situé à Denver. Si des agendas ou des travaux du domaine de Boulder dépendent d agendas ou de travaux du domaine d Aurora, ces dépendances sont résolues par le gestionnaire de domaine de Denver. La plupart des dépendances inter-agents sont gérées localement par les gestionnaires de domaine de niveau inférieur, ce qui réduit considérablement le trafic sur le réseau étendu. Tivoli Workload Scheduler - Guide de planification et d installation 13

34 Planification du réseau Avantages des réseaux à plusieurs domaines : Les agendas et les travaux ad hoc peuvent être soumis à partir du gestionnaire de domaine principal ou de tout autre gestionnaire de domaine ou agent ayant accès aux fichiers de base de données se trouvant sur le gestionnaire de domaine principal. Trafic réseau réduit en raison du traitement localisé. Résolution locale des dépendances inter-agents. Sécurité et administration localisées. Topologie souple mise en correspondance avec votre modèle de gestion. Basculement instantané vers le gestionnaire de domaine de sauvegarde. Basculement vers un gestionnaire de domaine de sauvegarde Chaque domaine possède un gestionnaire de domaine et, en option, un ou plusieurs gestionnaires de domaine de sauvegarde. Un gestionnaire de domaine de sauvegarde doit se trouver dans le même domaine que le gestionnaire de domaine dont il assure la sauvegarde. Les gestionnaires de domaine de sauvegarde doivent être des agents tolérant les pannes exécutant la même version du produit que le gestionnaire de domaine dont ils sont censés prendre le relais, et les options Résolution des dépendances et Statut intégral doivent être activées dans leur définition de poste de travail. Si un gestionnaire de domaine tombe en panne au cours d un jour de production, vous pouvez utiliser soit Job Scheduling Console, soit la commande switchmgr de la ligne de commande de la console du gestionnaire (conman), pour basculer vers un gestionnaire de domaine de sauvegarde. Une action de basculement vers un autre gestionnaire peut être exécutée par toute personne possédant un droit de démarrage et d interruption sur les postes de travail du gestionnaire de domaine et du gestionnaire de domaine de sauvegarde. Une opération de basculement du gestionnaire entraîne l arrêt du gestionnaire de sauvegarde, puis le redémarrage de ce dernier en tant que nouveau gestionnaire de domaine, et la conversion de l ancien gestionnaire de domaine en un agent tolérant les pannes. L identité des gestionnaires de domaine en cours est transmise au fichier Symphony d un jour de traitement à l autre, de sorte que chaque basculement reste effectif jusqu à ce que vous basculiez de nouveau vers le gestionnaire de domaine d origine. Base de données étendue et noms d objet longs Les bases de données Tivoli Workload Scheduler et le fichier Symphony ont été étendus de façon à ce qu ils puissent prendre en charge un plus grand nombre d enregistrements et des noms d objet plus longs. Vous bénéficiez ainsi d une plus grande souplesse lors de l affectation de noms aux objets de planification, en particulier avec les progiciels tels que SAP R/3, Baan, etc. Les bases de données étendues sont utilisées par défaut dans Tivoli Workload Scheduler. Elles permettent l utilisation de noms longs pour les objets de planification ; par exemple, les noms de travaux peuvent contenir jusqu à quarante caractères au lieu de huit dans les versions antérieures. Les bases de données non étendues sont toujours prises en charge et obligatoires sur les agents MPE (HP3000). Remarque : Assurez-vous que le système maître exécute une version du planificateur égale ou inférieure à celle des agents FTA du domaine. 14 Version 8.1

35 Planification du réseau Création de bases de données Pour de nouvelles installations, les bases de données Tivoli Workload Scheduler sont créées sur le gestionnaire de domaine principal lorsque vous exécutez le moteur Tivoli Workload Scheduler pour la première fois. Le type de bases de données créé, étendues ou non étendues, est déterminé par vérification de la valeur de l option globale expanded version = [yes no]. Cette option est définie par le script de personnalisation lors de l installation du moteur Tivoli Workload Scheduler. Par défaut, l option expanded (étendue) a pour valeur yes. 1. Introduction Vous pouvez sélectionner des bases de données non étendues lorsque vous installez Tivoli Workload Scheduler pour la première fois, et étendre les bases de données ultérieurement. Pour étendre les bases de données, exécutez la commande dbexpand sur le gestionnaire de domaine principal. Le programme définit l option globale expanded version à yes, effectue des copies de sauvegarde des bases de données existantes et étend les bases de données afin d accepter les noms d objet longs. N exécutez dbexpand qu une fois, sinon la copie de sauvegarde des bases de données existantes sera perdue. Les copies de sauvegarde sont placées dans un répertoire intitulé mozart.old dans le répertoire mozart. Noms des postes de travail La planification des travaux dans un réseau Tivoli Workload Scheduler est répartie entre plusieurs ordinateurs. Afin de permettre un suivi précis des travaux, des agendas et des autres objets, un nom de poste de travail unique est affecté à chaque ordinateur. Les noms peuvent être identiques aux noms des noeuds du réseau à condition qu ils soient conformes aux règles d affectation des noms de Tivoli Workload Scheduler : Pour les réseaux non étendus, les noms de poste de travail peuvent contenir jusqu à huit caractères alphanumériques, tirets (-) et traits de soulignement (_) et doivent commencer par une lettre. Pour les réseaux étendus, la longueur maximale est de seize caractères alphanumériques, tirets (-) et traits de soulignement (_) et doivent commencer par une lettre. Présentation de l installation Voici une récapitulation du processus d installation pour Tivoli Workload Scheduler. Le présent guide fournit des instructions détaillées pour chacune des étapes. 1. Sur l ensemble des gestionnaires de domaine (y compris sur le gestionnaire de domaine principal et de sauvegarde), respectez l ordre suivant : a. Si vous effectuez une installation par dessus une version antérieure de Maestro ou de Tivoli Workload Scheduler, supprimez la liaison des autres postes de travail du domaine et arrêtez Maestro ou Tivoli Workload Scheduler. Reportez-vous aux sections «Suppression et arrêt de Tivoli Workload Scheduler» à la page 20 et «Mise à jour de Tivoli Workload Scheduler» à la page 38. Installez Tivoli Workload Scheduler. Reportez-vous au Chapitre 2, «Installation sous Windows NT» à la page 19 ou au Chapitre 3, «Installation sous UNIX» à la page 33. En fait, vous pouvez inverser l ordre d exécution de cette étape et de l étape suivante. b. Installez Tivoli Management Framework. Si vous ne disposez pas de région d administration Tivoli (TMR) dans votre entreprise, effectuez l installation en tant que serveur TMR. Si une région d administration Tivoli existe déjà, vous pouvez choisir d effectuer l installation en tant que noeud géré. Pour plus de détails, reportez-vous à la documentation d installation de TMF. Tivoli Workload Scheduler - Guide de planification et d installation 15

36 Présentation de l installation c. Installez Job Scheduling Services et le connecteur sur Tivoli Framework. Reportez-vous au manuel Tivoli Job Scheduling Console - Guide de l utilisateur. d. Dans le bureau Tivoli, créez un Administrateur Tivoli pour Tivoli Workload Scheduler. En d autres termes, vous devez soit ajouter l utilisateur TWS ou Maestro en tant que connexion pour l administrateur TMF, soit créer un nouvel administrateur TMF avec la connexion utilisateur TWS ou Maestro. e. Mettez à jour la sécurité Tivoli Workload Scheduler de façon à inclure l Administrateur Tivoli. Sous NT, vous devez arrêter Tivoli Workload Scheduler avant d exécuter la commande makesec. Sous UNIX, vous pouvez exécuter makesec sans qu il soit nécessaire d arrêter Tivoli Workload Scheduler préalablement, mais vous devez arrêter et redémarrer Tivoli Workload Scheduler pour activer la fonction de sécurité. f. Installez Job Scheduling Console. Reportez-vous au manuel Tivoli Job Scheduling Console - Guide de l utilisateur. 2. Installez ce qui suit sur chaque poste de travail que vous souhaitez inclure en tant qu agent dans le réseau Tivoli Workload Scheduler : Tivoli Workload Scheduler. Job Scheduling Console (facultatif). Vous pouvez également installer JS Console sur des postes de travail ne faisant pas partie du réseau Tivoli Workload Scheduler et qui sont dotés d une connexion TCP/IP avec un gestionnaire de domaine exécutant le connecteur. 3. Connectez-vous à Job Scheduling Console et définissez les postes de travail de votre réseau Tivoli Workload Scheduler dans la base de données du planificateur. 4. Vous pouvez alors utiliser Job Scheduling Console pour définir vos travaux, flux de travaux et autres objets de planification. Groupes de produits Tivoli Workload Scheduler est organisé en groupes de produits. Cela permet l installation de plusieurs copies d un produit sur un seul ordinateur en désignant un groupe différent pour chaque copie. Fichier des composants Les groupes de produits sont définis dans le fichier des composants. Si le fichier n existe pas préalablement à l installation, il est créé par le script customize sous UNIX, ou par le programme Setup sous Windows NT. Voici un exemple sous UNIX : <produit> <version> <répertoire principal> <groupe de produit> Maestro Netman /opt/maestro /opt/netman production production Les entrées du fichier sont automatiquement effectuées et mises à jour par customize ou Setup. Le groupe de produits workstation_user est utilisé par défaut sous NT si vous n indiquez pas de groupe. 16 Version 8.1

37 Groupes de produits Sous UNIX, le nom du fichier des composants est défini dans la variable : UNISON_COMPONENT_FILE Si cette variable n est pas définie, customize utilise le nom de fichier : /usr/unison/components Sous Windows NT, le nom du fichier des composants, netmanhome\components, est enregistré dans le registre lors de la première installation de cette version de Workload Scheduler. Reportez-vous à la section «Répertoire principal de Netman». 1. Introduction Affichage du fichier des composants Suite à l installation ou à la mise à jour, vous pouvez afficher le contenu du fichier des composants en exécutant le programme ucomp comme suit : ucomp -l Répertoire principal de Netman L option -nmhome du script customize sous UNIX vous permet d indiquer un répertoire principal pour Netman. Si cette option est ignorée, la valeur par défaut sous UNIX est le répertoire principal de Workload Scheduler. Options locales de Netman Si le répertoire principal de Netman n est pas le même que le répertoire principal de Workload Scheduler, les options locales suivantes sont déplacées du fichier localopts de Workload Scheduler vers un fichier localopts séparé dans le répertoire Netman : nm mortal nm port nm read nm retry merge stdlists stdlist width syslog local Et l option suivante peut être ajoutée, le cas échéant : nm ipvalidate Pour plus d informations sur les options locales, reportez-vous à la section 2 du guide de l administrateur de Tivoli Workload Scheduler. Après l installation Après avoir installé Tivoli Workload Scheduler, reportez-vous aux chapitres suivants : Chapitre 4, «Définition de la sécurité» à la page 47, pour définir les paramètres de sécurité de Tivoli Workload Scheduler ; Chapitre 5, «Etapes de personnalisation facultatives» à la page 67, pour définir des options locales et globales ; Annexe A, «Fuseaux horaires et audit» à la page 89, pour plus d informations sur ces options. Tivoli Workload Scheduler - Guide de planification et d installation 17

38 Après l installation 18 Version 8.1

39 2 Installation sous Windows NT Ce chapitre décrit le processus d installation de Tivoli Workload Scheduler sur les systèmes et les réseaux Windows NT. Configuration requise La configuration requise pour l installation de Tivoli Workload Scheduler sur les systèmes Windows NT est la suivante. Windows NT version 4.0 avec le Service Pack 5 ou 6a. Lecteur de CD-ROM pour l installation. Partition NTFS pour installer Tivoli Workload Scheduler. Environ 100 Mo d espace disponible pour les gestionnaires de domaine et pour les agents tolérant les pannes configurés en tant qu unités de secours principales. Environ 40 Mo pour les agents standard. En outre, Tivoli Workload Scheduler génère des fichiers journaux et des fichiers temporaires qui sont placés sur le disque dur local. La quantité d espace requise dépend du nombre de travaux gérés par Tivoli Workload Scheduler et de la durée de conservation définie pour les fichier journaux. 128 Mo de RAM et 128 Mo d espace de permutation pour les gestionnaires de domaine et les agents tolérant les pannes. Les agents standard requièrent moins d espace. Communications réseau TCP/IP. Un compte utilisateur Tivoli Workload Scheduler est nécessaire pour l installation. Vous pouvez créer le compte préalablement ou demander au programme d installation de le créer. Remarque : Si vous créez un utilisateur avant d exécuter le programme d installation, choisissez un nom d utilisateur qui ne contient pas de point (.). Les comptes utilisateur contenant des points sont réservés aux utilisateurs MPE. Pour plus de détails, reportez-vous à la section «Création manuelle du compte Tivoli Workload Scheduler» à la page 30. Avant de poursuivre, reportez-vous au manuel Tivoli Workload Scheduler - Release Notes pour obtenir les informations les plus récentes sur la configuration requise et sur les problèmes spécifiques aux plateformes. 2. Installation sous Windows NT Tivoli Workload Scheduler - Guide de planification et d installation 19

40 Installation pour la planification de bout en bout Installation pour la planification de bout en bout Si vous installez Tivoli Workload Scheduler sur un poste de travail qui fera office d agent réparti pour la planification de bout en bout (un gestionnaire de domaine, un agent tolérant les pannes ou un agent standard), vous devez procéder comme suit : 1. Indiquez OPCMASTER comme nom du gestionnaire de domaine principal dans la zone CPU principale de la fenêtre Informations de configuration décrite à l étape Définissez le fuseau horaire GMT pour le poste de travail après l installation. Cette opération est nécessaire pour activer la génération d états de début et de fin sur le contrôleur Tivoli Workload Scheduler pour z/os avec le fuseau horaire du contrôleur local et pour résoudre correctement les dépendances horaires. Pour plus de détails, reportez-vous à la section «Fuseaux horaires» à la page 89. Préparation en vue d une mise à jour S il s agit d une mise à jour d une installation existante de Tivoli Workload Scheduler, effectuez les étapes suivantes avant d exécuter le programme d installation. Une fois l installation terminée, reportez-vous à la section «Achèvement de la mise à jour» à la page 27 pour plus d informations sur des étapes de post-installation importantes. Remarque : L approche standard de mise à jour d un réseau Tivoli Workload Scheduler consiste à mettre à jour les agents tolérant les pannes et les agents standard dans un premier temps, puis le gestionnaire de domaine principal. Toutefois, avant de décider comment mettre à jour votre réseau Tivoli Workload Scheduler, reportez-vous au document Tivoli Workload Scheduler - Release Notes pour connaître les informations de dernière minute concernant le processus de migration vers une nouvelle version du logiciel. Suppression et arrêt de Tivoli Workload Scheduler Vous devez supprimer les liens des postes de travail et arrêter les processus Tivoli Workload Scheduler avant de lancer une mise à jour de votre installation. Procédez comme suit : 1. Dans Job Scheduling Console, supprimez le lien entre le poste de travail cible et les autres postes de travail du réseau. Vous pouvez également exécuter la commande suivante à partir de la ligne de commande : conman "unlink nompostedetravail;noask" 2. Dans Job Scheduling Console, arrêtez le poste de travail cible. A partir de la ligne de commande, exécutez les commandes suivantes : conman stop conman shut;wait Vous pouvez accomplir la même tâche en exécutant l une des deux actions suivantes : 1. Arrêtez le processus à partir du Gestionnaire des tâches de Windows NT. 2. Exécutez la commande suivante à partir d une fenêtre d invite de commandes MSDOS : maestrohome/shutdown 20 Version 8.1

41 Préparation en vue d une mise à jour Fichiers de sauvegarde Le programme d installation de Tivoli Workload Scheduler va déplacer vos copies de Sfinal, Jnextday, NetConf, StartUp et le répertoire des méthodes vers un répertoire intitulé : TWShome\config.old Ces fichiers sont souvent personnalisés de façon à répondre à vos besoins spécifiques et vous pouvez utiliser les copies sauvegardées pour incorporer vos modifications une fois la mise à jour terminée. Le programme d installation n écrase pas les fichiers du répertoire mozart, du répertoire stdlist ou du répertoire unison qui ont été modifiés après l installation de Tivoli Workload Scheduler. Si vous souhaitez protéger d autres fichiers au cours de la mise à jour, copiez-les ou renommez-les maintenant. Par mesure de précaution, vous devriez également effectuer une sauvegarde de l intégralité du répertoire TWShome. Vous êtes maintenant prêt à exécuter le programme d installation. Reportez-vous à la section «Installation du logiciel». Installation du logiciel Utilisez le programme d installation pour installer le moteur Tivoli Workload Scheduler sous Windows NT. Le programme d installation Le programme d installation installe ou met à jour Tivoli Workload Scheduler. Il exécute les fonctions suivantes : Nouvelle installation de Tivoli Workload Scheduler : il installe Tivoli Workload Scheduler et Netman. Il crée un fichier de composants contenant de nouvelles entrées. Première mise à jour de Maestro : il met à jour Tivoli Workload Scheduler et Netman, si nécessaire. Il crée un fichier de composants contenant de nouvelles entrées. Mises à jours suivantes de Tivoli Workload Scheduler : il met à jour Tivoli Workload Scheduler et Netman, si nécessaire. Il met à jour les entrées du fichier des composants. Exécution du programme d installation 1. Assurez-vous que vous disposez des privilèges d administrateur local pour le poste de travail sur lequel vous allez installer Tivoli Workload Scheduler. 2. Fermez toutes les autres applications Windows ouvertes, y compris Windows NT Explorer. 3. Insérez le CD Tivoli Workload Scheduler. 4. Exécutez le programme d installation de Tivoli Workload Scheduler : d:\tws\i386\maestro\setup.exe où d est la lettre désignant votre lecteur de CD-ROM. 5. La fenêtre Sélection de la langue d installation s affiche. Sélectionnez votre langue d installation et cliquez sur OK. 2. Installation sous Windows NT Tivoli Workload Scheduler - Guide de planification et d installation 21

42 Installation du logiciel 6. La fenêtre de bienvenue s affiche. 7. Cliquez sur Suivant > dans la fenêtre de bienvenue pour continuer. La fenêtre Avertissement relatif au processus s affiche. Pour continuer, cliquez sur Suivant >. Si vous effectuez une mise à jour de Tivoli Workload Scheduler, assurez-vous que tous les processus Tivoli Workload Scheduler sont arrêtés, y compris Tivoli services. Si vous avez désinstallé Tivoli Workload Scheduler avant d exécuter le programme d installation, vous devez redémarrer votre ordinateur avant de poursuivre (pour plus de détails sur la désinstallation, reportez-vous à la section «Désinstallation de Tivoli Workload Scheduler» à la page 32). Pour accomplir ces tâches, quittez le programme d installation en cliquant sur Annuler. 22 Version 8.1

43 Installation du logiciel 8. Dans la fenêtre Options d installation, sélectionnez le type d installation et cliquez sur Suivant >. 2. Installation sous Windows NT Copie des fichiers et personnalisation Copiez les fichiers Netman à partir du CD-ROM et personnalisez l installation. Cette option doit être sélectionnée pour les nouvelles installations et les mises à jour. Personnalisation uniquement Personnalisez les fichiers existants. Cette option restaure les valeurs par défaut des droits d accès aux fichiers. Tivoli Workload Scheduler - Guide de planification et d installation 23

44 Installation du logiciel 9. Dans la fenêtre Informations relatives au compte, entrez les informations suivantes, puis cliquez sur Suivant > : Compte Le nom de l utilisateur Tivoli Workload Scheduler (généralement twsuser ou maestro). Si vous entrez un nom autre que twsuser ou maestro, veillez à ce qu il ne contienne pas le caractère point (.) qui est réservé aux noms d utilisateur MPE. Le logiciel est installé, ou mis à jour, dans le répertoire indiqué. Vous pouvez inclure le domaine, le cas échéant. Par exemple : hqtrs\twsuser. Si vous n indiquez pas le domaine, le programme d installation recherche un compte correspondant : 1) localement, 2) dans le domaine, ou 3) dans un domaine sécurisé. Le programme d installation crée automatiquement le compte et, si nécessaire, le répertoire principal et il leur affecte les droits nécessaires. Mot de passe Le mot de passe du compte. Confirmation Entrez de nouveau le mot de passe du compte. Remarque : Si vous installez plusieurs instances de Tivoli Workload Scheduler sur un ordinateur, notez que chaque installation va essayer de placer des fichiers dans le répertoire TWShome\..\unison. Assurez-vous que les répertoires parents sont différents de façon à éviter les conflits. Par exemple, c:\apps\maestro et c:\apps1\maestro. 10. Sélectionnez le répertoire de destination dans lequel vous souhaitez installer Tivoli Workload Scheduler. Si le répertoire par défaut ne vous convient pas, cliquez sur Parcourir pour indiquer un choix différent. Une fois que vous avez terminé, cliquez sur Suivant pour continuer. 24 Version 8.1

45 Installation du logiciel 11. Dans la fenêtre Extension de la base de données, choisissez l une des options suivantes et cliquez sur Suivant >. Cette fenêtre ne s affiche pas si vous effectuez une mise à jour d une installation existante. 2. Installation sous Windows NT Bases de données étendues (Noms d objets longs) Utilisez les bases de données étendues qui ne sont disponibles que dans Maestro 6.0 et dans Tivoli Workload Scheduler. Bases de données non étendues Utilisez les bases de données non étendues. Cette option doit être utilisée pour installer Tivoli Workload Scheduler sur le gestionnaire de domaine principal d un réseau qui contient des postes de travail exécutant n importe quelle version de Maestro pour MPE. Les bases de données peuvent être étendues ultérieurement à l aide de la commande dbexpand. Pour plus d informations sur la commande dbexpand, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence. Remarque : Si votre réseau comprend des postes de travail MPE, vous devez utiliser le mode non étendu. Les postes de travail MPE ne peuvent pas être inclus dans les réseaux Tivoli Workload Scheduler étendus. Tivoli Workload Scheduler - Guide de planification et d installation 25

46 Installation du logiciel 12. Dans la fenêtre Informations de configuration, entrez les informations suivantes, puis cliquez sur Suivant > : Entreprise Le nom de votre société. Cette CPU Le nom Tivoli Workload Scheduler de ce poste de travail. Pour la version non étendue de Tivoli Workload Scheduler, ce nom peut contenir jusqu à huit caractères alphanumériques, tirets (-) ou traits de soulignement (_) et doit commencer par une lettre. Pour la version étendue, la longueur est de seize caractères. Ce nom doit être utilisé plus tard pour définir le poste de travail officiellement dans Tivoli Workload Scheduler. CPU principale Le nom Tivoli Workload Scheduler du gestionnaire de domaine principal. Si ce poste est le gestionnaire de domaine principal, ou un poste de travail autonome, ce nom est le même que Cette CPU. Pour la version non étendue de Tivoli Workload Scheduler, ce nom peut contenir jusqu à huit caractères alphanumériques, tirets (-) ou traits de soulignement (_) et doit commencer par une lettre. Pour la version étendue, la longueur est de seize caractères. Si vous effectuez l installation sur le gestionnaire de domaine principal, le programme d installation crée sa définition de poste de travail automatiquement. Groupe de produits Le nom du groupe de produits pour cette installation ou mise à jour. La valeur par défaut est workstation_user. 13. Dans la fenêtre Port Netman, entrez le numéro du port Netman et cliquez sur Suivant >. Il doit s agir d une valeur 16 bits non signée comprise dans la fourchette (n oubliez pas que les valeurs comprises entre 0 et 1023 sont réservées aux services connus, tels que FTP, TELNET, HTTP, etc.). La valeur par défaut est Version 8.1

47 Installation du logiciel 14. Finalement, la fenêtre Informations de configuration résume les informations que le programme Setup va utiliser pour installer Tivoli Workload Scheduler. Cliquez sur < Précédent pour vérifier ou modifier les informations, ou cliquez sur Suivant > pour installer ou mettre à jour Tivoli Workload Scheduler et quitter le programme d installation. 2. Installation sous Windows NT 15. Vous avez maintenant terminé l installation du moteur Tivoli Workload Scheduler. Après l installation et la mise à jour Exécutez les tâches suivantes après avoir installé ou mis à jour Tivoli Workload Scheduler. Achèvement de la mise à jour S il s agit de la mise à jour d une installation existante, procédez comme suit : 1. Sur chaque poste de travail mis à jour, en utilisant comme référence les fichiers que vous avez protégés à la section «Préparation en vue d une mise à jour» à la page 20, appliquez vos modifications aux nouvelles versions des fichiers. 2. Sur le gestionnaire de domaine principal, redémarrez Tivoli Workload Scheduler. Le processus de mise à jour de Tivoli Workload Scheduler est maintenant terminé. Tivoli Workload Scheduler - Guide de planification et d installation 27

48 Après l installation et la mise à jour Définition de la variable PATH Connectez-vous en tant qu utilisateur du groupe Administrateurs locaux ou Administrateurs de domaine. Dans l environnement système, ajoutez les répertoires TWShome et TWShome\bin à la variable PATH. Par exemple : other_directories;c:\win32app\maestro;c:\win32app\maestro\bin Répertoires et services Tivoli Workload Scheduler Le programme Setup installe les fichiers Tivoli Workload Scheduler dans les répertoires TWShome et dans TWShome\..\unison, qui sont également utilisés par d autres produits Tivoli. Par exemple, si TWShome correspond à c:\win32app\maestro, alors le répertoire c:\win32app\unison est également créé. Le programme Setup enregistre également les services suivants auprès du Gestionnaire de contrôle des services : Tivoli MAESTRO pour user Tivoli Netman pour wkstn_user Tivoli Token Service pour user Notez que le Gestionnaire de contrôle des services gère sa propre base de données des mots de passe utilisateur. Par conséquent, si le mot de passe TWSuser est modifié après l installation, vous devez utiliser l applet Services du Panneau de configuration pour affecter le nouveau mot de passe aux services Token Service et Netman. Service Tivoli Workload Scheduler Le service Jobmon s exécute dans le compte SYSTEM en disposant du droit Autoriser le service à interagir avec le bureau. Vous pouvez supprimer ce droit pour des raisons de sécurité. Toutefois, cette suppression empêchera le service de lancer des travaux interactifs s exécutant dans une fenêtre sur le bureau de l utilisateur. Ces travaux se sont pas accessibles et n ont pas accès aux ressources du bureau. En conséquence, ils peuvent s exécuter en boucle ou s arrêter de façon anormale en raison du manque de ressources. Configuration de l administration décentralisée Vous pouvez administrer les objets de planification Tivoli Workload Scheduler à partir d ordinateurs autres que le gestionnaire de domaine principal où réside la base de données. Si vous avez l intention d administrer les objets de planification de cette manière, vous devez créer des partages pour les répertoires dans le gestionnaire de domaine principal et définir un ensemble d options locales sur les autres ordinateurs. Partage des répertoires principaux Faites en sorte que les répertoires suivants soient partageables sur le gestionnaire de domaine principal, puis définissez les droits d accès de façon à accorder le contrôle total à l utilisateur du domaine, TWS ou maestro. TWShome\mozart TWShome\..\unison\network Partage des paramètres Tivoli Workload Scheduler Les paramètres de substitution Tivoli Workload Scheduler sont normalement spécifiques à un ordinateur et administrés séparément sur chaque ordinateur. Si vous souhaitez que ces paramètres soient communs à l ensemble des ordinateurs et puissent être administrés à partir de n importe quel ordinateur, vous pouvez soit partager le répertoire TWShome en suivant les instruction fournies plus haut pour d autres répertoires, soit copier la base de données de 28 Version 8.1

49 Après l installation et la mise à jour paramètres, chaque fois qu elle est modifiée, depuis le gestionnaire de domaine principal sur chacun des autres ordinateurs. Les fichiers de base de données sont les suivants : TWShome\parameters TWShome\parameters.KEY Utilisation d un seul partage Une alternative au partage de différents répertoires consiste à déplacer l ensemble des fichiers de base de données dans un répertoire commun, de partager ce répertoire, puis de définir les options locales, décrites ci-dessous, sur le nom du partage. Les fichiers de base de données sont répertoriés ci-dessous. Dans TWShome\..\unison\ : cpudata cpudata.key userdata userdata.key Dans TWShome\mozart\ : calendars calendars.key job.sched job.sched.key jobs jobs.key mastsked mastsked.key prompts prompts.key resources resources.key Dans TWShome : parameters parameters.key Les fichiers sont créés en fonction des besoins de Tivoli Workload Scheduler. S ils n existent pas, vous pouvez simplement définir les options locales sur le répertoire partagé comme décrit ci-dessous. 2. Installation sous Windows NT Définition des options locales Pour accéder aux bases de données maîtres partagées, définissez les options locales sur chacun des ordinateurs à partir desquels vous souhaitez administrer les objets de planification Tivoli Workload Scheduler. Voici la description de ces options ainsi que la procédure à suivre pour les modifier. Notez que chaque option peut recevoir un nom conventionnel (lecteur:\partage) ou un nom UNC (\\noeud\partage). Si un nom conventionnel est défini, l utilisateur maestro doit se connecter explicitement au partage. Si un nom UNC est défini, une connexion explicite n est pas requise. Les options locales sont les suivantes : mozart directory Définit le nom du répertoire mozart partagé de l unité maître. unison network directory Définit le nom du répertoire unison partagé de l unité maître. parameters directory Définit le nom du répertoire TWShome partagé de l unité maître. Tivoli Workload Scheduler - Guide de planification et d installation 29

50 Après l installation et la mise à jour Sur chacun des ordinateurs, définissez les options comme suit : 1. Utilisez un éditeur de votre choix pour ouvrir et modifier le fichier TWShome\localopts. 2. Les options existent en tant que commentaires dans le fichier fourni par Tivoli. Pour définir une option, supprimez le signe # de la colonne 1 et modifiez la valeur de façon à pointer vers le répertoire approprié. Par exemple, pour accéder tous les objets à l exception des paramètres : mozart directory = \\hub\mozart unison network directory = \\hub\unison # parameters directory = d:\maestro 3. Enregistrez le fichier et quittez le programme. 4. Arrêtez et redémarrez Tivoli Workload Scheduler (y compris Netman) pour que les modifications soient prises en compte. Si une option n est pas définie ou n existe pas, le programme Composer de Tivoli Workload Scheduler tente d accéder aux fichiers de base de données sur l ordinateur local. Définition des options locales sur l unité maître Si les fichiers de base de données ont été déplacés des répertoires par défaut, tels qu ils sont répertoriés à la section Utilisation d un seul partage, vous devez définir les options locales sur le gestionnaire de domaine principal en fonction du nouvel emplacement. Reportez-vous à la section Définition des options locales ci-dessus. Création manuelle du compte Tivoli Workload Scheduler Les nouvelles installations de Tivoli Workload Scheduler nécessitent un compte utilisateur possédant des droits spécifiques dans lequel le logiciel sera installé. Le programme d installation crée ce compte utilisateur automatiquement. Si vous souhaitez le créer manuellement, procédez comme suit. Remarque : Les procédures suivantes présupposent une bonne connaissance de la gestion des comptes Windows NT, et notamment de la façon de créer des comptes et d affecter des droits utilisateur. Si vous ne possédez pas ces connaissances, consultez votre administrateur Windows NT ou reportez-vous à la documentation Microsoft et à l aide en ligne Windows NT. Types d administration Tivoli Workload Scheduler Les bases de données contenant les objets de planification Tivoli Workload Scheduler résident sur l ordinateur que vous définissez en tant que gestionnaire de domaine principal. Vous pouvez administrer les objets de planification de l une des deux façons suivantes : 1) centralisée, uniquement à partir du gestionnaire de domaine principal, ou 2) décentralisée, à partir de plusieurs ordinateurs Tivoli Workload Scheduler. Choisissez la procédure appropriée ci-dessous en fonction de la façon dont vous souhaitez administrer les objets de planification Tivoli Workload Scheduler. Administration centralisée Si vous allez administrer les objets de planification uniquement à partir du gestionnaire de domaine principal, utilisez la procédure suivante pour créer le compte utilisateur (généralementtws ou maestro). 30 Version 8.1

51 Création manuelle du compte Tivoli Workload Scheduler 1. Créez un compte utilisateur local appelé TWS sur l ordinateur que vous allez utiliser en tant que gestionnaire de domaine principal Tivoli Workload Scheduler. Notez que ce nom doit être utilisé sur tous les ordinateurs du réseau Tivoli Workload Scheduler, y compris sur les ordinateurs UNIX. Remarque : Vous pouvez également utiliser un compte utilisateur existant. Cependant, assurez-vous que ce compte utilisateur se trouve dans le groupe des Administrateurs NT. 2. Affectez un répertoire principal au compte utilisateur TWS. Par exemple : C:\win32app\maestro N indiquez pas le répertoire racine d une unité. Le logiciel Tivoli Workload Scheduler sera installé dans le répertoire principal de ce compte utilisateur. Dans la documentation, ce répertoire est également appelé TWShome. 3. Affectez au compte utilisateur TWS les droits utilisateur avancés suivants : Agir en tant que partie du système d exploitation Augmenter les quotas Connecter par lots Ouvrir une session en tant que service Ouvrir une session localement Remplacer un jeton niveau de processus 2. Installation sous Windows NT Vous êtes maintenant prêt à exécuter le programme Setup. Reportez-vous à la section «Installation du logiciel» à la page 21. Administration décentralisée Si vous allez administrer les objets de planification à partir de plusieurs ordinateurs Tivoli Workload Scheduler, en plus du gestionnaire de domaine principal, utilisez la procédure suivante pour créer le compte utilisateur TWS. Remarque : Une fois le logiciel installé, il sera nécessaire de créer des partages afin de permettre l accès aux bases de données résidant sur le gestionnaire de domaine principal. Cet aspect est traité à la section «Partage des répertoires principaux» à la page Créez un compte de domaine appelé TWS dans le domaine de l ordinateur que vous allez utiliser en tant que gestionnaire de domaine principal Tivoli Workload Scheduler. Notez que ce nom doit être aussi utilisé sur tous les ordinateurs UNIX du réseau Tivoli Workload Scheduler. Remarque : Vous pouvez également utiliser un compte utilisateur existant. Cependant, assurez-vous que ce compte utilisateur se trouve dans le groupe des Administrateurs NT. 2. Affectez un répertoire principal au compte utilisateur TWS. Par exemple : C:\win32app\maestro N indiquez pas le répertoire racine d une unité. Le logiciel Tivoli Workload Scheduler sera installé dans le répertoire principal de ce compte utilisateur. Dans la documentation, ce répertoire est également appelé TWShome. 3. Sur chaque ordinateur à partir duquel Tivoli Workload Scheduler va être géré, affectez les droits utilisateur avancés suivants au compte utilisateur TWS : Agir en tant que partie du système d exploitation Augmenter les quotas Tivoli Workload Scheduler - Guide de planification et d installation 31

52 Création manuelle du compte Tivoli Workload Scheduler Connecter par lots Ouvrir une session en tant que service Ouvrir une session localement Remplacer un jeton niveau de processus Vous êtes maintenant prêt à exécuter le programme Setup. Reportez-vous à la section «Installation du logiciel» à la page 21. Désinstallation de Tivoli Workload Scheduler Les programmes de désinstallation supprimeront les fichiers produit, les clés du registre, les services et les groupes de programmes. Notez que la désinstallation ne supprimera pas les fichiers créés après l installation de Tivoli Workload Scheduler, ni les fichiers qui sont ouverts au moment de la désinstallation. Vous devez utiliser l outil Ajout/Suppression de Windows NT pour désinstaller Tivoli Workload Scheduler. Utilisation de l outil Ajout/Suppression de Windows NT Pour désinstaller Tivoli Workload Scheduler sous Windows NT, vous devez posséder un compte utilisateur TWS doté des droits administrateur Windows NT. Procédez comme suit : 1. Arrêtez Tivoli Workload Scheduler ainsi que tous les services Tivoli Workload Scheduler. Pour plus de détails, reportez-vous à la section «Suppression et arrêt de Tivoli Workload Scheduler» à la page Dans le dossier Panneau de configuration, exécutez Ajout/Suppression de programmes. 3. Sous l onglet Installation/Désinstallation, sélectionnez Tivoli Workload Scheduler (User=username) pour le supprimer. 4. Cliquez sur le bouton Ajouter/Supprimer. Dans la boîte de dialogue, cliquez sur Oui. 5. Quittez Ajout/Suppression de programmes. 6. Arrêtez et redémarrez votre ordinateur. Les fichiers créés lors de l installation des produits sont supprimés lors de la désinstallation. Toutefois, les fichiers créés ou modifiés après l installation ne sont pas supprimés. Vous pouvez conserver ces fichiers en vue de les utiliser avec une installation ultérieure de Tivoli Workload Scheduler. 32 Version 8.1

53 3 Installation sous UNIX Cette section explique le processus d installation de Tivoli Workload Scheduler sur les systèmes et réseaux UNIX. Configuration requise Voici la configuration requise pour l installation de Tivoli Workload Scheduler sur les ordinateurs UNIX. Lecteur de CD-ROM pour l installation. Environ 120 Mo d espace disponible pour les gestionnaires de domaine et pour les agents tolérant les pannes. Environ 80 Mo pour les agents standard. En outre, Tivoli Workload Scheduler génère des fichiers journaux et des fichiers temporaires qui sont placés sur le disque dur local. La quantité d espace utilisée dépend du nombre de travaux gérés par Tivoli Workload Scheduler et de la durée de conservation définie pour les fichier journaux. 32 Mo de RAM et 48 Mo d espace de permutation pour les gestionnaires de domaine et les agents tolérant les pannes. Les agents standard requièrent moins d espace. Les agents tolérant les pannes ont la possibilité de monter des répertoires à partir du gestionnaire de domaine principal. Cette approche nécessite le système de gestion de fichiers en réseau NFS. Pour plus d informations, consultez vos administrateurs système et réseau et reportez-vous au manuel Tivoli Workload Scheduler User s Guide. Sous Digital UNIX, la variable d environnement LD_NO_LIBSTREAMSOCKET doit avoir pour valeur 0 et être exportée préalablement à l installation de Tivoli Workload Scheduler. Avant de poursuivre, reportez-vous au manuel Tivoli Workload Scheduler Release Notes pour obtenir des informations détaillées. 3. Installation sous UNIX Installation pour la planification de bout en bout Si vous installez Tivoli Workload Scheduler sur un poste de travail qui fera office d agent réparti pour la planification de bout en bout (un gestionnaire de domaine, un agent tolérant les pannes ou un agent standard), vous devez procéder comme suit : 1. Indiquez OPCMASTER comme nom du gestionnaire de domaine principal dans le script customize. 2. Définissez le fuseau horaire GMT pour le poste de travail après l installation. Cette opération est nécessaire pour activer la génération d états de début et de fin sur le Tivoli Workload Scheduler - Guide de planification et d installation 33

54 Installation pour la planification de bout en bout contrôleur Tivoli Workload Scheduler pour z/os avec le fuseau horaire du contrôleur local et pour résoudre correctement les dépendances horaires. Ajoutez les lignes suivantes au script du shell StartUp : TZ=GMT export TZ Pour plus de détails, reportez-vous à la section «Fuseaux horaires» à la page 89. Procédure d installation Suivez les instructions fournies ci-dessous sur les ordinateurs UNIX si vous installez Tivoli Workload Scheduler pour la première fois, ou si Tivoli Workload Scheduler a été entièrement désinstallé. Pour les ordinateurs Windows NT, reportez-vous au Chapitre 2, «Installation sous Windows NT» à la page 19. Installation du moteur Tivoli Workload Scheduler Exécutez les étapes suivantes pour installer Tivoli Workload Scheduler sur un ordinateur UNIX. 1. Créez le compte utilisateur Tivoli Workload Scheduler. Le logiciel est installé dans le répertoire principal du compte utilisateur également appelé twshome. Utilisateur : maestro Groupe : tivoli Répertoire principal : twshome (par exemple : /opt/maestro) Remarque : Si vous installez plusieurs instances de Tivoli Workload Scheduler sur un ordinateur, notez que chaque installation va essayer de placer des fichiers dans le répertoire twshome/../unison. Assurez-vous que les répertoires parents sont différents de façon à éviter les conflits. Par exemple, /opt/maestro, et /opt/maestro2. 2. Montez la bande ou le CD d installation et restaurez le logiciel. a. Connectez-vous avec des droits root et changez votre répertoire en twshome. b. Extrayez le logiciel : tar -xvf cd/tws/plateforme/maestro.tar où : cd Le chemin d accès de votre lecteur de CD. plateforme Votre type de plateforme, qui peut être l un des suivants : AIX (pour IBM) DYNIX (pour IBM-Sequent Numa) HPUX (pour Hewlett Packard UNIX) IRIX (pour SGI Irix) LINUX 34 Version 8.1

55 Procédure d installation I386 (pour Linux sur Intel) S390 (pour Linux sur 390) (pour Data General UNIX) OSF (pour Compaq True64) SOLARIS (pour Sun Solaris) 3. Exécutez le script customize. Voici, par exemple, un modèle de script de personnalisation pour un poste de travail gestionnaire de domaine principal : /bin/sh customize -new -thiscpu mdm -master mdm -uname twsuser -group group1 [autres_opts] Voici, par exemple, un modèle de script de personnalisation pour un poste de travail d agent tolérant les pannes (FTA) : /bin/sh customize -new -thiscpu dm1 -master mdm -uname twsuser -group group1 [options] Si vous utilisez un système HP-UX 10.x, votre shell Bourne peut se trouver dans le répertoire /usr. Dans ce cas, utilisez la syntaxe suivante : /usr/bin/sh customize -new -thiscpu mdm -master mdm -uname twsuser -group group1 [autres_opts] Pour plus d informations sur les arguments du script de personnalisation et pour obtenir d autres exemples, reportez-vous à la section Le script de personnalisation à la page Créez un fichier.profile pour le compte utilisateur maestro, si ce fichier n existe pas déjà (twshome/.profile). Editez le fichier et modifiez la variable PATH de façon à inclure twshome et twshome/bin. Par exemple : PATH=/bin:/usr/bin:/usr/local/bin:/opt/maestro:/opt/maestro/bin:$PATH Si l instruction PATH se termine par un point (.), nous vous recommandons de remplacer ce point par les chemins ci-dessus ou d insérer les chemins avant le point. Si l instruction PATH ne contient pas de point, ajoutez simplement les chemins à la fin. 5. Pour lancer le processus de gestion de réseau de Tivoli Workload Scheduler, Netman, automatiquement en tant que démon chaque fois que vous démarrez le système, ajoutez ce qui suit au fichier /etc/rc ou au fichier approprié pour votre système : Pour lancer uniquement Netman : if [-x twshome/startup] then echo "netman started..." /bin/su - maestro -c " twshome/startup" fi 3. Installation sous UNIX Ou, pour lancer l intégralité de l arborescence de processus Tivoli Workload Scheduler : if [-x twshome/bin/conman] then echo "Workload Scheduler started..." /bin/su - maestro -c " twshome/bin/conman start" fi Le processus d installation de Tivoli Workload Scheduler est maintenant terminé. Tivoli Workload Scheduler - Guide de planification et d installation 35

56 Procédure d installation Etapes de configuration Pour les installations sous UNIX, exécutez les tâches de configuration suivantes. Ces tâches doivent être exécutées à partir des interfaces de ligne de commande de composer et conman. Une fois que vous avez configuré le gestionnaire de domaine principal de cette façon, vous pouvez utiliser Job Scheduling Console pour configurer d autres postes de travail et les objets de planification de travaux de votre réseau Tivoli Workload Scheduler. Pour plus de détails sur la commande utilisée ci-dessous, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence. Pour plus d informations sur l utilisation de Job Scheduling Console pour configurer les autres postes de travail du réseau, reportez-vous au manuel Tivoli Job Scheduling Console - Guide de l utilisateur. Configuration d un gestionnaire de domaine principal après l installation 1. Connectez-vous au gestionnaire de domaine principal en tant que maestro. Il s agit de la variable d identification tws_user qui, sous UNIX, prend par défaut la valeur maestro. L ID tws_user sous UNIX peut être modifiée à l aide de l argument -uname dans le script customize. 2. Créez la définition du poste de travail gestionnaire de domaine principal dans la base de données Tivoli Workload Scheduler en utilisant la ligne de commande composer. Ouvrez une fenêtre de ligne de commande dans UNIX et entrez les commandes suivantes : composer new 3. Cette commande ouvre un éditeur de texte à partir duquel vous pouvez créer la définition du poste de travail gestionnaire de domaine principal dans la base de données Tivoli Workload Scheduler. Vous trouverez ci-dessous un exemple de définition de poste de travail pour un gestionnaire de domaine principal. Pour plus d informations sur les définitions de poste de travail, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence. cpuname MDM os UNIX node master.santaclara.tivoli.com description "Master Domain Manager" for Maestro autolink on resolvedep on fullstatus on end 4. Créez la définition du flux de travaux final. Ce flux de travaux contient le travail Jnextday qui automatise la création du fichier Symphony. composer add Sfinal Vous pouvez automatiser cette étape pour la première fois après l installation. Pour plus de détails, reportez-vous à la section «Automatisation du cycle de production» à la page Exécutez le travail Jnextday : Jnextday 36 Version 8.1

57 Procédure d installation Vous pouvez automatiser cette étape pour la première fois après l installation. Pour plus de détails, reportez-vous à la section «Automatisation du cycle de production» à la page Une fois l exécution du travail Jnextday terminée, vérifiez le statut de Tivoli Workload Scheduler : conman status Si Tivoli Workload Scheduler a démarré correctement, le statut est Batchman=LIVES. 7. Augmentez la limite de façon à autoriser l exécution des travaux. La limite par défaut pour les travaux a pour valeur zéro après l installation. Cela signifie qu aucun travail ne va s exécuter. Vous devez donc augmenter cette limite des travaux maintenant : conman limit;10 Vous pouvez alors commencer à définir des objets de planification supplémentaires dans l interface de ligne de commande, y compris des postes de travail, des travaux et des flux de travaux, ou vous pouvez continuer à installer Job Scheduling Console et le connecteur. Notez que les nouveaux objets ne sont pas reconnus tant que le travail Jnextday ne s exécute pas dans le flux de travaux final. Par défaut le flux de travaux final s exécute à 05:59 (vous pouvez changer cette valeur par défaut ; pour plus de détails, reportez-vous à la section «Modification du début de la journée» à la page 83. Si vous souhaitez incorporer de nouveaux objets de planification plus tôt, vous pouvez exécuter conman release final ou utiliser la commande Conman submit. Pour plus d informations sur la définition de vos objets de planification, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence ou au manuel Tivoli Job scheduling Console - Guide de l utilisateur. Configuration d un agent tolérant les pannes après l installation 1. Connectez-vous à l agent tolérant les pannes (FTA) en tant que maestro. Il s agit de la variable d identification tws_user qui, sous UNIX, prend par défaut la valeur maestro. L ID tws_user sous UNIX peut être modifiée à l aide de l argument -uname dans le script customize. 2. Créez la définition du poste de travail d agent FTA dans la base de données Tivoli Workload Scheduler en utilisant la ligne de commande composer. Ouvrez une fenêtre de ligne de commande dans UNIX et entrez les commandes suivantes : composer new 3. Cette commande ouvre un éditeur de texte à partir duquel vous pouvez créer la définition du poste de travail d agent FTA dans la base de données Tivoli Workload Scheduler. Vous trouverez ci-dessous un exemple de définition d agent tolérant les pannes. Pour plus d informations sur les définitions de poste de travail, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence. cpuname DM1 os UNIX node domain1.santaclara.tivoli.com description "Domain Manager" for Maestro autolink on end 3. Installation sous UNIX Tivoli Workload Scheduler - Guide de planification et d installation 37

58 Procédure d installation 4. Exécutez la commande StartUp pour lancer Netman. conman StartUp 5. Créez un nouveau fichier Symphony contenant la définition du poste de travail d agent FTA. Pour ce faire, exécutez le travail Jnextday sur le gestionnaire de domaine principal, ce qui automatise la création d un nouveau fichier Symphony : Jnextday 6. Emettez la commande de lien à partir du gestionnaire de domaine principal afin de lier l agent FTA et de télécharger le fichier Symphony sur cet agent : conman link nomfta Mise à jour de Tivoli Workload Scheduler Utilisez cette procédure pour mettre à jour les installations Tivoli Workload Scheduler existantes sur les ordinateurs UNIX. L ordre recommandé pour effectuer la mise à jour d un réseau Tivoli Workload Scheduler consiste à procéder en premier lieu à la mise à jour de tous les postes de travail des agents, puis à celle du gestionnaire de domaine principal. Remarque : Pour plus d informations détaillées sur la mise à jour d un logiciel existant, reportez-vous au manuel Tivoli Workload Scheduler - Release Notes. Les rubriques ci-dessous relatives à la mise à jour sont présentées dans l ordre où les tâches doivent être exécutées. Préparation-arrêt de Tivoli Workload Scheduler 1. Dans Job Scheduling Console, supprimez le lien entre le poste de travail cible et les autres postes de travail du réseau. Vous pouvez également exécuter la commande suivante à partir de la ligne de commande : conman "unlink nompostedetravail;noask" 2. Dans Job Scheduling Console, arrêtez le poste de travail cible. A partir de la ligne de commande, exécutez les commandes suivantes : conman stop conman shut;wait 3. Si vous effectuez la mise à jour d un agent, supprimez (démontez) du gestionnaire du domaine principal tous les répertoires montés du système NFS. Sauvegarde Le script customize va déplacer vos copies de travail de Sfinal, Jnextday, NetConf et StartUp vers un répertoire nommé twshome/config.old. Ces fichiers sont souvent personnalisés de façon à répondre à vos besoins spécifiques et vous pouvez utiliser les copies sauvegardées pour incorporer vos modifications une fois la mise à jour terminée. Le script customize n écrasera pas les fichiers des répertoires mozart, stdlist ou unison qui ont été modifiés après l installation de Tivoli Workload Scheduler. Si vous souhaitez protéger d autres fichiers au cours de la mise à jour, copiez-les ou renommez-les maintenant. Par mesure de précaution, vous devriez également effectuer une sauvegarde des éléments suivants : Le répertoire twshome. Le répertoire principal de Netman (twshome/../unison) Le fichier des composants (généralement, /usr/unison/components) 38 Version 8.1

59 Mise à jour de Tivoli Workload Scheduler Mise à jour du logiciel et exécution du script de personnalisation 1. Montez la bande ou le CD d installation et restaurez le logiciel. a. Connectez-vous avec des droits root et changez votre répertoire en twshome. b. Extrayez le logiciel : tar xvf cd/tivoli/plateforme/maestro.tar où : cd Le chemin d accès de votre lecteur de CD. plateforme Votre type de plateforme, qui peut être l un des suivants : AIX (pour IBM) DYNIX (pour IBM-Sequent Numa) HPUX (pour Hewlett Packard UNIX) IRIX (pour SGI Irix) LINUX I386 (pour Linux sur Intel) S390 (pour Linux sur 390) (pour Data General UNIX) OSF (pour Compaq True64) SOLARIS (pour Sun Solaris) 2. Exécutez le script customize. Voici, par exemple, un modèle de script de personnalisation pour un poste de travail gestionnaire de domaine principal : /bin/sh customize -update [-uname nom] [autres_opts] 3. Installation sous UNIX Voici, par exemple, un modèle de script de personnalisation pour un poste de travail d agent tolérant les pannes (FTA) : /bin/sh customize -update [-uname nom] [options] Si vous utilisez un système HP-UX 10.x, votre shell Bourne peut se trouver dans le répertoire /usr. Dans ce cas, utilisez la syntaxe suivante : /usr/bin/sh customize -update [-uname nom] [autres_opts] Pour plus d informations sur les arguments du script de personnalisation et pour obtenir d autres exemples, reportez-vous à la section Le script de personnalisation à la page 41. Tivoli Workload Scheduler - Guide de planification et d installation 39

60 Mise à jour de Tivoli Workload Scheduler Mise à jour du profil de sécurité Pour effectuer une migration à partir de Maestro 6.0, une définition d utilisation Maestro supplémentaire doit être ajoutée au fichier de sécurité. L ID tme_region_administrator doit être ajouté au fichier de sécurité si vous avez déjà installé Tivoli Framework pour utiliser le connecteur Tivoli Workload Scheduler. 1. Connectez-vous en tant que Maestro. 2. Exécutez la commande dumpsec pour créer une copie modifiable temporaire du fichier de sécurité : dumpsec >tempsec 3. Editez le fichier de sécurité. Dans la section USER MAESTRO, ajoutez l ID administrateur Tivoli : USER MAESTRO root, maestro, administrator, tme_region_admin 4. Exécutez la commande makesec pour compiler le fichier temporaire dans un nouveau fichier de sécurité : makesec tempsec Pour plus d informations sur les commandes Makesec et Dumpsec, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence. Restauration de vos fichiers En utilisant comme référence les fichiers que vous avez protégés, appliquez vos modifications aux nouvelles versions des fichiers. Redémarrage de Tivoli Workload Scheduler Pour redémarrer Tivoli Workload Scheduler : 1. Connectez-vous en tant qu utilisateur TWS ou maestro. 2. Exécutez la commande start : conman start 3. Exécutez la commande link : Pour un gestionnaire de domaine principal : conman Pour un poste de travail d agent FTA : conman link nomdomaine La mise à jour du logiciel est désormais terminée sur ce poste de travail. 40 Version 8.1

61 Le script de personnalisation Le script de personnalisation Utilisez le script customize pour installer et mettre à jour Tivoli Workload Scheduler sur les plateformes. Syntaxe customize -new -thiscpu nompostetravail -master nompostetravail [-company nomsociété ] [-group nomgroupe] [-nmhome répretoireprincipalnetman] [-noexp] [-nolinks -execpath nomdechemin] [-unamenomutilisateur][-port portnetman] customize -update [-company nomsociété ] [-group nomgroupe] [-uname nomutilisateur] Description Le script customize installe ou met à jour Tivoli Workload Scheduler. Utilisez-le pour exécuter les fonctions suivantes : Nouvelle installation de Tivoli Workload Scheduler : il installe Tivoli Workload Scheduler et Netman. Il crée un fichier de composants contenant de nouvelles entrées. Mises à jour de Tivoli Workload Scheduler : il met à jour Tivoli Workload Scheduler et Netman, si nécessaire. Il met à jour les entrées du fichier des composants. Utilisez-le également pour restaurer les valeurs par défaut des droits à condition que le fichier MAESTRO.TAR d origine ne se trouve pas dans le répertoire twshome. Les détails relatifs au processus d installation sont consignés dans un fichier journal nommé customize.log. Vous pouvez trouver ce fichier dans le même répertoire que celui à partir duquel vous exécutez le script de personnalisation. Arguments -new Il s agit d une nouvelle installation. -update Il s agit d une mise à jour d une installation existante. Notez que la mise à jour du logiciel ne modifiera pas le type de bases de données utilisé par Tivoli Workload Scheduler. -thiscpu Le nom de ce poste de travail. Pour la version non étendue de Tivoli Workload Scheduler, ce nom peut contenir jusqu à huit caractères alphanumériques, tirets (-) ou traits de soulignement (_) et doit commencer par une lettre. Pour la version étendue, la longueur est de seize caractères. Ce nom doit être utilisé plus tard pour définir le poste de travail officiellement dans Tivoli Workload Scheduler. -master Le nom du gestionnaire de domaine principal. Pour la version non étendue de Tivoli Workload Scheduler, ce nom peut contenir jusqu à huit caractères alphanumériques, tirets (-) ou traits de soulignement (_) et doit commencer par une lettre. Pour la version étendue, la longueur est de seize caractères. Si ce poste est le gestionnaire de domaine principal, ou un poste de travail autonome, entrez le même nom que pour -thiscpu. Ce nom doit être utilisé plus tard pour définir le poste de travail officiellement dans Tivoli Workload Scheduler. -company Le nom de l entreprise, délimité par des guillemets (jusqu à 40 caractères). Ce nom apparaît dans les en-têtes et les états du programme. 3. Installation sous UNIX Tivoli Workload Scheduler - Guide de planification et d installation 41

62 Le script de personnalisation -group Le nom du groupe de produits dans lequel vous souhaitez effectuer l installation ou la mise à jour de Tivoli Workload Scheduler. Il peut contenir jusqu à 40 caractères et doit commencer par une lettre. Si ce nom est omis pour une nouvelle installation ou une première mise à jour d une version antérieure de Tivoli Workload Scheduler, il prend par défaut la valeur DEFAULT. S il est inclus pour une mise à jour autre qu une première mise à jour d une version antérieure de Tivoli Workload Scheduler, ce nom est remplacé par le groupe du fichier de composants, le répertoire principal du compte utilisateur étant utilisé comme référence. Pour plus d informations, reportez-vous à la section «Groupes de produits» à la page 16. -nmhome Le répertoire principal de Netman. Si cet argument est omis, Netman est installé dans le répertoire principal de Tivoli Workload Scheduler (twshome). Pour plus d informations, reportez-vous à la section «Répertoire principal de Netman» à la page 17. Cette option n a aucune incidence sur les mises à jour. -noexp Utilisez les bases de données non étendues. Cet argument affecte la valeur non à l option globale version étendue et crée des bases de données non étendues. Du fait que les versions antérieures ne supportent pas les bases de données étendues, utilisez ce mot clé lorsque vous installez Tivoli Workload Scheduler dans un réseau qui contient des ordinateurs exécutant n importe quelle version de Maestro pour MPE. Sur l ensemble des ordinateurs exécutant Maestro 6.0 ou une version ultérieure ou Tivoli Workload Scheduler, il est possible d étendre les bases de données en exécutant la commande dbexpand sur le gestionnaire de domaine principal. Pour plus d informations, reportez-vous à la section du manuel Tivoli Workload Scheduler - Guide de référence concernant la commande dbexpand. Si cet argument est omis, l option globale version étendue prend pour valeur oui et des bases de données étendues sont créées. [-nolinks -execpath nomdechemin] L option de lien détermine le chemin que le script de personnalisation utilise pour créer des liens vers les utilitaires de Tivoli Workload Scheduler. Si vous incluez -nolinks, aucun lien n est créé. Si vous incluez -execpath, des liens sont créés à partir du chemin indiqué. Si linkopt est omis, des liens sont créés comme suit : usr/bin/mat usr/bin/mbatch usr/bin/datecalc usr/bin/jobstdl usr/bin/maestro usr/bin/mdemon usr/bin/morestdl usr/bin/muser usr/bin/parms twshome/bin/at twshome/bin/batch twshome/bin/datecalc twshome/bin/jobstdl twshome/bin/maestro twshome/bin/mdemon twshome/bin/morestdl twshome/bin/muser twshome/bin/parms 42 Version 8.1

63 -uname Le nom de l utilisateur pour lequel Tivoli Workload Scheduler va être installé ou mis à jour. Ce nom ne doit pas contenir le caractère point (.) qui est réservé aux ID de connexion MPE. Le logiciel est installé ou mis à jour dans le répertoire principal de ce compte utilisateur. Si cet argument est omis, le nom d utilisateur par défaut est maestro. -port Le script de personnalisation Le numéro du port TCP auquel Netman répond sur l ordinateur local. Il doit s agir d une valeur 16 bits non signée comprise dans la fourchette (n oubliez pas que les valeurs comprises entre 0 et 1023 sont réservées aux services connus, tels que FTP, TELNET, HTTP, etc.). La valeur par défaut est Vous pouvez modifier cette valeur à tout moment dans le fichier des options locales. 3. Installation sous UNIX Tivoli Workload Scheduler - Guide de planification et d installation 43

64 Désinstallation de Tivoli Workload Scheduler Désinstallation de Tivoli Workload Scheduler Pour désinstaller Tivoli Workload Scheduler sur un système UNIX, procédez comme suit : 1. Avant d effectuer la désinstallation, arrêtez tous les processus Tivoli Workload Scheduler existants qui ont été créés sur ce système UNIX particulier. 2. Sur le système UNIX, connectez-vous avec des droits root. 3. Sauvegardez tous les fichiers de base de données Tivoli Workload Scheduler que vous souhaitez réutiliser. Les fichiers de base de données sont stockés dans le répertoire principal du compte utilisateur Tivoli Workload Scheduler et sont les suivants : /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 Remarque : La base de données job.sched est automatiquement régénérée. Vous n avez pas besoin de la sauvegarder. 4. Examinez le contenu du fichier nommé /usr/unison/components. Si le fichier contient plusieurs entrées correspondant aux différents comptes Maestro/Tivoli Workload Scheduler (groupes de produits), éditez le fichier en supprimant les lignes qui correspondent à l instance que vous souhaitez supprimer. Par exemple, supposez que /usr/unison/components contienne les entrées suivantes : netman 1.5 /opt/maestro DEFAULT maestro 7.0 /opt/maestro DEFAULT netman 1.3 /home/maestro dev_test maestro 6.1 /home/maestro dev_test Si vous avez l intention de supprimer l instance de Tivoli Workload Scheduler située dans /home/maestro, vous devez supprimer les deux dernières lignes. Si /usr/unison/components ne contient que l instance que vous souhaitez supprimer, vous devez supprimer l ensemble du fichier. 5. Le cas échéant, supprimez les liens vers le répertoire /usr/bin. Le processus d installation vous donne la possibilité d établir des liens entre les fichiers exécutables Tivoli Workload Scheduler et un répertoire commun. La valeur par défaut est /usr/bin. Supprimez les fichiers suivants : /usr/bin/maestro /usr/bin/mat /usr/bin/mbatch /usr/bin/datecalc 44 Version 8.1

65 Désinstallation de Tivoli Workload Scheduler /usr/bin/morestdl /usr/bin/jobstdl /usr/bin/parms 6. Finalement, supprimez l intégralité du compte Maestro/Tivoli Workload Scheduler en utilisant les commandes suivantes : rm -rf <twshome>/../unison rm -rf <twshome> Si votre commande de démarrage du système a été modifiée de façon à inclure une commande conman start ou <twshome>/startup, vous devez également supprimer ces entrées. 3. Installation sous UNIX Tivoli Workload Scheduler - Guide de planification et d installation 45

66 Désinstallation de Tivoli Workload Scheduler 46 Version 8.1

67 4 Définition de la sécurité Les programmes et les commandes Tivoli Workload Scheduler déterminent les capacités d un utilisateur en comparant le nom de l utilisateur avec les définitions d utilisateur du fichier de sécurité. Ce chapitre explique comment écrire des définitions d utilisateur et gérer le fichier de sécurité. Le fichier de sécurité Un fichier modèle nommé TWShome/config/Security est fourni avec le logiciel. Au cours de l installation, une copie du modèle est installée en tant que TWShome/Security et une copie opérationnelle compilée est installée en tant que TWShome/../unison/Security. Création du fichier de sécurité Pour créer des définitions d utilisateur, éditez le fichier modèle TWShome/Security. Ne modifiez pas le modèle d origine qui se trouve dans TWShome/config/Security. Ensuite, utilisez la commande makesec pour compiler et installer un nouveau fichier de sécurité opérationnel. Une fois ce fichier installé, vous pouvez apporter d autres modifications en créant une copie éditable du fichier opérationnel à l aide de la commande dumpsec. Les commandes makesec et dumpsec sont décrites plus loin dans ce chapitre. Les modifications apportées au fichier de sécurité sont prises en compte une fois que Tivoli Workload Scheduler a été arrêté et redémarré. Gestion de la sécurité dans un réseau Chaque poste de travail appartenant à un réseau Tivoli Workload Scheduler (gestionnaires de domaine, agents tolérant les pannes et agents standard) possède son propre fichier de sécurité. Vous pouvez gérer un fichier sur chaque poste de travail ou créer un fichier de sécurité sur le gestionnaire de domaine principal et le copier sur chaque gestionnaire de domaine, agent tolérant les pannes ou agent standard. Remarque : Pensez à mettre à jour le fichier de sécurité de façon à ajouter l administrateur Tivoli une fois que vous avez installé Tivoli Management Framework et le connecteur Tivoli Workload Scheduler. Pour plus de détails, reportez-vous au chapitre du manuel Tivoli Job Scheduling Console - Guide de l utilisateur qui explique comment installer le connecteur Tivoli Workload Scheduler. 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 47

68 Le fichier de sécurité Définition de la sécurité pour l administrateur Tivoli Pour qu il soit possible d utiliser Job Scheduling Console sur le système maître ou sur un agent FTA, un ou plusieurs utilisateurs Administrateur Tivoli doivent être définis dans le fichier de sécurité de ce poste maître ou de cet agent FTA. En particulier, une entrée utilisateur doit être définie avec CPU=$FRAMEWORK et LOGON="tme-admin" Il peut s agir d une entrée utilisateur séparée ou d une entrée utilisateur existante. Reportez-vous aux exemples fournis à la section «Exemple de fichier de sécurité» à la page 58. Syntaxe du fichier de sécurité Le fichier de sécurité contient une ou plusieurs définitions d utilisateur. Chaque définition d utilisateur identifie un ensemble d utilisateurs, les objets auxquels ils ont le droit d accéder et les types d action qu ils peuvent exécuter. Définitions d utilisateur Une définition d utilisateur définit un ensemble d utilisateurs, les objets auxquels ils ont le droit d accéder et les types d action qu ils peuvent exécuter. Syntaxe [# commentaire] user nom-def attributs-util begin [* commentaire] type-objet [attributs-objet] access[=action[,...]] [type-objet... ] [end] Variables [# *]commentaire Tout texte précédé d un signe dièse ou d un astérisque et d au moins un espace est traité comme un commentaire. Les commentaires ne sont pas copiés dans le fichier de sécurité opérationnel installé par la commande makesec. nom-def Indique le nom de la définition d utilisateur. Ce nom peut contenir jusqu à 36 caractères alphanumériques et doit commencer par une lettre. attributs-util Indique un ou plusieurs attributs identifiant l ensemble d utilisateurs auquel la définition s applique. Indiquez les attributs utilisateur comme suit : attributs-util[{+ ~}attributs-util[...]] 48 Version 8.1

69 Syntaxe du fichier de sécurité Utilisez un signe plus (+) pour ajouter un attribut que l utilisateur ou les utilisateurs doivent posséder. Utilisez un tilde (~) pour ajouter un attribut que l utilisateur ou les utilisateurs ne doivent pas posséder. Un attributs-util se définit comme suit : cpu=postetravail [,...] où : postetravail Indique le poste de travail sur lequel l utilisateur est connecté. Les caractères génériques sont autorisés. Les variables Tivoli Workload Scheduler suivantes peuvent être utilisées : $master L utilisateur est connecté sur le gestionnaire de domaine principal de Tivoli Workload Scheduler. $remotes L utilisateur est connecté sur n importe quel agent Tivoli Workload Scheduler. $slaves L utilisateur est connecté sur n importe quel agent FTA Tivoli Workload Scheduler. $thiscpu L utilisateur est connecté sur le poste de travail Tivoli Workload Scheduler sur lequel le programme sécurisé s exécute. Pour les utilisateurs de Job Scheduling Console, utilisez $framework. $framework Indique le poste de travail à partir duquel l utilisateur exécute Job Scheduling Indique que l utilisateur accède à Tivoli Workload Scheduler avec Job Scheduling Console ou qu il est connecté sur n importe quel poste de travail Tivoli Workload Scheduler. group=nomgroupe[,...] Uniquement pour les utilisateurs UNIX. N utilisez pas cet argument pour les utilisateurs de Job Scheduling Console. Indique le groupe UNIX dont l utilisateur est membre. Les caractères génériques sont autorisés. logon=nomutilisateur [,...] où : nomutilisateur Indique le nom avec lequel l utilisateur s est connecté sur un poste de travail Tivoli Workload Scheduler. Les caractères génériques sont autorisés. L attribut cpu= doit avoir pour valeur un nom de poste de travail tme-admin Indique le nom du groupe d administrateurs Tivoli dont l utilisateur est membre. Si ce nom contient des espaces, il doit être délimité par des guillemets. Les caractères génériques sont autorisés. L attribut cpu= doit avoir pour valeur $framework 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 49

70 Syntaxe du fichier de Indique que l utilisateur s est connecté avec un nom quelconque ou qu il est membre d un groupe d administrateurs Tivoli. type-objet Indique le type d objet auquel l utilisateur a le droit d accéder. Les types d objets sont les suivants : calendar Calendriers utilisateur. cpu Postes de travail et domaines. file Fichiers de base de données Tivoli Workload Scheduler. job Travaux planifiés. parameter Paramètres utilisateur. prompt Invites globales. resource Ressources de planification. schedule Flux de travaux. userobj Objets utilisateur. Vous pouvez inclure plusieurs types d objets dans une définition d utilisateur. L omission d un type d objet empêche l accès à tous les objets de ce type. attributs-objet Indique un ou plusieurs attributs identifiant un ensemble d objets du type spécifié. Si aucun attribut n est indiqué, tous les objets du type spécifié sont accessibles. Indiquez les attributs d objet de la façon suivante : attributs-objet[{+ ~}attributs-objet[...]] Utilisez un signe plus (+) pour ajouter un attribut que les objets doivent posséder. Utilisez un tilde (~) pour ajouter un attribut que les objets ne doivent pas posséder. Un attribut-objet peut être l un des suivants : Pour le type d objet calendar : name=nom-calendrier[,...] Indique un ou plusieurs noms de calendrier. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les calendriers sont valides. Pour le type d objet cpu (poste de travail) : cpu=postetravail[,...] Indique un ou plusieurs noms de poste de travail ou de domaine. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les postes de travail sont valides. Les variables Tivoli Workload Scheduler suivantes sont autorisées : $master, $remotes, $slaves, et $thiscpu. Pour plus d informations, reportez-vous à la section «Variables fournies par Tivoli» à la page Version 8.1

71 Syntaxe du fichier de sécurité Pour le type d objet file : name=nomfichier[,...] Indique les noms des fichiers de base de données Tivoli Workload Scheduler. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les fichiers sont valides. Les noms de fichier sont les suivants : calendars Contient des calendriers. cpudata Contient des postes de travail et des domaines. jobs Contient des travaux. mastsked Contient des flux de travaux. parameters Contient des paramètres. prodsked Contient l agenda de production. prompts Contient des invites. resources Contient des ressources. security Le fichier de sécurité. Symphony Contient le plan de production. Pour le type d objet job : cpu=postetravail Indique le nom du poste de travail sur lequel le travail s exécute. Les caractères génériques sont autorisés. Si cet attribut est omis, tous les postes de travail sont valides. Les variables Tivoli Workload Scheduler suivantes sont autorisées : $master, $remotes, $slaves, et $thiscpu. Pour plus d informations, reportez-vous à la section «Variables fournies par Tivoli» à la page 57. jcl= chemin cmd Indique la commande ou le nom de chemin d accès du fichier exécutable du travail. La commande ou le chemin doivent être délimités par des guillemets ( ). Les caractères génériques sont autorisés. Si cet attribut est omis, tous les fichiers de travail et les commandes sont valides. logon=nomutilisateur[,...] Indique les noms utilisateur sous lesquels les travaux s exécutent. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les noms utilisateur sont valides. Les variables Tivoli Workload Scheduler suivantes sont autorisées : $jclowner, $owner et $user. Pour plus d informations, reportez-vous à la section «Variables fournies par Tivoli» à la page Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 51

72 Syntaxe du fichier de sécurité name=[fluxtravaux.]travail[,...] Indique le nom du travail Tivoli Workload Scheduler. Le nom du flux de travaux du travail est facultatif. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les noms de travail sont valides. Pour le type d objet parameter : cpu=postetravail Indique le nom du poste de travail sur lequel les paramètres sont définis. Les caractères génériques sont autorisés. Si cet attribut est omis, tous les postes de travail sont valides. Les variables Tivoli Workload Scheduler suivantes sont autorisées : $master, $remotes, $slaves, et $thiscpu. Pour plus d informations, reportez-vous à la section «Variables fournies par Tivoli» à la page 57. name=paramètre[,...] Indique un ou plusieurs noms de paramètres. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les paramètres sont valides. Pour le type d objet prompt : name=invite[,...] Indique un ou plusieurs noms d invite. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, toutes les invites sont valides. Pour le type d objet resource : cpu=postetravail[,...] Indique le nom du poste de travail sur lequel les ressources sont définies. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les postes de travail sont valides. Les variables Tivoli Workload Scheduler suivantes sont autorisées : $master, $remotes, $slaves, et $thiscpu. Pour plus d informations, reportez-vous à la section «Variables fournies par Tivoli» à la page 57. name=ressource[,...] Indique un ou plusieurs noms de ressource. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, toutes les ressources sont valides. Pour le type d objet schedule (flux de travaux) : cpu=postetravail Indique le nom du poste de travail sur lequel le flux de travaux s exécute. Les caractères génériques sont autorisés. Si cet attribut est omis, tous les postes de travail sont valides. Les variables Tivoli Workload Scheduler suivantes sont autorisées : $master, $remotes, $slaves, et $thiscpu. Pour plus d informations, reportez-vous à la section «Variables fournies par Tivoli» à la page Version 8.1

73 Syntaxe du fichier de sécurité action name=fluxtravaux[,...] Indique un ou plusieurs noms de flux de travaux. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les flux de travaux sont valides. Pour le type d objet userobj : cpu=postetravail Indique le nom du poste de travail sur lequel l utilisateur est défini. Les caractères génériques sont autorisés. Si cet attribut est omis, tous les postes de travail sont valides. Les variables Tivoli Workload Scheduler suivantes sont autorisées : $master, $remotes, $slaves, et $thiscpu. Pour plus d informations, reportez-vous à la section «Variables fournies par Tivoli» à la page 57. logon=nomutilisateur[,...] Indique un ou plusieurs noms d utilisateur. Les caractères génériques sont autorisés. Lorsque plusieurs noms sont indiqués, ils doivent être séparés par des virgules. Si cet attribut est omis, tous les utilisateurs sont valides. Indique les actions que les utilisateurs peuvent exécuter. Lorsque plusieurs actions sont indiquées, elles doivent être séparées par des virgules. Si aucune action n est indiquée, aucune action n est autorisée. Le fait d entrer access=@ confère aux utilisateurs la capacité d exécuter toutes les actions. Pour le type d objet calendar : add Ajoutez et enregistrez de nouveaux calendriers dans la base de données. delete Supprimez des calendriers de la base de données. display Affichez des calendriers de la base de données. modify Modifiez des calendriers de la base de données. use Utilisez des calendriers pour planifier des flux de travaux. Pour le type d objet cpu, qui inclut les postes de travail et les domaines : add Ajoutez et enregistrez de nouveaux postes de travail et domaines dans la base de données. console Visualisez et modifiez la console Tivoli Workload Scheduler. delete Supprimez des postes de travail et des domaines de la base de données. display Affichez des postes de travail et des domaines dans la base de données. fence limit link Modifiez les priorités limites des travaux des postes de travail dans le plan de production. Modifiez les limites des travaux des postes de travail dans le plan de production. Ouvrez les liaisons des postes de travail. 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 53

74 Syntaxe du fichier de sécurité modify Modifiez et remplacez des postes de travail et des domaines dans la base de données. shutdown Arrêtez le traitement Tivoli Workload Scheduler. Cette action est uniquement disponible au niveau de la ligne de commande. start Démarrez le traitement Tivoli Workload Scheduler. stop Arrêtez le traitement Tivoli Workload Scheduler. unlink Fermez les liaisons des postes de travail. Pour permettre à un utilisateur de faire basculer la fonction de gestionnaire de domaine sur un poste de travail, il faut que cet utilisateur possède à la fois un droit de démarrage et d interruption sur ce poste de travail. Pour le type d objet file : build Générez les fichiers de base de données de Tivoli Workload Scheduler. Cette action est uniquement disponible au niveau de la ligne de commande. delete Pas encore mis en oeuvre. display Accédez au fichier de sécurité à l aide de la commande dumpsec. Affichez également les fichiers maîtres des calendriers, des paramètres, des invites et des ressources. Ces actions sont uniquement valides au niveau de la ligne de commande. modify Accédez au fichier de sécurité à l aide de la commande makesec. Modifiez également les fichiers maîtres des calendriers, des paramètres, des invites et des ressources. Ces actions sont uniquement disponibles au niveau de la ligne de commande. Remarque : Le type d objet file permet de gérer la sécurité sur l interface de ligne de commande et n est valide que sur l interface de ligne de commande. Pour le type d objet job : add Ajoutez et enregistrez de nouveaux travaux dans la base de données. adddep Ajoutez des dépendances aux travaux dans le plan de production. Cette action n est pas disponible sur les postes connectés à Tivoli Workload Scheduler pour z/os pour la planification de bout en bout. altpri Modifiez la priorité des travaux dans le plan de production. Cette action n est pas disponible sur les postes connectés à Tivoli Workload Scheduler pour z/os pour la planification de bout en bout. cancel Annulez des travaux dans le plan de production. Cette action n est pas disponible sur les postes connectés à Tivoli Workload Scheduler pour z/os pour la planification de bout en bout. 54 Version 8.1

75 Syntaxe du fichier de sécurité confirm Confirmez la fin de travaux du plan de production. Cette action n est pas disponible sur les postes connectés à Tivoli Workload Scheduler pour z/os pour la planification de bout en bout. deldep Supprimez des dépendances de travaux dans le plan de production. Cette action n est pas disponible sur les postes connectés à Tivoli Workload Scheduler pour z/os pour la planification de bout en bout. delete Supprimez des travaux de la base de données. display Affichez les travaux de la base de données. kill Supprimez des travaux du plan de production. modify Modifiez et remplacez des travaux dans la base de données. release Libérez des travaux de leurs dépendances dans le plan de production. Cette action n est pas disponible sur les postes connectés à Tivoli Workload Scheduler pour z/os pour la planification de bout en bout. reply Répondez aux invites de travaux dans le plan de production. rerun Réexécutez des travaux du plan de production. Cette action n est pas disponible sur les postes connectés à Tivoli Workload Scheduler pour z/os pour la planification de bout en bout. submit Soumettez des travaux dans le plan de production. Cette action n est pas disponible sur les postes connectés à Tivoli Workload Scheduler pour z/os pour la planification de bout en bout. use Ajoutez des travaux aux flux de travaux dans la base de données. Pour le type d objet parameter : add Ajoutez et enregistrez de nouveaux paramètres dans la base de données. delete Supprimez des paramètres de la base de données. display Affichez les paramètres de la base de données. modify Modifiez et remplacez des paramètres dans la base de données. Pour le type d objet prompt : add Ajoutez et enregistrez de nouvelles invites dans la base de données. delete Supprimez des invites de la base de données. display Affichez les invites de la base de données. modify Modifiez et remplacez des invites dans la base de données. 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 55

76 Syntaxe du fichier de sécurité use Ajoutez des invites aux flux de travaux dans la base de données et ajoutez des invites aux travaux et aux flux de travaux dans le plan de production. Pour le type d objet resource : add Ajoutez et enregistrez de nouvelles ressources dans la base de données. delete Supprimez des ressources de la base de données. display Affichez les ressources de la base de données. modify Modifiez et remplacez des ressources dans la base de données. use Ajoutez des ressources aux flux de travaux dans la base de données et ajoutez des ressources aux travaux et aux flux de travaux dans le plan de production. Pour le type d objet schedule (flux de travaux) : add Ajoutez et enregistrez de nouveaux flux de travaux dans la base de données. adddep Ajoutez des dépendances aux flux de travaux dans le plan de production. altpri Modifiez la priorité des flux de travaux dans le plan de production. cancel Annulez des flux de travaux dans le plan de production. deldep Supprimez des dépendances de flux de travaux dans le plan de production. delete Supprimez des flux de travaux de la base de données. display Affichez les flux de travaux de la base de données. limit Modifiez la limite de travaux des flux de travaux dans le plan de production. modify Modifiez et remplacez des flux de travaux dans la base de données. release Libérez des flux de travaux de leurs dépendances dans le plan de production. reply Répondez aux invites de flux de travaux dans le plan de production. submit Soumettez des flux de travaux dans le plan de production. Pour le type d objet userobj : add Ajoutez de nouveaux utilisateurs à la base de données. delete Supprimez des utilisateurs de la base de données. display Affichez les utilisateurs de la base de données. 56 Version 8.1

77 Syntaxe du fichier de sécurité modify Modifiez et remplacez des utilisateurs dans la base de données. altpass Modifiez des mots de passe utilisateur dans la base de données. Ordre de qualification des utilisateurs Lors de la qualification des utilisateurs pour l accès aux objets Tivoli Workload Scheduler, les attributs réels d un utilisateur sont comparés aux définitions d utilisateur selon l ordre dans lequel les définitions sont entrées dans le fichier Security. La première définition qui correspond à l utilisateur détermine les capacités de cet utilisateur. Pour cette raison, il est important d ordonner les définitions d utilisateur en allant des plus spécifiques aux moins spécifiques. Par exemple : #Incorrect: CPU=@+LOGON=TWSUser #Correct: CPU=@+LOGON=TWSDomain\TWSUser Pour plus d informations, reportez-vous à la section «Exemple de fichier de sécurité» à la page 58. Ordre de qualification des objets Dans une définition d utilisateur, vous pouvez utiliser plusieurs instructions pour un seul type d objet afin d affecter différentes capacités d accès à différents ensembles d objet. Du fait que la première instruction correspondante est utilisée, l ordre des instructions d objets est important. Les instructions doivent être ordonnées en allant du plus spécifique au moins spécifique. Par exemple : #Incorrect: job name=@ access=display job name=ar@ access=@ #Correct: job name=ar@ access=@ job name=@ access=display Pour plus d informations, reportez-vous à la section «Exemple de fichier de sécurité» à la page 58. Variables fournies par Tivoli Les variables fournies par Tivoli pouvant être utilisées dans les attributs d objet sont les suivantes : $jclgroup Le nom du groupe du fichier exécutable d un travail. $jclowner Le propriétaire du fichier exécutable d un travail. $master Le gestionnaire de domaine principal de Tivoli Workload Scheduler. $owner Le créateur d un flux de travaux et de ses travaux. $remotes Tous les postes de travail d agents standards. $slaves Tous les postes de travail d agents tolérant les pannes. 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 57

78 Syntaxe du fichier de sécurité $thiscpu Le poste de travail sur lequel l utilisateur exécute la commande ou le programme Tivoli Workload Scheduler. $user L utilisateur qui exécute la commande ou le programme Tivoli Workload Scheduler. Les variables $jclgroup et $jclowner ne sont vérifiables que si l utilisateur exécute un programme Tivoli Workload Scheduler sur le poste de travail où réside le fichier exécutable du travail. Si le programme est exécuté sur un poste de travail différent, l accès est refusé à l utilisateur. Caractères génériques Lorsque les descriptions de syntaxe l indiquent, les caractères génériques suivants sont autorisés :? Remplace un caractère alphabétique. % Remplace un caractère Remplace zéro ou plusieurs caractères alphanumériques. Le superutilisateur sous UNIX Si aucun fichier de sécurité n existe, aucun utilisateur autre que l utilisateur root ne peut accéder aux objets Tivoli Workload Scheduler, et l utilisateur root possède un accès illimité à l ensemble des objets et peut exécuter tous les programmes et les commandes Tivoli Workload Scheduler. Pour contrôler root, créez un fichier de sécurité comportant une définition d utilisateur pour l utilisateur root. Dans le fichier de sécurité d un réseau, vous pouvez faire une distinction entre les utilisateurs root locaux et l utilisateur root du gestionnaire de domaine principal. Par exemple, vous pouvez limiter les utilisateurs locaux à l exécution d opérations affectant uniquement leur poste de travail de connexion et autoriser l utilisateur root maître à exécuter des opérations affectant tous les postes de travail du réseau. Pour plus d informations, reportez-vous à la section Exemple de fichier de sécurité. Exemple de fichier de sécurité Voici un exemple de fichier de sécurité. Vous trouverez une explication de ce fichier à la suite de la liste. ########################################################### # Sample Security File ########################################################### # (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE # MASTER DOMAIN MANAGER OR FRAMEWORK. user mastersm cpu=$master,$framework + logon=maestro,root,root_london-region begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job access=@ schedule access=@ resource access=@ prompt access=@ file access=@ calendar access=@ cpu access=@ 58 Version 8.1

79 Exemple de fichier de sécurité parameter ~ access=@ userobj + access=@ end ########################################################### # (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY # WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user sm logon=maestro,root begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job cpu=$thiscpu access=@ schedule cpu=$thiscpu access=@ resource cpu=$thiscpu access=@ prompt access=@ file access=@ calendar access=@ cpu cpu=$thiscpu access=@ parameter cpu=$thiscpu ~ name=r@ access=@ end ########################################################### # (3) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON THE # MASTER DOMAIN MANAGER OR FRAMEWORK. user masterop cpu=$master,$fw + group=sys begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job cpu=@ + logon=twsdomain\twsuser access=@ job cpu=@ + logon=root access=adddep,altpri,cancel, confirm,deldep,release, reply,rerun,submit,use job cpu=@ + logon=$user,$jclowner ~ logon=root access=add,adddep,altpri, cancel,confirm, deldep,release,reply, rerun,submit,use schedule cpu=$thiscpu access=@ schedule cpu=@ access=adddep,altpri,cancel, deldep,limit,release, submit resource access=add,display, resource,use prompt access=add,display,reply,use file access=build calendar access=display,use cpu cpu=@ access=@ parameter name=@ ~ name=r@ access=@ end ########################################################### # (4) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON ANY # WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER user op group=sys begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job job job cpu=$thiscpu + logon=$user access=@ cpu=$thiscpu + logon=root access=adddep,altpri,cancel, confirm,deldep,release, reply,rerun,submit,use cpu=$thiscpu ~ logon=root access=adddep,altpri,cancel, 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 59

80 Exemple de fichier de sécurité confirm,deldep,release, reply,rerun,submit,use schedule cpu=$thiscpu resource access=add,display,resource,use prompt access=add,display,reply,use file access=build calendar access=use cpu cpu=$thiscpu access=console,fence,limit, link,start,stop,unlink parameter ~ access=@ end ########################################################### # (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON # ANY WORKSTATION OR FRAMEWORK. user misusers group=mis begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job cpu=$thiscpu job + logon=$user access=@ cpu=$thiscpu + logon=$jclowner ~ logon=root access=submit,use schedule cpu=$thiscpu access=add,submit, modify,display parameter name=r@ access=@ parameter name=@ access=display end ########################################################### # (6) APPLIES TO ALL OTHER USERS LOGGED IN ON ANY # WORKSTATION. user default logon=@ begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job job cpu=$thiscpu + logon=$user access=@ cpu=$thiscpu + logon=$jclowner ~ logon=root access=submit,use schedule cpu=$thiscpu access=add,submit, modify,display parameter name=u@ access=@ parameter name=@ ~ name=r@ access=display end ########################################################### Explication de l exemple de fichier de sécurité Notez que l ordre des définitions est du plus spécifique au moins spécifique. En raison de cet ordre, les utilisateurs maestro et root sont mis en correspondance en premier, suivis par les utilisateurs du groupe sys, puis par les utilisateurs du groupe mis. Tous les autres utilisateurs sont mis en correspondance avec la dernière définition, qui est la moins spécifique. # (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE MASTER DOMAIN MANAGER OR FRAMEWORK. user mastersm cpu=$master,$fw + logon=maestro,root,root_london-region Cette définition d utilisateur s applique aux accès à l interface graphique et à l interface de ligne de commande pour les utilisateurs maestro et root connectés à un gestionnaire de domaine principal. Elle donne également accès à l interface graphique aux utilisateurs répertoriés dans le groupe d administrateurs Tivoli Root_london-region. Ces utilisateurs ont 60 Version 8.1

81 Exemple de fichier de sécurité un accès illimité à tous les objets, à l exception des paramètres dont les noms commencent par r. L accès aux paramètres r n est accordé qu aux utilisateurs du groupe mis. # (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user sm logon=maestro,root Cette définition d utilisateur s applique aux utilisateurs maestro et root auxquels la définition 1 ne s applique pas, à savoir, les utilisateurs qui sont connectés à des postes de travail autres que le gestionnaire de domaine principal ou un ordinateur Framework. Ils ont un accès illimité à tous les objets sur leur poste de travail de connexion. Notez que les invites, les fichiers et les calendriers sont globaux par nature et ne sont pas associés à un poste de travail. # (3) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON THE MASTER DOMAIN MANAGER OR FRAMEWORK. user masterop cpu=$master,$framework + group=sys Cette définition d utilisateur s applique aux utilisateurs connectés au groupe sys sur le gestionnaire de domaine principal ou sur un ordinateur Framework. Ces utilisateurs possèdent un ensemble unique de capacités d accès. Plusieurs instructions d objet sont utilisées pour donner à ces utilisateurs des types d accès spécifiques à différents ensembles d objets. Par exemple, il existe trois instructions de travail : La première instruction de travail autorise l accès illimité aux travaux qui s exécutent sur n importe quel poste de travail (@) sous le nom de l utilisateur ($user). La deuxième instruction de travail permet des types d accès spécifiques aux travaux qui s exécutent sur n importe quel poste de travail et avec des droits root. La troisième instruction de travail permet des types d accès spécifiques aux travaux qui s exécutent sur n importe quel poste de travail. Les travaux doivent s exécuter sous le nom de l utilisateur ($user ou sous le nom du propriétaire du fichier de travail ($jclowner). Les travaux qui s exécutent avec des droits root sont exclus. # (4) APPLIES TO USERS LOGGED INTO THE SYS GROUP ON ANY WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user op group=sys Cette définition d utilisateur s applique aux utilisateurs du groupe sys auxquels la définition 3 ne s applique pas, à savoir, les utilisateurs qui sont connectés sur n importe quel poste de travail autre que le gestionnaire de domaine principal ou un ordinateur Framework. Ils possèdent un ensemble de capacités d accès similaires à celles de la définition 3. L exception est que l accès est limité aux objets sur le poste de travail de connexion de l utilisateur ($thiscpu). # (5) APPLIES TO USERS LOGGED INTO THE MIS GROUP ON ANY WORKSTATION OR FRAMEWORK. user misusers group=mis Cette définition d utilisateur s applique aux utilisateurs connectés au groupe mis sur n importe quel poste de travail ou sur un ordinateur Framework. Ces utilisateurs possèdent un ensemble limité de capacités d accès. Les ressources, les invites, les fichiers, les calendriers et les postes de travail sont omis, ce qui empêche l accès à ces objets. Ces utilisateurs ont un accès illimité aux paramètres dont le nom commence par r, mais peuvent uniquement afficher les autres paramètres. # (6) APPLIES TO ALL OTHER USERS LOGGED IN ON ANY WORKSTATION. user default logon=@ 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 61

82 Exemple de fichier de sécurité Cette définition utilisateur donne un ensemble de capacités par défaut aux utilisateurs autres que ceux qui sont concernés par les définitions précédentes. Ces utilisateurs ont un accès illimité aux paramètres dont le nom commence par u, mais peuvent uniquement afficher les autres paramètres. Aucun accès n est autorisé aux paramètres dont le nom commence par r. 62 Version 8.1

83 La commande dumpsec La commande dumpsec Décompile le fichier de sécurité et envoie le résultat à stdout. L utilisateur doit avoir des droits d accès d affichage sur le fichier de sécurité. Syntaxe dumpsec -v -u dumpsec fichier-sécurité Description Si aucun argument n est indiqué, le fichier de sécurité opérationnel (../unison/security) est vidé. Pour créer une copie éditable d un fichier de sécurité, redirigez le résultat de la commande vers un autre fichier, comme illustré dans les exemples. Arguments -v Affiche uniquement les informations sur la version de la commande. -u Affiche uniquement les informations sur l utilisation de la commande. fichier-sécurité Indique le nom du fichier de sécurité à vider. Exemples L exemple suivant affiche la version de la commande : dumpsec -v L exemple suivant vide le fichier de sécurité opérationnel dans stdout : dumpsec L exemple suivant vide le fichier de sécurité opérationnel dans un fichier intitulé monsec : dumpsec > monsec L exemple suivant vide un fichier de sécurité intitulé sectemp dans stdout : dumpsec sectemp 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 63

84 La commande makesec La commande makesec Compile les définitions d utilisateur et installe le fichier de sécurité. Les modifications apportées au fichier de sécurité sont prises en compte une fois que Tivoli Workload Scheduler a été arrêté et redémarré. Les éléments concernés sont les suivants : conman composer Connecteurs Tivoli Workload Scheduler Quittez simplement les programmes. Lors de leur prochaine exécution, les nouvelles définitions de sécurité seront reconnues. En ce qui concerne les connecteurs Tivoli Workload Scheduler, vous aurez besoin de les arrêter en exécutant la commande wmaeutil. Les connecteurs seront automatiquement redémarrés avec la régénération de n importe quelle requête dans JS Console. L utilisateur doit avoir des droits d accès de modification sur le fichier de sécurité. Remarque : Pour Windows NT, les processus des connecteurs doivent être arrêtés (à l aide de la commande wmaeutil) pour que la commande makesec puisse fonctionner correctement. Syntaxe makesec -v -u makesec [-verify] fichier-in Description La commande makesec compile le fichier indiqué et l installe en tant que fichier de sécurité opérationnel (../unison/security). Si l argument -verify est indiqué, la syntaxe du fichier est vérifiée mais le fichier n est ni compilé, ni installé. Arguments -v Affiche uniquement les informations sur la version de la commande. -u Affiche uniquement les informations sur l utilisation de la commande. -verify Vérifie la syntaxe des définitions d utilisateur dans fichier-in uniquement. Le fichier n est pas installé en tant que fichier de sécurité. (La vérification de la syntaxe s effectue automatiquement lorsque le fichier de sécurité est installé.) fichier-in Indique le nom d un fichier ou d un ensemble de fichiers contenant des définitions utilisateur. Un schéma d extension de nom de fichier est autorisé. Exemples L exemple suivant affiche la version de la commande : makesec -v L exemple suivant crée une copie éditable du fichier de sécurité opérationnel dans un fichier intitulé tempsec ; il modifie les définitions d utilisateurs à l aide d un éditeur de texte, puis compile tempsec et remplace le fichier de sécurité opérationnel : dumpsec > tempsec edit tempsec 64 Version 8.1

85 Vous effectuez alors les modifications requises dans le fichier tempsec. Une fois que la modification du fichier tempsec est terminée, exécutez la commande makesec pour charger le fichier de sécurité dans Tivoli Workload Scheduler : makesec tempsec L exemple suivant compile les définitions d utilisateur à partir de l ensemble de fichiers userdef* et remplace le fichier de sécurité opérationnel : makesec userdef* La commande makesec 4. Définition de la sécurité Tivoli Workload Scheduler - Guide de planification et d installation 65

86 La commande makesec 66 Version 8.1

87 5 Etapes de personnalisation facultatives 5. Etapes de personnalisation Options globales Après avoir installé le produit, vous pouvez le personnaliser de façon à ce qu il réponde à vos besoins opérationnels. Ce chapitre décrit les étapes de personnalisation facultatives pour votre installation de Tivoli Workload Scheduler. Les options globales sont définies sur le gestionnaire de domaine principal et s appliquent à tous les postes de travail du réseau Tivoli Workload Scheduler. Définition des options globales Les options globales sont entrées dans le fichier globalopts à l aide d un éditeur de texte. Vous pouvez apporter des modifications à tout moment, mais elles ne seront prises en compte qu une fois que Tivoli Workload Scheduler aura été arrêté et redémarré. La syntaxe est décrite dans le tableau suivant. Les entrées ne font pas de distinction majuscules/minuscules. Syntaxe de l option globale Valeur par défaut # commentaire automatically grant logon as batch = yes no no batchman schedule = yes no no bmmsgbase = entier 1000 bmmsgdelta = entier 1000 carry job states = ([état[,...]]) null carryforward = yes no all yes company = nom_société null database audit level = expanded version = yes no null history = jours 10 ignore calendars = yes no no master = postetravail Initialement défini par customize sous UNIX et par Setup sous Windows NT plan audit level = retain rerun job name = yes no no start = heure_début 0600 timezone enable = yes no no Tivoli Workload Scheduler - Guide de planification et d installation 67

88 Options globales # commentaire Traitez tout ce qui suit le signe dièse jusqu à la fin de la ligne comme du commentaire. automatically grant logon as batch job Cette option concerne uniquement les travaux Windows NT. Si elle a pour valeur yes, les utilisateurs connectés pour les travaux Windows NT bénéficient automatiquement du droit Connecter par lots. Si elle a pour valeur no, ou si elle n est pas définie, ce droit doit être accordé manuellement à chaque utilisateur ou groupe. Notez que ce droit ne peut pas être accordé automatiquement aux utilisateurs exécutant des travaux sur un contrôleur secondaire de domaine (CSD) et que vous devez donc l accorder manuellement. bmmsgbase Indique le nombre maximum d invites pouvant s afficher pour l opérateur suite à l arrêt anormal d un travail. La valeur par défaut est bmmsgdelta Indique un nombre d invites supplémentaire pour la valeur définie dans l option bmmsgbase dans l éventualité où un travail serait réexécuté suite à un arrêt anormal et que la limite indiquée dans bmmsgbase aurait été atteinte. La valeur par défaut est batchman schedule Il s agit d une option de production affectant le fonctionnement de Batchman, qui est le processus de contrôle de production de Tivoli Workload Scheduler. La valeur définie détermine la priorité affectée aux flux de travaux créés pour les travaux non planifiés. Entrez yes pour affecter une priorité de 10 à ces flux de travaux. Entrez no pour affecter une priorité de 0 à ces flux de travaux. carry job states Il s agit d une option de pré-production qui affecte le fonctionnement de la commande stageman. Sa valeur détermine quels travaux, par état, doivent être inclus dans les flux de travaux à reporter. Vous devez délimiter l état des travaux à l aide de parenthèses, de guillemets doubles ou de guillemets simples. Les virgules peuvent être remplacées par les espaces. Les états de travaux internes valides sont les suivants : abend abenp add done exec fail hold intro pend ready rjob sched skel succ succp susp wait waitd Voici des exemples de définition de cette option : carry job states=(abend,exec,hold,intro) carry job states="abend exec hold intro" carry job states= abend exec hold intro Une liste vide doit être entrée de la façon suivante : carry job states=() Pour plus d informations, reportez-vous à la section «Présentation des options de report» à la page 71. carryforward Il s agit d une option de pré-production qui affecte le fonctionnement de la commande stageman. Sa valeur détermine si oui ou non les flux de travaux non terminés sont reportés depuis l ancien plan de production vers le nouveau 68 Version 8.1

89 Options globales (Symphony). Entrez yes pour que les flux de travaux ne soient reportés que si l option Carry Forward est activée dans la définition de flux de travaux. Entrez all pour que tous les flux de travaux non terminés soient reportés, sans tenir compte de l option Carry Forward. Entrez no pour désactiver entièrement la fonction de report. L option de ligne de commande stageman -carryforward prend les même valeurs et assure la même fonction que l option globale carryforward. Si elle est utilisée, elle se substitue à l option globale. Pour plus d informations, reportez-vous à la section «Présentation des options de report» à la page 71. company Il s agit du nom de votre société, contenant jusqu à 40 caractères. Si le nom contient des espaces, délimitez-le à l aide de guillemets ( ). database audit level Sélectionnez l activation ou la désactivation de l audit de base de données. Les valeurs valides sont 0 pour désactiver l audit de base de données et 1 pour activer l audit de base de données. Les informations d audit sont consignées dans un fichier à plat dans le répertoire TWShome/audit/database. Chaque poste de travail Tivoli Workload Scheduler gère son propre journal. Pour la base de données, seules les actions sont consignées dans le fichier d audit, mais pas le delta de l action. Pour plus d informations sur cette fonction, reportez-vous à la section Annexe A, «Fuseaux horaires et audit». expanded version Cette option est définie au cours de l installation par le programme de personnalisation sous UNIX et par le programme d installation sous Windows NT. Si elle a pour valeur yes, les bases de données étendues sont utilisées. Si elle a pour valeur no, les bases de données étendues ne sont pas utilisées. Les bases de données étendues autorisent l utilisation de noms d objets longs. Par exemple, les noms de travaux étendus peuvent contenir jusqu à seize caractères. Cette option a également pour valeur yes lorsque vous exécutez l utilitaire dbexpand pour convertir des bases de données non étendues en bases de données étendues. Si cette option n existe pas, comme c est le cas dans une version antérieure à Maestro Version 6.0, elle est interprétée comme ayant pour valeur no. history Entrez le nombre de jours pendant lequel vous souhaitez sauvegarder des statistiques relatives aux travaux. Les statistiques sont éliminées en fonction de la règle premier entré premier sorti. Cette option n a aucun effet sur les fichiers de liste standard des travaux, lesquels doivent être supprimés à l aide de la commande rmstdlist. Pour plus d informations sur la commande rmstdlist, reportez-vous au document Tivoli Workload Scheduler - Guide de référence. ignore calendars Il s agit d une option de pré-production qui affecte le fonctionnement de la commande compiler. Sa valeur détermine si oui ou non les calendriers utilisateur sont copiés dans le nouveau fichier de contrôle de production. Entrez yes pour empêcher que les calendriers utilisateur soient copiés dans le nouveau plan de production (fichier Symphony). Cette valeur permet de préserver de l espace dans le fichier, mais aussi d utiliser des noms de calendrier dans les expressions de date. Entrez no pour que les calendriers utilisateur soient copiés dans le nouveau plan de production. Pour plus d informations, reportez-vous à l explication de la commande compiler dans le guide de référence de Tivoli Workload Scheduler. 5. Etapes de personnalisation Tivoli Workload Scheduler - Guide de planification et d installation 69

90 Options globales master Le nom du gestionnaire de domaine principal. Cette option est définie lorsque vous installez Tivoli Workload Scheduler à l aide du programme customize (UNIX) ou du programme d installation (Windows NT). plan audit level Sélectionnez l activation ou la désactivation de l audit du plan. Les valeurs valides sont 0 pour désactiver l audit du plan et 1 pour activer l audit du plan. Les informations d audit sont consignées dans un fichier à plat dans le répertoire TWShome/audit/plan. Chaque poste de travail Tivoli Workload Scheduler gère son propre journal. Pour le plan, seules les actions sont consignées dans le fichier d audit, mais pas la réussite ou l échec d une action. Pour plus d informations sur cette fonction, reportez-vous à l Annexe A, «Fuseaux horaires et audit». retain rerun job name Il s agit d une option de production affectant le fonctionnement de Batchman, qui est le processus de contrôle de production de Tivoli Workload Scheduler. Sa valeur détermine si oui ou non les travaux qui sont réexécutés à l aide de la commande Conman rerun vont conserver leur nom d origine. Entrez yes pour que les travaux réexécutés conservent leur nom d origine. Entrez no pour autoriser l affectation du nom rerun from aux travaux réexécutés. start Entrez l heure de début de la journée de traitement de Tivoli Workload Scheduler en utilisant un format 24 heures : hhmm ( ). L heure de début par défaut est 06:00, et l heure de lancement par défaut du flux de travaux final est 05:59. Si vous modifiez cette option, vous devez également modifier l heure de lancement du flux de travaux final qui est généralement défini une minute avant l heure de début. timezone enable Sélectionnez l activation ou la désactivation de l option de fuseau horaire. Les valeurs valides sontyes pour activer les fuseaux horaires dans votre réseau, et no pour désactiver les fuseaux horaires dans votre réseau. Les fuseaux horaires sont désactivés par défaut lors de l installation de Tivoli Workload Scheduler. Si l entrée timezone enable est manquante dans le fichier globalopts, les fuseaux horaires sont désactivés. Pour plus d informations sur cette fonction, reportez-vous à l Annexe A, «Fuseaux horaires et audit». Exemple de fichier des options globales Un modèle de fichier des options globales contenant les paramètres par défaut de Tivoli Workload Scheduler se trouve dans TWShome/config/globalopts. Au cours du processus d installation, une copie de travail du fichier des options globales est installée en tant que TWShome/mozart/globalopts. Vous pouvez personnaliser la copie de travail en fonction de vos besoins. Voici un exemple de fichier des options globales : # Globalopts file on the master domain manager defines # attributes of the Tivoli Workload Scheduler network. # company="tivoli Systems" master=main start=0600 history=10 carryforward=yes ignore calendars=no batchman schedule=no 70 Version 8.1

91 Options globales retain rerun job name=no # # # End of globalopts. Présentation des options de report Les flux de travaux sont reportés par la commande stageman au cours du traitement de fin de journée. Le processus de report est affecté par les éléments suivants : Le mot clé carryforward dans vos flux de travaux. Pour plus d informations, reportez-vous au document Tivoli Workload Scheduler - Guide de référence. L option globale carryforward. Reportez-vous à la page 68. L option de ligne de commande stageman -carryforward. Reportez-vous à l explication de la commande stageman dans le document Tivoli Workload Scheduler - Guide de référence. L option globale carry job states. Reportez-vous à la page 68. Le tableau suivant indique la façon dont les différentes options de report fonctionnent conjointement. 5. Etapes de personnalisation Options globales carryforward=no carryforward=yes carry job states=(états) carryforward=yes carry job states=() carryforward=all carry job states=(états) carryforward=all carry job states=() Opération de report Aucun flux de travaux n est reporté. Les flux de travaux ne sont reportés que s ils comprennent des travaux dans les états indiqués et si l option Carryforward est activée. Seuls les travaux se trouvant dans les états indiqués sont reportés avec les flux de travaux. Les flux de travaux ne sont reportés que s ils sont non terminés et si l option Carryforward est activée. Tous les travaux sont reportés avec les flux de travaux. Les flux de travaux ne sont reportés que s ils comprennent des travaux dans les états indiqués. Seuls les travaux se trouvant dans les états indiqués sont reportés avec les flux de travaux. Les flux de travaux ne sont reportés que s ils sont non terminés. Tous les travaux sont reportés avec les flux de travaux. Les informations suivantes concernent le comportement des options de report : Tous les flux de travaux qui ne sont pas à l état SUCC sont considérés comme non terminés et sont reportés. L option de ligne de commande stageman -carryforward, si elle est utilisée, remplace toujours l option globale carryforward. La valeur par défaut, si aucune des deux n est indiquée, est carryforward=yes. L entrée par défaut est nulle pour l option globale carry job states. Cela signifie que, si la liste est vide ou si l option est absente, l option de report fonctionne comme décrit pour carry job states=(). Les travaux et les flux de travaux qui ont été annulés ne sont jamais reportés. Les travaux et les flux de travaux dont l heure until est arrivée à expiration ne sont jamais reportés. Tivoli Workload Scheduler - Guide de planification et d installation 71

92 Options globales La décision de reporter un travail répétitif (défini par l option Every) dépend de l état de son exécution la plus récente. Si un travail est en cours d exécution lorsque le travail Jnextday commence à s exécuter et si son report n est pas défini, ce travail se poursuit et il est placé dans le flux de travaux userjobs pour la nouvelle journée de production. Notez que les dépendances de ces travaux ne sont pas reportées et que toutes les ressources bloquées par ce travail sont libérées. Définition des options globales pour les agents MPE Dans un réseau Tivoli Workload Scheduler dans lequel des systèmes UNIX ou NT sont configurés en tant que gestionnaires de domaine et des systèmes HP3000 (MPE) sont configurés en tant qu agents FTA, vous pouvez indiquer un ensemble d options globales sur le gestionnaire de domaine principal UNIX/NT afin de contrôler le fonctionnement de Tivoli Workload Scheduler sur les agents FTA MPE. Ces options remplacent les paramètres qui seraient normalement définis sur les systèmes MPE à l aide de la transaction CTP1 du programme Arranger. Pour incorporer ces options, ajoutez-les à votre fichier globalopts en utilisant la syntaxe décrite dans le tableau suivant. Les entrées ne font pas de distinction majuscules/minuscules. Syntaxe de l option globale rules mode = yes no batchman schedule = yes no all userjobs in userjobs schedule = yes no set mpe job pri to zero = yes no Valeur par défaut no no no no rules mode Remplace le paramètre 4 de CTP1-, c est-à-dire Complete Control Mode. Si vous avez défini la valeur yes pour cette option, vous devez également définir la valeur yes pour batchman schedule. L état normal de Batchman est Lives lorsqu il est actif, Down lorsqu il est inactif. Ces informations s affichent dans la fenêtre Propriétés du planificateur de Job Scheduling Console, ou lorsque vous exécutez la commande conman status dans l interface de ligne de commande. L activation de cette option change l état actif de Batchman pour afficher Rules. batchman schedule Remplace le paramètre 7 de CTP1-, c est-à-dire Assign priority 10 to Batchman-created job streams. Notez que cette option est également valide sous UNIX et Windows NT. Reportez-vous à la section «Options globales» à la page 67. all userjobs in userjobs schedule Remplace le paramètre 8 de CTP1-, c est-à-dire, Place all user jobs in USERJOBS job stream. Définissez la valeur no pour cette option si rules mode a pour valeur yes. set mpe job pri to zero Remplace le paramètre 9 de CTP1-, c est-à-dire Force MPE priority to 0 for all userjobs. Définissez la valeur no pour cette option si l option all userjobs in userjobs schedule a pour valeur yes. 72 Version 8.1

93 Options locales Options locales Des options locales sont définies sur chaque poste de travail et ne s appliquent qu à ce poste de travail. Définition des options locales Vous entrez des options locales dans un fichier nommé localopts à l aide d un éditeur de texte. Vous pouvez apporter des modifications à tout moment, mais elles ne seront prises en compte qu une fois que Tivoli Workload Scheduler aura été arrêté et redémarré. La syntaxe est décrite dans le tableau suivant. Les entrées ne font pas de distinction majuscules/minuscules. 5. Etapes de personnalisation Syntaxe de l option locale Valeur par défaut # commentaire bm check file = secondes 120 bm check status = secondes 300 bm check until = secondes 300 bm look = secondes 30 bm read = secondes 15 bm stats = on off off bm verbose = on off off composer prompt= clé dash (-) conman cli prompt= clé percent (%) date format= entier 1 jm job table size = entrées 160 jm look = secondes 300 jm nice = valeur 0 jm no root = yes no no jm read = secondes 10 merge stdlists = yes no yes mm cache mailbox= yes no no mm cache size= octets 32 mm read = secondes 15 mm response = secondes 600 mm retry link = secondes 600 mm sound off = yes no no mm unlink = secondes 960 mozart directory = partage_mozart None nm ipvalidate = none full none nm mortal = yes no no nm port = numéro de port nm read = secondes 60 nm retry = secondes 800 parameters directory =partage_paramètres None stdlist width = colonnes 80 Tivoli Workload Scheduler - Guide de planification et d installation 73

94 Options locales Syntaxe de l option locale Valeur par défaut sync level= low medium high high switch sym prompt=clé percent (%) syslog local = utilitaire -1 thiscpu = postetravail thiscpu unison network directory = partage_unison None wr read = secondes 600 wr enable compression= yes no no wr unlink = secondes 600 # commentaire Traite tout ce qui suit le signe dièse jusqu à la fin de la ligne comme du commentaire. bm check file Indiquez le nombre minimum de secondes pendant lequel Batchman va attendre avant de vérifier l existence d un fichier qui est utilisé en tant que dépendance. bm check status Indiquez le nombre de secondes pendant lequel Batchman va attendre avant de vérifier l état d une dépendance interréseau. bm check until Indiquez le nombre maximum de secondes pendant lequel Batchman va attendre avant de signaler l expiration d une échéance pour un travail ou flux de travaux. L indication d une valeur inférieure à la valeur par défaut (300) peut entraîner une surcharge du système. Si cette option a une valeur inférieure à celle de l option locale bm read, la valeur de bm read est utilisée à sa place. bm look Indiquez le nombre minimum de secondes pendant lequel Batchman va attendre avant d analyser et de mettre à jour son fichier de contrôle de production. bm read Indiquez le nombre maximum de secondes pendant lequel Batchman va attendre l arrivée d un message dans son fichier de messages. bm stats Indiquez la valeur on pour que Batchman envoie ses statistiques de démarrage et d arrêt à son fichier de liste standard. Indiquez la valeur off pour empêcher l envoi des statistiques de Batchman à son fichier de liste standard. bm verbose Indiquez la valeur on pour que Batchman envoie tous les messages d état des travaux à son fichier de liste standard. Indiquez off pour empêcher l envoi de l ensemble étendu de messages d état des travaux au fichier de liste standard. composer prompt Indiquez une invite pour la ligne de commande du Composer. L invite peut contenir jusqu à 10 caractères. La valeur par défaut est un tiret (-). conman prompt Indiquez une invite pour la ligne de commande Conman. L invite peut contenir jusqu à 8 caractères. La valeur par défaut est un signe pourcentage (%). 74 Version 8.1

95 Options locales date format Indiquez la valeur qui correspond au format de date que vous souhaitez utiliser. Les valeurs peuvent être les suivantes : 0 correspond à aa/mm/jj 1 correspond à mm/jj/aa 2 correspond à jj/aa/mm 3 indique l utilisation de variables d environnement NLS (Native Language Support) La valeur par défaut est 1. jm job table size Indiquez la taille, en nombre d entrées, de la table des travaux utilisée par Jobman. jm look Indiquez le nombre minimum de secondes pendant lequel Jobman va attendre avant de rechercher les travaux terminés et d exécuter des tâches de gestion générales des travaux. jm nice Pour UNIX uniquement, indiquez la valeur nice à appliquer aux travaux lancés par Jobman. jm no root Pour UNIX uniquement, indiquez yes pour empêcher que Jobman ne lance des travaux root. Indiquez no pour autoriser que Jobman lance des travaux root. jm read Indiquez le nombre maximum de secondes pendant lequel Jobman va attendre l arrivée d un message dans son fichier de messages. mm cache mailbox Utilisez cette option pour activer mailman afin d utiliser une mémoire cache de lecture pour les messages entrants. Dans ce cas, tous les messages ne sont pas mis en cache ; seuls les messages qui ne sont pas considérés comme essentiels à la cohérence du réseau sont mis en cache. La valeur par défaut est no. mm cache size Définissez cette option si vous utilisez également mm cache mailbox. La valeur par défaut est 32 octets. Utilisez la valeur par défaut pour les réseaux de petite et de moyenne envergure. Utilisez des valeurs plus importantes pour les grands réseaux. Evitez d utilisateur une valeur élevée sur les petits réseaux. La valeur maximale est 512 (les valeurs supérieures sont ignorées). merge stdlists Indiquez yes pour que tous les processus de contrôle Tivoli Workload Scheduler, à l exception de Netman, envoient leurs messages écran à un seul fichier de liste standard. Ce fichier est intitulé maestro. Indiquez no pour que les processus envoient les messages à des fichiers de liste standard séparés. mm read Indiquez la fréquence, en secondes, à laquelle Mailman vérifie la présence de messages dans sa boîte aux lettres. La valeur par défaut est 15 secondes. L indication d une valeur inférieure entraînera une exécution plus rapide de Tivoli Workload Scheduler, mais aussi l utilisation de plus de temps processeur. 5. Etapes de personnalisation Tivoli Workload Scheduler - Guide de planification et d installation 75

96 Options locales mm response Indiquez le nombre maximum de secondes pendant lequel Mailman va attendre une réponse avant de signaler qu un poste de travail ne répond pas. Le temps de réponse ne doit pas être inférieur à 90 secondes. mm retry link Indiquez le nombre maximum de secondes pendant lequel Mailman va attendre, après avoir supprimé les liens avec un poste de travail ne répondant pas, avant d essayer à nouveau de créer un lien avec ce poste de travail. mm sound off Indique la façon dont Mailman répond à une commande conman tellop?. Indiquez yes pour que Mailman affiche des informations concernant chacune des tâches qu il exécute. Indiquez no pour que Mailman envoie uniquement son propre état. mm unlink Indiquez le nombre maximum de secondes pendant lequel Mailman va attendre avant de supprimer les liens avec un poste de travail ne répondant pas. Le délai d attente ne doit pas être inférieur au temps de réponse indiqué pour l option locale nm response. nm ipvalidate Indiquez full pour activer la validation de l adresse IP. Si la validation IP échoue, la connexion n est pas autorisée. Indiquez none pour autoriser les connexions lorsque la validation IP échoue. nm mortal Indiquez yes pour que Netman se ferme lorsque tous ses processus enfants se sont arrêtés. Indiquez no pour que Netman continue à s exécuter même lorsque tous ses processus enfants se sont arrêtés. nm port Indiquez le numéro du port TCP auquel Netman répond sur l ordinateur local. Cette valeur doit correspondre au port TCP indiqué dans la définition de poste de travail de cet ordinateur. Il doit s agir d une valeur 16 bits non signée comprise dans la fourchette (n oubliez pas que les valeurs comprises entre 0 et 1023 sont réservées aux services connus, tels que FTP, TELNET, HTTP, etc.) nm read Indiquez le nombre maximum de secondes pendant lequel Netman va attendre une demande de connexion avant de vérifier la présence des commandes stop et start dans sa file d attente de messages. nm retry Indiquez le nombre maximum de secondes pendant lequel Netman va attendre avant de réessayer une connexion qui a échoué. stdlist width Indiquez la largeur maximale des messages écran de Tivoli Workload Scheduler. Vous pouvez indiquer un numéro de colonne compris entre 1 et 255 et que le renvoi à la ligne s effectue au niveau de la colonne indiquée ou avant cette colonne, en fonction de la présence de caractères de contrôle chariot incorporés. Indiquez un nombre négatif ou nul pour ignorer l épaisseur de ligne. Sous UNIX, vous devez ignorer l épaisseur de ligne si vous activez la journalisation système avec l option syslog local. 76 Version 8.1

97 Options locales syslog local Active ou désactive la journalisation système de Tivoli Workload Scheduler uniquement pour les ordinateurs UNIX. Indiquez -1 pour désactiver la journalisation système pour Tivoli Workload Scheduler. Indiquez un nombre compris entre 0 et 7 pour activer la journalisation système et pour que Tivoli Workload Scheduler utilise l utilitaire local correspondant (LOCAL0 à LOCAL7) pour ses messages. Indiquez tout autre nombre pour activer la journalisation système et pour que Tivoli Workload Scheduler utilise l utilitaire USER pour ses messages. Pour plus d informations, reportez-vous à la section «Invites et messages d écran de Tivoli Workload Scheduler» à la page 80. sync level Indiquez la vitesse des accès en écriture sur le disque. Cette option affecte tous les agents mailbox et elle s applique uniquement aux postes de travail UNIX. Les valeurs peuvent être les suivantes : low Laisse le système d exploitation gérer ce paramètre. medium Effectue des mises à jour dès qu une transaction est terminée. high Effectue des mises à jour chaque fois que des données sont entrées. La valeur par défaut est high. switch sym prompt Indiquez une invite pour la ligne de commande conman après avoir sélectionné un fichier Symphony différent à l aide de la commande setsym. L invite peut contenir jusqu à 8 caractères. La valeur par défaut est un signe pourcentage (%). thiscpu Indiquez le nom Tivoli Workload Scheduler de ce poste de travail. wr enable compression Utilisez cette option sur les agents tolérant les pannes. Indiquez si l agent FTA peut recevoir le fichier Symphony sous forme compressée à partir du gestionnaire de domaine principal. La valeur par défaut est no. wr read Indiquez le nombre de secondes pendant lequel le processus Writer va attendre la réception d un message entrant avant de vérifier l existence d une demande d arrêt émise par Netman. wr unlink Indiquez le nombre de secondes pendant lequel le processus Writer va attendre avant de s arrêter si aucun message entrant n est reçu. La limite inférieure est 120 et la valeur par défaut est Etapes de personnalisation Exemple de fichier d options locales Un modèle de fichier contenant les paramètres par défaut de Tivoli Workload Scheduler se trouve dans TWShome/config/localopts. Au cours du processus d installation, une copie de travail du fichier des options locales est installée en tant que TWShome/localopts à moins que vous n ayez indiqué un emplacement autre que l emplacement par défaut pour netman. Si c est le cas, il existe deux copies du fichier localopts, une dans TWShome et une autre dans Netmanhome. Toutes les options se rapportant à netman doivent être mises à jour avec le fichier localopts situé dans Netmanhome. Tivoli Workload Scheduler - Guide de planification et d installation 77

98 Options locales Vous pouvez personnaliser la copie de travail en fonction de vos besoins. Voici un exemple de fichier des options locales : # # Tivoli Workload Scheduler localopts file defines attributes of this Workstation. # # # Attributes of this Workstation: # thiscpu=<thiscpu> merge stdlists=yes stdlist width=80 syslog local=-1 # # # Attributes of this Workstation for Tivoli Workload Scheduler batchman process: # bm check file=120 bm check status=300 bm look=15 bm read=10 bm stats=off bm verbose=off bm check until=300 # # # Attributes of this Workstation for Tivoli Workload Scheduler jobman process: # jm job table size=1024 jm look=300 jm nice=0 jm no root=no jm read=10 # # # Attributes of this Workstation for Tivoli Workload Scheduler mailman process: # mm response=600 mm retrylink =600 mm sound off =no mm unlink=960 mm cache mailbox =no mm cache size =32 # # # Attributes of this Workstation for Tivoli Workload Scheduler netman process: # nm mortal=no nm port=<tcp_port> nm read=10 nm retry=800 # # # Attributes of this Workstation for Tivoli Workload Scheduler writer process: # wr read =600 wr unlink =120 wr enable compression =no # # # Optional attributes of this Workstation for remote database files # # mozart directory = <HOME>/mozart # parameters directory = <HOME> # unison network directory = <HOME>/../unison/network # # Version 8.1

99 Options locales # Custom format attributes # date format = 1# The possible values are 0-ymd, 1-mdy, 2-dmy, 3-NLS. composer prompt = - conman prompt = % switch sym prompt = <n>% # # # Attributes for customization of I/O on mailbox files # sync level = high # # Définition des options locales Netman Si le répertoire principal de Netman n est pas le même que le répertoire principal de Tivoli Workload Scheduler, les options locales suivantes sont déplacées dans un fichier localopts séparé dans le répertoire Netman : nm ipvalidate nm mortal nm port nm read nm retry merge stdlists stdlist width syslog local Pour plus d informations sur le répertoire Netman, reportez-vous à la section «Répertoire principal de Netman» à la page 17. Définition des options pour l administration centralisée sous Windows NT Si vous avez installé Tivoli Workload Scheduler en utilisant la procédure qui autorise l administration décentralisée des objets de planification, vous pouvez définir les répertoires partagés sur le gestionnaire de domaine principal à l aide des options suivantes. mozart directory Indiquez le nom du répertoire mozart partagé du gestionnaire de domaine principal. unison network directory Indiquez le nom du répertoire unison partagé du gestionnaire de domaine principal. parameters directory Indiquez le nom du répertoire TWShome partagé du gestionnaire de domaine principal. Si une option n est pas définie ou n existe pas, les programmes Tivoli Workload Scheduler tentent d ouvrir les fichiers de base de données sur l ordinateur local. 5. Etapes de personnalisation Tivoli Workload Scheduler - Guide de planification et d installation 79

100 Options locales Invites et messages d écran de Tivoli Workload Scheduler Les processus de contrôle de Tivoli Workload Scheduler (Netman, Mailman, Batchman, Jobman et Writer) écrivent leurs messages d état, appelés messages d écran, dans leurs fichiers de liste standard. Ces messages comprennent les invites utilisées en tant que dépendances de travail et de flux de travaux. Sous UNIX, les messages peuvent également être acheminés vers le démon syslog (syslogd) et vers un terminal exécutant le gestionnaire de console Tivoli Workload Scheduler. Ces fonctions sont décrites dans les sections suivantes. Définition de sysloglocal sous UNIX Si vous affectez un nombre positif à sysloglocal dans le fichier des options locales, les processus de contrôle de Tivoli Workload Scheduler envoient leurs messages d écran et leurs messages d invite au démon syslog. La définition de la valeur -1 pour cette option désactive cette fonction. Si vous affectez un nombre positif à cette option pour activer la journalisation système, vous devez également affecter la valeur 0 ou un nombre négatif à l option stdlistwidth. Les messages d écran de Tivoli Workload Scheduler correspondent aux niveaux syslog suivants : LOG_ERR Les messages d erreur, tels que les arrêts anormaux des processus de contrôle et les erreurs de système de fichier. LOG_WARNING Les messages d avertissement, tels que les erreurs de lien et les flux de travaux bloqués. LOG_NOTICE Les messages spéciaux, tels que les invites et les tellops. LOG_INFO Les messages d information, tels que les lancements de travaux et les modifications d état de travaux et de flux de travaux. La définition d un nombre positif pour l option sysloglocal détermine l utilitaire syslog utilisé par Tivoli Workload Scheduler. Par exemple, une valeur de 4 indique à Tivoli Workload Scheduler d utiliser l utilitaire local LOCAL4. Après avoir défini cette valeur, vous devez effectuer les entrées appropriées dans le fichier /etc/syslog.conf et reconfigurer le démon syslog. Pour utiliser LOCAL4 et pour que les messages Tivoli Workload Scheduler soient envoyés à la console système, entrez la ligne suivante dans /etc/syslog.conf : local4 /dev/console Pour que les messages d erreur Tivoli Workload Scheduler soient envoyés aux utilisateurs maestro et root, entrez la ligne suivante : local4.err maestro,root Notez que les zones de sélecteur et d action doivent être séparées par au moins une tabulation. Après avoir modifié /etc/syslog.conf, vous pouvez reconfigurer le démon syslog en entrant la commande suivante : kill -HUP `cat /etc/syslog.pid` 80 Version 8.1

101 Options locales Commande console Vous pouvez utiliser la commande console du Gestionnaire de console pour définir le niveau de message de Tivoli Workload Scheduler et pour acheminer les messages jusqu à votre terminal. La définition du niveau de message concerne uniquement les messages Batchman et Mailman, lesquels sont les plus nombreux. Elle définit également le niveau des messages écrits dans le ou les fichiers de liste standard et dans le démon syslog. Par exemple, la commande suivante définit le niveau des messages Batchman et Mailman à 2 et envoie les messages à votre ordinateur : console sess;level=2 Les messages sont envoyés à votre ordinateur jusqu à ce que vous exécutiez une autre commande console ou que vous quittiez Conman. Pour arrêter l envoi de messages à votre terminal, vous pouvez entrer la commande Conman suivante : console sys 5. Etapes de personnalisation Automatisation du cycle de production Le traitement de pré- et de post-production peut être entièrement automatisé par l ajout du flux de travaux final fourni par Tivoli, ou d un équivalent fourni par l utilisateur, à la base de données Tivoli Workload Scheduler en même temps que les autres flux de travaux. Une copie du flux de travaux fourni par Tivoli peut être trouvé dans TWShome/Sfinal, etune copie du script de travail peut être trouvé dans TWShome/Jnextday. Vous pourrez trouver utile de disposer de copies imprimées pour mieux comprendre le processus de rotation. Le flux de travaux final est mis en production tous les jours et entraîne l exécution d un travail nommé Jnextday avant le début d une nouvelle journée. Ce travail exécute les tâches suivantes : 1. Etablit des liens avec tous les postes de travail pour s assurer que le gestionnaire de domaine principal a été mis à jour avec les informations de planification les plus récentes. 2. Exécute la commande schedulr pour sélectionner les flux de travaux pour le plan de production de la nouvelle journée. 3. Exécute la commande compiler pour compiler le plan de production. 4. Exécute la commande reptr pour imprimer les rapports de pré-production. 5. Arrête Tivoli Workload Scheduler. 6. Exécute la commande stageman pour reporter les flux de travaux non terminés, enregistrer l ancien plan de production et installer le nouveau plan. 7. Démarre Tivoli Workload Scheduler pour la nouvelle journée. 8. Exécute les commandes reptr et rep8 pour imprimer les états de post-production pour le jour précédent. 9. Exécute la commande logman pour consigner les statistiques relatives aux travaux pour le jour précédent. Dans l ensemble de manuels Tivoli Workload Scheduler, les termes final etjnextday sont utilisés pour faire référence à la fois aux versions fournies par Tivoli et à tous les équivalents fournis par l utilisateur. Tivoli Workload Scheduler - Guide de planification et d installation 81

102 Automatisation du cycle de production Personnalisation du flux de travaux final Avant d utiliser le flux de travaux final, vous pouvez le modifier de façon à l adapter à vos besoins, ou vous pouvez créer un flux de travaux différent à utiliser à sa place. Lors de la création de votre propre flux de travaux, utilisez comme modèle celui qui est fourni par Tivoli. Si vous choisissez cette approche, tenez compte des considérations suivantes : Si vous choisissez de modifier la façon dont stageman génère les noms des fichiers journaux, souvenez-vous que reptr et logman doivent utiliser les mêmes noms. Si vous souhaitez imprimer les états de pré-production en avance par rapport à une nouvelle journée, vous pouvez diviser le travail Jnextday en deux travaux. Le premier travail exécutera schedulr, compiler et reptr. Le deuxième travail arrêtera Tivoli Workload Scheduler, exécutera stageman, démarrera Tivoli Workload Scheduler et exécutera reptr et logman. Le premier travail peut ensuite être planifié pour s exécuter à tout moment avant la fin de la journée, tandis que le deuxième travail est planifié pour s exécuter juste avant la fin de la journée. Ajout du flux de travaux final Si vous avez suivi les instructions fournies à la section «Configuration d un gestionnaire de domaine principal après l installation» à la page 36 sous UNIX, ou si vous avez installé Tivoli Workload Scheduler à l aide du programme d installation sous NT, le flux de travaux final a déjà été ajouté à la base de données. Si ce n est pas le cas, exécutez les étapes suivantes pour ajouter le flux de travaux final ou un équivalent fourni par l utilisateur. 1. Connectez-vous en tant qu utilisateur TWS ou maestro sur le gestionnaire de domaine principal. 2. A l invite de commande, exécutez la commande suivante sous UNIX ou sous Windows NT : composer add Sfinal Pour ajouter votre propre flux de travaux, utilisez son nom à la place de Sfinal. Démarrage d un cycle de production Si aucun cycle de production n a été démarré auparavant, ou s il devient nécessaire de démarrer une nouvelle journée de production à une heure autre que le début de journée défini, procédez comme suit : 1. Connectez-vous en tant qu utilisateur maestro sur le gestionnaire de domaine principal. 2. A l invite de commande, exécutez conman "release final". Le traitement de pré-production va alors s exécuter et les processus de production de Tivoli Workload Scheduler vont démarrer. 82 Version 8.1

103 Gestion de l environnement de production Gestion de l environnement de production Cette section fournit des informations sur la modification du début de la journée pour Tivoli Workload Scheduler et sur la création d un plan pour traiter les processus de journées ultérieures ou antérieures. Choix du début de la journée Il existe trois choix courants pour le début du jour de production. tôt le matin tard l après-midi minuit Voici quelques-unes des implications en terme de planification : Heures de début et échéances Les heures de début mot clé AT) indiquées sont toujours relatives à l heure de début du jour de production de Tivoli Workload Scheduler. Vous pouvez avoir besoin d ajouter + 1 day aux flux de travaux dont les travaux s exécutent sur plusieurs jours de production. Aussi, vous devez vous assurer que l échéance (mot clé UNTIL) est ultérieure à l heure de début m. Mot clé On Les jours de production et les jours du calendrier ne coïncident pas forcément. Si votre jour de production commence à 06:00 (valeur par défaut), 05:59 correspond à la dernière minute du jour de production. Un flux de travaux défini pour s exécuter ON MONDAY à 05:30 sera sélectionné lundi et s exécutera mardi matin à 05:30. mot clé Carryforward Si le début de la journée est défini vers minuit de façon à correspondre au jour du calendrier, il est probable que cela entraînera le report d un grand nombre de flux de travaux et augmentera la complexité de la gestion du centre de données. Modification du début de la journée Le début de la journée pour Tivoli Workload Scheduler correspond au moment où le flux de travaux final s exécute et où les processus Tivoli Workload Scheduler sont arrêtés et redémarrés. Pour indiquer le début de la journée pour Tivoli Workload Scheduler : 1. Modifiez l option start dans le fichier Globalopts. Voici l heure de début du jour de traitement de Tivoli Workload Scheduler au format 24 heures : hhmm ( ). L heure de début par défaut est 06: Modifiez l heure de début (mot clé AT) du flux de travaux final pour qu il s exécute une minute avant la fin de la journée. Si vous souhaitez définir le début du jour de production à minuit, procédez comme suit : 1. Définissez l heure de début du flux de travaux final à minuit. 2. Affectez la valeur 0001 à l option start dans le fichier Globalopts. Autrement, si vous définissez l option start sur 0000 et l option Jnextday sur 2359, vous risquez de sélectionner des agendas et des flux de travaux pour la journée qui vient de se terminer, étant donné que la commande schedulr utilise la date du système et que les petits réseaux peuvent parfois lancer l exécution de schedulr avant minuit. 5. Etapes de personnalisation Tivoli Workload Scheduler - Guide de planification et d installation 83

104 Gestion de l environnement de production Création d un plan pour les dates ultérieures ou antérieures Vous pouvez créer un plan qui exécute un traitement normalement planifié pour un jour de traitement ultérieur ou antérieur. Cette procédure recrée efficacement n importe quel jour de traitement spécifié. Vous pouvez avoir besoin d utiliser cette procédure si vous avez perdu un jour de traitement en raison d une urgence. 1. Supprimez les liens avec tous les postes de travail de votre réseau Tivoli Workload Scheduler et arrêtez-les à l aide des commandes suivantes : conman conman Ces commandes arrêtent tout traitement sur le réseau. 2. Exécutez la commande schedulr avec l option date pour créer un fichier prodsked : schedulr -date MM/DD/YY Avec l option date, vous pouvez indiquer la création d un plan basé sur un jour de traitement ultérieur ou antérieur. 3. Exécutez la commande compiler pour créer un fichier symnew : compiler (-date MM/DD/YY) Vous pouvez utiliser l option date avec compiler pour indiquer la date d aujourd hui ou la date du jour que vous essayez de recréer. Cette option peut être nécessaire si vous avez des flux de travaux contenant des paramètres d entrée liés à la date. Le paramètre scheddate est défini par rapport à la date indiquée à l aide de la commande compiler. Si vous n indiquez pas de date, ce paramètre prend par défaut la date entrée à l aide de la commande schedulr. 4. Exécutez le Gestionnaire de console pour arrêter les processus de Tivoli Workload Scheduler : conman 5. Exécutez stageman pour créer un nouveau fichier symphony : stageman 6. Exécutez le Gestionnaire de console pour démarrer les processus de Tivoli Workload Scheduler : conman start Utilisation des scripts de configuration Tivoli Workload Scheduler fournit deux scripts de configuration standard, l un au niveau global et l autre au niveau local, pour établir votre environnement de production. Script de configuration standard - jobmanrc Un modèle de script de configuration standard nommé maestrohome/config/jobmanrc est fourni avec Tivoli Workload Scheduler. Il est installé automatiquement en tant que maestrohome/jobmanrc. Ce script peut être utilisé par l administrateur système pour établir un environnement de son choix avant l exécution de chaque travail. Si vous souhaitez modifier le script, apportez vos modifications dans la copie de travail (maestrohome/jobmanrc) en laissant le fichier modèle intact. Ce fichier contient des variables configurables et des commentaires qui vous aident à comprendre la méthodologie. Le tableau 3 décrit les variables de jobmanrc. 84 Version 8.1

105 Tableau 3. Variables de jobmanrc Nom de la variable UNISON_JCL UNISON_STDLIST UNISON_EXIT LOCAL_RC_OK MAIL_ON_ABEND Utilisation des scripts de configuration Valeur Le chemin d accès du fichier script du travail. Le chemin d accès du fichier de liste standard du travail. (Définissable) Si cette variable a pour valeur yes, le travail est arrêté immédiatement si une commande renvoie un code de sortie non nul. Si elle a pour valeur no, le travail continue à s exécuter si une commande renvoie un code de sortie non nul. Toute autre valeur est interprétée comme étant no. (Définissable) Si cette variable a pour valeur yes, le script de configuration local de l utilisateur s exécute (s il existe) et passe $UNISON_JCL comme premier argument. L utilisateur peut être autorisé ou non à utiliser cette option. Pour plus d informations, reportez-vous à la section «Script de configuration local - $HOME/.jobmanrc» à la page 86. Si cette variable a pour valeur no, la présence d un script de configuration local est ignorée et $UNISON_JCL s exécute. Toute autre valeur est interprétée comme étant no. (Définissable) Si cette variable a pour valeur yes, un message est envoyé à la boîte aux lettres de l utilisateur qui s est connecté si le travail se termine avec un code de sortie non nul. Cette variable peut également être définie sur un ou plusieurs noms d utilisateur, séparés par des espaces, et un message est envoyé à chacun d eux. Par exemple, root mis sam mary. Sila variable a pour valeur no, aucun message n est envoyé si le travail s interrompt anormalement. Les messages d arrêt anormal utilisent le format suivant : cpu#sched.job fichier-jcl failed with code-sortie Please review nomfichier-standard-liste 5. Etapes de personnalisation Tivoli Workload Scheduler - Guide de planification et d installation 85

106 Utilisation des scripts de configuration Tableau 3. Variables de jobmanrc (suite) Nom de la variable SHELL_TYPE USE_EXEC Valeur (Configurable) Si cette variable a pour valeur standard, la première ligne du fichier jcl est lue pour déterminer quel shell utiliser pour exécuter le travail. Si la première ligne ne commence pas par #!, alors /bin/sh est utilisé pour exécuter le script de configuration local ou $UNISON_JCL. Les commandes sont répercutées sur le fichier de liste standard du travail. Si cette variable a pour valeur le nom de l utilisateur, le script de configuration local ou $UNISON_JCL est exécuté par le shell de connexion de l utilisateur ($UNISON_SHELL). Les commandes sont répercutées sur le fichier de liste standard du travail. Si cette variable a pour valeur script, le script de configuration local ou $UNISON_JCL est exécuté directement et les commandes ne sont pas répercutées, à moins que le script de configuration local ou $UNISON_JCL ne contienne une commande set -x. Toute autre valeur est interprétée comme étant standard. (Définissable) Si cette variable a pour valeur yes, le travail, ou le script de configuration local de l utilisateur, est exécuté à l aide de la commande exec, ce qui élimine un processus supplémentaire. Cette option est remplacée si MAIL_ON_ABEND est également défini à yes. Toute autre valeur est interprétée comme étant no, auquel cas le travail ou le script de configuration local est exécuté par un autre processus du shell. Script de configuration local - $HOME/.jobmanrc Le script de configuration local permet aux utilisateurs d établir un environnement de leur choix pour l exécution de leurs propres travaux. Le script ne s exécutera que dans les conditions suivantes : 1. Le script de configuration standard, jobmanrc, doit être installé et la variable d environnement LOCAL_RC_OK doit avoir pour valeur yes (reportez-vous au tableau 3). 2. Si le fichier maestrohome/localrc.allow existe, le nom de l utilisateur doit figurer dans le fichier. Si le fichier allow n existe pas, le nom de l utilisateur ne doit pas figurer dans le fichier, maestrohome/localrc.deny. Si aucun de ces fichiers n existe, l utilisateur est autorisé à utiliser un script de configuration local. 3. Le script de configuration local doit être installé dans le répertoire principal de l utilisateur ($HOME/.jobmanrc), et il doit disposer de droits en exécution. Si vous avez l intention d utiliser un script de configuration local, il doit au minimum exécuter le fichier script du travail ($UNISON_JCL). Le script de configuration standard fourni par Tivoli, jobmanrc, exécute votre script de configuration local de la façon suivante : $EXECIT $USE_SHELL $HOME/.jobmanrc "$UNISON_JCL" $IS_COMMAND 86 Version 8.1

107 Utilisation des scripts de configuration La valeur de USE_SHELL est définie sur la valeur de la variable SHELL_TYPE de jobmanrc (reportez-vous au tableau 3 à la page 85). IS_COMMAND a pour valeur yes si le travail a été planifié ou soumis à l aide de la structure docommand. EXECIT a pour valeur exec si la variable USE_EXEC a pour valeur yes (reportez-vous au tableau 3 à la page 85), sinon elle est nulle. L exemple suivant indique comment exécuter le fichier de script, ou la commande, d un travail dans votre script de configuration local. #!/bin/ksh PATH=maestrohome:maestrohome/bin:$PATH export PATH /bin/sh -c "$UNISON_JCL" Voici un exemple de.jobmanrc qui effectue les traitements en fonction du code de sortie du travail de l utilisateur : #!/bin/sh # PATH=maestrohome:maestrohome/bin:$PATH export PATH /bin/sh -c "$UNISON_JCL" #or use eval "$UNISON_JCL" and the quotes are required RETVAL=$? if [ $RETVAL -eq 1 ] then echo "Exit code 1 - Non Fatal Error" exit 0 elif [ $RETVAL -gt 1 -a $RETVAL -lt 100 ] then conman "tellop This is a database error - page the dba" elif [ $RETVAL -ge 100 ] then conman "tellop Job aborted. Please page the admin" fi 5. Etapes de personnalisation Tivoli Workload Scheduler - Guide de planification et d installation 87

108 Utilisation des scripts de configuration 88 Version 8.1

109 A Fuseaux horaires et audit Fuseaux horaires Cette annexe décrit les éléments suivants : Fuseaux horaires Audit Tivoli Workload Scheduler prend en charge les fuseaux horaires. L activation des fuseaux horaires vous donne la possibilité de gérer votre charge de travail à l échelle internationale. L implémentation des fuseaux horaires permet également une planification aisée sur plusieurs fuseaux horaires et la gestion des travaux devant s exécuter dans la zone morte. La zone morte correspond à l espace situé entre l heure du début de journée de Tivoli Workload Scheduler sur le système maître et l heure qu il est sur l agent FTA dans un autre fuseau horaire. Par exemple, si un maître de la côte Est sur lequel le début de journée Tivoli Workload Scheduler est défini à 06:00 initialise un agent de la côte Ouest présentant un décalage horaire de 3 heures, la zone morte pour cet agent FTA se situe entre 03:00 et 06:00. Auparavant, un traitement spécial était nécessaire pour exécuter les travaux au cours de cette période. Désormais, lorsque vous définissez un fuseau horaire avec l heure de début sur un travail ou un flux de travaux, Tivoli Workload Scheduler les exécute comme prévu. Par exemple, examinez les deux flux de travaux suivants pour un agent FTA PST (heure du Pacifique) avec un maître EST (Heure côte Est) : Schedule PST_SCHEDULE1 Schedule PST_SCHEDULE2 On SU, weekdays except FR on weekdays CARRYFORWARD AT 0330 TZ PST AT 0330 : : joba job1 jobb job2 END END Les fuseaux horaires ne sont pas activés pour le flux de travaux PST_SCHEDULE1. Pour obtenir que ce flux de travaux s exécute tous les jours de la semaine, le matin, vous devez le planifier pour qu il s exécute de Dimanche à Jeudi et indiquer carryforward. Sans carryforward, les travaux ne s exécuteraient jamais étant donné que l agent FTA serait initialisé à 03:00 chaque matin (en supposant que le début de journée Tivoli Workload Scheduler soit défini à 06:00 sur le maître EST). Les fuseaux horaires sont activés pour le flux de travaux PST_SCHEDULE2. Lorsque le maître EST initialise l agent FTA PST à 03:00, il démarre le flux de travaux le même jour à 03:30. A. Fuseaux horaires et audit Tivoli Workload Scheduler - Guide de planification et d installation 89

110 Fuseaux horaires L activation des fuseaux horaires a également une incidence sur les agents FTA de la côte Est lorsque la planification est effectuée à partir de maîtres de la côte Ouest. Par exemple, examinez les deux flux de travaux suivants pour un agent FTA EST (Heure côte Est) et un maître PST (Heure du Pacifique) avec un début de journée défini à 06:00. Schedule EST_SCHEDULE1 Schedule EST_SCHEDULE2 On SU, weekdays except FR On SU, weekdays except FR AT0800+1DAY AT0800 TZ EST CARRYFORWARD : : joba job1 jobb job2 END END Les fuseaux horaires ne sont pas activés pour le flux de travaux EST_SCHEDULE1. Pour que ce flux de travaux s exécute tous les jours de la semaine, le matin, vous devez le planifier pour qu il s exécute de Dimanche à Jeudi. Indiquez carryforward et +1DAY pour l heure AT. Carryforward est nécessaire à l indication +1DAY. Sans l indication +1DAY, le flux de travaux se déclencherait immédiatement après son initialisation à 09:00 depuis le maître de la côte Ouest. Les fuseaux horaires sont activés pour le flux de travaux EST_SCHEDULE2. Lorsque l agent FTA de la côte Est est initialisé à 09:00, il exécute le flux de travaux à 08:00 le jour suivant. Une fois activés, les fuseaux horaires peuvent être indiqués dans JS Console ou dans composer pour les heures de début et les échéances dans les travaux et les flux de travaux. Pour conman, les commandes suivantes acceptent désormais les paramètres de fuseaux horaires lorsque les heures AT et UNTIL sont utilisées : submit job submit docommand submit file submit schedule addep schedule addep job addep schedule addep job rurun job; from option Activation de la fonction de fuseau horaire La fonction de fuseau horaire est activée par une entrée dans le fichier globalopts et par l indication d un fuseau horaire dans la définition de poste de travail du système maître, comme suit : timezone enable = yes no Les fuseaux horaires sont désactivés par défaut lors de l installation ou de la mise à jour du produit. Si l entrée timezone enable est absente du fichier globalopts, les fuseaux horaires sont désactivés. 90 Version 8.1

111 Fuseaux horaires Nom et description des fuseaux horaires Le tableau suivant répertorie le nom des fuseaux horaires supportés par Tivoli Workload Scheduler : Nom Description Par rapport à GMT GMT Heure de Greenwich GMT UTC Temps UTC GMT ECT Heure de l Europe centrale GMT+1:00 EET Heure de l Europe orientale GMT+2:00 ART Heure de l Egypte GMT+2:00 EAT Heure de l Afrique orientale GMT+3:00 MET Heure du Moyen-Orient GMT+3:30 NET Heure du Proche-Orient GMT+4:00 PLT Heure du Pakistan (Lahore) GMT+5:00 IST Heure de l Inde GMT+5:30 BST Heure du Bangladesh GMT+6:00 VST Heure du Vietnam GMT+7:00 CTT Heure de la Chine GMT+8:00 JST Heure du Japon GMT+9:00 ACT Heure de l Australie centrale GMT+9:30 AET Heure de l Australie orientale GMT+10:00 SST Heure des Iles Salomon GMT+11:00 NST Heure de la Nouvelle-Zélande GMT+12:00 MIT Heure des Iles Midway GMT-11:00 HST Heure des Iles Hawaii GMT-10:00 AST Heure de l Alaska GMT-9:00 PST Heure du Pacifique GMT-8:00 PNT Heure de Phoenix GMT-7:00 MST Heure des Montagnes (USA) GMT-7:00 CST Heure Central (USA) GMT-6:00 EST Heure Côte Est (USA) GMT-5:00 IET Heure d Indiana (Est) - USA GMT-5:00 PRT Heure de Porto Rico et des Iles Vierges GMT-4:00 CNT Heure du Canada (Newfoundland) GMT-3:30 AGT Heure de l Argentine GMT-3:00 BET Heure du Brésil (Est) GMT-3:00 CAT Heure de l Afrique centrale GMT-1:00 A. Fuseaux horaires et audit Tivoli Workload Scheduler - Guide de planification et d installation 91

112 Audit Audit Une option d audit a été mise en oeuvre pour assurer le suivi des modifications apportées à la base de données et au plan : Pour la base de données, toutes les modifications utilisateur sont consignées. Toutefois, la version antérieure aux modifications n est pas consignée. Si un objet est ouvert et sauvegardé, l action est consignée même si aucune modification n a été effectuée. Pour le plan, toutes les modifications utilisateur apportées au plan sont consignées. Les actions sont consignées, qu elles aboutissent ou non. Des journaux d audit sont créés dans les répertoires suivants : TWShome/audit/plan TWShome/audit/database Les fichiers d audit sont consignés dans un fichier texte à plat sur des machines individuelles du réseau Tivoli Workload Scheduler. Cela permet de réduire au minimum le risque d erreurs d audit dus à des problèmes de réseau et d écrire directement dans le journal. En règle générale, les formats de journaux sont les mêmes pour le plan et pour la base de données. Les journaux comportent un en-tête, qui est le même pour tous les enregistrements, un ID action et une section de données qui diffère en fonction du type d action. Toutes les données sont conservées sous forme de texte et vous pouvez les utiliser dans un éditeur de texte tel que vi ou notepad. Remarque : Pour les commandes modify, deux entrées sont effectuées dans le journal pour les ressources, les calendriers, les paramètres et les invites. La commande modify est affichée dans le journal sous la forme des commandes delete et add. Activation de la fonction d audit L option d audit est activée par deux entrées du fichier globalopts : plan audit level = 0 1 database audit level = 0 1 Une valeur égale à 1 active l audit et une valeur égale à 0 désactive l audit. Tivoli Workload Scheduler adopte actuellement par défaut la valeur 0, c est-à-dire, l audit désactivé. Si ces options ne sont pas présentes dans le fichier globalopts, l audit est désactivé. L audit est désactivé par défaut lors de l installation du produit. Pour lancer l audit de la base de données, vous devez complètement arrêter Tivoli Workload Scheduler et utiliser la commande wmaeutil pour arrêter l instance du connecteur. Lorsque vous redémarrez Tivoli Workload Scheduler et l instance du connecteur, le journal d audit de la base de données est lancé. L audit du plan prend effet lorsque Jnextday s exécute. Format du journal d audit Les formats du journal d audit sont essentiellement les mêmes pour le plan et la base de données. Le journal comprend un en-tête, un ID action et des sections de données qui varient en fonction du type d action. Les données sont au format texte et les différents éléments de données sont séparés par une barre verticale ( ). Les entrées du fichier journal utilisent le format suivant : Log Type GMT Date GMT Time Local Date Local Time Object Type Action Type Workstation Name User ID Framework User Object Name Action Data fields 92 Version 8.1

113 Audit Les fichiers journaux contiennent les informations suivantes : Log Type Cette zone affiche une valeur à huit caractères indiquant la source de l enregistrement du journal. Les types de journaux suivants sont pris en charge : HEADER L en-tête du fichier journal CONMAN Texte de la commande conman FILEAID Commande qui ouvre un fichier PLAN Action du plan STAGEMAN Exécution de stageman RELEASE Texte de la commande release DATABASE Action de la base de données PARMS Texte des paramètres de la commande MAKESEC Exécution de makesec DBEXPAND Exécution de dbexpand GMT Date Cette zone affiche la date GMT à laquelle l action a été exécutée. Le format est aaaammjj, oùaaaa est l année, mm est le mois et jj est le jour. GMT Time Cette zone affiche l heure GMT à laquelle l action a été exécutée. Le format est hhmmss, oùhh est l heure, mm correspond aux minutes et ss aux secondes. Local Date Cette zone affiche la date locale à laquelle l action a été exécutée. La date locale est définie par l option de fuseau horaire du poste de travail. Le format est aaaammjj, où aaaa est l année, mm est le mois et jj est le jour. Local Time Cette zone affiche l heure locale à laquelle l action a été exécutée. L heure locale est définie par l option de fuseau horaire du poste de travail. Le format est hhmmss, où hh est l heure, mm correspond aux minutes et ss aux secondes. Object Type Cette zone affiche le type de l objet qui a été affecté par une action. Il s agit de l un des types suivants : DATABASE Définition de base de données A. Fuseaux horaires et audit Tivoli Workload Scheduler - Guide de planification et d installation 93

114 Audit DBWKSTN Définition de poste de travail de la base de données DBWKCLS Définition de classe de poste de travail de la base de données DBDOMAIN Définition de domaine de la base de données DBUSER Définition d utilisateur de la base de données DBJBSTRM Définition de flux de travaux de la base de données DBJOB Définition de travail de la base de données DBCAL Définition de calendrier de la base de données DBPROMPT Définition d invite de la base de données DBPARM Définition de paramètre de la base de données DBRES Définition de ressource de la base de données DBSEC Sécurité de la base de données PLAN Plan PLWKSTN Poste de travail du plan PLDOMAIN Domaine du plan PLJBSTRM Flux de travaux du plan PLJOB Travail du plan PLPROMPT Invite du plan PLRES Ressource du plan PLFILE Fichier du plan 94 Version 8.1

115 Audit Action Type Cette zone affiche l action qui a été effectuée sur l objet. Les valeurs appropriées pour cette zone dépendent de l action effectuée. Pour la base de données, le type d action peut être ADD, DELETE, MODIFY, EXPAND ou INSTALL. Tivoli Workload Scheduler enregistrera les actions ADD, DELETE et MODIFY pour les postes de travail, les classes de poste de travail, les domaines, les utilisateurs, les travaux, les flux de travaux, les calendriers, les invites, les ressources et les paramètres dans la base de données. La zone Action Type enregistre également l installation d un nouveau fichier de sécurité. Lorsque makesec est exécuté, Tivoli Workload Scheduler l enregistre comme une action INSTALL pour un objet Définition de sécurité. Lorsque dbexpand est exécuté, il est enregistré comme une action EXPAND pour un objet de base de données. Les actions LIST et DISPLAY concernant les objets ne sont pas consignées. Pour fileaid, Tivoli Workload Scheduler ne consignera que les commandes donnant lieu à l ouverture d un fichier. Pour les paramètres, la ligne de commande avec arguments est consignée. Workstation Name Cette zone affiche le poste de travail Tivoli Workload Scheduler à partir duquel l utilisateur exécute l action. User ID Cette zone affiche l utilisateur connecté qui a exécuté l action spécifique. Sur les plateformes Win32, il s agira du nom de domaine complet domaine\utilisateur. Framework User Cette zone affiche l ID utilisateur reconnu par Tivoli Framework. Il s agit de l ID de connexion de l utilisateur de Job Scheduling Console. Object Name Cette zone affiche le nom complet de l objet. Le format de ce champ dépendra du type d objet, comme indiqué ici : DATABASE N/A DBWKSTN postetravail DBWKCLS classe_postetravail DBDOMAIN domaine DBUSER [postetravail#]utilisateur DBJBSTRM postetravail#fluxtravail DBJOB postetravail#travail DBCAL calendrier A. Fuseaux horaires et audit Tivoli Workload Scheduler - Guide de planification et d installation 95

116 Audit DBPROMPT invite DBPARM postetravail#paramètre DBRES postetravail#ressource DBSEC N/A PLAN N/A PLWKSTN postetravail PLDOMAIN domaine PLJBSTRM postetravail#instance_fluxtravaux PLJOB postetravail#instance_fluxtravaux.travail PLPROMPT [postetravail#]invite PLRES postetravail#ressource PLFILE postetravail#chemin(qualifiant) Action Dependent Data Cette zone affiche les zones de données spécifiques à une action. Le format de ces données dépend de la zone Action Type. En-tête du journal d audit Chaque fichier journal commence par un enregistrement d en-tête qui contient des informations sur le moment où le journal a été créé et indiquant s il s agit d un journal du plan ou de la base de données. Le contenu de l entrée du fichier d en-tête est le suivant : Log Type HEADER GMT Date La date GMT à laquelle le fichier journal a été créé. GMT Time L heure GMT à laquelle le fichier journal a été créé. Local Date La date locale à laquelle le fichier journal a été créé. Local Time L heure locale à laquelle le fichier journal a été créé. 96 Version 8.1

117 Workstation Name Le nom du poste de travail Tivoli Workload Scheduler pour lequel ce fichier a été créé. Chaque poste de travail du réseau Tivoli Workload Scheduler crée son propre journal. User ID L ID utilisateur Tivoli Workload Scheduler qui a créé le fichier journal. Object Type Ce champ indique DATABASE pour un fichier journal de la base de données et PLAN pour un fichier journal du plan. Object Name N/A Action Type N/A Action Dependent Data Cette zone affiche la version du fichier. Exemple d entrées du journal d audit Voici quelques exemples d entrées du fichier journal : HEADER DATABASE GANGES RIVERS\pyasa 1.0 DATABASE DBWKSTN ADD GANGES RIVERS\pyasa JAMUNA DATABASE DBJOB MODIFY SINDHU RIVERS\tairak NARMADA#dubo Audit A. Fuseaux horaires et audit Tivoli Workload Scheduler - Guide de planification et d installation 97

118 Audit 98 Version 8.1

119 B Réseaux Tivoli Workload Scheduler Un réseau Tivoli Workload Scheduler est constitué d un ou plusieurs domaines organisés de façon hiérarchique. Un domaine Tivoli Workload Scheduler correspond à un groupe logique d ordinateurs comprenant un gestionnaire de domaine et un certain nombre d agents. Définitions Gestionnaire de domaine de sauvegarde Agent tolérant les pannes capable d assumer les responsabilités de son gestionnaire de domaine. Domaine Groupe nommé de postes de travail Tivoli Workload Scheduler constitué d un ou de plusieurs agents et d un gestionnaire de domaine. Tous les domaines ont un parent. Gestionnaire de domaine (DM) Concentrateur de gestion d un domaine. Toutes les communications à destination et en provenance des agents d un domaine sont acheminées à travers le gestionnaire de domaine. Voir aussi Gestionnaire de domaine principal. Agent étendu (xa) Poste de travail qui ne lance des travaux que sous la direction de son hôte. Les agents étendus peuvent servir d interface entre Tivoli Workload Scheduler et les systèmes et applications non Tivoli Workload Scheduler. B. Réseaux Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 99

120 Définitions Agent tolérant les pannes (fta) Poste de travail capable de résoudre les dépendances locales et de lancer ses travaux en l absence d un gestionnaire de domaine. Hôte (x-hôte) La fonction de planification requise par les agents étendus. Elle peut être exécutée par tout poste de travail Tivoli Workload Scheduler, à l exception d un autre agent étendu. Gestionnaire de domaine principal Le gestionnaire du domaine supérieur d un réseau Tivoli Workload Scheduler. Il contient les fichiers maîtres centralisés servant à documenter les objets de planification. Il crée le fichier de contrôle de production au début de chaque journée et exécute l ensemble des opérations de journalisation et de génération d états pour le réseau. Voir aussi Gestionnaire de domaine. Domaine principal Le domaine supérieur d un réseau Maestro. Domaine parent Le domaine situé directement au-dessus du domaine en cours. Tous les domaines, à l exception du domaine principal, ont un domaine parent. Toutes les communications à destination ou en provenance d un domaine sont acheminées via le gestionnaire de domaine parent. Agent standard (sa) CPU agent qui ne lance des travaux que sous la direction de son gestionnaire de domaine. Tivoli Workload Scheduler pour MPE Les réseaux Tivoli Workload Scheduler peuvent contenir une combinaison de postes MPE (système d exploitation propriétaire de Hewlett-Packard), Windows NT, UNIX et d autres ordinateurs et agents. Pour plus d informations, reportez-vous au manuel Maestro for MPE User s Guide. Communications réseau Dans un réseau Tivoli Workload Scheduler, les agents communiquent avec leur gestionnaire de domaine et les gestionnaires de domaine communiquent avec leur gestionnaire de domaine parent. Principalement deux types de communications peuvent avoir lieu : 1) l initialisation de début de journée et 2) les événements de planification sous la forme de messages de changement d état au cours du jour de traitement. Chaque jour, en début de journée, le gestionnaire de domaine principal crée un fichier de contrôle de production intitulé Symphony. Tivoli Workload Scheduler est alors redémarré dans le réseau et le gestionnaire de domaine principal envoie une copie du nouveau fichier Symphony à chacun des agents et des gestionnaires de domaine subordonnés auxquels il est automatiquement relié. A leur tour, les gestionnaires de domaine envoient des copies du fichier aux agents et aux gestionnaires de domaine subordonnés auxquels ils sont automatiquement reliés. Les agents et les gestionnaires de domaine qui ne sont pas configurés pour être reliés automatiquement sont initialisés avec une copie de Symphony dès qu une opération de liaison est exécutée dans Tivoli Workload Scheduler. Une fois que le réseau est démarré, des messages de planification tels que les débuts et fin de travaux sont transmis depuis les agents vers leur gestionnaire de domaine, en passant par les gestionnaires de domaine parents et jusqu au gestionnaire de domaine principal. Le 100 Version 8.1

121 Communications réseau gestionnaire de domaine principal diffuse alors les messages à travers l ensemble de l arborescence des domaines afin de mettre à jour les fichiers Symphony de tous les gestionnaires de domaine et de tous les agents tolérant les pannes qui s exécutent en mode Statut intégral. Liaisons réseau Les liaisons assurent les communications bidirectionnelles entre les postes de travail Tivoli Workload Scheduler d un réseau. Elles sont contrôlées par l indicateur Liaison automatique et par les commandes Link et Unlink du Gestionnaire de console. Lorsqu une liaison est ouverte, des messages sont transmis entre les postes de travail. Lorsqu une liaison est fermée, le poste de travail expéditeur stocke les messages dans un fichier pobox local et les envoie au poste de travail de destination dès que la liaison est de nouveau ouverte. Remarque : Les agents étendus ne possèdent pas de liaisons. Ils communiquent avec leurs gestionnaires de domaine via leurs hôtes. Pour qu une liaison de poste de travail s ouvre automatiquement, activez l indicateur Liaison automatique dans la définition du poste de travail. La liaison est d abord ouverte lorsque Tivoli Workload Scheduler est démarré sur le poste de travail du domaine principal. Si le gestionnaire de sous-domaines et les postes de travail ne sont pas initialisés et si leur indicateur Liaison automatique est activé, le gestionnaire de domaine principal tente d établir une liaison avec ses subordonnés et commence les processus d initialisation. Si l indicateur Liaison automatique est désactivé, le poste de travail est uniquement initialisé par l exécution d une commande Link à partir du gestionnaire de domaine principal. Une fois le poste de travail initialisé, il démarre automatiquement et émet une liaison en retour vers son gestionnaire de domaine. Si vous arrêtez un poste de travail, les chemins allant de ce dernier vers les autres postes de travail sont fermés. Toutefois, les chemins allant des autres postes de travail vers ce poste restent ouverts jusqu à ce que l une des conditions suivantes soit remplie : le poste de travail arrêté est redémarré et une commande Link est émise ; les processus Mailman des autres postes de travail dépassent leur délai de temporisation. Pour s assurer que la communication entre les postes de travail est correctement rétablie, vous pouvez émettre une commande Link après avoir redémarré un poste de travail. Fonctionnement du réseau Le processus Batchman sur chaque gestionnaire de domaine et sur chaque poste de travail d agent tolérant les pannes fonctionne de façon autonome, en analysant ses fichiers Symphony pour résoudre les dépendances et lancer des travaux. Batchman lance des travaux par l intermédiaire du processus Jobman. Sur un agent standard, le processus Jobman répond aux demandes de lancement émises par le processus Batchman du gestionnaire de domaine. Le gestionnaire de domaine principal est informé en permanence du lancement et de l aboutissement de travaux et il est chargé de diffuser les informations aux gestionnaires de domaine et aux agents tolérant les pannes pour leur permettre de résoudre les dépendances entre postes de travail. Le degré de synchronisation entre les fichiers Symphony dépend de la façon dont les modes Statut intégral et Résolution des dépendances sont paramétrés dans la définition d un poste de travail. En supposant que ces modes sont activés, le fichier Symphony d un agent tolérant les pannes contient les mêmes informations que celui du gestionnaire de domaine principal (reportez-vous à la section qui explique comment gérer les postes de travail dans la base de B. Réseaux Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 101

122 Fonctionnement du réseau données dans le manuel Tivoli Job Scheduling Console Guide de l utilisateur. Processus du réseau Netman est démarré par le script StartUp. L ordre de création des processus est Netman, Mailman, Batchman et Jobman. Batchman ne s exécute pas sur les postes de travail d agent standard. Tous les processus, à l exception de Jobman, s exécutent avec des droits d utilisateur TWS. Jobman s exécute avec des droits root. Tandis que l activité réseau commence, Netman reçoit des requêtes en provenance de processus Mailman distants. Lors de la réception d une requête, Netman génère un processus Writer et lui transmet la connexion. Writer reçoit le message et le transmet au processus Mailman local. Les processus Writer (il peut y en avoir plusieurs sur un gestionnaire de domaine) sont démarrés par des demandes de connexion et sont arrêtés par des demandes de déconnexion (ou lorsque le processus Mailman en cours de communication se termine). Les gestionnaires de domaine, y compris le gestionnaire de domaine principal, peuvent communiquer avec un grand nombre d agents et de gestionnaires de domaine subordonnés. Pour une efficacité accrue, vous pouvez définir des serveurs Mailman sur un gestionnaire de domaine afin de répartir la charge des communications (reportez-vous à la section qui explique comment gérer les postes de travail dans la base de données dans le manuel Tivoli Job Scheduling Console Guide de l utilisateur). 102 Version 8.1

123 Fonctionnement du réseau Agents étendus Un agent étendu (xa ou x-agent) fait office d interface vers un système ou une application externe non Tivoli Workload Scheduler. Il est défini en tant que poste de travail Tivoli Workload Scheduler doté d une méthode d accès et d un hôte. La méthode d accès communique avec le système ou l application externe pour lancer et surveiller des travaux et tester les dépendances de fichier Opens. L hôte est un autre poste de travail Tivoli Workload Scheduler (mais pas un autre agent étendu) qui résout le dépendances et émet des demandes de lancement de travaux par l intermédiaire de la méthode. Les travaux sont définis pour un x-agent de la même manière que pour les autres postes de travail Tivoli Workload Scheduler, à ceci près que les attributs de travail sont dictés par le système ou l application externe. Le logiciel d agent étendu est disponible pour plusieurs systèmes et applications. Les agents étendus UNIX, inclus avec Tivoli Workload Scheduler, sont décrits dans la section suivante. Veuillez contacter votre ingénieur commercial Tivoli Systems pour obtenir plus d informations sur les autres agents étendus. Pour plus d informations sur la définition de postes de travail Tivoli Workload Scheduler, reportez-vous à la section qui explique comment gérer les postes de travail dans la base de données dans le manuel Tivoli Job Scheduling Console - Guide de l utilisateur). Pour plus d informations sur l écriture de méthodes d accès, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence. B. Réseaux Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 103

124 Agents étendus Agents étendus UNIX Tivoli Workload Scheduler inclut des méthodes d accès pour deux types d agents étendus UNIX. La méthode Local UNIX permet à un seul ordinateur UNIX de fonctionner comme deux postes de travail Tivoli Workload Scheduler pouvant tous deux exécuter des travaux planifiés par Tivoli Workload Scheduler. La méthode d accès Remote UNIX vous permet de désigner un ordinateur UNIX distant pour qu il exécute des travaux planifiés par Tivoli Workload Scheduler sans que Tivoli Workload Scheduler soit installé sur ce poste. Des informations sur l exécution d un travail sont envoyées à Tivoli Workload Scheduler depuis un agent étendu via le fichier stdlist du travail. Un fichier d options de méthode peut indiquer des sessions de remplacement pour lancer des travaux et vérifier les dépendances de fichier Opens. Pour plus d informations, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence. Méthode d accès Local UNIX La méthode Local UNIX peut être utilisée pour définir plusieurs postes de travail Tivoli Workload Scheduler sur un seul ordinateur : le poste de travail hôte et un ou plusieurs agents étendus. Lorsque Tivoli Workload Scheduler envoie un travail à un xa UNIX local, la méthode d accès unixlocl est appelée par l hôte pour exécuter le travail. La méthode commence par exécuter le script de configuration standard sur le poste de travail hôte (TWShome/jobmanrc). Si l utilisateur du travail est autorisé à utiliser le script de configuration local et si le script existe en tant que $HOME/.jobmanrc, le script de configuration local est également exécuté. Le travail lui-même est alors exécuté par le script de configuration standard ou local. Si aucun des deux scripts de configuration n existe, la méthode lance le travail. Le lancement des scripts de configuration, jobmanrc et.jobmanrc est configurable dans le script de la méthode. La méthode exécute les scripts de configuration par défaut, s ils existent. Pour désactiver cette fonction, vous devez transformer en commentaires un ensemble de lignes du script de la méthode. Pour plus d informations, examinez le fichier de script TWShome/methods/unixlocl sur l hôte de l agent étendu. Méthode d accès Remote UNIX La méthode d accès Remote UNIX peut être utilisée pour désigner un ordinateur non Tivoli Workload Scheduler pour qu il exécute des travaux planifiés par Tivoli Workload Scheduler. Lorsque Tivoli Workload Scheduler envoie un travail à un agent étendu UNIX distant, la méthode d accès unixrsh crée un répertoire /tmp/maestro sur l ordinateur non Tivoli Workload Scheduler. Elle transfère alors un script encapsuleur au répertoire et l exécute. L encapsuleur exécute ensuite le travail planifié. L encapsuleur est créé une fois seulement, à moins qu il ne soit supprimé, déplacé ou périmé. Pour exécuter des travaux par l intermédiaire de l agent étendu, les utilisateurs du travail doivent posséder des droits d accès appropriés sur l ordinateur UNIX non Tivoli Workload Scheduler. Pour que ces droits leurs soient accordés, il faut qu un fichier.rhost, /etc/host.equiv, ou un fichier soit configuré sur l ordinateur. Si les dépendances de fichier Opens doivent être vérifiées, les droits d accès root doivent également être accordés. Contactez votre administrateur système si vous avez besoin d assistance. Pour plus d informations sur la méthode d accès, examinez le fichier de script Maestrohome/methods/unixrsh sur l hôte d un agent étendu. 104 Version 8.1

125 Agents étendus Gestion de la production pour les agents étendus En règle générale, les travaux s exécutant sur des agents étendus se comportent comme les autres travaux Tivoli Workload Scheduler. Tivoli Workload Scheduler assure le suivi de l état d un travail et enregistre les résultats dans les fichiers stdlist du travail. Ces fichiers sont stockés sur le poste de travail HOTE de l agent étendu. Pour plus d informations sur la gestion des travaux, reportez-vous à la section qui décrit les tâches du plan Tivoli Workload Scheduler dans le manuel Tivoli Job Scheduling Console - Guide de l utilisateur. Echec du lancement de travaux sur un agent étendu Si la méthode d accès ne se trouve pas dans le répertoire approprié sur l hôte de l agent étendu ou si Tivoli Workload Scheduler ne parvient pas à accéder à la méthode, le lancement des travaux échouera ou la vérification d une dépendance de fichier ne sera pas effectuée. Pour un travail, l utilisateur d un travail Tivoli Workload Scheduler ou l utilisateur indiqué dans le fichier des options de méthode doit posséder des droits d accès en lecture et en exécution pour la méthode d accès. Lorsqu un fichier est vérifié en vue de satisfaire une dépendance Opens, l utilisateur root est utilisé en tant qu ID de connexion à moins qu un autre ID de connexion ne soit indiqué dans le fichier des options de méthode. Pour plus d informations sur les options de méthode, reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence Fichier de configuration Netman Le fichier de configuration Netman existe sur tous les postes de travail Tivoli Workload Scheduler. Si Netman est installé dans le répertoire principal de Tivoli Workload Scheduler (répertoire par défaut), le nom du fichier est Maestrohome/Netconf. Si Netman est installé dans un répertoire séparé, le nom du fichier est netmanhome/netconf. Il définit les services fournis par Netman. Le fichier NetConf fourni par Tivoli inclut des commentaires décrivant chaque service. Ces services sont les suivants : 2001 Lance un processus Writer pour traiter les messages entrants provenant d un Mailman distant Lance le processus Mailman. A son tour, Mailman, lance le reste de l arborescence de processus (Batchman, Jobman) Arrête le processus Tivoli Workload Scheduler pour traiter les messages entrants provenant d un Mailman distant Cherche et renvoie un fichier stdlist au processus Conman à l origine de la demande Change le gestionnaire de domaine dans un domaine 2501 Vérifie l état d un travail distant Démarre le Gestionnaire de console un service demandé par le côté client de la console éloignée. Le service Mailman (2002) peut inclure un paramètre qui détermine la taille de la table Symphony interne. La table doit contenir suffisamment d espace pour tous les enregistrements du fichier Symphony, et de l espace supplémentaire pour les travaux soumis après que Tivoli Workload Scheduler a démarré son exécution de production. La syntaxe pour l entrée NetConf est la suivante : 2002 son bin/mailman [-parm valeur] B. Réseaux Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 105

126 Fichier de configuration Netman Dans l option -parm, valeur peut être l un des éléments suivants : -number La table Symphony est construite avec de l espace prévu exactement pour ce nombre d enregistrements. Par exemple, -parm 6000 crée une table contenant de l espace pour exactement 6000 enregistrements. Le nombre maximum autorisé est enregistrements. La définition de la valeur -1 pour ce paramètre assure que la taille maximale est utilisée. number La table Symphony est construite avec de l espace prévu pour tous les enregistrements du fichier Symphony, auquel s ajoute l espace destiné à ce nombre d enregistrements supplémentaires. Si vous recevez un message indiquant que le nombre de travaux planifiés est trop important pour Batchman, il peut s avérer nécessaire d augmenter la taille de la table Symphony. Avant de procéder à cette modification, contactez votre ingénieur de support client Tivoli pour qu il vous aide à déterminer la taille appropriée. Validation de l adresse IP du réseau Lorsqu une connexion TCP/IP est établie, Netman lit le nom de noeud et l adresse IP du demandeur à partir du socket. L adresse IP et le nom de noeud permettent de rechercher un poste de travail Tivoli Workload Scheduler connu dans le fichier Symphony, cette recherche pouvant aboutir à l un des résultats suivants : Si une concordance d adresse IP est trouvée, la validation est considérée comme ayant réussi. Si une concordance de nom de noeud est trouvée, la validation est considérée comme ayant réussi. Si aucune concordance n est trouvée dans Symphony ou si l adresse IP renvoyée par gethostbyname() ne correspond pas à celle qui a été lue à partir du socket, la validation est considérée comme ayant échoué. L option locale, nm ipvalidate, détermine l action à effectuer si la validation IP a échoué. Si l option a pour valeur full, en cas d échec de validation, Tivoli Workload Scheduler ferme la connexion et génère un message d erreur. Si l option a pour valeur none, Tivoli Workload Scheduler autorise toutes les connexions, mais génère un message d avertissement pour les échecs de validation. Configuration système (UNIX uniquement) La validation IP dépend de l appel système gethostbyname() pour rechercher toutes les adresses valides pour un hôte. le comportement de cette routine varie en fonction de la configuration du système. Lorsque gethostbyname() utilise le fichier /etc/hosts, il renvoie la première entrée concordante. Si la connexion est lancée sur une adresse qui figure après la première entrée concordante, la validation IP échoue. Pour résoudre le problème, placez l entrée utilisée pour lancer la connexion avant toutes les autres entrées concordantes dans le fichier /etc/hosts.si gethostbyname() utilise le serveur de noms nommé ou le serveur du Service d information réseau et que gethostbyname() échoue, contactez votre administrateur système pour obtenir de l aide. 106 Version 8.1

127 Validation de l adresse IP du réseau Messages d erreur/d avertissement Voici une liste des messages relatifs à la validation IP. Si l option locale nm ipvalidate a pour valeur none, les erreurs s affichent en tant qu avertissements. Le nom du poste de travail Tivoli Workload Scheduler est introuvable dans le fichier Symphony Ip address validation failed for request: Service num for program on cpu(os_type). Connection received from IP address: c_ipaddr. MAESTRO CPU cpu not found in Symphony file. Echec de l appel de gethostbyname() : IP address validation failed for request: Service num for program on cpu(os_type). Connection received from IP address: c_ipaddr. gethostbyname() failed, unable to retrieve IP address of connecting node: node. Les adresses IP renvoyées par gethostbyname()ne correspondent pas à l adresse IP du poste de travail de connexion : IP address validation failed for request: Service num for program on cpu(os_type). Connection received from IP address: c_ipaddr. System known IP addresses for node name node: k_ipaddr. L adresse IP indiquée dans la définition de poste de travail pour le poste de travail Tivoli Workload Scheduler indiqué dans le paquet de demande de service ne correspond pas à l adresse IP du poste de travail de connexion : IP address validation failed for request: Service num for program on cpu(os_type). Connection received from IP address: c_ipaddr. TWS known IP addresses for cpu k_ipaddr. Quel que soit l état de l option nm ipvalidate, le message d information suivant s affiche lorsque la validation IP ne peut pas être effectuée du fait que le fichier Symphony n existe pas ou qu une erreur se produit lors de sa lecture : IP address validation not performed for request: Service num for program on cpu(os_type). Connection received from IP address: c_ipaddr. Cannot open or read Symphony file. Service request accepted. Où : num numéro du service (2001-writer, 2002-mailman...) program programme demandant le service cpu nom Tivoli Workload Scheduler du poste de travail de connexion os_type système d exploitation du poste de travail de connexion node nom de noeud ou adresse IP du poste de travail de connexion c_ipaddr adresse IP du poste de travail de connexion B. Réseaux Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 107

128 Validation de l adresse IP du réseau k_ipaddr adresse IP connue du poste de travail de connexion La validation IP est toujours réussie en l absence de fichier Symphony. Dans un gestionnaire de domaine, la liaison à un agent aboutit normalement étant donné que le fichier Symphony n existe pas encore. Toutefois, si l agent possède un fichier Symphony utilisé lors d une exécution antérieure, la demande de liaison initiale peut échouer si le fichier Symphony n inclut pas le nom du gestionnaire de domaine. Reprise du réseau Plusieurs types de problèmes peuvent rendre nécessaire l exécution des procédures de reprise du réseau, notamment : Problèmes d initialisation empêchant les agents et les gestionnaires de domaine de démarrer correctement au début d une nouvelle journée Les problèmes de liaison réseau empêchant les agents de communiquer avec leurs gestionnaires de domaine La perte d un gestionnaire de domaine, qui nécessite son remplacement par une unité de sauvegarde. Remarque : Dans tous les cas, un problème survenant au niveau d un gestionnaire de domaine affecte l ensemble de ses agents et de ses gestionnaires de domaine subordonnés. Problèmes d initialisation Des problèmes d initialisation peuvent se produire lorsque Tivoli Workload Scheduler est démarré pour une nouvelle journée. Ils peuvent être dus à l exécution de processus Tivoli Workload Scheduler sur un agent ou un gestionnaire de domaine du jour précédent ou d une exécution Tivoli Workload Scheduler précédente. Dans cette situation, pour initialiser l agent ou le gestionnaire de domaine, procédez comme suit : 1. Pour un gestionnaire de domaine, connectez-vous au gestionnaire de domaine parent ou au gestionnaire de domaine principal. Pour un agent, connectez-vous au gestionnaire de domaine de l agent, au gestionnaire de domaine parent ou au gestionnaire de domaine principal. 2. Exécutez le Gestionnaire de console, puis exécutez une commande Stop pour l agent concerné. 3. Exécutez une commande Link pour l agent concerné. Cette action initialise et démarre l agent. Si ces actions échouent, vérifiez si Netman est en cours d exécution sur l agent concerné. Si ce n est pas le cas, émettez la commande startup localement, puis émettez une commande LINK à partir de son gestionnaire de domaine. En cas de problèmes graves au niveau du réseau, un agent tolérant les pannes ou un gestionnaire de domaine subordonné peut être exécuté en tant que système autonome. Pour ce faire, arrêtez l agent ou le gestionnaire de domaine et copiez le fichier TWShome\Sinfonia à partir du gestionnaire de domaine principal. Renommez le fichier copié TWShome\Symphony et démarrez l agent ou le gestionnaire de domaine. Toutes les dépendances entre postes de travail doivent être résolues localement à l aide des commandes appropriées du Gestionnaire de console : Delete Dependency et Release, par exemple. 108 Version 8.1

129 Reprise du réseau Remarque : Pour que cela soit possible, il faut que le gestionnaire de domaine principal et l agent ou le gestionnaire de domaine subordonné possèdent la même architecture de processeur. Problèmes de liaison réseau Tivoli Workload Scheduler présente un degré élevé de tolérance aux pannes en cas de problème de communication. Chaque agent tolérant les pannes possède sa propre copie du fichier Symphony, lequel contient le traitement du jour. En cas de défaillance de la liaison, ils poursuivent le traitement en utilisant leur propre copie de Symphony. Toutes les dépendances entre postes de travail doivent toutefois être résolues localement à l aide des commandes appropriées du Gestionnaire de console : Delete Dependency et Release, par exemple. Pendant qu une liaison est interrompue, tous les messages destinés à des postes de travail non communicants sont stockés par les postes de travail expéditeurs dans le répertoire TWShome\pobox, dans des fichiers nommés workstationname.msg.lorsque les liaisons sont rétablies, les postes de travail commencent à envoyer leurs messages stockés. Si les liaisons vers un gestionnaire de domaine vont être interrompues pendant une longue période, il peut être nécessaire de basculer vers un poste en veille. Remarques Les commandes du Gestionnaire de console Submit Job et Submit Schedule ne peuvent pas être utilisées sur un agent qui ne peut pas communiquer avec son gestionnaire de domaine. Si la liaison vers un poste de travail d agent standard est perdue, aucune option de reprise temporaire n est disponible car les agents standard sont hébergés par leur gestionnaire de domaine. Dans les réseaux possédant un grand nombre d agents standard, vous pouvez choisir de basculer vers un poste en veille. Configuration d un gestionnaire de domaine en veille Pour faciliter la procédure de reprise, il est essentiel que vous vous prépariez à l éventualité d incidents de réseau. En particulier, vous devez effectuer les actions suivantes : Désignez un agent tolérant les pannes du domaine pour être gestionnaire de domaine en veille. Assurez-vous que les modes Statut intégral et Résolution des dépendances sont sélectionnés dans la définition de poste de travail du poste en veille. Assurez-vous que les modes Statut intégral et Résolution des dépendances sont activés sur tous les gestionnaires de domaine (y compris le gestionnaire de domaine principal). Ces actions sont importantes si vous devez recourir à une reprise à long terme au cours de laquelle le maître de secours génère un fichier Symphony (exécute Jnextday). Si ces enregistrements ne sont pas activés, le gestionnaire de domaine principal précédent sera identifié comme un agent FTA ordinaire après la première occurrence de Jnextday. Au cours des opérations normales, le travail Jnextday active automatiquement les indicateurs Statut intégral et Résolution des dépendances pour le gestionnaire de domaine principal, à moins qu ils ne soient déjà activés. Lorsque le nouveau maître exécute Jnextday, il n identifie le gestionnaire de domaine principal précédent comme étant un maître de secours que si ces indicateurs sont activés. Le maître précédent ne possède pas de fichier Symphony exact lorsque le moment est venu de changer de nouveau de maître pour revenir au maître d origine. Traitez toutes les définitions de poste de travail des B. Réseaux Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 109

130 Reprise du réseau gestionnaires de domaine comme s il s agissait de définitions de gestionnaire de domaine de sauvegarde pour les nouveaux gestionnaires de domaine. Cette approche assure une véritable tolérance aux pannes. Pour un gestionnaire de domaine principal en veille Il peut s avérer nécessaire de transférer des fichiers entre le gestionnaire de domaine maître et son poste en veille. Pour cette raison, les ordinateurs doivent utiliser des systèmes d exploitation compatibles. N associez pas des postes UNIX à des postes Windows NT, et sous UNIX, n associez pas des postes Big-Endian à des postes Little-Endian. Chaque jour, à la suite du traitement de début de journée sur le gestionnaire de domaine principal, effectuez des copies des répertoires Maestrohome\mozart et TWShome\..\unison\network et du fichier TWShome\Sinfonia. Si nécessaire, ces copies peuvent être déplacées sur le gestionnaire de domaine principal en veille. Remarque : Pour un gestionnaire de domaine principal UNIX, si les répertoires Maestrohome/mozart et../unison/network situés sur le gestionnaire de domaine principal en cours sont raisonnablement statiques, ils peuvent être copiés préalablement vers le poste en veille. Dans des conditions de fonctionnement normales, ils sont masqués lorsque vous montez les répertoires du gestionnaire de domaine principal en cours sur le poste en veille. S il devient nécessaire de passer au poste en veille, le simple démontage des répertoires du gestionnaire de domaine principal en cours rendra les copies du poste en veille accessibles. Remarque sur la sécurité du réseau La sécurité du réseau est renforcée grâce à la validation de l adresse IP. En conséquence, une liaison à un poste de travail (option Liaison automatique ou commande Link) peut échouer si un agent possède un fichier Symphony ancien qui ne contient pas le nouveau gestionnaire de domaine. Si une connexion échoue, supprimez l ancien fichier Symphony sur l agent et réessayez d établir la connexion. Perte d un gestionnaire de domaine La perte d un gestionnaire de domaine peut se produire à la suite de problèmes de liaison réseau ou de la défaillance de l ordinateur du gestionnaire de domaine. Le fonctionnement du réseau sans gestionnaire de domaine produit les effets suivants : Les agents et les gestionnaires de domaine subordonnés ne peuvent pas résoudre les dépendances entre postes de travail étant donné que les enregistrements d activité diffusés par le gestionnaire de domaine principal ne sont pas reçus. Les agents standard hébergés par le gestionnaire de domaine défaillant ne peuvent exécuter aucun traitement étant donné qu ils dépendent du gestionnaire de domaine pour toutes les opérations de planification et de lancement de travaux. Si le problème ne doit pas durer longtemps, vous pouvez le traiter comme décrit à la section «Problèmes de liaison réseau» à la page 109. Si vous n êtes pas sûr de sa durée, ou si vous souhaitez restaurer le fonctionnement normal des agents, vous devez basculer vers un poste en veille, comme décrit dans les sections suivantes. 110 Version 8.1

131 Reprise du réseau Remplacement d un gestionnaire de domaine Utilisez cette procédure lorsque vous faites face à la perte à court terme du gestionnaire de domaine principal. 1. Exécutez JS Console. 2. Sélectionnez le connecteur maître. 3. Sélectionnez la liste du plan par défaut. 4. Cliquez sur Statut de tous les domaines. 5. Cliquez sur Rafraîchir. 6. Sélectionnez Changer de gestionnaire. 7. Indiquez le nom du gestionnaire de domaine de sauvegarde que vous souhaitez utiliser. 8. Cliquez sur OK. Les gestionnaires de domaine restent permutés jusqu à ce que vous effectuiez une nouvelle opération de changement de gestionnaire. Pour revenir au gestionnaire de domaine d origine, répétez cette procédure. Dans le cas d un gestionnaire de domaine principal permuté, vous devez effectuer cette opération avant la rotation du jour suivant, à moins que vous ne vous attendiez pas à ce que le gestionnaire de domaine principal soit disponible pour la rotation du jour suivant (agenda final et travail Jnextday). Dans ce cas, utilisez la procédure décrite à la section suivante. Perte prolongée du gestionnaire de domaine principal Utilisez la procédure suivante pour basculer vers le poste en veille si le maître d origine ne doit pas être remis en service avant la rotation du jour suivant (agenda final et travail Jnextday). Pour UNIX, utilisez des barres obliques normales dans les chemins d accès. 1. Utilisez la fonction Stop du Gestionnaire de console pour arrêter Tivoli Workload Scheduler sur le gestionnaire de domaine principal et sur son poste en veille. 2. Sous UNIX, démontez les répertoires du maître s ils sont montés sur l un des agents ou des gestionnaires du domaine. 3. Créez une méthode pour que le poste en veille accède au système de fichiers Tivoli Workload Scheduler pour UNIX. Vous pouvez utiliser l une des deux approches suivantes : Copiez les répertoires maestrohome/mozart et maestrohome/../unison/network sur le poste en veille. Notez que vous devez faire cela avant qu une panne totale du système ne survienne sur le maître d origine. Configurez un système de fichiers à monter. Vous pouvez décider que ce système de fichiers soit externe au maître et au poste en veille, au cas où le maître d origine subirait une panne système totale. Sur le système qui contient les répertoires maestro maestrohome/mozart et maestrohome/../unison/network, assurez-vous que les répertoires peuvent être montés via une entrée dans le fichier etc/exports. Montez le système de fichiers sur le poste en veille. 4. Sur le poste en veille, éditez le fichier maestrohome\mozart\globalopts et remplacez le maître des options globales par le nom de poste de travail du poste en veille. B. Réseaux Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 111

132 Reprise du réseau 5. Sur le poste en veille, utilisez Composer pour modifier tous les flux de travaux importants qui s exécutent sur le gestionnaire de domaine principal, tel que l agenda final. Pour chacun d eux, remplacez le nom du poste de travail par le nom du poste en veille. 6. Si nécessaire, sur les agents et les gestionnaires de domaine, montez les répertoires à partir du gestionnaire de domaine en veille. 7. Utilisez la fonction Changer de gestionnaire du Gestionnaire de console pour basculer vers le maître de secours. Reportez-vous à la section «Remplacement d un gestionnaire de domaine» à la page Version 8.1

133 C Gestion de réseau avec MPE Cette annexe décrit la configuration requise et le fonctionnement des réseaux Tivoli Workload Scheduler/Maestro contenant une combinaison d ordinateurs MPE, UNIX et Windows NT. Ces réseaux sont conformes à la hiérarchie standard Tivoli Workload Scheduler des CPU maîtres, des CPU d agent tolérant les pannes (esclaves) et des CPU d agent standard, qui se caractérisent comme suit : Le poste de travail maître peut être un ordinateur MPE, UNIX ou Windows NT. Il constitue le concentrateur administratif d un réseau. Il contient les fichiers de planification maîtres Maestro et exécute tous les traitements de post-production (fin de journée) et de pré-production (début de journée) pour le réseau. Lorsqu un nouveau jour de production commence, le maître traite ses propres agendas ainsi que ceux des CPU d agents standard. Il lance ses propres travaux et émet des demandes de lancement pour exécuter des travaux sur les agents standard. Lorsqu un maître UNIX ou NT est utilisé, il est également connu sous le nom de gestionnaire de domaine principal. Un poste MPE ne peut pas être le maître d un poste Windows NT étant donné qu il n existe pas de base de données USERDATA équivalente sur le produit MPE pour stocker les définitions de mot de passe utilisateur NT. Les CPU esclaves MPE sont l équivalent d agents tolérant les pannes UNIX et Windows NT. Pour les fonctions administratives, elles dépendent du poste de travail maître. Lorsqu un nouveau jour de production commence, elles traitent leurs propres agendas et lancent leurs propres travaux. Les CPU d agent standard sont des ordinateurs UNIX ou Windows NT. Pour les fonctions administratives, elles dépendent du poste de travail maître. Lorsqu un nouveau jour de production commence, elles exécutent des travaux uniquement en réponse aux demandes de lancement émises par le gestionnaire de domaine (le gestionnaire de domaine principal par défaut). Remarques relatives au réseau Vous devez examiner l intégralité de cette annexe avant de décider de la façon de configurer un réseau mixte Tivoli Workload Scheduler/Maestro. Voici un résumé des remarques de base à prendre en considération : Les définitions d objet et la planification pour les esclaves et les agents tolérant les pannes doivent être effectuées sur le gestionnaire de domaine principal si les esclaves et les agents tolérant les pannes n utilisent pas la même plateforme que le maître. Le cas échéant, le gestionnaire de domaine principal en veille doit utiliser la même plateforme que le gestionnaire de domaine principal. C. Gestion de réseau avec MPE Tivoli Workload Scheduler - Guide de planification et d installation 113

134 Remarques relatives au réseau Les remarques relatives à la sécurité sont différentes pour chaque plateforme : MPE, UNIX et Windows NT. Les gestionnaires de domaine principaux UNIX et NT supportent l agencement hiérarchique dans lequel vous pouvez avoir plusieurs gestionnaires de sous-domaines utilisant des agents de chacun des types de plateforme pris en charge. Les maîtres MPE ne supportent qu une architecture à plat. Les systèmes MPE peuvent être utilisés en tant qu agents FTA (esclaves) dans n importe quel agencement de domaine hiérarchique. Une CPU maître MPE peut se connecter à des esclaves MPE en utilisant soit NS, soit TCP/IP. Une CPU maître UNIX ou Windows NT utilise uniquement TCP/IP. Remarques relatives à la planification Vous devez prendre les faits suivants en considération : Toute combinaison de postes dans un réseau Tivoli Workload Scheduler/maestro comprenant un poste de travail MPE nécessite que les équivalents UNIX/NT fonctionnent en mode non étendu (ne pouvant pas utiliser de noms d objet de planification contenant plus de huit caractères). Etant donné que la sécurité d un agent FTA UNIX ou Windows NT est indépendante du maître MPE, ce type d agent peut également être configuré en mode Statut intégral et être utilisé pour la gestion centrale de la console du réseau. Les utilisateurs peuvent ainsi bénéficier des interfaces graphiques et d ensembles de commandes plus puissants et plus souples. Toutefois, l agent tolérant les pannes est toujours soumis à un certain nombre de limitations sur certaines commandes Conman. Ces limitations sont les suivantes : v v v v v Impossible de soumettre des travaux à l aide de la commande CONMAN SUBMIT JOB. Impossible de soumettre des agendas à l aide de la commande CONMAN SUBMIT SCHEDULE. Impossible de réexécuter des travaux à l aide des options CONMAN RERUN ;FROM et ;FILE. Impossible d ajouter des dépendances d invite prédéfinies (ou globales) à l aide de la commande ADDDEP. Impossible d utiliser la commande CONMAN ADDDEP pour ajouter des dépendances d invite globales (prédéfinies). v Impossible d utiliser la commande CONMAN DISPLAY pour les travaux et les agendas. La fonction docommand est pleinement opérationnelle sous UNIX et Windows NT pour les définitions de travaux et pour la commande conman submit. Cette fonction n est pas prise en charge sous MPE. Composer sous UNIX et Windows NT peut ajouter et modifier tous les objets de planification (y compris les agendas et les travaux) à partir d un seul fichier d édition. Les dépendances INET ne sont pas possibles pour le maître MPE. Elles peuvent toutefois référencer des agents tolérant les pannes MPE si le gestionnaire de domaine s exécute sous UNIX ou Windows NT. 114 Version 8.1

135 Remarques relatives au réseau Installation Des instructions d installation de Tivoli Workload Scheduler pour UNIX et Windows NT sont fournies dans le présent guide. Pour installer Maestro pour MPE pour la première fois, reportez-vous à la section 2 du manuel Maestro User Guide for the MPE System User. Configuration Cette section décrit les étapes nécessaires à la configuration des réseaux Tivoli Workload Scheduler/Maestro après leur installation avec des agents UNIX sous MPE, et avec des agents MPE sur des postes de travail maîtres UNIX ou Windows NT. Remarque : Pour plus de détails sur les commandes et les transactions spécifiques, reportez-vous au présent guide et au manuel MaestroUser Guide for the MPE System User. Configuration d un agent UNIX avec un maître MPE Sur le maître MPE, utilisez le programme ARRANGER pour effectuer les opérations suivantes : 1. Utilisez la transaction ACPU pour créer une définition de CPU pour la CPU UNIX dans le réseau. 2. Utilisez la transaction CSYS pour définir cette CPU en tant que maître. 3. Utilisez la transaction ALNK pour définir les liaisons suivantes : a. Maître à maître : définissez une liaison avec des commandes TCP/IP. b. Maître à UNIX : définissez une liaison avec des commandes TCP/IP. 4. Une fois que les tâches d agent UNIX ci-dessous seront terminées, les agents seront initialisés et démarrés lors de la prochaine exécution de Jnextday sur le gestionnaire de domaine principal. Sur chaque agent tolérant les pannes et agent standard UNIX, effectuez les opérations suivantes : 1. Modifiez les fichiers d options globales et locales de façon à répondre à vos besoins. Des valeurs par défaut, adaptées à la plupart des installations, sont insérées par les programmes de personnalisation et d installation. 2. Modifiez et installez le fichier de sécurité. Si vous le souhaitez, vous pouvez faire cela sur un ordinateur, puis copier le fichier sur chacun des autres systèmes UNIX. 3. Emettez la commande StartUp sur chaque agent UNIX pour lancer le démon Netman (s il n est pas déjà lancé). Configuration d un agent FTA MPE avec UNIX ou Windows NT Un réseau Tivoli Workload Scheduler contenant des ordinateurs MPE doit être installé en mode non étendu. Après avoir installé le logiciel, exécutez la procédure suivante pour configurer chaque CPU du réseau. Sur le maître UNIX ou Windows NT, procédez comme suit : 1. Utilisez l interface graphique de JS Console ou l interface de ligne de commande du programme Composer pour créer des définitions de poste de travail pour tous les postes de travail. Les définitions comprennent également des informations relatives aux liaisons (une combinaison des transactions ACPU et ALNK du programme Arranger). C. Gestion de réseau avec MPE Tivoli Workload Scheduler - Guide de planification et d installation 115

136 Configuration 2. Modifiez les fichiers d options globales de façon à répondre à vos besoins. Les options globales suivantes remplacent les paramètres ARRANGER CTP1 pour les esclaves MPE. Elles ne sont pas présentes dans le fichier globalopts par défaut et devront être ajoutées si vous le souhaitez : rules mode={yes no} Remplace CTP1-Complete Control Mode. Si cette option a pour valeur yes, vous devez également définir la valeur yes pour batchman schedule. all userjobs in userjobs schedule={yes no} Remplace CTP1-Place all userjobs in USERJOBS schedule. Vous devez définir la valeur no pour cette option si rules mode a pour valeur yes. set mpe job pri to zero={yes no} Remplace CTP1-Force MPE priority to 0 for all userjobs. Vous devez définir la valeur no pour cette option si all userjobs in userjobs schedule a pour valeur yes. batchman schedule={yes no} Remplace CTP1-Assign priority 10 to Batchman-created schedules. Cette option affecte également les postes de travail UNIX et Windows NT. 3. Une fois que les tâches d agent MPE ci-dessous seront terminées, les agents seront initialisés et démarrés lors de la prochaine exécution de Jnextday sur le gestionnaire de domaine principal. Sur chaque esclave MPE, utilisez le programme ARRANGER pour effectuer les opérations suivantes : 1. Utilisez la transaction ACPU pour créer des définitions pour cette CPU et ce maître. 2. Utilisez la transaction CSYS pour identifier cette CPU et le maître. 3. Utilisez la transaction ALNK pour définir une liaison esclave à maître contenant des commandes TCP/IP. 4. Utilisez les transactions CTP2 et CTP3 pour définir les paramètres CONMAN et BATCHMAN. 5. Exécutez mstream ou stream sur le travail JBATCHMN.MAESTRO.CCC pour activer le processus NETMAN. Pour que son démarrage et son initialisation via TCP/IP réussissent, le processus NETMAN doit déjà être en cours d exécution sur l esclave MPE. Différences opérationnelles entre les plateformes Cette section décrit les exceptions qui s appliquent dans un réseau de postes de travail MPE, UNIX et Windows NT dans lequel un poste MPE, UNIX, ou Windows NT est défini en tant que maître. Pour plus d informations sur le fonctionnement du réseau, reportez-vous aux manuels Tivoli Workload Scheduler - Guide de référence, Tivoli Workload Scheduler - Guide d installation et de planification, etmaestro User Guide for the MPE System User (disponible auprès de ROCsoftware). 116 Version 8.1

137 Différences opérationnelles entre les plateformes Sur le maître MPE Arranger et Composer Conman Toutes les définitions d objet et les planifications pour les agents tolérant les pannes et les agents standard UNIX doivent être effectuées à l aide des programmes COMPOSER et ARRANGER sur le maître MPE. Le programme COMPOSER sous MPE ne prend pas en charge la fonction docommand dans les instructions de travail pour les agendas qui s exécutent sur des agents FTA ou des agents standard UNIX et Windows NT. Les options de reprise pour les travaux UNIX et Windows NT doivent être documentées avec la transaction ARRANGER XJOB. Dans le langage de planification MPE, scriptname n est pas un mot clé valide. Utilisez plutôt jobfilename pour définir les scripts des travaux UNIX et Windows NT. Par exemple : jobfilename " nomchemin" streamlogon utilisateur L option docommand n est pas disponible dans la commande submit pour soumettre des commandes à exécuter sur une CPU UNIX ou Windows NT. Les paramètres wildcard et selectionset pour certaines commandes conman ne sont pas pris en charge à partir d un maître MPE, mais ils peuvent être utilisés à partir d un agent FTA UNIX en mode Statut intégral. Sur les agents tolérant les pannes UNIX Composer Vous pouvez uniquement utiliser Composer pour documenter, modifier et supprimer des paramètres Maestro (parms), qui sont locaux sur chaque poste de travail. Conman Les opérations CONMAN suivantes ne sont pas autorisées : Soumettre des travaux à l aide de la commande CONMAN SUBMIT JOB. Soumettre des agendas à l aide de la commande CONMAN SUBMIT SCHEDULE. Ajouter des dépendances d invite prédéfinies (ou globales) à l aide de la commande ADDDEP. Utiliser les options ;FROM et ;FILE dans la commande RERUN. Afficher des travaux et des agendas à l aide de la commande DISPLAY. Sur le maître UNIX ou Windows NT Composer Toutes les définitions d objet et les planifications pour les esclaves MPE doivent être effectuées à l aide de l interface graphique de JS Console dans l interface de ligne de commande de Composer sur le maître UNIX ou Windows NT. Pour une documentation automatique sur les travaux, l instruction de travail du langage de planification UNIX et Windows NT accepte les mots clés spécifiques à MPE, ainsi que les noms de fichier et les noms d utilisateur MPE. Par exemple : jobfilename file.grp.acct [streamlogon user.acct[, grp]] C. Gestion de réseau avec MPE Tivoli Workload Scheduler - Guide de planification et d installation 117

138 Différences opérationnelles entre les plateformes Conman ou isuserjob [= jobname] streamlogon user.acct[, grp] Le mot clé opens du langage de planification UNIX et Windows NT accepte les noms de fichier MPE. Par exemple : opens [ cpu#]" nomchemin" file.grp.acct[( qualifiants)] [,...] La commande showjob affiche des informations spécifiques à MPE : [userjob] >> alias is >> run again as SKEL La commande submit docommand n est pas valide lorsqu elle est dirigée vers une CPU MPE, même si elle peut être exécutée sur le maître UNIX ou Windows NT. Sur les esclaves MPE Arranger Les seules transactions ARRANGER valides sont : CTP2, CTP3, xcpu, xlnk, xprm, xpas, xsys. Composer Vous ne pouvez pas exécuter COMPOSER correctement. Conman Les opérations CONMAN suivantes ne sont pas autorisées : Soumettre des travaux à l aide de la commande CONMAN SUBMIT JOB. Soumettre des agendas à l aide de la commande CONMAN SUBMIT SCHEDULE. Ajouter des dépendances d invite prédéfinies (ou globales) à l aide de la commande ADDDEP. Utiliser les options ;FROM et ;FILE dans la commande RERUN. Afficher des travaux et des agendas à l aide de la commande DISPLAY. 118 Version 8.1

139 D Migration vers Tivoli Workload Scheduler Les informations fournies dans cette annexe peuvent être utiles lorsque vous effectuez une migration à partir de Maestro version 6.x vers Tivoli Workload Scheduler. Tivoli Management Framework pour utilisateurs non Tivoli Tivoli Management Framework est une structure ouverte, orientée objet, qui comprend un ensemble de gestionnaires, de courtiers et d agents conformes à la spécification OMG/CORBA (Object Management Group/Common Object Request Broker Architecture). La technologie OMG/CORBA permet de rendre transparent pour l utilisateur les différences importantes qui existent entre les systèmes d exploitation informatiques et elle permet l encapsulation des services clés dans des objets pouvant être utilisés par plusieurs applications de gestion. Tivoli Management Framework offre une indépendance par rapport aux plateformes, une architecture unificatrice pour toutes les applications et un riche ensemble d interfaces API qui ont été adoptés par la DMTF (Desktop Management Task Force) et par l Open Group (anciennement X/Open) comme base pour une structure de gestion systèmes. Les API Tivoli offrent des services communs de gestion réseau et système, y compris la planification, le support des transactions, les profils de configuration et un service complémentaire générique de base de données d objets. L unité de base de la fonctionnalité de Management Framework est la région TMR (Tivoli management region). Une région est composée d unserveur Tivoli et de clients que le serveur gère. Le serveur Tivoli héberge la base de données pour cette région. En fonction de la taille et des exigences d un environnement, plusieurs régions peuvent être définies. Si plusieurs régions sont définies, elles peuvent être autonomes ou reliées entre elles de façon à partager des informations et des ressources. Les administrateurs ayant le rôle approprié peuvent gérer toutes les ressources échangées dans un ensemble de régions connectées à partir d un seul système, comme si les ressources se trouvaient toutes dans la région du système local. En règle générale, un serveur Tivoli peut supporter jusqu à 200 noeuds entièrement gérés. A partir de Tivoli Management Framework 3.6 ou d une version ultérieure, de nouveaux services sont placés sur le serveur Tivoli et sur certains noeuds gérés de façon à permettre à ces noeuds d agir comme des passerelles pour des centaines de noeuds finaux. La portée d une région se trouve ainsi considérablement étendue. Tivoli Management Framework comprend une implémentation de l ORB (Object Request Broker) et du BOA (Basic Object Adapter) CORBA. Il offre également des services d objet, de gestion et de bureau associés et comprend une implémentation des interfaces API adoptées par l Open Group pour une structure de gestion systèmes. Le répartiteur d objets (oserv) est le principal composant du temps d exécution de la structure. Il est implémenté comme un seul processus multi-thread et s exécute en arrière plan de chaque client Tivoli à l intérieur d une région et du serveur Tivoli pour cette région. Le répartiteur d objet comprend un répartiteur de requêtes d objets, le BOA et les services associés. Le répartiteur D. Migration vers Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 119

140 Tivoli Management Framework pour utilisateurs non Tivoli d objets s exécutant sur le serveur Tivoli offre des services supplémentaires, y compris la sécurité et la résolution d héritage d implémentation. Un noeud géré Tivoli exécute le même logiciel que celui qui s exécute sur un serveur Tivoli. A partir d un noeud géré, vous pouvez exécuter le bureau Tivoli et gérer directement d autres ressources gérées Tivoli. Un noeud géré possède son propre service oserv qui s exécute en continu et communique avec le service oserv sur le serveur Tivoli. Un noeud géré gère également sa propre base de données client. La principale différence entre un serveur Tivoli et un noeud géré est la taille de la base de données. Aussi, vous ne pouvez pas avoir un noeud géré sans serveur Tivoli dans une région TMR. Remarques sur l installation Le moteur Workload Scheduler est complètement séparé de Tivoli Management Framework. Il ne s agit pas d une application de Tivoli Management Framework. Toutefois, le connecteur Tivoli Workload Scheduler est une application de Tivoli Management Framework. Le connecteur est requis si vous souhaitez utiliser Job Scheduling Console, la nouvelle interface graphique. Tivoli Workload Scheduler 8.1 ne contient plus l interface graphique existante de Maestro. En outre, JS Console est requis si vous souhaitez utiliser à la fois les moteurs Tivoli Workload Scheduler pour z/os et Tivoli Workload Scheduler à partir de la même interface utilisateur. Où installer le client JS Console Job Scheduling Console offre les fonctionnalités de composer et conman par le biais d une véritable interface graphique. Il peut être installé sur plusieurs plateformes UNIX et Microsoft Windows. Il ne requiert pas l installation de Tivoli Management Framework, ni de Tivoli Workload Scheduler sur le client. La seule condition préalable est que le système client soit connecté via TCP/IP à au moins l un des noeuds qui exécutent le connecteur. Où installer les connecteurs Le connecteur est un service Tivoli Management Framework qui permet aux clients JS Console de communiquer avec le moteur Tivoli Workload Scheduler. Un connecteur peut être installé sur un système qui doit aussi être un serveur ou un noeud géré Tivoli. Si vous souhaitez installer le connecteur dans votre domaine Tivoli Workload Scheduler, mais que vous n avez aucune région existante et que vous n avez pas envie d implémenter un environnement TMR complet, vous devez installer Tivoli Management Framework en tant que région unique (et par conséquent l installer en tant que serveur Tivoli) sur chaque noeud qui va exécuter le connecteur. Vous pouvez installer des connecteurs sur des postes de travail autres que le gestionnaire de domaine principal. Vous pourrez ainsi afficher la version du fichier Symphony de ce poste de travail particulier. Cela peut être important si vous utilisez JS Console pour gérer la base de données de paramètres locale ou la commande submit directement sur le poste de travail au lieu d effectuer des soumissions par l intermédiaire du maître. Votre poste de travail doit être soit un noeud géré, soit un serveur Tivoli de la région TMR pour installer les connecteurs sur un poste de travail. 120 Version 8.1

141 Installation des connecteurs sur des agents FTA Utilisateurs d environnement non Tivoli : Lorsque vous créez un agent FTA, assurez-vous que vous installez le moteur Tivoli Workload Scheduler avant d installer le connecteur. Avant de commencer, assurez-vous que Tivoli Management Framework est installé sur l agent FTA et que le système figure dans la liste des plateformes prises en charge pour le connecteur. Suivez les instructions d installation décrites dans le chapitre du manuel Tivoli Job Scheduling Console - Guide de l utilisateur qui explique comment installer le connecteur. Utilisateurs d environnement Tivoli : Généralement, le gestionnaire de domaine principal réside sur un noeud géré. Vous devez d abord installer les services de planification des travaux/classes de connecteur sur le serveur Tivoli. Faites attention de ne pas créer d instance sur un noeud géré sur lequel le moteur Tivoli Workload Scheduler n est pas installé. Tous les utilisateurs : Vous devez savoir qu au cours du processus d installation, un message vous invitera à indiquer un nom d instance Tivoli Workload Scheduler. Ce nom sera affiché dans l arborescence de la planification des travaux de JS Console. Pour éviter toute confusion, vous devriez utiliser un nom qui contient le nom de l agent FTA. Si vous installez le connecteur sur plusieurs agents FTA d un réseau, gardez à l esprit que les noms d instance doivent être uniques à la fois à l intérieur du réseau Tivoli Workload Scheduler et de la région TMR. Remarques par rapport au maître de secours Remarques sur l installation Si vous souhaitez installer le connecteur sur le maître de secours, que vous n avez pas de régions existantes et que vous ne souhaitez pas implémenter un environnement de gestion Tivoli complet, vous pouvez installer un nouveau serveur Tivoli sur le maître de secours. Si vous installez sur le maître de secours un serveur Tivoli différent de celui du maître, assurez-vous d activer les mêmes entrées que sur le maître, à savoir : Start Plan audit level et Database audit level Timezone enable D. Migration vers Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 121

142 Gestion des maîtres n appartenant pas aux plateformes de niveau 1 dans un réseau Maestro existant Gestion des maîtres n appartenant pas aux plateformes de niveau 1 dans un réseau Maestro existant Si votre gestionnaire de domaine principal ne s exécute pas sur une plateforme prise en charge pour installer Tivoli Management Framework et le connecteur et si vous souhaitez pouvoir utiliser Job Scheduling Console, vous pouvez choisir entre les trois options suivantes : Déplacer le gestionnaire de domaine principal vers l une des plateformes prises en charge. Créer un maître de secours sur une plateforme prise en charge. NFS monte les bases de données maîtres sur un agent FTA. Déplacement du maître de secours Pour déplacer le gestionnaire de domaine principal (de UNIX vers UNIX) : 1. Choisissez un agent FTA existant dans le réseau ou créez-en un. Si vous créez un agent FTA, veillez à le définir avec les modes Résolution des dépendances et Statut intégral activés. 2. Sur le gestionnaire de domaine principal, compactez maestro/mozart/* et maestro/../unison/network/*. 3. Décompactez ces fichiers sur l agent FTA, dans des répertoires du même nom. 4. Ne copiez pas parameters ni parameters.key à partir du répertoire principal, sinon vous allez remplacer des paramètres qui sont uniques à l agent FTA. Créez une liste de paramètres à partir des deux machines, en ajoutant les paramètres obligatoires à l agent FTA. 5. Sur l agent FTA, éditez le fichier globalopts pour remplacer le nom du maître par celui de l agent FTA. 6. Sur l ancien maître, utilisez la commande switchmgr pour basculer vers le nouveau maître. 7. Annulez l agent final existant dans le jour de production en cours. 8. Ajoutez l agenda final au nouveau maître (utilisez composer modify sched=anciennommaître#final et modifiez l ID du poste de travail sur la ligne d agenda). 9. Après avoir effectué la sauvegarde et l ajout, supprimez l agenda oldmastername#final à l aide de la commande : composer delete sched=anciennommaître#final 10. Soumettez le nouvel agenda final dans la production quotidienne. 11. Sur l ancien maître, éditez le fichier globalopts de façon à refléter le nom du nouveau maître. Remarque : Il n est pas nécessaire d éditer toutes les options globales pour chaque poste de travail du réseau. Les noeuds reconnaîtront le nouveau maître au moment de l exécution de Jnextday, lorsque le maître les initialisera. 122 Version 8.1

143 Gestion des maîtres n appartenant pas aux plateformes de niveau 1 dans un réseau Maestro existant Création d un maître de secours Pour créer un maître de secours : 1. Installez Tivoli Management Framework. Pour plus de détails, reportez-vous au manuel Tivoli Enterprise - Guide d installation. 2. Installez le moteur Tivoli Workload Scheduler. Reportez-vous au Chapitre 2, «Installation sous Windows NT» à la page 19 ou au Chapitre 3, «Installation sous UNIX» à la page Installez le connecteur. Reportez-vous au chapitre du manuel Tivoli Job Scheduling Console - Guide de l utilisateur qui explique comment installer le connecteur. 4. Personnalisez le poste de travail avec la sécurité et les options locales Tivoli Workload Scheduler. Reportez-vous au Chapitre 4, «Définition de la sécurité» à la page 47 et au Chapitre 5, «Etapes de personnalisation facultatives» à la page Définissez le poste de travail dans le réseau Tivoli Workload Scheduler. Utilisez soit la commande cpuname de Composer, soit la fenêtre Créer un poste de travail de Job Scheduling Console. Veillez à le définir avec les options Résolution des dépendances et Statut intégral activées. Reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence ou au manuel Tivoli Job Scheduling Console - Guide de l utilisateur. Montages de bases de données MDM Vous pouvez montez à l aide du système NFS les bases de données maîtres suivantes sur un agent FTA qui s exécute sur une plateforme prise en charge : /usr/lib/maestro/mozart/globalopts (la copie opérationnelle) /usr/lib/unison/network/cpudata Les modes Statut intégral et Résolution des dépendances doivent être activés dans la définition de poste de travail de l agent FTA. Avant de monter les bases de données, assurez-vous que le système de fichiers qui contient les répertoires requis ont été inclus dans le fichier /etc/exports sur le poste de travail maître. Si vous choisissez de contrôler la disponibilité du système de fichiers, effectuez les entrées appropriées dans le fichier /etc/hosts ou /etc/netgroup sur le maître. Le point de montage sur l agent FTA doit être le même que sur le maître. Par exemple, sur l agent FTA : cd twshome /etc/mount nommaître:mozart mozart /etc/mount nommaître:../unison/network../unison/network Pour que les bases de données soient montées automatiquement, vous pouvez entrer les montages dans le fichier /etc/checklist. Si vous utilisez cette solution, vous devez savoir que la base de données des paramètres de l agent FTA n est pas celle du maître mais une copie locale. Cela constitue un problème si vous utilisez des paramètres dans le cadre des définitions de travaux (dans le nom de tâche ou de connexion), parce qu au moment de l exécution de Jnextday, tous les paramètres référencés avec le symbole ^ (carat) dans les définitions de travaux sont étendus à partir de la base de données des paramètres du maître. Il existe deux moyens de contourner ce problème : Créez un script qui télécharge et modifie les valeurs des paramètres depuis l agent FTA vers le maître. Exécutez ce script juste avant Jnextday. En établissant une dépendance D. Migration vers Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 123

144 Gestion des maîtres n appartenant pas aux plateformes de niveau 1 dans un réseau Maestro existant entre Jnextday et ce script, vous vous assurez que les paramètres seront téléchargés correctement avant que Jnextday ne configure la production du jour suivant. Sur la CPU maître, déplacez la base de données des paramètres dans le répertoire mozart. Créez un lien entre la maître et le répertoire principal. Ensuite, sur l agent FTA, créez un lien entre la base de données des paramètres du répertoire mozart et le répertoire twshome. Si vous souhaitez activer la fonction de fuseau horaire dans Job Scheduling Console, vous aurez également besoin d éditer le fichier globalopts local sur l agent FTA afin de définir l entrée Timezone Enable. Gestion des maîtres de secours n appartenant pas aux plateformes de niveau 1 dans un réseau Maestro existant Vous pouvez conserver votre maître de secours existant même s il ne s exécute pas sur les plateformes prises en charge (niveau 1). Toutefois, souvenez-vous que cela vous empêchera d utiliser Job Scheduling Console dans cet environnement. Suivez les instructions de la section précédente si vous décidez de changer de machine. Exécution de plusieurs fenêtres dans JS Console Si vous avez besoin de plus de sept fenêtres actives JS Console sur un client, vous devez installer une autre instance de Job Scheduling Console sur ce système. Au cours de l installation, veillez à choisir un emplacement unique pour la deuxième instance. Sous Windows NT, l emplacement du raccourci doit également être unique. Préservation d un fichier de sécurité existant Lors de la migration vers Tivoli Workload Scheduler0, pour préserver une structure de sécurité existante, vous devez créer un administrateur Tivoli sur le serveur Tivoli Management Framework pour chaque définition de sécurité Maestro dont vous disposez, puis inclure une définition pour cet administrateur dans le fichier de sécurité. Pour plus de détails sur la création d un administrateur Tivoli, reportez-vous à la documentation de Tivoli Management Framework. Pour plus de détails sur la façon d éditer le fichier de sécurité, reportez-vous au Chapitre 4, «Définition de la sécurité» à la page 47. Ajout d administrateurs Tivoli Supposons que vous souhaitiez faire migrer votre réseau Maestro vers Tivoli Workload Scheduler et que le système qui héberge le gestionnaire de domaine principal actuellement soit l une des plateformes prises en charge. Vous souhaitez installer le connecteur sur ce système de façon à disposer d un certain nombre de clients JS Console. Par conséquent, vous devez d abord installer Tivoli Management Framework. Supposons que vous installiez un serveur Tivoli. Le fichier de sécurité actuel de votre maître est le suivant : ########################################################### # Security File ########################################################### # (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE # MASTER DOMAIN MANAGER user mastersm cpu=$master + logon=maestro,root begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # Version 8.1

145 Préservation d un fichier de sécurité existant job access=@ schedule access=@ resource access=@ prompt access=@ file access=@ calendar access=@ cpu access=@ parameter name=@ ~ name=r@ access=@ userobj cpu=@ + logon=@ access=@ end ########################################################### # (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY # WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user sm logon=maestro,root begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job cpu=$thiscpu access=@ schedule cpu=$thiscpu access=@ resource cpu=$thiscpu access=@ prompt access=@ file access=@ calendar access=@ cpu cpu=$thiscpu access=@ parameter cpu=$thiscpu ~ name=r@ access=@ end ########################################################### Supposons que vous souhaitiez que ces deux utilisateurs utilisent JS Console. Après avoir installé le logiciel TMF, dans le bureau Tivoli, créez un administrateur Tivoli supplémentaire (en plus de l administrateur par défaut créé par le processus d installation) pour chaque utilisateur Maestro. Vous appelez l un mastersm et l autre sm. Vous ajoutez ensuite les définitions respectives de façon à ce que le fichier de sécurité ressemble à ce qui suit : ########################################################### # Security File ########################################################### # (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE # MASTER DOMAIN MANAGER user mastersm cpu=$master + logon=maestro,root begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job access=@ schedule access=@ resource access=@ prompt access=@ file access=@ calendar access=@ cpu access=@ parameter name=@ ~ name=r@ access=@ userobj cpu=@ + logon=@ access=@ end ########################################################### # (2) TIVOLI ADMINISTATOR DEFINITION FOR MAESTRO OR ROOT USERS LOGGED IN ON THE # MASTER DOMAIN MANAGER user mastersm cpu=$framework + logon=mastersm begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job access=@ schedule access=@ resource access=@ prompt access=@ file access=@ D. Migration vers Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 125

146 Préservation d un fichier de sécurité existant calendar access=@ cpu access=@ parameter name=@ ~ 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,root begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job cpu=$thiscpu access=@ schedule cpu=$thiscpu access=@ resource cpu=$thiscpu access=@ prompt access=@ file access=@ calendar access=@ cpu cpu=$thiscpu access=@ parameter cpu=$thiscpu ~ name=r@ access=@ end ############################################## ################ (4) TIVOLI ADMINISTRATOR DEFINITION FOR MAESTRO OR ROOT USERS LOGGED IN ON ANY # WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER. user sm cpu=$framework + logon=sm begin # OBJECT ATTRIBUTES ACCESS CAPABILITIES # job cpu=$thiscpu access=@ schedule cpu=$thiscpu access=@ resource cpu=$thiscpu access=@ prompt access=@ file access=@ calendar access=@ cpu cpu=$thiscpu access=@ parameter cpu=$thiscpu ~ name=r@ access=@ end ########################################################## Le nouveau fichier de sécurité accorde aux utilisateurs d origine les mêmes privilèges sur Job Scheduling Console. En outre, sur le serveur Tivoli, vous pouvez ajouter deux nouveaux ID de connexion pour l administrateur Tivoli mastersm : [email protected] [email protected] De cette façon, tout utilisateur autorisé qui se connecte à rome ou à london en tant que maestro bénéficiera des privilèges accordés à mastersm. 126 Version 8.1

147 Gestion de la sécurité Les modifications apportées au fichier de sécurité sont prises en compte une fois que l un des programmes Workload Scheduler suivants est arrêté et redémarré : conman composer connecteur Quittez simplement les programmes. La prochaine fois qu ils seront exécutés, les nouvelles définitions de sécurité seront reconnues. En ce qui concerne les connecteurs, utilisez la commande wmaeutil pour les arrêter. Ils seront redémarrés automatiquement avec le rafraîchissement de n importe quelle requête dans Job Scheduling Console. Arrêt des connecteurs en vue d implémenter les modifications Un connecteur démarre automatiquement lorsque quelqu un émet une commande à partir de JS Console. Vous devez toutefois l arrêter manuellement. Sous Windows NT, vous devez arrêter le connecteur avant d exécuter la commande makesec. Sous UNIX, vous pouvez l arrêter soit avant, soit après l exécution de makesec. Utilisez la commande wmaeutil pour arrêter le connecteur. Exécution de WMAEUTIL Pour exécuter la commande wmaeutil : 1. Définissez l environnement Tivoli : A partir de la ligne de commande UNIX : v Pour ksh :. /etc/tivoli/setup_env.sh v Pour csh : source /etc/tivoli/setup_env.sh A partir d une ligne de commande Windows NT : %SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd 2. Entrez la commande suivante : wmaeutil ALL -stop Remarques sur les fuseaux horaires La méthode d implémentation correcte est la suivante : Gestion de la sécurité 1. Chargez Tivoli Workload Scheduler. Par défaut, les fuseaux horaires ne sont pas activés (entrée timezone enable dans globaloptions). La base de données autorisera la définition de fuseaux horaires pour les postes de travail, mais pas pour les heures de début, ni pour les échéances dans les flux de travaux de la base de données. La création du plan (Jnextday) ignorera tous les fuseaux horaires définis dans la base de données. Vous ne pourrez pas indiquer de fuseaux horaires dans le plan. 2. Définissez les fuseaux horaires des postes de travail. Définissez le fuseau horaire du poste maître, du maître de secours et de tous les agents FTA se trouvant dans un fuseau horaire différent de celui du maître. Aucun fuseau horaire ne sera autorisé dans la base de données pour les heures de début et les D. Migration vers Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 127

148 Remarques sur les fuseaux horaires échéances. Aucun fuseau horaire ne sera autorisé dans le plan à ce stade étant donné que l entrée timezone enable de globaloptions a toujours pour valeur NO. 3. Une fois que les fuseaux horaires des postes de travail sont définis correctement, affectez la valeur YES à l option timezone enable dans le fichier globaloptions. Ce paramètrage, ainsi que la définition d un fuseau horaire sur le poste maître, permettront au réseau Tivoli Workload Scheduler de bénéficier du support des fuseaux horaires. A ce stade, tous les utilisateurs peuvent utiliser des fuseaux horaires dans la base de données, bien qu il soit préférable qu ils attendent la prochaine exécution de Jnextday pour les utiliser sur les heures de début et les échéances. Tant que Jnextday ne s est pas exécuté, ils ne pourront pas utiliser de fuseaux horaires dans le plan. Lors de la prochaine exécution de Jnextday, les fuseaux horaires seront transmis au plan et JS Console et les processus dorsaux autoriseront la spécification de fuseaux horaires dans le plan. 4. Commencez à utiliser des fuseaux horaires sur les heures de début et les échéances lorsque vous en avez besoin. Vous pouvez maintenant utiliser toutes les références de fuseaux horaires dans la base de données et dans le plan, à la fois avec JS Console et avec l interface de ligne de commande. Pour les agents tolérant les pannes MPE et pour les LFTA AS400 (Version 6.1), vous pouvez indiquer des informations de fuseau horaire uniquement à partir de JS Console. Transmission des préférences utilisateur à d autres utilisateurs (Vues/Requêtes personnalisées) Cette option, disponible avec Job Scheduling Console, permet à un utilisateur utilisant JS Console pour la première fois de copier les préférences d un autre utilisateur. Elle peut également servir à transmettre un ensemble de préférences à plusieurs utilisateurs. Les préférences utilisateur sont stockées dans un fichier intitulé GlobalPreferences.ser. Ce fichier contient les noms et les informations détaillées, y compris les filtres, de toutes les requêtes (ou listes) ayant été enregistrées au cours d une session. Chaque fois que vous fermez JS Console, GlobalPreferences est mis à jour avec toutes les requêtes que vous avez enregistrées ou supprimées dans l arborescence de la planification des travaux. GlobalPreferences est enregistré localement dans un répertoire utilisateur dans...\jsconsole\dat\.tmeconsole sous Windows, ou dans $HOME/.tmeconsole sous UNIX. Le répertoire utilisateur a un nom composite qui correspond à ce qui suit : Le nom de l administrateur Tivoli associé au connecteur auquel l utilisateur a accédé. Il est suivi du signe arobase (@). Le nom du système exécutant le connecteur, suivi d un trait de soulignement (_). Les paramètres régionaux du système d exploitation sur lequel le connecteur est installé. L ID change de façon dynamique si l utilisateur se connecte au même connecteur et constate que les paramètres régionaux ont été modifiés. Remarque : Les deux premiers sont les noms que vous entrez dans la fenêtre Startup de Job Scheduling Console pour démarrer JS Console. Par exemple, supposez que, pour démarrer JS Console, vous vous connectiez pour la première fois à la machine fta12 sur laquelle le connecteur a été installé par 128 Version 8.1

149 Transmission des préférences utilisateur à d autres utilisateurs (Vues/Requêtes personnalisées) l Administrateur Tivoli tws12adm. Un répertoire utilisateur nommé tws12adm@fta12_en (où en représente les paramètres régionaux anglais) est créé dans le chemin décrit plus haut sur votre poste de travail. Chaque fois que vous vous connectez à un connecteur différent, un nouveau répertoire utilisateur est ajouté. Et chaque fois que vous fermez JS Console, un fichier GlobalPreferences.ser est créé ou mis à jour dans le répertoire utilisateur qui correspond à votre connexion. Lorsque les utilisateurs se connectent à un connecteur pour la première fois, une fenêtre Accès à une adresse leur demande s ils souhaitent utiliser un fichier GlobalPreferences.ser existant à partir d un lecteur réseau connecté ou d une URL. Si vous souhaitez transmettre un ensemble de requêtes spécifique à de nouveaux utilisateurs, vous devez d abord rendre le fichier GlobalPreferences.ser correspondant disponible, puis demander aux utilisateurs d indiquer le fichier ou l URL dans la fenêtre Accès à une adresse. Si vous souhaitez transmettre un fichier de préférences à des utilisateurs existants, vous devez remplacer leur propre fichier GlobalPreferences.ser par celui que vous avez préparé. Remarque : Un fichier GlobalPreferences.ser différent existe dans...\jsconsole\dat\.tmeconsole\tivoliconsole sous Windows ou dans $HOME/.tmeconsole/TivoliConsole sous UNIX. Ce fichier contient des préférences qui affectent la présentation de JS Console et ne doivent pas être transmises. Retour à une base de données non étendue Si vous souhaitez revenir à une base de données étendue, vous avez le choix entre deux méthodes : Utilisez la méthode suivante si aucun objet de planification n a été créé ou modifié depuis que la base de données a été étendue. Si des objets de planification ont été créés, ils peuvent être ajoutés à la base de données manuellement après le retour à un état non étendu. Si des modifications ont été effectuées, elles devront être de nouveau appliquées. Procédez comme suit : 1. Sur le maître, restaurez les fichiers de sauvegarde du répertoire mozart.old dans les répertoires mozart et unison/network : a. Déplacez les fichiers suivants vers le répertoire unison/network : v cpudata v cpudata.key v userdata v userdata.key b. Déplacez tous les autres fichiers vers le répertoire mozart. 2. Assurez-vous que l option globale expanded version a pour valeur NO. 3. Vérifiez que les noms de CPU indiqués dans globalopts et dans localopts contiennent au maximum huit caractères. D. Migration vers Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 129

150 Retour à une base de données non étendue Utilisez la méthode suivante si de nombreux objets de planification ont été créés ou modifiés depuis que la base de données a été étendue. Utilisez également cette méthode lorsque vous souhaitez revenir à une base de données non étendue et que les objets de planification ont des noms longs. 1. Entrez les commandes composer suivantes pour créer des fichiers qui contiennent toutes les informations de base de données pour les objets de planification. Les fichiers seront créés uniquement si ces objets existent dans la base de données : create cpu.txt from cpu=@ create jobs.txt from jobs=@#@ create sched.txt from sched=@#@ create cal.txt from calendars create prompt.txt from prompts create parms.txt from parms create param.txt from parameters 2. Déplacez les fichiers objet des répertoires mozart et unison/mozart vers un répertoire temporaire. Le fichier globalopts et les fichiers runmsgno restent dans le répertoire mozart. Dans globalopts, vérifiez que le nom de la CPU contient au maximum huit caractères et que expanded version a pour valeur NO. Vérifiez également que le nom de la CPU contient au maximum huit caractères dans localopts. 3. Modifiez les fichiers suivants que vous avez créés à la première étape : v cpu.txt v jobs.txt v sched.txt Editez tous les noms de CPU, de domaine, de travail, d agenda et d utilisateur de façon à ce qu ils contiennent au maximum huit caractères. Vérifiez également la longueur des noms des fichiers de travail et des commandes. 4. Renommez les fichiers suivants dans le répertoire unison/network : v cpudata v cpudata.key v userdata v userdata.key 5. Entrez les commandes composer suivantes pour alimenter la nouvelle base de données non étendue avec les objets de planification : add cpu.txt add jobs.txt add sched.txt replace cal.txt replace prompt.txt replace parms.txt replace param.txt 6. Renommez le fichier Symphony avant d exécuter Jnextday. 130 Version 8.1

151 Migration sous Windows NT Migration sous Windows NT Sur les postes de travail Windows NT, si vous effectuez une migration à partir de Maestro 6.x, connectez-vous en tant qu administrateur. D. Migration vers Tivoli Workload Scheduler Tivoli Workload Scheduler - Guide de planification et d installation 131

152 Migration sous Windows NT 132 Version 8.1

153 Glossaire A agent étendu : Agent utilisé pour intégrer les fonctions de contrôle de travaux de Tivoli Workload Scheduler avec d autres systèmes d exploitation (par exemple, MVS) et applications (par exemple, Oracle, Peoplesoft et Baan). Les agents étendus utilisent des scripts appelés méthodes d accès pour communiquer avec les systèmes externes. agent réseau : Type d agent étendu servant à créer des dépendances entre les travaux et flux de travaux des différents réseaux Tivoli Workload Scheduler. Voir aussi dépendance interréseau (INET). agent tolérant les pannes (FTA) : Dans le réseau Tivoli Workload Scheduler, poste de travail capable de résoudre des dépendances locales et de lancer ses travaux en l absence d un gestionnaire de domaine. B base de données : Base de données contenant toutes les définitions que vous avez créées pour les objets de planification (par exemple, les travaux, les flux de travaux, les ressources, les postes de travail, etc). Elle contient également des informations importantes, telles que les statistiques relatives à l exécution des travaux et des flux de travaux, des informations sur l ID utilisateur qui a créé un objet et la date de dernière modification d un objet. Au contraire, le plan ne contient que les travaux et les flux de travaux (y compris les objets qui en dépendent) qui sont planifiés pour être exécutés dans la production du jour. base de données étendue : Base de données étendue autorisant les noms longs pour les objets de base de données, tels que les travaux, les flux de travaux, les postes de travail, les domaines et les utilisateurs. Les bases de données étendues sont configurées à l aide de la commande dbexpand ou correspondent à une option lors de l installation. N étendez pas votre base de données avant de comprendre les implications et les incidences de cette commande. Batchman : Processus exécuté au début de chaque journée de traitement Tivoli Workload Scheduler pour lancer des travaux conformément aux informations du fichier symphony. C calendrier : Objet défini dans la base de données Tivoli Workload Scheduler qui contient une liste de dates de planification. Etant donné qu il s agit d un objet unique défini dans la base de données, il peut être affecté à plusieurs flux de travaux. L affectation d un calendrier à un flux de travaux se traduit par l exécution de ce flux de travaux les jours indiqués dans le calendrier. Notez qu un calendrier peut être utilisé comme cycle d exécution inclusif ou exclusif. caractères génériques : Les caractères génériques de Tivoli Workload Scheduler sont les suivants :? Remplace un caractère alphabétique. % Remplace un caractère numérique. * Remplace zéro ou plusieurs caractères alphanumériques. Les caractères génériques sont généralement utilisés pour détailler la recherche d un ou de plusieurs objets de la base de données. Par exemple, pour afficher tous les postes de travail, vous pouvez entrer le caractère générique * (astérisque). Pour accéder à la liste des postes de travail site1 à site8, vous pouvez entrer site%. classe de poste de travail : Groupe de postes de travail. Une classe peut contenir n importe quel nombre de postes de travail. Des flux de travaux et des travaux peuvent être affectés à des fins d exécution dans une classe de poste de travail. Cela facilite la réplication d un travail ou d un flux de travaux sur plusieurs postes de travail. Composer : Application de ligne de commande existante autorisant la gestion des définitions de vos objets de planification dans la base de données. Conman : Application de ligne de commande existante autorisant la gestion de l environnement de production. Conman (gestionnaire de console) permet de lancer et d arrêter des processus de production, de modifier et d afficher des agendas et des travaux du plan et de contrôler la connexion des postes de travail dans un réseau. cycle d exécution : Cycle indiquant les jours pendant lesquels un flux de travaux est planifié pour s exécuter. Dans Tivoli Workload Scheduler, trois types de cycles d exécution peuvent être indiqués pour un flux de travaux : cycle d exécution simple, cycle d exécution hebdomadaire, ou cycle d exécution de calendrier (appelé calendrier). Chaque type de cycle d exécution peut être inclusif ou exclusif. En d autres termes, chaque cycle d exécution peut définir des jours pour lesquels un flux de travaux est inclus dans le cycle de production ou ceux pour lesquels un flux de travaux est exclu du cycle de production. Lorsque vous définissez plusieurs cycles d exécution pour un flux de travaux et que des cycles d exécution de type inclusif et exclusif indiquent les mêmes jours, les cycles d exécution de type exclusif sont prioritaires. cycle d exécution exclusif : Cycle d exécution indiquant les jours pendant lesquels un flux de travaux ne peut pas s exécuter. Les cycles d exécution de type exclusif sont prioritaires par rapport aux cycles d exécution de type inclusif. cycle d exécution hebdomadaire : Cycle d exécution qui indique les jours de la semaine pendant lesquels un flux de travaux est exécuté. Par exemple, un flux de travaux peut être signalé comme devant s exécuter chaque lundi, mercredi et vendredi à l aide d un cycle d exécution hebdomadaire. Un cycle d exécution hebdomadaire est défini pour un flux de travaux spécifique et ne peut pas être utilisé par plusieurs flux de travaux. Pour plus d informations, reportez-vous à cycle d exécution. Glossaire Tivoli Workload Scheduler - Guide de planification et d installation 133

154 cycle d exécution inclusif : Cycle d exécution indiquant les jours pendant lesquels un flux de travaux est planifié pour s exécuter. Les cycles d exécution de type exclusif sont prioritaires par rapport aux cycles d exécution de type inclusif. cycle d exécution simple : Ensemble spécifique de jours définis par l utilisateur pendant lesquels un flux de travaux est exécuté. Un cycle d exécution simple est défini pour un flux de travaux spécifique et ne peut pas être utilisé par plusieurs flux de travaux. Pour plus d informations, voir cycle d exécution. D dépendance : Condition préalable requise devant être remplie pour permettre l exécution d un travail ou d un flux de travaux. Le nombre maximal de dépendances admis pour un travail ou un flux de travaux est de 40. Les quatre types de dépendances utilisés par Tivoli Workload Scheduler sont : les dépendances d aboutissement d autres travaux ou flux de travaux (follows), les dépendances de ressource, les dépendances de fichier et les dépendances d invite. dépendance d aboutissement d autres travaux ou flux de travaux (follows) : L exécution d un travail ou d un flux de travaux ne peut pas être lancée tant que l exécution des autres travaux ou flux de travaux n a pas abouti. dépendances interréseau (INET) : Dépendance entre les travaux ou flux de travaux des différents réseaux Tivoli Workload Scheduler. Voir aussi agent réseau. domaine : Groupe nommé de postes de travail Tivoli Workload Scheduler constitué d un ou de plusieurs agents et d un gestionnaire de domaine servant de concentrateur de gestion. Les domaines ont tous un domaine parent excepté le domaine principal. durée : Il s agit du temps prévu pour effectuer un travail. Dans la vue Diagramme des travaux de la base de données, la durée est représentée par une barre bleu clair située au milieu de la barre d activité ou par un losange bleu clair. E échéance : Heure au-delà de laquelle un travail ou flux de travaux ne peut plus être exécuté. Correspond à l information Until dans Maestro. F fichier stdlist : Un fichier de liste standard créé pour chaque travail lancé par Tivoli Workload Scheduler. Les fichiers de liste standard contiennent des bannières d en-tête et de fin, des commandes echo, ainsi que des erreurs et des avertissements. Ces fichiers peuvent être utilisés pour résoudre les incidents d exécution de travaux. fichier Symphony : Fichier contenant les informations de planification requises par le processus de contrôle de production (batchman) pour exécuter le plan. Le fichier est généré et chargé lors de la phase de pré-production. Lors de la phase de production, il est mis à jour en continu pour indiquer le statut en cours du processus de production : travaux terminés, travaux en cours, travaux restant à effectuer. Pour gérer le processus de production, le contenu du fichier symphony (plan) peut être affiché et modifié à l aide de Job Scheduling Console. flux de travaux : Liste de travaux exécutés en un tout (application de sauvegarde hebdomadaire, par exemple), avec les heures, les priorités et toute autre dépendance qui déterminent l ordre d exécution des travaux. flux de travaux final : Dernier flux de travaux exécuté pour un jour de production. Il contient un travail qui exécute le fichier script Jnextday. G gestionnaire de domaine : Concentrateur de gestion dans un domaine Tivoli Workload Scheduler. Toutes les communications à destination et en provenance des agents d un domaine sont acheminées à travers le gestionnaire de domaine. gestionnaire de domaine principal : Le poste de travail gère les fichiers servant à documenter les objets de planification sur un réseau Tivoli Workload Scheduler. Il crée le plan en début de journée et effectue l ensemble des opérations de journalisation et de présentation pour le réseau. H heure au plus tôt : Heure avant laquelle le travail ou le flux de travaux ne peut pas être lancé. L heure de début au plus tôt correspond à votre estimation, déterminée en fonction de votre expérience antérieure de l exécution du travail ou du flux de travaux. Le travail ou le flux de travaux peut toutefois être lancé après l heure définie à partir du moment ou toutes les autres dépendances sont respectées. Dans le diagramme, l heure de début est représentée par le début (bord gauche) de la barre d activité bleu marine. Pour les instances de travail, l heure de début calculée par Tivoli Workload Scheduler est représentée par une barre bleu clair. Voir aussi heure de début réelle et heure de début prévue. heure de début prévue : Heure à laquelle Tivoli Workload Scheduler estime qu une instance de travail va commencer. Cette estimation est fondée sur l heure de début d exécutions précédentes. hôte : Poste de travail Workload Scheduler requis par les agents étendus. Il peut s agir de n importe quel poste de travail Tivoli Workload Scheduler à l exception d un autre agent étendu. I instance de flux de travaux : Flux de travaux planifié pour une date d exécution spécifique du plan. Voir aussi flux de travaux. instance de travail : Travail planifié pour une date d exécution particulière du plan. Voir aussi travail. 134 Version 8.1

155 invite : Objet pouvant servir de dépendance pour des travaux et des flux de travaux. Une réponse affirmative doit être donnée à une invite pour que le travail ou le flux de travaux dépendant soit lancé. Il existe deux types d invites : prédéfinie et ad hoc. Une invite ad hoc est définie dans les propriétés d un travail ou d un flux de travaux ; elle est propre à ce travail ou à ce flux de travaux. Une invite prédéfinie est définie dans la base de données Tivoli Workload Scheduler et peut être utilisée par n importe quel travail ou flux de travaux. L limite : Limite d un travail qui permet d allouer un nombre spécifique d emplacements de travaux où Tivoli Workload Scheduler est autorisé à lancer des travaux. Une limite de travail peut être définie pour chaque flux de travaux et pour chaque poste de travail. Par exemple, l attribution d une valeur de 25 à la limite des travaux d un poste de travail permet à Tivoli Workload Scheduler d exécuter simultanément un maximum de 25 travaux sur le poste de travail. liste : Liste affichant les objets de planification des travaux. Vous devez créer des listes distinctes pour chaque objet de planification des travaux. Pour chacun de ces objets, il existe deux types de liste : une liste de définitions dans la base de données et une liste d instances dans le plan. M méthode d accès : Fichier exécutable utilisé par les agents étendus pour se connecter à d autres systèmes d exploitation (par exemple, MVS) et à d autres applications (par exemple, Oracle, Peoplesoft et Baan) pour contrôler l exécution de travaux. La méthode d accès doit être indiquée dans la définition de poste de travail de l agent étendu. O options globales : Options qui s appliquent à tous les postes de travail d un réseau Tivoli Workload Scheduler. Elles sont définies dans le fichier globalopts sur le gestionnaire de domaine principal. Voir aussi options locales. options locales : Options ne s appliquant qu au poste de travail sur lequel elles sont définies. Les options locales sont définies dans le fichier localopts de chaque poste de travail du réseau Tivoli Workload Scheduler. Voir aussi options globales. P paramètre : Paramètre utilisé pour remplacer les valeurs de vos travaux ou flux de travaux. Lors de l utilisation d un paramètre dans un script de travail, la valeur est remplacée au moment de l exécution. Dans ce cas, le paramètre doit être défini sur le poste de travail où il va être utilisé. Les paramètres ne peuvent pas être utilisés lors du traitement de script des travaux de l agent étendu. plan : Fichier contenant toute l activité de planification d un travail prévue pour une période d un jour. Dans Tivoli Workload Scheduler, le plan est créé toutes les 24 heures et est constitué de travaux, de flux de travaux et d objets de dépendances dont l exécution est prévue ce jour. Tous les flux de travaux pour lesquels vous avez créé des cycles d exécution sont automatiquement planifiés et intégrés au plan. Au fur et à mesure de la progression du cycle d exécution, les travaux et les flux de travaux du plan sont exécutés conformément à leurs restrictions temporelles et à d autres dépendances. Tous les travaux et les flux de travaux dont l exécution n aboutit pas sont reportés au plan du jour suivant. poste de travail : Ordinateur individuel sur lequel des travaux et des flux de travaux sont exécutés. Il est défini dans la base de données Tivoli Workload Scheduler sous la forme d un objet unique. Une définition de poste de travail est requise pour chaque ordinateur qui exécute des travaux ou des flux de travaux dans le réseau Workload Scheduler. prédécesseur : Travail devant aboutir pour que l exécution des travaux successeurs puisse commencer. priorité : Préférence temporelle dans le système de file d attente de Tivoli Workload Scheduler pour l exécution des travaux et des flux de travaux du plan. Vous pouvez affecter à chaque travail ou flux de travaux un niveau de priorité de 0 à 101. Une priorité de 0 empêche toute exécution. priorité limite : La priorité limite constitue un contrôle principal de l exécution d un travail sur un poste de travail. La priorité limite correspond au niveau de priorité qu un travail ou un flux de travaux doit dépasser avant de pouvoir s exécuter. Une priorité limite de 40, par exemple, empêche le lancement des travaux dont la priorité est inférieure ou égale à 40. R ressource : Objet représentant des ressources physiques ou logiques de votre système. Une fois définies dans la base de données Tivoli Workload Scheduler, les ressources peuvent servir de dépendances pour les travaux et flux de travaux. Par exemple, vous pouvez définir une ressource appelée bandes avec une valeur d unité égale à deux. Ensuite, définissez des travaux qui requièrent deux unités de bande disponibles comme dépendance. Les travaux liés à cette dépendance ne peuvent pas s exécuter en même temps car chaque fois qu un travail est exécuté, la ressource bandes est utilisée. restrictions temporelles : Les restrictions temporelles peuvent être indiquées pour les travaux et les flux de travaux. Vous pouvez définir l heure de début d une exécution ou l heure après laquelle l exécution ne peut plus avoir lieu. En indiquant ces deux heures, vous pouvez définir une fenêtre dans laquelle un travail ou un flux de travaux est exécuté. Pour les travaux, vous pouvez aussi indiquer un taux de répétition. Par exemple, vous pouvez configurer Tivoli Workload Scheduler de sorte que le même travail soit lancé toutes les 30 minutes entre 08h30 et 13h30. Glossaire Tivoli Workload Scheduler - Guide de planification et d installation 135

156 S statut : Reflète le statut en cours du travail ou du flux de travaux de Job Scheduling Console. Le statut de Job Scheduling Console est commun à Tivoli Workload Scheduler et à Tivoli Workload Scheduler pour z/os. Voir aussi statut interne. statut du travail : Voir statut. statut interne : Reflète le statut en cours des travaux et flux de travaux dans le moteur Tivoli Workload Scheduler. Le statut interne est unique à Tivoli Workload Scheduler. Voir aussi statut. successeur : Travail qui ne peut être lancé que si tous les travaux prédécesseurs dont il dépend sont terminés. T Tivoli Management Framework : Logiciel de base requis pour l exécution d applications de l ensemble de produits Tivoli. L infrastructure du logiciel permet l intégration d applications de gestion systèmes de Tivoli Systems Inc. et Tivoli Partners. Tivoli Management Framework contient les éléments suivants : vrépartiteur de requêtes d objets (oserv), vbase de données d objets distribuée, vfonctions d administration de base, vservices d applications de base, vservices de bureau de base tels que l interface utilisateur graphique. Dans un environnement Tivoli, Tivoli Management Framework est installé sur chaque client et serveur. Toutefois, le serveur TMR est le seul serveur qui contient la base de données d objets entière. effectuer avant ou après la production. TWShome\Jnextday est exemple de travail jnextday. Jnextday configure le traitement du jour suivant (contenu dans le fichier symphony), imprime des rapports, reporte des flux de travaux non terminés et arrête et relance Tivoli Workload Scheduler. travaux interactifs : Travail exécuté de manière interactive sur un bureau Windows NT. U utilisateur : Pour Windows NT uniquement, le nom d utilisateur indiqué dans la zone Connexion d une définition de travail doit correspondre à une définition d utilisateur. Les définitions fournissent les mots de passe utilisateur requis par Tivoli Workload Scheduler pour lancer des travaux. utilitaires : Ensemble d exécutables de ligne de commande permettant la gestion de Tivoli Workload Scheduler. vue Arborescence : Vue située dans la partie gauche de Job Scheduling Console et dans laquelle s affichent le serveur Tivoli Workload Scheduler, les groupes de listes par défaut et les groupes de listes créées par l utilisateur. X x-agent : Voir agent étendu. Tivoli Management Region (TMR) : Dans un environnement Tivoli, il s agit d un serveur Tivoli et de l ensemble des clients qu il sert. Une entreprise peut disposer de plusieurs TMR. Une TMR s occupe de la connectivité physique des ressources alors qu une région d administration s occupe de l organisation logique des ressources. travail : Unité de travail traitée sur un poste de travail. La définition du travail est constituée d un nom de travail unique de la base de données Tivoli Workload Scheduler ainsi que d autres informations nécessaires à l exécution du travail. Lorsque vous ajoutez un travail à un flux de travaux, vous pouvez définir ses dépendances et ses restrictions temporelles telles que l heure de début prévue et l échéance. travail externe : Travail d un flux de travaux donné correspondant au prédécesseur d un travail d un autre flux de travaux. Un travail externe est représenté par une icône de réserve dans la vue Graphe du flux de travaux. travail (flux de travaux) interréseau (INET) : Travail ou flux de travaux d un réseau Tivoli Workload Scheduler éloigné correspondant au prédécesseur d un travail ou d un flux de travaux du réseau local. Un travail interréseau est représenté par une icône de réserve dans la vue Graphe du flux de travaux. Voir aussi agent réseau. travail Jnextday : Travail planifié pour s exécuter à la fin de chaque journée afin d automatiser complètement le traitement à 136 Version 8.1

157 Index Caractères spéciaux /usr/unison/components 44 définition des options locales 73 définitions d utilisateur, sécurité 47 dumpsec 47 A activation de l audit 92 activation de la fonction de fuseau horaire 90 adresse électronique xvi audit activation 92 exemple d entrées de journal 97 fichiers journaux 92 format d en-tête 96 format de journal 92 niveau de base de données 69 niveau du plan 70 B base de données job.sched 44 bureau Tivoli 120 C carryforward 83 client JSconsole 6 commande console 81 commande de publications xv commande wmaeutil 92 commentaires sur les publications compiler 81, 84 connecteur TWS 5, 120 instances 121 cpuname 123 création du fichier de sécurité 47 D database audit level 69 date except 8 on 8 début 83, 127 début de la journée 70 définition des options globales 67 xvi E échéance 83, 127 états de pré-production 82 exemple d entrées de journal, audit 97 exemple de fichier de sécurité 58 expanded version 69, 129 F fenêtre Accès à une adresse 129 Créer un poste de travail 123 fichier de sécurité 124 fichier des composants 16 fichier des composants, affichage 17 fichier globalopts fonction d audit 92 fonction de fuseau horaire 90 fichier modèle, sécurité 47 final 81, 122 flux de travaux 7 fuseau horaire 120 option d activation 70 G gcomposer 120 gconman 120 gestion de la sécurité 47 gestionnaire de domaine principal 5 globalopts 122, 129 GlobalPreferences.ser 128 groupes de produits 16 H heure de début 70 Index Tivoli Workload Scheduler - Guide de planification et d installation 137

158 I invites de processus 80 invites et messages d écran 80 J Jnextday 81 Job Scheduling Console 120 L LD_NO_LIBSTREAMSOCKET 33 localopts 129 logman 81 M maestro 6.x 119 maître de secours 121 makesec 47, 127 messages de processus 80 montage NFS 122 mot clé AT 83 mot clé UNTIL 83 mozart 124 mozart.old 129 option jm look 75 option jm nice 75 option jm no root 75 option jm read 75 option merge stdlists 75 option mm read 75 option mm response 75 option mm retry link 76 option mm sound off 76 option mm unlink 76 option nm ipvalidate 76 option nm port 76 option nm read 76 option nm retry 76 option stdlist width 76 option syslog local 76 option thiscpu 77 option wr read 77 option wr unlink 77 options globales définition 67 exemple de fichier 70 modèle de fichier 70 pour agents MPE 72 syntaxe 67 options locales définition 73 exemple de fichier 77 modèle de fichier 77 syntaxe 73 options locales netman 79 ordre des objets, fichier de sécurité 57 ordre des utilisateurs, fichier de sécurité 57 oserv 119 N netman options locales 17 répertoire principal 17 niveau de message 81 nm mortal 76 noeud géré 119 nouvelles fonctions 89 P parameters 122 parameters.key 122 plan audit level 70 présentation de l installation 15 publications en ligne xv O option bm check file 74 option bm check status 74 option bm check until 74 option bm look 74 option bm read 74 option bm status 74 option bm verbose 74 option carryforward 68, 71 option history 69 option jm job table size 74 R régénération des connecteurs 92 région TMR 119 rep8 81 répartiteur d objets 119 reptr 81 résolution des dépendances 122 runmsgno Version 8.1

159 S scheddate 84 schedulr 81, 84 sécurité création du fichier de sécurité 47 définitions d utilisateur 48 dumpsec 47 fichier exemple 58 fichier modèle 47 gestion 47 makesec 47 ordre des définitions d utilisateur 57 ordre des objets 57 présentation 47 superutilisateur UNIX 58 syntaxe de fichier 48 variables 57 Service clientèle xvii Service clientèle Tivoli xvii setup_env 127 Sfinal 81 stageman 81 start 83 statut intégral 122 submit 120 superutilisateur UNIX, sécurité 58 support des fuseaux horaires 8 switchmgr 122 Symphony 120 syntaxe, fichier de sécurité 48 syslog 80 T timezone enable 124, 128 Tivoli Management Server 119 travail 7 V variables, fichier de sécurité 57 W wmaeutil 127 Index Tivoli Workload Scheduler - Guide de planification et d installation 139

160 140 Version 8.1

161

162 Numéro de programme : 5698-WKB SH