IBM Tivoli Workload Scheduler for Applications - Guide d...

IBM Tivoli Workload Scheduler for Applications

Guide d’utilisation

Version 8.2

SC11-2011-00

��

Important

Avant d’utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à la

section «Remarques» à la page 197.

Première édition - juillet 2003

Réf. US : SC32-1278-00

LE PRESENT DOCUMENT EST LIVRE ″EN L’ETAT″. IBM DECLINE TOUTE RESPONSABILITE, EXPRESSE OU

IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE

LES GARANTIES DE QUALITE MARCHANDE OU D’ADAPTATION A VOS BESOINS. Certaines juridictions

n’autorisent pas l’exclusion des garanties implicites, auquel cas l’exclusion ci-dessus ne vous sera pas applicable.

Remarque : Les captures d’écrans et les graphiques de cette brochure ne sont pas disponibles en français à la date

d’impression.

Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y

sont fournies sont susceptibles d’être modifiées avant que les produits décrits ne deviennent eux-mêmes

disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou

services non annoncés dans ce pays. Cela ne signifie cependant pas qu’ils y seront annoncés.

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 :

v http://www.fr.ibm.com (serveur IBM en France)

v http://www.can.ibm.com (serveur IBM au Canada)

v http://www.ibm.com (serveur IBM aux Etats-Unis)

Compagnie IBM France

Direction Qualité

Tour Descartes

92066 Paris-La Défense Cedex 50

© Copyright IBM France 2003. Tous droits réservés.

© Copyright International Business Machines Corporation 2002,2003. All rights reserved.

© Copyright International Business Machines Corporation 2000, 2003. All rights reserved.

http://www.fr.ibm.com

http://www.can.ibm.com

http://www.ibm.com

Table des matières

Avis aux lecteurs canadiens . . . . . vii

Avant-propos . . . . . . . . . . . . ix

A qui s’adresse ce manuel ? . . . . . . . . . ix

Que contient ce manuel ? . . . . . . . . . . ix

Publications . . . . . . . . . . . . . . xii

Publications concernant IBM Tivoli Workload

Scheduler . . . . . . . . . . . . . . xii

Publications concernant IBM Tivoli Workload

Scheduler pour z/OS . . . . . . . . . . xii

Kit de collecte des versions électroniques pour

IBM Tivoli Workload Scheduler for z/OS . . . xiii

Publications connexes . . . . . . . . . . xiv

Accès en ligne aux publications . . . . . . xiv

Commande de publications . . . . . . . . xiv

Commentaires sur les publications . . . . . xv

Accessibilité . . . . . . . . . . . . . . xv

Contact du service de support d’IBM . . . . . . xv

Conventions utilisées dans ce manuel . . . . . xv

Conventions typographiques . . . . . . . xv

Variables et chemins dépendants du système

d’exploitation . . . . . . . . . . . . xvi

Partie 1. Installation commune et

tâches de configuration . . . . . . . 1

Chapitre 1. Généralités sur le produit . . 3

Chapitre 2. Installation d’IBM Tivoli

Workload Scheduler for Applications . . 5

Procédures d’installation . . . . . . . . . . 6

Utilisation de l’assistant d’installation . . . . . 7

Utilisation de l’installation automatique . . . . 18

Utilisation de Tivoli Configuration Manager . . 21

Désinstallation du produit . . . . . . . . . 25

Suppression d’une installation via ISMP . . . . 25

Suppression d’une installation via Tivoli

Configuration Manager . . . . . . . . . 25

Suppression manuelle des éléments restants lors

du retrait de la méthode d’accès pour Oracle

e-Business Suite . . . . . . . . . . . . 26

Chapitre 3. Définition des options à

l’aide de l’Editeur d’options . . . . . . 27

Création d’un fichier d’options locales . . . . . 30

Héritage des valeurs des options . . . . . . . 30

Chapitre 4. Définition des postes de

travail d’agent étendu . . . . . . . . 31

Création d’un poste de travail avec Job Scheduling

Console . . . . . . . . . . . . . . . . 31

Création d’un poste de travail à partir de la ligne de

commande . . . . . . . . . . . . . . 33

Définition de postes de travail pour une

planification de bout en bout . . . . . . . . 34

Création de l’instruction CPUREC . . . . . . 34

Définition d’un poste de travail avec ISPF . . . 35

Chapitre 5. Définition des travaux

d’agent étendu . . . . . . . . . . . 37

Définition des travaux avec Job Scheduling Console 37

Définition des travaux à partir de la ligne de

commande Tivoli Workload Scheduler . . . . . 40

Définition des travaux pour une planification de

bout en bout . . . . . . . . . . . . . . 41

Partie 2. Méthode d’accès Oracle

e-Business Suite . . . . . . . . . 43

Chapitre 6. Introduction . . . . . . . 45

Fonctions . . . . . . . . . . . . . . . 45

Configuration logicielle requise . . . . . . . . 45

Tâches post-installation . . . . . . . . . . 45

Programmes d’interface . . . . . . . . . . 47

Chapitre 7. Informations sur la

définition des travaux . . . . . . . . 49

Définition des travaux dans Oracle Applications . . 49

Exécutions simultanées d’un même travail . . . 49

Définition des travaux Oracle Applications dans

Tivoli Workload Scheduler . . . . . . . . . 49

Paramètres de chaîne de tâches pour les travaux

Oracle Applications . . . . . . . . . . . 49

Etats des travaux Tivoli Workload Scheduler et

Oracle Applications . . . . . . . . . . . . 52

Chapitre 8. Informations de référence

sur le fichier d’options MCMAGENT . . 53

Fichier d’options . . . . . . . . . . . . . 53

Syntaxe des entrées . . . . . . . . . . . 53

Exemple . . . . . . . . . . . . . . 54

Chiffrage des mots de passe utilisateur Oracle

Applications . . . . . . . . . . . . . 54

Partie 3. Méthode d’accès

PeopleSoft . . . . . . . . . . . . 55


Fonctions . . . . . . . . . . . . . . . 57

Principes de fonctionnement . . . . . . . . . 57

Travaux du planificateur de traitements PeopleSoft 58

Suivi des travaux PeopleSoft dans Tivoli

Workload Scheduler . . . . . . . . . . 58

Sécurité . . . . . . . . . . . . . . . . 58

Remarques sur le support PeopleSoft Version 8.x . . 58

© Copyright IBM Corp. 2000, 2003 iii

Chapitre 10. Planification

d’implémentation . . . . . . . . . . 61

PeopleSoft version 7.5 ou antérieure . . . . . . 61

Configuration requise pour l’hôte . . . . . . 61

Configuration logicielle requise . . . . . . . 61

Configuration de l’utilisateur Windows . . . . 61

Vérification de l’environnement PeopleSoft . . . 62

Création d’un ID de traitement par lots dans

PeopleSoft . . . . . . . . . . . . . . 62

Fichiers installés . . . . . . . . . . . . 62

PeopleSoft version 8.x . . . . . . . . . . . 62

Configuration requise pour l’hôte . . . . . . 62


Création d’un ID de traitement par lots dans

PeopleSoft . . . . . . . . . . . . . . 63

Fichiers installés . . . . . . . . . . . . 63

Chapitre 11. Tâches post-installation 65

Configuration utilisateur pour Windows . . . . . 65

Création du fichier d’options . . . . . . . . 65

Modification manuelle des fichiers d’options . . 68

Connexion à plusieurs bases de données

PeopleSoft . . . . . . . . . . . . . . 69

Configuration d’un environnement PeopleSoft,

version 7.5 ou antérieure . . . . . . . . . . 69

Personnalisation du serveur de processus . . . 69

Configuration du client . . . . . . . . . 71

Exécution du script de l’outil Déplacement de

données . . . . . . . . . . . . . . 72

Configuration d’un environnement PeopleSoft

version 8.1x . . . . . . . . . . . . . . 74

Personnalisation du serveur d’applications . . . 74

Configuration du client . . . . . . . . . 75

Configuration d’un environnement PeopleSoft

version 8.4x . . . . . . . . . . . . . . 75


PeopleSoft . . . . . . . . . . . . . 77

Création de définitions de travaux PeopleSoft dans


Paramètres des chaînes de tâches des travaux

PeopleSoft . . . . . . . . . . . . . . 77

Configuration de dépendances OPENS 7.x

uniquement . . . . . . . . . . . . . . 78

Exemple de dépendances OPENS . . . . . . 80

Mappage de statut des travaux IBM Tivoli Workload

Scheduler et PeopleSoft . . . . . . . . . . 80

Partie 4. Méthode d’accès R/3 . . . 83


Champ d’application . . . . . . . . . . . 85

Processus de planification pour l’agent étendu R/3 85

Support d’interface XBP 2.0 . . . . . . . . . 86

Chapitre 14. Installation . . . . . . . 87

Configuration logicielle requise . . . . . . . . 87

Généralités sur l’installation . . . . . . . . 87

Installation sur des plateformes Tier2 . . . . . . 88

Chiffrement des mots de passe utilisateur R/3 . . 89

Chapitre 15. Configuration de

l’environnement R/3 . . . . . . . . . 91

Présentation . . . . . . . . . . . . . . 91

Création de l’utilisateur RFC pour IBM Tivoli

Workload Scheduler . . . . . . . . . . . 91

Création du profil d’autorisation pour l’utilisateur


Utilisation de la transaction SU02 pour la

création manuelle du profil . . . . . . . . 92

Utilisation de la transaction PFCG (Générateur de

profils) . . . . . . . . . . . . . . . 92

Copie des fichiers de correction et de transfert . . . 94

Importation de modules ABAP/4 dans R/3 . . . 94

Installation des modules ABAP r3batch sur le

système R/3 . . . . . . . . . . . . . . 95

Identification et résolution des incidents . . . . . 96

Modification du mot de passe de l’ID

utilisateur RFC au niveau de Tivoli Workload

Scheduler . . . . . . . . . . . . . . . 97

Migration à partir de versions précédentes . . . . 97

Utilisation du support d’interface XBP 2.0 . . . . 98

Création du profil d’autorisation pour

l’utilisateur Tivoli Workload Scheduler . . . . 99

Incidents dus aux paramètres d’impression et à la

classe de travail . . . . . . . . . . . . . 99


d’agent étendu R/3 . . . . . . . . . 101

Définition d’un travail dans R/3 . . . . . . . 101

Définition d’un travail dans Tivoli Workload

Scheduler . . . . . . . . . . . . . . . 101

Utilisation des fenêtres SAP de Job Scheduling

Console . . . . . . . . . . . . . . 102

Paramètres de chaîne de tâches pour les

travaux R/3 . . . . . . . . . . . . . 109

Etats des travaux dans Tivoli Workload Scheduler

et dans R/3 . . . . . . . . . . . . . . 111

Chapitre 17. Réexécution de travaux 113

Ancienne et nouvelle copies d’un travail à

réexécuter . . . . . . . . . . . . . . 113

Chapitre 18. Business Information

Warehouse . . . . . . . . . . . . 115

Prise en charge de Business Information

Warehouse - InfoPackages . . . . . . . . . 115

Autorisations utilisateur . . . . . . . . . 115

Composants Business Information Warehouse . . 115

Définition des travaux d’agent étendu pour BIW 116

Options de planification R/3 d’un InfoPackage . . 116

Chapitre 19. Connexion au

système R/3 . . . . . . . . . . . . 117

Connexions à un serveur d’applications spécifique 117

Groupes de connexion . . . . . . . . . . 118

iv IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

Chapitre 20. Fichiers d’options de la

méthode d’accès R/3 . . . . . . . . 119

Options de configuration . . . . . . . . . 119

Options globales . . . . . . . . . . . 119

Options locales . . . . . . . . . . . . 120

Options générales . . . . . . . . . . . 121

Utilisation des options de configuration . . . . 123

Migration des fichiers de configuration . . . . . 124

Chapitre 21. Attente BDC . . . . . . 127

Utilisation des noms de session BDC . . . . . 127

Utilisation des ID de file d’attente BDC avec le

rapport BDCRECXX . . . . . . . . . . . 128

Utilisation des ID de file d’attente BDC avec le

module fonctionnel BDC_OPEN_GROUP . . . . 129

Chapitre 22. Fonctions d’interception

des travaux et fonctions parent-enfant 131

Interception des travaux . . . . . . . . . . 131

Implémentation de l’interception de travaux . . 131

La fonction parent-enfant . . . . . . . . . 134

Chapitre 23. Support de la langue

nationale . . . . . . . . . . . . . 137

Options de support de la langue nationale . . . 137

Pages de codes R/3 prises en charge . . . . . 138

Configurations prises en charge et limites . . . . 138

Partie 5. Méthode d’accès z/OS 139

Chapitre 24. Introduction . . . . . . 141

Fonctions . . . . . . . . . . . . . . . 141


Présentation de l’installation . . . . . . . . 141

Installation sur des plateformes de niveau 2 . . 142

Installation sous z/OS . . . . . . . . . 142

Définition des autorisations sous z/OS . . . . 144

Remarques supplémentaires . . . . . . . 144

Version de la passerelle z/OS . . . . . . . 149

Chapitre 25. Configuration et

fonctionnement . . . . . . . . . . 151

Fichiers d’options de méthode . . . . . . . . 151

Fichiers d’options de méthodes sur les

plateformes de niveau 2 . . . . . . . . . 151

Définition de travaux dans z/OS . . . . . . . 152

Définition de travaux z/OS dans Tivoli Workload

Scheduler . . . . . . . . . . . . . . . 153

Syntaxe de définition de tâche pour les travaux

z/OS planifiés avec Tivoli Workload Scheduler . 153

Syntaxe de définition de tâche pour les travaux

z/OS . . . . . . . . . . . . . . . 155

Syntaxe des dépendances de fichier (OPENS)

sur les fichiers z/OS . . . . . . . . . . 156

Chapitre 26. Informations de référence 159

Présentation technique . . . . . . . . . . 159

Fonctionnement sous JES . . . . . . . . 159

Fonctionnement avec CA-7 . . . . . . . . 160

Autres conseils pour CA-7 . . . . . . . . 161

Fonctionnement avec l’interface OPC ou avec

Tivoli Workload Scheduler pour z/OS . . . . 162

Vérification des fichiers sur z/OS . . . . . 163

Considérations de délais . . . . . . . . . 163

Informations relatives au diagnostic . . . . . . 164

Messages de la passerelle . . . . . . . . . 164

Partie 6. Maintenabilité commune 169

Chapitre 27. Référence aux agents

étendus . . . . . . . . . . . . . . 171

Que sont les agents étendus ? . . . . . . . . 171

Définition de poste de travail . . . . . . . 171

Interface de méthode d’accès . . . . . . . . 171

Syntaxe de la ligne de commande de la

méthode . . . . . . . . . . . . . . 171

Messages de réponse de méthode . . . . . 174

Fichier d’options de méthode . . . . . . . 175

Exécution de méthode . . . . . . . . . . 175

Tâche de lancement d’un travail (LJ) . . . . 176

Tâche de gestion du travail (MJ) . . . . . . 176

Tâche de vérification d’un fichier (CF) . . . . 177

Tâche d’obtention d’un état (GS) . . . . . . 177

La commande cpuinfo . . . . . . . . . 178

Identification et résolution des incidents . . . . 178

Messages d’erreur de la liste standard d’un

travail . . . . . . . . . . . . . . . 178

Méthode non exécutable . . . . . . . . . 179

Messages du gestionnaire de consoles . . . . 179

Messages du programme Composer et Compiler 179

Messages de Jobman . . . . . . . . . . 179

Chapitre 28. Bibliothèque de mappage

de code retour . . . . . . . . . . . 181

Fichier de mappage du code retour . . . . . . 181 181 181 182 182

Mappage du code retour pour Psagent et

MCMAGENT . . . . . . . . . . . . 182

Noms de fichier de mappage de code retour 186

Chapitre 29. Configuration de

l’utilitaire de trace . . . . . . . . . 187

Chapitre 30. Identification et

résolution des incidents . . . . . . . 189

Identification des incidents lors de l’installation de

la méthode d’accès PeopleSoft . . . . . . . . 190

Chapitre 31. Fichiers installés . . . . 191

Partie 7. Annexes . . . . . . . . . 195

Remarques . . . . . . . . . . . . 197

Marques . . . . . . . . . . . . . . . 199

Glossaire . . . . . . . . . . . . . 201

Table des matières v

Index . . . . . . . . . . . . . . . 207

vi IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

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

ingénieur commercial représentant

agence commerciale succursale

ingénieur technico-commercial informaticien

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

v les pages de codes 850 (multilingue) et 863 (français-canadien),

v le code pays 002,

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

© Copyright IBM Corp. 2000, 2003 vii

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 1 800 465-1234.

viii IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

Avant-propos

Le manuel IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

explique comment installer, configurer et utiliser les méthodes d’accès à

l’application IBM Tivoli Workload Scheduler qui exécutent et gèrent les travaux

des applications suivantes :

v Oracle e-Business Suite

v PeopleSoft

v R/3

v z/OS

Ce guide aborde le contenu des manuels ci-dessous :

v IBM Tivoli Workload Scheduler for Applications Version 8.1.1 - Guide d’utilisation pour

Oracle e-Business Suite


PeopleSoft


R/3


z/OS

A qui s’adresse ce manuel ?

Ce manuel est destiné aux planificateurs de travaux qui souhaitent exécuter et

gérer les travaux des applications citées plus haut à l’aide d’IBM Tivoli Workload

Scheduler. Les lecteurs doivent posséder des connaissances sur :

v IBM Tivoli Workload Scheduler

v Tivoli Job Scheduling Console

v L’environnement propre à l’application

Que contient ce manuel ?

Ce manuel comprend les sections suivantes :

1ère partie - Installation commune et tâches de configuration

La partie 1 comprend les chapitres suivants :

v Chapitre 1, «Généralités sur le produit», à la page 3

Ce chapitre décrit le fonctionnement de base d’un agent étendu.

v Chapitre 2, «Installation d’IBM Tivoli Workload Scheduler for Applications», à la

page 5

Ce chapitre explique les différentes manières d’installer et de désinstaller le

produit, ainsi que les plateformes prises en charge et les composants prérequis.

v Chapitre 3, «Définition des options à l’aide de l’Editeur d’options», à la page 27

Ce chapitre explique comment utiliser l’éditeur d’options.

v Chapitre 4, «Définition des postes de travail d’agent étendu», à la page 31

Ce chapitre présente la manière de définir les postes de travail d’agent étendu

pour toutes les méthodes d’accès.

© Copyright IBM Corp. 2000, 2003 ix

v Chapitre 5, «Définition des travaux d’agent étendu», à la page 37

Ce chapitre explique comment définir des travaux d’agent étendu pour toutes

les méthodes d’accès.

2ème partie - Méthode d’accès Oracle e-Business Suite


v Chapitre 6, «Introduction», à la page 45

Ce chapitre décrit les fonctions, la configuration requise pour le logiciel, les

tâches post-installation et le logiciel d’interface spécifiques de la méthode d’accès

à Oracle e-Business Suite.

v Chapitre 7, «Informations sur la définition des travaux», à la page 49

Ce chapitre fournit des informations pour la définition des travaux de Tivoli

Workload Scheduler spécialement pour cette méthode d’accès.

v Chapitre 8, «Informations de référence sur le fichier d’options MCMAGENT», à

la page 53

Ce chapitre décrit les options utilisées par cette méthode d’accès.

3ème partie - Méthode d’accès PeopleSoft



Ce chapitre décrit les fonctions, les fonctionnalités et d’autres informations

générales relatives à la méthode d’accès PeopleSoft.

v Chapitre 10, «Planification d’implémentation», à la page 61

Ce chapitre présente la configuration requise pour l’hôte et le logiciel ainsi que

des informations relatives aux différentes versions de PeopleSoft prises en

charge par cette méthode d’accès.

v Chapitre 11, «Tâches post-installation», à la page 65

Ce chapitre présente les tâches post-installation pour cette méthode d’accès.

v Chapitre 12, «Définition des travaux PeopleSoft», à la page 77

Ce chapitre fournit des informations sur la définition des travaux de Tivoli

Workload Scheduler spécialement pour cette méthode d’accès.

4ème partie - Méthode d’accès R/3



Ce chapitre décrit les fonctions de la méthode d’accès à R/3.

v Chapitre 14, «Installation», à la page 87

Ce chapitre fournit des informations concernant l’installation de cette méthode

d’accès et explique comment installer les plateformes de niveau 2.

v Chapitre 15, «Configuration de l’environnement R/3», à la page 91

Ce chapitre explique comment configurer cette méthode d’accès pour qu’elle soit

utilisée avec R/3.

v Chapitre 16, «Définition des travaux d’agent étendu R/3», à la page 101

Ce chapitre fournit les informations sur la définition des travaux de Tivoli

Workload Scheduler spécialement pour la méthode d’accès à R/3.

v Chapitre 17, «Réexécution de travaux», à la page 113

Ce chapitre explique le mécanisme de réexécution des travaux.

x IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

v Chapitre 18, «Business Information Warehouse», à la page 115

Ce chapitre fournit des informations sur la manière d’utiliser la méthode d’accès

avec l’entrepôt de données métier R/3.

v Chapitre 19, «Connexion au système R/3», à la page 117

Ce chapitre décrit les connexions et les groupes de connexion R/3.

v Chapitre 20, «Fichiers d’options de la méthode d’accès R/3», à la page 119

Ce chapitre décrit les options utilisées par cette méthode d’accès.

v Chapitre 21, «Attente BDC», à la page 127

Ce chapitre fournit des informations détaillées sur l’attente BDC.

v Chapitre 22, «Fonctions d’interception des travaux et fonctions parent-enfant», à

la page 131

Ce chapitre décrit les fonctions parent-enfant et les fonctions d’interception de

travaux de XBP 2.0.

v Chapitre 23, «Support de la langue nationale», à la page 137

Ce chapitre décrit le support de la langue nationale pour cette méthode d’accès.

5ème partie - Méthode d’accès z/OS



Ce chapitre répertorie les fonctions de la méthode d’accès à z/OS, explique

comment installer l’environnement réparti sur les plateformes de niveau 2 et

comment installer le composant passerelle sur z/OS.

v Chapitre 25, «Configuration et fonctionnement», à la page 151

Ce chapitre présente les options de cette méthode d’accès et fournit des

informations concernant la définition des travaux pour cette méthode.

v Chapitre 26, «Informations de référence», à la page 159

Ce chapitre fournit des informations de référence à destination des planificateurs

de travaux autorisés et répertorie les messages relatifs à la passerelle.

6ème partie - Maintenabilité commune


v Chapitre 27, «Référence aux agents étendus», à la page 171

Ce chapitre fournit des informations de référence pour le développement d’une

méthode d’accès Tivoli Workload Scheduler.

v Chapitre 28, «Bibliothèque de mappage de code retour», à la page 181

Ce chapitre explique comment utiliser l’utilitaire de mappage de code retour.

v Chapitre 29, «Configuration de l’utilitaire de trace», à la page 187

Ce chapitre explique comment configurer l’utilitaire de trace.

v Chapitre 30, «Identification et résolution des incidents», à la page 189

Ce chapitre fournit des informations générales sur l’identification des incidents.

v Chapitre 31, «Fichiers installés», à la page 191

Ce chapitre répertorie les fichiers installés en fonction de la plateforme et de la

fonction.

Avant-propos xi

Publications

Cette section répertorie les publications dans la bibliothèque IBM Tivoli Workload

Scheduler et explique comment accéder en ligne aux publications Tivoli, comment

les commander et transmettre vos commentaires.

Publications concernant IBM Tivoli Workload Scheduler

Cette section répertorie les publications présentes dans la bibliothèque de IBM

Tivoli Workload Scheduler et dans les documents qui s’y rapportent. Elle explique

aussi comment accéder aux publications Tivoli en ligne et comment les

commander.

v IBM Tivoli Workload Scheduler - Guide de planification et d’installation, SC11-2008

Décrit comment planifier un réseau Tivoli Workload Scheduler et comment

installer et personnaliser Tivoli Workload Scheduler ainsi que le logiciel qui lui

est associé.

v IBM Tivoli Workload Scheduler - Guide de référence, SC11-2009

Explique la ligne de commande de Tivoli Workload Scheduler, le fonctionnement

des agents étendus et des agents de réseau et l’intégration de Tivoli Workload

Scheduler dans NetView et dans Tivoli Business Systems Manager.

v IBM Tivoli Workload Scheduler Troubleshooting and Error Messages, SC32-1275

Interprète les messages d’erreur de Tivoli Workload Scheduler et fournit des

sources d’information pour vous aider à résoudre les problèmes relatifs à cette

application.

v IBM Tivoli Workload Scheduler Job Scheduling Console - Notes d’édition, SC11-2007

Fournit des informations sur la manière de travailler avec Tivoli Workload

Scheduler à partir d’une interface graphique commune, quelle que soit la

plateforme utilisée.

v IBM Tivoli Workload Scheduler Job Scheduling Console - Guide d’utilisation,

SC11-2006

Fournit des informations sur la manière de travailler avec Tivoli Workload

Scheduler à partir d’une interface graphique commune, quelle que soit la

plateforme utilisée.

v IBM Tivoli Workload Scheduler for Applications Release Notes, SC32-1279

Fournit les informations à jour sur les agents étendus de Tivoli Workload

Scheduler.

v IBM Tivoli Workload Scheduler AS/400 Limited Fault-tolerant Agent User’s Guide,

SC32-1280

Décrit l’installation, la configuration et l’utilisation sur l’AS/400 des agents de

Tivoli Workload Scheduler tolérants aux pannes.

v IBM Tivoli Workload Scheduler - Guide de l’utilisateur du module Plus, SC11-2010

Explique comment configurer et utiliser le module Plus de Tivoli Workload

Scheduler.

v IBM Tivoli Workload Scheduler Release Notes, SC32-1277

Explique les informations à jour sur Tivoli Workload Scheduler.

Publications concernant IBM Tivoli Workload Scheduler pour

z/OS

Les documents ci-dessous sont disponibles dans la bibliothèque d’IBM Tivoli

Workload Scheduler pour z/OS :

v IBM Tivoli Workload Scheduler pour z/OS Customization and Tuning, SC32-1265

xii IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

Explique comment personnaliser Tivoli Workload Scheduler pour z/OS.

v IBM Tivoli Workload Scheduler pour z/OS Diagnosis Guide and Reference, SC32-1261

Fournit des informations d’aide au diagnostic et à la correction des incidents lors

de l’utilisation du produit.

v IBM Tivoli Workload Scheduler pour z/OS - Informations générales, SC11-2005

Présente les avantages de la suite complète Tivoli Workload Scheduler.

v IBM Tivoli Workload Scheduler pour z/OS Getting Started, SC32-1262

Décrit les concepts et la terminologie d’IBM Tivoli Workload Scheduler for z/OS

et donne des instructions pour vous permettre de travailler avec le produit le

plus rapidement possible.

v IBM Tivoli Workload Scheduler pour z/OS Installation Guide, SC32-1264

Explique comment installer Tivoli Workload Scheduler pour z/OS.

v IBM Tivoli Workload Scheduler pour z/OS Licensed Program Specifications, GI11-4208

Fournit des informations sur la planification concernant Tivoli Workload

Scheduler pour z/OS.

v IBM Tivoli Workload Scheduler pour z/OS Managing the Workload, SC32-1263

Explique comment planifier la charge de travail et comment contrôler et

surveiller le plan actuel.

v IBM Tivoli Workload Scheduler pour z/OS Memo to Users, GI11-4209

Fournit un résumé des modifications pour l’édition actuelle du produit.

v IBM Tivoli Workload Scheduler pour z/OS Messages and Codes, SC32-1267

Explique les messages et les codes.

v IBM Tivoli Workload Scheduler pour z/OS Program Directory, GI11-4203

Fourni par la bande d’installation de Tivoli Workload Scheduler pour z/OS, il

décrit tous les supports d’installation et donne des instructions d’installation

correspondant au niveau d’édition du produit et au numéro de la fonction.

v IBM Tivoli Workload Scheduler pour z/OS Programming Interfaces, SC32-1266

Fournit les informations permettant d’écrire les programmes de l’application.

v IBM Tivoli Workload Scheduler pour z/OS Quick Reference, SC32-1268

Fournit un moyen de référence facile et rapide pour consulter comment

fonctionne le produit.

Kit de collecte des versions électroniques pour IBM Tivoli

Workload Scheduler for z/OS

Tous les manuels de la bibliothèque, à l’exception des publications sous licence,

peuvent être affichés via leur version électronique dans les kits de collecte

suivants :

v IBM Online Library Omnibus Edition OS/390 Collection Kit, SK2T-6700.

v IBM Online Library z/OS Software Products Collection Kit, SK2T-4270.

Vous pouvez la version électronique des manuels sur CD-ROM à l’aide de ces

logiciels IBM sous licence :

v Softcopy Reader

v BookManager READ/2

v BookManager READ/DOS

v BookManager READ/6000

Tous les logiciels de type BookManager requièrent un ordinateur équipé d’un

lecteur de CD-ROM (capable de lire des CD-ROM de norme ISO 9660), ainsi qu’un

Avant-propos xiii

adaptateur et un câble correspondants. Pour plus d’informations concernant les

matériels et les logiciels requis, reportez-vous à la documentation concernant le

produit BookManager spécifique que vous utilisez.

Les mises à jour des manuels intervenant entre deux éditions sont uniquement

fournies sous forme de copie électronique.

Publications connexes

Le glossaire des logiciels Tivoli (Tivoli Software Glossary) comprend les définitions

de nombreux termes techniques relatifs aux logiciels Tivoli. Il est disponible à

l’adresse suivante (en anglais uniquement) :

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

Accès en ligne aux publications

Le CD de documentation contient les publications présentes dans la bibliothèque

du produit. Le format des publications est PDF, HTML ou les deux. Pour accéder

aux publications à l’aide d’un navigateur Web, ouvrez le fichier infocenter.html,

qui se trouve dans le répertoire des publications approprié sur le CD du produit.

IBM crée des publications pour tous les nouveaux produits Tivoli et à chaque

nouvelle mise à jour, et les met à disposition sur le site Web Tivoli Software

Information Center. Le Tivoli Software Information Center est situé à l’adresse

suivante :

http://publib.boulder.ibm.com/tividd/td/tdprodlist.html

Cliquez sur le lien Tivoli Workload Scheduler pour accéder à la bibliothèque de

produits.

Remarque : Si vous imprimez des documents PDF sur un format autre que le

papier à lettre, cochez la case Ajuster à la page dans la fenêtre

Imprimer d’Adobe Acrobat. Cette option est disponible lorsque vous

cliquez sur Fichier → Imprimer. L’option Ajuster à la page garantit

que les dimensions d’une page au format lettre s’impriment sur le

format de papier que vous utilisez.

Commande de publications

Vous pouvez commander en ligne un grand nombre de publications Tivoli sur le

site Web suivant :

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

Vous pouvez aussi passer votre commande par téléphone en appelant l’un des

numéros suivants :

v Aux Etats-Unis : (1)800-879-2755

v Au Canada : (1)800-426-4968

Pour les autres pays, consultez la liste des numéros de téléphone sur le site Web

ci-dessous :

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

xiv IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

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

http://publib.boulder.ibm.com/tividd/td/tdprodlist.html

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

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

Commentaires sur les publications

Si vous avez des commentaires ou des suggestions concernant les produits Tivoli et

leur documentation, répondez à l’étude client disponible sur le site Web à

l’adresse :

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

Accessibilité

Les fonctions d’accessibilité permettent aux utilisateurs possédant un handicap

physique, tel qu’une mobilité réduite ou une vision à champ limité, d’utiliser les

produits logiciels de manière efficace. Grâce à ce produit, vous pouvez utiliser les

technologies d’assistance pour naviguer dans l’interface. Vous pouvez également

utiliser le clavier de préférence à la souris pour exécuter toutes les fonctions de

l’interface graphique.

Pour plus d’informations, consultez l’annexe relative à l’accessibilité dans le

manuel IBM Tivoli Workload Scheduler Job Scheduling Console - Guide d’utilisation.

Contact du service de support d’IBM

Si vous rencontrez un problème avec un produit Tivoli, vous pouvez contacter le

service de support d’IBM. Consultez le IBM Software Support Guide sur le site Web

suivant :

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

Ce guide vous indique comment contacter le service de support d’IBM, en fonction

de la gravité du problème et vous fournit les informations suivantes :

v Inscription et validité

v Les numéros de téléphone et les adresses de courrier électronique, en fonction

du pays où vous vous trouvez

v Les informations que vous devez avoir à votre portée avant de contacter le

service de support d’IBM

Conventions utilisées dans ce manuel

Ce manuel utilise plusieurs conventions concernant les actions et les termes

spécifiques, ainsi que les chemins et les commandes spécifiques du système

d’exploitation.

Conventions typographiques

Ce manuel utilise les conventions typographiques suivantes :

Gras

v Commandes en minuscules et utilisation de caractères

majuscules et minuscules (sauf ceux qui sont tous en lettres

majuscules) dont la distinction s’avérerait par ailleurs difficile à

partir du contexte

v Contrôles de l’interface (cases à cocher, boutons de fonction,

boutons radio, sélecteurs rotatifs, zones, dossiers, icônes, boîtes à

liste, éléments compris dans les boîtes à liste, listes

multi-colonnes, conteneurs, options de menu, noms de menu,

Avant-propos xv

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

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

onglets, feuilles de propriétés), libellés (tels que Conseil : et

Considérations du système d’exploitation :)

v En-têtes de colonnes dans un tableau

v Mots clés et paramètres dans le texte

Les commandes (sauf celles qui apparaissent en lettres majuscules)

sont affichées en caractères gras.

Italique

v Citations (titres de manuels, disquettes et CD)

v Mots définis dans le texte

v Mise en évidence des mots (mots en tant que tels)

v Lettres en tant que telles

v Nouveaux termes dans le texte (sauf dans une liste de définition)

v Variables et valeurs à fournir

Espacement fixe

v Exemples, exemples de code et résultat

v Noms de fichier, mots clés de programmation et autres éléments

difficiles à distinguer en contexte

v Texte et invites de messages destinés à l’utilisateur

v Texte que l’utilisateur doit entrer

v Valeurs pour les arguments ou les options de commande

Les exemples de code, les résultats, le texte que vous devez entrer

et les messages système sont affichés en police en espacement

fixe.

Barres de révision

Les modifications d’ordre technique apportées au texte sont

indiquées par une ligne verticale située à gauche de la

modification.

Variables et chemins dépendants du système d’exploitation

Ce manuel utilise la convention UNIX pour spécifier les variables d’environnement

et pour la notation des répertoires.

Lorsque vous utilisez la ligne de commande de Windows, remplacez $variable par

% variable% pour les variables d’environnement, et remplacez chaque barre oblique

(/) par une barre oblique inversée ( \) dans les chemins des répertoires.

Remarque : Si vous utilisez le shell bash sur un système Windows, vous pouvez

utiliser les conventions UNIX.

xvi IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

Partie 1. Installation commune et tâches de configuration

© Copyright IBM Corp. 2000, 2003 1

2 IBM Tivoli Workload Scheduler for Applications - Guide d’utilisation

Chapitre 1. Généralités sur le produit

Les agents étendus (XA) permettent d’étendre les fonctions de planification de

travaux de IBM Tivoli Workload Scheduler à d’autres systèmes et applications. Un

agent étendu est un poste de travail disposant d’un hôte et d’une méthode d’accès.

L’hôte est un agent tolérant aux pannes (FTA) ou un agent standard (SA) de Tivoli

Workload Scheduler.

La méthode d’accès est un programme exécuté par le poste de travail hébergeant

lorsque Tivoli Workload Scheduler doit interagir avec le système externe, via sa

ligne de commande ou via Tivoli Job Scheduling Console. Tivoli Workload

Scheduler for Applications inclut les méthodes d’accès suivantes :

v méthode d’accès pour Oracle e-Business Suite (MCMAGENT),

v méthode d’accès pour PeopleSoft (psagent),

v méthode d’accès pour R/3 (r3batch),

v méthode d’accès pour z/OS (mvsca7, mvsjes et mvsopc).

Pour lancer et contrôler un travail sur un agent étendu, l’hôte exécute la méthode

d’accès en transmettant les informations relatives au travail sous la forme d’options

de ligne de commande. La méthode d’accès communique avec le système externe

pour lancer le travail et renvoie le statut de ce travail.

Un poste de travail d’agent étendu n’est qu’une entité logique associée à une

méthode d’accès hébergée par le poste de travail physique Tivoli Workload

Scheduler. Plusieurs postes de travail d’agent étendu peuvent être hébergés par le

même poste de travail Tivoli Workload Scheduler et utiliser la même méthode

d’accès. L’agent étendu (ou x-agent) est défini dans le cadre d’une définition de

poste de travail Tivoli Workload Scheduler standard, laquelle attribue un nom à

l’agent étendu et identifie la méthode d’accès.

Le schéma ci-après illustre comment ces éléments interagissent dans le cas d’une

configuration type d’agent étendu.


Pour lancer un travail dans un environnement externe, Tivoli Workload Scheduler

exécute la méthode d’accès associée à l’agent étendu et fournit à cette dernière le

nom du poste de travail d’agent étendu ainsi que les informations relatives au

travail. La méthode analyse le fichier correspondant, nommé

<NOM_POSTE_DE_TRAVAIL>_ <nom_méthode>.opts, pour déterminer l’instance

d’environnement externe à laquelle elle se connectera. La méthode d’accès peut

alors lancer des travaux sur cette instance et les contrôler tout au long de leur

exécution en écrivant la progression du travail et les informations d’état dans le

fichier stdlist du travail.

Les agents étendus peuvent également être utilisés pour exécuter des travaux dans

un environnement semi-fermé, où la planification et le contrôle des travaux

s’effectuent à partir d’un contrôleur IBM Tivoli Workload Scheduler pour z/OS.

Figure 1. Fonctionnement des agents étendus.


Chapitre 2. Installation d’IBM Tivoli Workload Scheduler for

Applications

Sur la plupart des plateformes prises en charge, toutes les méthodes d’accès d’IBM

Tivoli Workload Scheduler for Applications décrites dans ce guide sont installées

via un processus d’installation commun. Ce processus permet d’installer une

instance de Tivoli Workload Scheduler for Applications (où une instance

correspond à l’association d’au moins une méthode d’accès à une installation

existante de Tivoli Workload Scheduler) et de sélectionner une ou plusieurs

méthodes d’accès à partir des composants d’installation.

Le processus d’installation commun est disponible pour les plateformes suivantes,

lorsque celles-ci sont prises en charge par une méthode d’accès :

v Microsoft Windows NT ou 2000,

v IBM AIX,

v HP-UX,

v Environnement d’exploitation Sun,

v Linux pour Intel,

v Linux/390.

Pour les plateformes suivantes, le processus d’installation reste identique à celui

décrit dans la documentation des différentes méthodes, dans les chapitres

suivants :

v Compaq Tru64

v SGI Irix

v IBM Sequent Dynix

Le tableau ci-dessous répertorie les plateformes prises en charge par cette version

d’IBM Tivoli Workload Scheduler for Applications :

Tableau 1. Plateformes prises en charge

Méthode d’accès

Plateforme z/OS

(passerelle)

z/OS

(serveur de transactions)

R/3 PeopleSoft Oracle eBusiness

Suite

IBM OS/390 V2R10

et supérieures

X

IBM z/OS V1R1 et

supérieures

X

IBM AIX Versions

4.3.3, 5.1, 5.2

X X X

IBM Sequent Dynix

Version 4.5.1

X

Environnement

d’exploitation Solaris

Versions 7, 8, 9

X X X

Hewlett Packard

PA-RISC Versions

11.0, 11i

X X X


Tableau 1. Plateformes prises en charge (suite)

Méthode d’accès

Plateforme z/OS

(passerelle)

z/OS

(serveur de transactions)

R/3 PeopleSoft Oracle eBusiness

Suite

SuSE Linux

Enterprise Server

Version 7 pour

OS/390 et zSeries

(noyau 2.4)

X X

RedHat Linux pour

OS/390 et zSeries

Version 7

X X

RedHat Linux (Intel)

Versions 7.2, 7.3

X

SuSE Linux (Intel)

Enterprise Server

Version 8

X

Microsoft

Windows NT

Version 4.0 avec

Service Pack 6a

X X X

Microsoft

Windows 2000 avec

Service Pack 3

Professional, Server,

Advanced

X X X

Compaq Tru64

Version 5.1

X X

SGI Irix Version 6.5.x X

Procédures d’installation

Vous avez le choix entre trois méthodes pour installer Tivoli Workload Scheduler

for Applications :

v Utiliser l’assistant InstallShield Multi-Platform (ISMP),

v Exécuter l’option d’installation automatique d’InstallShield,

v Utiliser le composant Software Distribution de Tivoli Configuration Manager.

Avant d’installer le produit à l’aide de l’une des procédures susmentionnées,

vérifiez que vous remplissez les conditions suivantes :

v Vous devez avoir une installation valide d’IBM Tivoli Workload Scheduler,

Version 7.0 ou supérieure, sur votre ordinateur avant d’installer l’une des

méthodes d’accès.

v Vous devez disposer de droits Root (sous Unix) ou Administrateur (sous

Windows) pour exécuter l’installation.

v Vous devez arrêter tous les services Tivoli Workload Scheduler avant de

démarrer le processus d’installation.

v Dans le cas de la méthode d’accès destinée à PeopleSoft, l’installation de cette

dernière requiert que le ou les environnements PeopleSoft correspondants soient

déjà installés et entièrement accessibles à partir du poste de travail où vous

effectuez l’installation.


v Dans le cas de la méthode d’accès pour Oracle eBusiness Suite, le serveur Oracle

e-Business Suite doit être situé sur le même noeud physique que la méthode

d’accès et l’hôte Tivoli Workload Scheduler.

v Vérifiez que le processus d’installation n’a pas déjà été lancé sur le poste de

travail. Ce scénario peut se produire sur un réseau où plusieurs connexions

Telnet ont été ouvertes sur une même station Unix par des utilisateurs autorisés

à commander à distance l’installation d’une méthode d’accès. Lancez la

commande suivante pour déterminer si le processus d’installation est déjà actif

sur l’ordinateur où vous voulez procéder à l’installation :

ps -ef | grep setup.bin

De même, si votre poste de travail exécute plusieurs instances de Tivoli

Workload Scheduler, veillez à ne pas exécuter le processus d’installation sur plus

d’une instance à la fois.

v Avant d’installer des instances supplémentaires du produit ou de mettre à jour

des instances existantes, vérifiez que l’Editeur d’options n’est pas en cours

d’exécution, sinon l’installation pourrait échouer.

Reportez-vous au Chapitre 31, «Fichiers installés», à la page 191 pour consulter la

liste des fichiers que vous devriez trouver sur votre ordinateur à l’issue de

l’installation.

Utilisation de l’assistant d’installation

Pour utiliser l’assistant d’installation ISMP sur votre ordinateur, votre système

d’exploitation doit pouvoir exécuter l’environnement d’exécution Java (JRE)

Version 1.3.1. Certaines plateformes requièrent des niveaux de maintenance pour

prendre en charge JRE 1.3.1. Reportez-vous au tableau ci-dessous pour savoir si

votre système d’exploitation doit (ou non) être mis à jour. Aucun correctif

supplémentaire n’est requis pour les plateformes prises en charge, non

mentionnées dans ce tableau.

Chapitre 2. Installation d’IBM Tivoli Workload Scheduler for Applications 7

Tableau 2. Correctifs requis pour exécuter JRE 1.3.1

Système d’exploitation Correctif requis pour exécuter JRE 1.3.1

IBM AIX Version 4.3.3 Niveau de maintenance recommandé AIX 4330–10.

IBM AIX Version 5.1 Niveau de maintenance recommandé AIX 5100–02. Ce

niveau de maintenance requiert que le correctif

APAR IY19375 ait été précédemment appliqué et validé.

Si vous utilisez l’un des paramètres locaux CKJ non-UTF8

pris en charge, vous devez disposer de l’un des ensembles

de fichiers suivants (disponibles sur le CD d’AIX 5.1

base) :

v X11.fnt.ucs.ttf (pour ja_JP ou Ja_JP)

v X11.fnt.ucs.ttf_CN (pour zh_CN ou Zh_CN)

v X11.fnt.ucs.ttf_KR (pour ko_KR)

v X11.fnt.ucs.ttf_TW (pour zh_TW ou Zh_TW)

Pour les utilisateurs japonais : si vous utilisez la méthode

d’entrée propre au japonais, vous pouvez appliquer les

PTF suivants pour éviter certains incidents liés à la

méthode d’entrée :

v jkit.Wnn6.base 2.2.0.2 (PTF U479697 ou APAR IY22917)

(uniquement utilisateur de Wnn6),

v X11.motif.lib 5.1.0.15 (PTF U479604 ou APAR IY22933)

(uniquement utilisateur d’AIX 5.1).

Environnement d’exploitation

Solaris Versions 7, 8, 9

Ensembles de correctifs datés du mois de janvier 2002 ou

ultérieurs.

Hewlett Packard PA-RISC

Versions 11.0, 11i

Les correctifs du système d’exploitation doivent être

installés avant le produit. Pour déterminer les correctifs à

installer sur votre ordinateur, connectez-vous en tant que

Root et exécutez :

/usr/sbin/swlist -l produit

Pour prendre en charge JRE 1.3.1.05, vous devez avoir :

v pour HP-UX 11.0, le Quality Pack QPK1100,

v pour HP-UX 11i, le Quality Pack GOLDQPK11i.

Pour installer une ou plusieurs méthodes d’accès de Tivoli Workload Scheduler for

Applications sur votre ordinateur, procédez comme suit :

1. Arrêtez tous les services Tivoli Workload Scheduler.

2. Exécutez la commande d’installation à partir du CD du produit ou d’une

image, à savoir :

v setup.bin sous Unix, ou

v setup.exe sous Windows.

La fenêtre Bienvenue s’affiche.


3. Cliquez sur Suivant pour continuer. La fenêtre Contrat de licence logicielle

apparaît.

4. Sélectionnez le bouton correspondant pour accepter le contrat et cliquez sur

Suivant pour continuer. La fenêtre Sélectionnez un type d’installation

apparaît.

Figure 2. Fenêtre Bienvenue.

Figure 3. Fenêtre Contrat de licence logicielle.


5. Déterminez si vous voulez procéder à une nouvelle installation de Tivoli

Workload Scheduler for Applications ou mettre à jour une installation

existante. Si vous installez une méthode d’accès supplémentaire, sélectionnez

Mettre à jour une instance.

v Si vous choisissez Créer une nouvelle instance, le programme d’installation

détecte et énumère toutes les installations de Tivoli Workload Scheduler

présentes sur votre ordinateur.

v Si vous choisissez Mettre à jour une instance, le programme d’installation

détecte et énumère toutes les installations de Tivoli Workload Scheduler for

Applications présentes sur votre ordinateur.

Cliquez sur Suivant pour continuer.

Si vous avez sélectionné Créer une nouvelle instance, une fenêtre similaire à

la figure 5 à la page 11 apparaît.

Figure 4. Fenêtre Sélectionnez un type d’installation


Le programme d’installation sonde le système et répertorie toutes les instances

existantes de Tivoli Workload Scheduler.

Remarques :

a. Si le processus d’exploration ne détecte aucune instance existante, une

fenêtre s’affiche, vous permettant d’entrer le chemin d’installation et le

nom d’une instance.

b. Si vous êtes sous Unix et avez plusieurs installations de Tivoli Workload

Scheduler, version 7.0 ou 8.1, qui n’ont pas été correctement installées

dans un répertoire de base /home/ utilisateur_TWS, la fenêtre affiche

alors, au hasard, une seule de ces instances et l’appelle <unknown>. Parmi

ces instances, celle-ci sera la seule que vous pourrez marquer pour

l’installation. Reportez-vous au tableau 24 à la page 189 pour plus de

détails.

Si vous avez sélectionné Mettre à jour une instance, une fenêtre similaire à la

figure 6 à la page 12 apparaît.

Figure 5. Fenêtre Instances installées de Tivoli Workload Scheduler.


Le programme d’installation sonde le système et répertorie toutes les instances

existantes de Tivoli Workload Scheduler for Applications.

6. Sélectionnez une ou plusieurs instances et cliquez sur Suivant pour continuer.

Une fenêtre apparaît, répertoriant toutes les méthodes d’accès définies dans

Tivoli Workload Scheduler for Applications. La liste varie en fonction de la

plateforme sur laquelle vous procédez à l’installation : les installations sous

Unix ne proposent pas la méthode d’accès pour PeopleSoft, alors que les

installations sous Windows ne proposent pas la méthode d’accès pour Oracle.

Voici un exemple d’installation sous Windows.

Figure 6. Fenêtre Instances installées de Tivoli Workload Scheduler for Applications.

Figure 7. Fenêtre de sélection des composants Tivoli Workload Scheduler for Applications sous MS Windows.


Voici un exemple d’installation sous Unix.

7. Sélectionnez la ou les méthodes d’accès que vous voulez installer sur votre

ordinateur et cliquez sur Suivant pour continuer. En fonction du nombre et

des méthodes d’accès que vous avez sélectionnées, une ou plusieurs fenêtres

supplémentaires apparaîtront, vous demandant d’entrer des informations

spécifiques à l’une ou l’autre de ces méthodes, à savoir :

v Pour toutes les méthodes d’accès : le nom de l’utilisateur Tivoli Workload

Scheduler qui exécutera la méthode sélectionnée. Il peut s’agir du même

nom que celui défini lors de l’installation de Tivoli Workload Scheduler.

v Pour la méthode d’accès PeopleSoft : la version de l’environnement

PeopleTools ainsi que l’un des chemins suivants :

– pour les versions PeopleSoft 7.0x ou 7.5x, le chemin du répertoire

d’exécution COBOL (généralement <racine_PS>\cblbin),

– pour la version PeopleSoft 8.1x, le chemin des API PeopleSoft externes

(généralement <REP_API_EXT>\bin\client\winx86_extapi),

– pour la version PeopleSoft 8.4x, le chemin du répertoire client PeopleSoft

(généralement <racine_PS>\bin\client\winx86).

Voici la fenêtre de la méthode d’accès R/3.

Figure 8. Fenêtre de sélection des composants Tivoli Workload Scheduler for Applications sous Unix.


Voici la première fenêtre de la méthode d’accès PeopleSoft.

Voici la deuxième fenêtre de la méthode d’accès PeopleSoft.

Figure 9. Fenêtre supplémentaire d’informations utilisateur pour la méthode d’accès R/3.

Figure 10. Première fenêtre supplémentaire d’informations utilisateur pour la méthode d’accès PeopleSoft.


Voici la fenêtre de la méthode d’accès z/OS.

8. Entrez les informations requises et cliquez sur Suivant pour continuer. Une

fenêtre d’informations récapitulatives apparaît. La figure 13 à la page 16

représente un exemple d’informations récapitulatives pour l’installation de la

méthode d’accès R/3.

Figure 11. Deuxième fenêtre supplémentaire d’informations utilisateur pour la méthode d’accès PeopleSoft.

Figure 12. Fenêtre supplémentaire d’informations utilisateur pour la méthode d’accès z/OS.


9. Cliquez sur Suivant pour continuer. Le processus d’installation commence à

installer les méthodes d’accès sélectionnées sur votre ordinateur. Une fenêtre

de progression s’affiche.

Une fois l’installation terminée, la fenêtre suivante apparaît, vous demandant

si vous voulez (ou non) exécuter l’Editeur d’options. Il s’agit d’un éditeur de

fichiers Java qui permet de définir des options pour les méthodes d’accès que

vous avez installées. Si vous choisissez de ne pas exécuter l’Editeur d’options

immédiatement, vous pourrez le faire, à tout moment, ultérieurement.

Figure 13. Fenêtre d’informations récapitulatives pour l’installation.

Figure 14. Fenêtre de progression de l’installation.


10. Cliquez sur le bouton d’option approprié pour exécuter (ou non) l’Editeur

d’options immédiatement et cliquez sur Suivant pour continuer.

Si vous cliquez sur Oui, l’Editeur d’options s’ouvre, vous permettant de

définir les options des méthodes que vous avez installées. Reportez-vous au

Chapitre 3, «Définition des options à l’aide de l’Editeur d’options», à la page

27 pour plus de détails sur l’utilisation de l’Editeur d’options.

Lorsque vous avez fini d’utiliser l’Editeur d’options (ou que vous aviez

sélectionné Non dans la fenêtre précédente), la fenêtre de fin d’installation

s’affiche.

Figure 15. Fenêtre de lancement de l’Editeur d’options .

Figure 16. Fenêtre de fermeture de l’assistant d’installation.


11. Cliquez sur Terminer pour quitter l’assistant d’installation.

Le journal d’installation, nommé TWS4APPS.LOG, est enregistré dans le

répertoire maestro.

Utilisation de l’installation automatique

Cette méthode permet d’installer le produit sans recourir à l’assistant d’installation

ISMP. Pour installer via cette méthode, vous devez préparer auparavant un fichier

d’options et spécifier son nom dans une commande d’installation.

La procédure d’installation automatique vous permet d’installer, si vous le

souhaitez, toutes les méthodes d’accès simultanément.

Le journal d’installation, nommé TWS4APPS.LOG, est enregistré dans le répertoire

maestro.

Syntaxe : Pour installer Tivoli Workload Scheduler for Applications avec la

méthode automatique, utilisez la commande suivante :

v sous Windows

setup.exe -silent -options chemin_et_nom_du_fichier_options

v sous Unix

setup.bin -silent -options chemin_et_nom_du_fichier_options

Paramètres :

-silent Spécifie que l’installation ne s’exécute pas via une interface utilisateur, mais

via un fichier d’options.

-options chemin_et_nom_du_fichier_options

Fournit le chemin ainsi que le nom du fichier contenant les options

d’installation. Ce fichier d’options est un fichier texte, du nom et de

l’extension de votre choix. Les options sont écrites séparément, ligne par

ligne.

Un modèle permettant d’exécuter une installation automatique est livré

avec le produit. Ce modèle, appelé silent.txt, se trouve dans le répertoire

RESPONSE_FILE du CD-ROM du produit.

Le tableau suivant répertorie les options disponibles pour piloter

l’installation :

Tableau 3. Options requises pour la procédure d’installation automatique.

Option Description Valeur

-P TWS4APPS.installLocation Chemin où vous souhaitez

installer Tivoli Workload

Scheduler for Applications.

Cette option est obligatoire.

Chemin absolu.

-P TWS4APPS.name Nom de cette instance de Tivoli

Workload Scheduler for

Applications. Cette option est

obligatoire.

Nom, à inclure entre des

guillemets s’il contient un

blanc.

-P MCMAGENT_FEATURE.active Spécifie que la méthode d’accès

pour Oracle eBusiness Suite

doit être installée.

True ou False.


Tableau 3. Options requises pour la procédure d’installation automatique. (suite)


-W LJUSER_MCMAGENT_INPUT_BEAN.LJUSER Nom de l’utilisateur de Tivoli

Workload Scheduler qui doit

exécuter la méthode d’accès

pour Oracle eBusiness Suite.

Cette option est obligatoire si

vous installez cette méthode.

Nom d’utilisateur de Tivoli

Workload Scheduler, à

inclure entre des


blanc.

-P R3BATCH_FEATURE.active Spécifie que la méthode d’accès

pour R/3 doit être installée.

True ou False.

-W LJUSER_R3BATCH_INPUT_BEAN.LJUSER Nom de l’utilisateur de Tivoli



pour R/3. Cette option est

obligatoire si vous installez

cette méthode.



inclure entre des


blanc.

-P ZOSAGENT_FEATURE.active Spécifie que la méthode d’accès

pour z/OS doit être installée.

True ou False.

-W LJUSER_ZOSAGENT_INPUT_BEAN.LJUSER Nom de l’utilisateur de Tivoli



pour z/OS. Cette option est

obligatoire si vous installez

cette méthode.



inclure entre des


blanc.

-P PSAGENT_FEATURE.active Spécifie que la méthode d’accès

pour PeopleSoft doit être

installée.

True ou False.

-W LJUSER_PSAGENT_INPUT_BEAN.LJUSER Nom de l’utilisateur de Tivoli



pour PeopleSoft. Cette option

est obligatoire si vous installez

cette méthode.



inclure entre des


blanc.




-W LJUSER_PSAGENT_INPUT_BEAN.BEND_TYPE Spécifie la version de

l’environnement PeopleTools.

Cette option est obligatoire si

vous installez cette méthode.

Il peut s’agir de l’un ou de

plusieurs des

environnements suivants :

PS70MR2

PeopleTools 7.0x

et Merant

NetExpress 2.x

PS70MR3

PeopleTools 7.0x

et Merant

NetExpress 3.x

PS70WB4

PeopleTools 7.0x

et MF COBOL

Workbench 4.x

PS75MR2

PeopleTools 7.5x

et Merant

NetExpress 2.x

PS75MR3

PeopleTools 7.5x

et Merant

NetExpress 3.x

PS81 PeopleTools 8.1x


Les entrées multiples

doivent être séparées par

des points-virgules.

-W PS70MR2_CBLDIR.DIRNAME Chemin du répertoire COBOL

pour PeopleTools 7.0x et

Merant NetExpress 2.x. Utilisez

ce chemin si vous avez spécifié

cet environnement.

Chemin d’accès complet à

ce répertoire, généralement

<racine_PS>\cblbin.





cet environnement.



<racine_PS>\cblbin.

-W PS70WB4_CBLDIR.DIRNAME Chemin du répertoire COBOL


MF COBOL Workbench 4.x.

Utilisez ce chemin si vous avez

spécifié cet environnement.



<racine_PS>\cblbin.





cet environnement.



<racine_PS>\cblbin.








cet environnement.



<racine_PS>\cblbin.

-W PS81_APIDIR.DIRNAME Chemin du répertoire des API

externes pour PeopleTools 8.1x.

Utilisez ce chemin si vous avez




<REP_API_EXT>\bin\client\

winx86_extapi.

-W PS84_APIDIR.DIRNAME Chemin du répertoire client

PeopleSoft pour

PeopleTools 8.4x. Utilisez ce

chemin si vous avez spécifié

cet environnement.



<racine_PS>\bin\client\

winx86.

Exemples : L’exemple suivant utilise un fichier d’options appelé

silent_options.txt pour installer automatiquement Tivoli Workload Scheduler for

Applications sur un ordinateur Windows :

setup.exe –silent –options c:\tmp\silent_options.txt

L’exemple suivant utilise un fichier d’options appelé silent_options.txt pour

installer automatiquement Tivoli Workload Scheduler for Applications sur une

station Unix où X-Server n’est pas disponible :

setup.bin –silent –options /tmp/silent_options.txt

L’exemple suivant est un fichier d’options utilisé pour piloter l’installation de

Tivoli Workload Scheduler for Applications sur un ordinateur Windows. Les

méthodes d’accès pour R/3 et pour PeopleSoft sont définies comme composants

d’installation.

# EMPLACEMENT D’INSTALLATION et NOM D’INSTANCE

-P TWS4APPS.installLocation=C:\win32app\maestro

-P TWS4APPS.name=SILENT

# PARAMETRES R3BATCH

-P R3BATCH_FEATURE.active=true

-W LJUSER_R3BATCH_INPUT_BEAN.LJUSER=utilisateur_tws

# PARAMETRES PSAGENT

-P PSAGENT_FEATURE.active=true

-W LJUSER_PSAGENT_INPUT_BEAN.LJUSER=tws

-W LJUSER_PSAGENT_INPUT_BEAN.BEND_TYPE=PS70MR2;PS75MR3

-W PS70MR2_CBLDIR.DIRNAME=M:\PSDIRS\PS70Merant2

-W PS75MR3_CBLDIR.DIRNAME=N:\PSDIRS\PS75Merant3

Utilisation de Tivoli Configuration Manager

Il est également possible d’installer chaque méthode d’accès en distribuant un

groupe de logiciels (SPB), à partir du bureau Tivoli ou de la commande winstsp du

composant Software Distribution d’IBM Tivoli Configuration Manager, Version 4.2.

La distribution et l’installation des SPB peut s’effectuer via des ordinateurs

exécutant Tivoli Management Framework.

Le déploiement de Tivoli Workload Scheduler for Applications via un format

regroupé présente les avantages suivants :

v Déploiement non seulement de fichiers et de répertoires, mais aussi d’éléments

d’environnement, tels que fichiers INI, registres, icônes, etc.


v Utilisation de la commande UNDO au lieu de REMOVE pour chacun des

éléments ci-dessus, intégrés au groupe de logiciels.

v Utilisation de variables (intégrées, spécifiques à une cible ou prédéfinies) dans le

groupe de logiciels.

v Utilisation de paramètres d’environnement dans le groupe de logiciels, via des

sections spécifiques pour des plateformes spécifiques.

v Utilisation illimitée de programmes utilisateur génériques, pour différentes

phases d’exécution, et gestion personnalisée des codes retour des programmes.

v Réamorçage ou redémarrage à un point de contrôle durant l’exécution des

actions du groupe de logiciels.

Ce format ne vous permet toutefois d’installer qu’une seule méthode d’accès par

groupe de logiciels (SPB). Si vous utilisez plusieurs SPB pour installer d’autres

méthodes d’accès, veillez à attribuer des noms différents aux groupes de logiciels.

Si vous choisissez de piloter le processus d’installation à partir du bureau Tivoli et

que le moteur Tivoli Workload Scheduler du poste de travail cible est une

version 8.2, vérifiez que vous connaissez le nom du répertoire d’installation du

moteur avant de démarrer.

Pour être installés par voie de distribution logicielle, tous les SPB de Tivoli

Workload Scheduler for Applications requièrent les options suivantes :

Tableau 4. Options requises pour installer tous les SPB de Tivoli Workload Scheduler for

Applications via le module Software Distribution.

Option Description

INSTALL_DIR Chemin d’accès au répertoire maestro (qui contient les

méthodes).

LJUSER Nom de l’utilisateur de Tivoli Workload Scheduler qui doit

exécuter la méthode d’accès.


De plus, le SPB de la méthode d’accès PeopleSoft requiert les options suivantes :

Tableau 5. Options supplémentaires requises pour installer la méthode d’accès du SPB

PeopleSoft via le module Software Distribution.

Option Description

INSTALL_BEND Spécifie la version de l’environnement PeopleTools. Il peut s’agir

de l’un ou de plusieurs des environnements suivants :

PS70MR2

PeopleTools 7.0x et Merant NetExpress 2.x

PS70MR3


PS70WB4

PeopleTools 7.0x et MF COBOL Workbench 4.x

PS75MR2


PS75MR3

PeopleTools 7.5x and Merant NetExpress 3.x



Les entrées multiples doivent être séparées par des

points-virgules.

PS70MR2_CBLDIR Chemin du répertoire COBOL pour PeopleTools 7.0x et Merant

NetExpress 2.x. Utilisez ce chemin si vous avez spécifié cet

environnement.



environnement.

PS70WB4_CBLDIR Chemin du répertoire COBOL pour PeopleTools 7.0x et

MF COBOL Workbench 4.x. Utilisez ce chemin si vous avez




environnement.



environnement.

PS81_APIDIR Chemin du répertoire des API externes pour PeopleTools 8.1x.

Utilisez ce chemin si vous avez spécifié cet environnement.

PS84_APIDIR Chemin du répertoire client PeopleSoft pour PeopleTools 8.4x.

Utilisez ce chemin si vous avez spécifié cet environnement.

Le produit inclut également un SPB contenant une machine virtuelle Java, fort utile

pour installer l’Editeur d’options avec cette méthode. Cette machine virtuelle Java

ne peut toutefois pas remplacer celle requise pour l’exécution du produit

PeopleSoft.

Pour installer un groupe de logiciels, vous devez exécuter les actions suivantes, en

utilisant soit une ligne de commande, soit le bureau Tivoli :

1. Importez le SPB dans un profil de groupe de logiciels. Procédez ainsi pour les

SPB :


v des méthodes d’accès que vous voulez installer,

v de la machine virtuelle Java (JVM),

v de l’Editeur d’options (requiert, pour l’exécution, que les deux autres SPB

aient été installés).2. Installez le profil de groupe de logiciels sur les noeuds finaux gérés par Tivoli

Framework.

L’exemple ci-dessous illustre comment installer le SPB de la méthode d’accès R/3

sur un poste de travail Windows.

1. Importez le fichier SBP TWS4APPS_R3BATCH_I386NT.SPB dans un profil de groupe

de logiciels de Tivoli Framework appelé, par exemple,

TWS4APPS_R3BATCH_I386NT.8.2. Utilisez la commande suivante :

wimpspo -c PROFILE_MANAGER -f <CHEMIN_SOURCE>/TWS4APPS_R3BATCH_I386NT.SPB -t build

-p <CHEMIN_DEST_LOCAL>/TWS4APPS_R3BATCH_I386NT.SPB TWS4APPS_R3BATCH_I386NT.8.2

Dans cet exemple, le fichier CHEMIN_SOURCE/TWS4APPS_R3BATCH_I386NT.SPB est

importé dans un profil de groupe de logiciels appelé

TWS4APPS_R3BATCH_I386NT.8.2, lequel appartient à un gestionnaire de profil

PROFILE_MANAGER de Tivoli Framework.

TWS4APPS_R3BATCH_I386NT.8.2 doit faire référence au fichier

<CHEMIN_DEST_LOCAL>/TWS4APPS_R3BATCH_I386NT.SPB en tant que fichier local

contenant les informations requises.

Remarque : Pour installer une instance supplémentaire de ce SPB sur le même

poste de travail, vous devez renommer le SPB.

2. Installez le profil de groupe de logiciels TWS4APPS_R3BATCH_I386NT.8.2 sur un

ordinateur ayant pour nom d’hôte epw2000 (qui doit également être défini

comme noeud final de Tivoli Framework). Utilisez la commande suivante :

winstsp -D INSTALL_DIR=racine_TWS -D LJUser=utilisateur_TWS

TWS4APPS_R3BATCH_I386NT.8.2 epw2000

Lorsque le journal d’installation, dans ce cas, un fichier nommé

$BINDIR/../swdis/work/TWS4APPS_R3BATCH_I386NT.log, affiche le message

Opération réussie, le processus d’installation peut être considéré comme terminé.

L’exemple ci-dessous illustre comment installer le SPB de la machine virtuelle Java

pour AIX sur un système AIX. Notez qu’il existe un groupe de logiciels JVM

différent pour chaque plateforme.

1. Importez le groupe de logiciels ayant pour nom JRE131_AIX.SPB dans un profil

de groupe de logiciels appelé JRE131AIX.8.2. Utilisez la commande suivante :

wimpspo -c PROFILE_MANAGER -f <CHEMIN_SOURCE>/JRE131_AIX.SPB -t build

-p <CHEMIN_DEST_LOCAL>/JRE131_AIX.SPB

JRE131AIX.8.2

2. Installez le profil de groupe de logiciels JRE131AIX.8.2 sur un ordinateur ayant

pour nom d’hôte epAIX. Utilisez la commande suivante :

winstsp

-D INSTALL_DIR=racine_TWS -D LJUser=utilisateur_TWS

JRE131AIX.8.2 epAIX

L’exemple suivant illustre comment installer le SPB de l’Editeur d’options sur le

même système AIX. Notez que le SPB de l’Editeur d’options est le même pour

toutes les plateformes.

1. Importez le groupe de logiciels ayant pour nom OPTED.SPB dans un profil de

groupe de logiciels appelé OPTED.8.2. Utilisez la commande suivante :


wimpspo -c PROFILE_MANAGER -f <CHEMIN_SOURCE>/OPTED.SPB -t build

-p <CHEMIN_DEST_LOCAL>/OPTED.SPB OPTED.8.2

2. Installez le profil de groupe de logiciels OPTED.8.2 sur un ordinateur ayant

pour nom d’hôte epAIX. Utilisez la commande suivante :

winstsp

-D INSTALL_DIR=racine_TWS -D LJUser=utilisateur_TWS

OPTED.8.2 epAIX

Désinstallation du produit

Pour désinstaller Tivoli Workload Scheduler for Applications d’un poste de travail,

vous devez suivre la même procédure que celle que vous avez utilisée lors de

l’installation :

v Si vous avez utilisé l’assistant d’installation ISMP, vous devez utiliser une

méthode compatible ISMP pour la désinstallation.

v Si vous avez procédé à l’installation par voie de distribution logicielle, vous

devez désinstaller par la même méthode.

Si vous envisagez de désinstaller la méthode d’accès pour Oracle eBusiness suite,

notez que vous devrez achever manuellement le retrait du produit. Reportez-vous

à la section «Suppression manuelle des éléments restants lors du retrait de la

méthode d’accès pour Oracle e-Business Suite» à la page 26.

Dans certains cas, lorsque vous désinstallez complètement le produit, le processus

de désinstallation peut laisser un répertoire nommé _xauninst. Si tel est le cas,

supprimez ce dernier manuellement.

Suppression d’une installation via ISMP

Pour désinstaller le produit suite à une installation effectuée via ISMP :

v Sous Windows :

1. Sélectionnez Ajout/Suppression de programmes dans le Panneau de

configuration.

2. Recherchez IBM Tivoli Workload Scheduler for Applications (nom

d’utilisateur).

3. Cliquez sur Supprimer. Une fenêtre de désinstallation s’ouvre, vous

proposant de supprimer le produit dans son intégralité, ou une ou plusieurs

méthodes d’accès qui avaient été installées en tant que fonction(s) du

produit.v Sous Unix :

1. Accédez au répertoire <racine_TWS>/methods.

2. Lancez la commande suivante :

../_xauninst/uninstaller

Une fenêtre de désinstallation s’ouvre, vous proposant de supprimer le

produit dans son intégralité, ou une ou plusieurs méthodes d’accès qui

avaient été installées en tant que fonction(s) du produit.

Suppression d’une installation via Tivoli Configuration

Manager

Pour supprimer le produit suite à une installation effectuée par distribution de

logiciels, utilisez le bureau Tivoli ou la commande wremovsp.


Pour consulter la liste des groupes de logiciels installés sur l’ordinateur suite à

distribution, utilisez l’une ou l’autre des procédures suivantes :

v Utilisez Tivoli Inventory, inclus dans la version 4.2 de Tivoli Configuration

Manager, pour exécuter la requête CM_STATUS_QUERY et répertorier les méthodes

d’accès installées sur les postes de travail. Reportez-vous à la documentation de

Tivoli Inventory pour plus de détails.

v Affichez les fichiers journaux générés par Software Distribution sur l’ordinateur.

Chaque groupe de logiciels distribué a son propre fichier journal, c’est-à-dire un

fichier texte qui enregistre l’historique d’installation et de désinstallation de ce

groupe. Par exemple, le fichier journal du groupe de logiciels de la méthode

d’accès R/3 sur un système AIX, à savoir r3batch_tws_aix.log, est enregistré

dans le répertoire $BINDIR/../swdis/work (où $BINDIR représente une variable

d’environnement de Tivoli Framework qui est initialisée via la commande

/etc/Tivoli/setup_env.sh).

Reportez-vous à la documentation de Tivoli Software Distribution pour plus de

détails.

Suppression manuelle des éléments restants lors du retrait de

la méthode d’accès pour Oracle e-Business Suite

Une fois le processus de désinstallation terminé, exécutez les étapes suivantes :

1. Restaurez le contenu original d’APPLSYS.env en supprimant la chaîne MCM des

variables APPLSHAR et APPLFUL. Par exemple :

APPLSHAR=’ALR FF MCM’

doit devenir

APPLSHAR=’ALR FF’

2. Supprimez les fichiers suivants :

v <racine_TWS>/methods/MCMAGENT

v <racine_TWS>/catalog/C/mcm.cat

v MCMLJ, MCMSTAT et MCMTJ situés dans le répertoire $MCM_TOP/bin

v MCMprod.txt situé dans le répertoire $APPL_TOP/admin

v Tous les fichiers d’options


Chapitre 3. Définition des options à l’aide de l’Editeur

d’options

Un fichier d’options est un fichier texte contenant un ensemble d’options de

configuration requises pour exécuter un agent étendu. Ces options sont écrites à

raison d’une par ligne et se présentent sous le format suivant :

OPTION=VALEUR

sans espace autour des mots clés ou entre les mots clés.

Les options sont utilisées pour modifier les propriétés d’exécution de la méthode

d’accès, telles que le mot de passe requis pour se connecter à un système externe

(par exemple, SAP R/3) ou le nom de connexion.

Toutes les méthodes d’accès utilisent deux types de fichiers d’options, à savoir :

Fichier d’options globales

Il s’agit d’un fichier de configuration commun, propre à une instance

particulière d’une méthode d’accès, dont les paramètres affectent tous les

postes de travail d’agent étendu définis dans cette instance. Ce fichier

contient des options qui sont, en partie, entrées au moment de

l’installation, par exemple : LJuser (qui fournit le nom de l’utilisateur qui

exécute la méthode d’accès) ou IFuser (qui fournit le nom de l’utilisateur

qui exécute la méthode pour extraire les informations relatives aux travail).

Le nom de ce fichier est <nom_méthode_accès>.opts.

Par exemple, pour une installation de la méthode d’accès R/3, le nom du

fichier d’options globales est r3batch.opts.

Fichier d’options locales

Il s’agit d’un fichier de configuration, spécifique à chaque poste de travail

d’agent étendu au sein d’une instance particulière d’une méthode d’accès.

Chaque poste de travail d’agent étendu (sauf pour z/OS) doit avoir un

fichier d’options locales avec ses propres options de configuration. Le nom

de ce fichier est Nom du poste de travail_<nom_méthode_accès>.opts.

Par exemple, si une installation de la méthode d’accès R/3 comporte deux

postes de travail d’agent étendu, CPU1 et CPU2, les noms des fichiers

d’options locales seront respectivement CPU1_r3batch.opts et

CPU2_r3batch.opts.

Les fichiers doivent résider dans le sous-répertoire methods d’installation de Tivoli

Workload Scheduler et sont lus lorsque l’agent étendu est initialisé. Les options

sont spécifiques à chaque méthode d’accès. Pour connaître les options de chaque

méthode d’accès, reportez-vous aux chapitres suivants :

v Chapitre 8, «Informations de référence sur le fichier d’options MCMAGENT», à

la page 53 pour Oracle,

v Chapitre 11, «Tâches post-installation», à la page 65 pour PeopleSoft,

v Chapitre 20, «Fichiers d’options de la méthode d’accès R/3», à la page 119 pour

R/3,

v Chapitre 25, «Configuration et fonctionnement», à la page 151 pour z/OS.


Vous pouvez écrire les fichiers d’options à l’aide d’un éditeur de texte de votre

choix ou les créer avec l’Editeur d’options fourni avec le produit.

Avant de terminer l’installation, Tivoli Workload Scheduler for Applications vous

propose de démarrer l’Editeur d’options pour vous permettre de définir des

options locales, alors que certaines valeurs que vous avez entrées durant le

processus sont utilisées pour créer un fichier d’options globales. Pour démarrer

l’Editeur d’options à tout autre moment, accédez au sous-répertoire methods de

votre installation Tivoli Workload Scheduler et exécutez la commande (Windows)

opted.exe ou (Unix) opted.bin.

Si vous avez installé le produit via Tivoli Configuration Manager, lancez l’Editeur

d’options à l’aide de l’une de ces commandes :

v racine_TWS\methods\opted\opted.bat sous Windows,

v racine_TWS/methods/opted/opted.sh sous Unix.

L’Editeur d’options charge automatiquement tous les fichiers d’options globales et

locales existants. Vous pouvez ainsi modifier les fichiers existants et créer des

fichiers d’options locales pour les postes de travail d’agent étendu nouvellement

définis.

L’Editeur d’options fournit trois vues possibles d’un fichier d’options :

Simple

Affiche les options sous forme de séquence d’onglets, vous permettant de

modifier une option à la fois. Pour afficher ou modifier une option,

sélectionnez l’onglet portant le nom de l’option pour afficher la zone de la

valeur. Il s’agit de la méthode la plus aisée pour modifier les options,

puisque vous ne voyez que la valeur réelle qui sera utilisée dans le fichier.

Les valeurs héritées et les valeurs par défaut ne sont pas affichées. Les

options obligatoires apparaissent en jaune et sont caractérisées par un

astérisque (*).

Table Fournit une vue en forme de tableau de toutes les options d’un fichier

sélectionné. Pour chaque option, les colonnes suivantes sont affichées :

Valeur Valeur spécifiée dans le fichier.

Valeur par défaut

Valeur utilisée par la méthode si aucune autre valeur n’est

disponible.

Valeur héritée

Valeur provenant du fichier d’options globales, si l’héritage est pris

en charge par la méthode.

Valeur réelle

Valeur réellement utilisée lors de l’exécution. L’ordre d’utilisation

est le suivant : valeur, si disponible ; valeur héritée, si prise en

charge ; valeur par défaut.

Les options obligatoires sont affichées sur fond jaune.

Texte Affiche les fichiers d’options dans un format classique, ne présentant que

les options ayant une valeur. Cette vue est généralement utilisée à des fins

de prévisualisation, car les fichiers sont affichés en mode Lecture seule. Les

zones relatives aux mots de passe apparaissent sous forme codée.


La fenêtre de l’Editeur d’options se compose de trois zones principales, comme

illustré à la figure 17, à savoir :

Arborescence des fichiers d’options

Affiche la liste de tous les fichiers d’options existants, regroupés par

méthode.

Descripteur d’options

Donne une description de la sélection en cours.

Vue du fichier d’options

Affiche les options d’un fichier sélectionné dans l’une des trois vues

disponibles.

Vérifiez que l’Editeur d’options n’est pas en cours d’exécution avant d’ajouter ou

de mettre à jour des paramètres ou des instances d’une installation existante de

Tivoli Workload Scheduler for Applications.

Vous devez restreindre l’accès au fichier exécutable de l’Editeur d’options. Dans le

cas de multiples installations d’un agent étendu, vous pouvez améliorer la sécurité

en ne conservant qu’une seule copie de l’Editeur d’options (sur le poste de travail

principal, par exemple). Grâce à FTP, vous pouvez gérer tous les fichiers d’options

chiffrés à partir d’un même emplacement.

Figure 17. Editeur d’options

Chapitre 3. Définition des options à l’aide de l’Editeur d’options 29

Création d’un fichier d’options locales

Alors que les fichiers d’options globales sont générés automatiquement à chaque

installation d’une instance de méthode d’accès, vous pouvez créer des fichiers

d’options locales à tout moment, avant ou après avoir défini un poste de travail

d’agent étendu. Pour créer un fichier d’options locales avec l’Editeur d’options :

1. Cliquez sur Fichier→Nouveau dans la barre de menus. La fenêtre Nouveau

fichier d’options s’affiche.

2. Entrez le nom d’un poste de travail d’agent étendu que vous venez de définir

ou envisagez de définir.

3. Sélectionnez une méthode d’accès parmi celles proposées dans le menu

déroulant. Le nouveau fichier d’options aura pour nom :

<nom_poste_de_travail_agent_étendu>_<nom_méthode>.opts.

4. Commencez à entrer les valeurs des options.

Héritage des valeurs des options

Cette propriété n’est actuellement disponible que pour r3batch. Elle permet aux

fichiers d’options locales de pouvoir hériter, pour des options identiques, des

valeurs existant dans le fichier d’options globales (r3batch.opts). En fait, pour une

même méthode d’accès, les options sont listées deux fois : une fois en tant que

globale, une autre fois en tant que locale. Si l’option locale n’a pas de valeur

propre, celle de l’option globale est utilisée. A l’inverse, si elle existe, la valeur de

l’option locale prévaut toujours sur la valeur globale.

Par exemple, vous pouvez vouloir définir les mêmes utilisateur et mot de

passe R/3 pour tous vos systèmes R/3. Grâce à cette propriété, au lieu d’écrire les

mêmes valeurs dans chaque fichier d’options locales, il vous suffit de les entrer

une fois dans le fichier d’options globales.


Chapitre 4. Définition des postes de travail d’agent étendu

Une définition de poste de travail d’agent étendu est requise pour chaque entité de

méthode d’accès utilisée par Tivoli Workload Scheduler pour planifier et lancer des

travaux. Les postes de travail d’agent étendu sont définis de manière standard et

incluent le nom de l’hôte de l’agent étendu ainsi que le nom de la méthode.

Pour lancer un travail sur un poste de travail d’agent étendu, Tivoli Workload

Scheduler exécute la méthode d’accès et transmet les informations relatives au

travail. La méthode d’accès communique avec l’instance du système considéré

(z/OS, R/3, PeopleSoft ou Oracle) et contrôle le travail tout au long de son

exécution, consignant la progression de celui-ci et les informations d’état dans le

fichier stdlist du travail.

Création d’un poste de travail avec Job Scheduling Console

Pour définir un poste de travail d’agent étendu avec Job Scheduling Console,

suivez les étapes ci-après :

1. Dans la fenêtre principale, sélectionnez l’icône Nouveau poste de travail dans

la barre d’outils supérieure ou cliquez avec le bouton droit de la souris sur le

nom du moteur Tivoli Workload Scheduler, puis sélectionnez Nouveau poste

de travail dans le menu déroulant. La fenêtre Propriétés - Poste de travail dans

la base de données s’affiche.

2. Complétez les zones en vous aidant des informations données dans le tableau 6

à la page 32.

3. Cliquez sur OK pour enregistrer et fermer la fenêtre.

Figure 18. Définition d’un poste de travail avec Job Scheduling Console


Le tableau ci-après indique comment compléter les zones de la fenêtre des

propriétés du poste de travail en fonction du poste de travail d’agent étendu que

vous voulez définir.

Tableau 6. Comment compléter les zones de la fenêtre Propriétés - Poste de travail dans la base de données

Zone Description par méthode d’accès

PeopleSoft z/OS Oracle eBusiness Suite R/3

Nom Nom du poste de travail d’agent étendu. Pour toutes les méthodes d’accès (sauf pour la

méthode z/OS pour laquelle il est toujours limité à 8 caractères), le nom peut contenir

jusqu’à 8 ou 16 caractères alphanumériques, en fonction des bases de données (étendues ou

non étendues) que vous utilisez. Il peut contenir des tirets et des traits de soulignement,

mais il doit commencer par une lettre.

Pour toutes les méthodes d’accès, ce nom doit être cohérent avec celui du fichier d’options

associé au poste de travail, c’est-à-dire que, si le fichier d’options (que vous avez

normalement créé avec l’éditeur d’options) s’appelle <ma_cpu>_<ma_méthode>.opts, alors

ma_cpu et le paramètre Nom doivent être identiques.

Noeud Non défini. Nom du noeud ou

adresse IP du système

z/OS. Seuls les noms

de domaine complets

sont acceptés.

Non défini. Non défini.

Port TCP Tout nombre autre

que 0.

Adresse TCP (numéro

de port) de la

passerelle z/OS dans

le système z/OS.

Entrez la même

valeur que la variable

SYSTSIN PORT

décrite dans le

tableau 21 à la page

146.

Tout nombre autre que

0.

Tout nombre autre

que 0.

Système

d’exploitation

Sélectionnez AUTRE.

Domaine Nom du domaine Tivoli Workload Scheduler du poste de travail hôte. Si vous avez besoin

d’aide pour le trouver, cliquez sur les points de suspension (...) pour afficher la liste des

domaines existants. Cliquez sur Utiliser le maître si vous savez que le poste de travail hôte

se situe dans le même domaine que le gestionnaire de domaine principal.

Fuseau horaire Si le réseau Tivoli Workload Scheduler utilise l’option Fuseau horaire, sélectionnez le fuseau

approprié dans la liste déroulante. Si ce n’est pas le cas, laissez cette zone vide.

Description Description textuelle facultative, à format libre, du poste de travail (40 caractères

maximum).

Communication SSL Non utilisé sur les postes de travail d’agent étendu.

Pare-feu Non utilisé sur les postes de travail d’agent étendu.

Port sécurisé Non utilisé sur les postes de travail d’agent étendu.

Type de poste de

travail

Sélectionnez Agent étendu.

Liaison automatique Non utilisé sur les postes de travail d’agent étendu.

Ignorer Sélectionnez cette option uniquement si vous souhaitez que Tivoli Workload Scheduler

ignore cette définition de poste de travail. Cette option permet de prédéfinir les flux de

travaux, les travaux et les objets d’un système qui n’est pas encore opérationnel.

Statut intégral Non utilisé sur les postes de travail d’agent étendu.


Tableau 6. Comment compléter les zones de la fenêtre Propriétés - Poste de travail dans la base de

données (suite)

Zone Description par méthode d’accès

PeopleSoft z/OS Oracle eBusiness Suite R/3

Résolution des

dépendances

Non utilisé sur les postes de travail d’agent étendu.

Serveur Non utilisé sur les postes de travail d’agent étendu.

Méthode d’accès psagent L’une des méthodes

suivantes, en fonction

de votre interface de

planification des

travaux :

mvsca7 Pour lancer

et contrôler

les travaux

z/OS via

CA-7.

mvsjes Pour lancer

et contrôler

les travaux

z/OS via

JES2 ou JES3.

mvsopc

Pour lancer

et contrôler

les travaux

z/OS via

OPC ou

Tivoli

Workload

Scheduler

pour z/OS.Remarque : Le nom

est sensible à la casse

sous UNIX (il doit

être en minuscules).

MCMAGENT

Remarque : Le nom est

sensible à la casse sous

UNIX (il doit être en

minuscules).

r3batch

Remarque : Le nom

est sensible à la

casse sous UNIX (il

doit être en

minuscules).

Hôte Nom Tivoli Workload Scheduler du système hôte. Il s’agit de l’agent tolérant aux pannes ou

de l’agent standard Tivoli Workload Scheduler sur lequel l’agent étendu est installé. Cliquez

sur les points de suspension (...) pour afficher la liste des hôtes existants.

Création d’un poste de travail à partir de la ligne de commande

Les définitions de postes de travail d’agent étendu peuvent également être créées à

partir de la ligne de commande de Tivoli Workload Scheduler via le programme

Composer. L’exemple suivant illustre une définition de poste de travail d’agent

étendu z/OS, appelé MVSCPU, qui utilise la méthode d’accès mvsjes.

cpuname MVSCPU description "agent étendu zOS"

os other

node mvsesa36.rome.tivoli.com

tcpaddr 5000

domain masterdm

for maestro

Chapitre 4. Définition des postes de travail d’agent étendu 33

type x-agent

host ROCIOUS

access mvsjes

end

Consultez le manuel IBM Tivoli Workload Scheduler - Guide de référence pour

plus de détails sur la définition des postes de travail avec Composer.

Définition de postes de travail pour une planification de bout en bout

Planifier dans un environnement de bout en bout signifie que, dans Tivoli

Workload Scheduler pour z/OS, vous planifiez et contrôlez des travaux qui

s’exécutent physiquement sur des postes de travail Tivoli Workload Scheduler.

Pour ce faire, les postes de travail d’agent étendu doivent être définis en tant que

postes de travail tolérants aux pannes dans Tivoli Workload Scheduler pour z/OS.

Un poste de travail tolérant aux pannes correspond à la définition Tivoli Workload

Scheduler pour z/OS d’un agent Tivoli Workload Scheduler existant dans le réseau

réparti. L’agent Tivoli Workload Scheduler se trouve là où le travail associé au

poste de travail tolérant aux pannes sera réellement exécuté dans le réseau réparti.

Pour définir un poste de travail d’agent étendu dans Tivoli Workload Scheduler

pour z/OS, vous devez :

1. Définir le poste de travail dans l’instruction d’initialisation CPUREC.

2. Ajouter la même définition de poste de travail à la base de données, via ISPF

ou Job Scheduling Console. Pour plus de détails sur la procédure à suivre pour

définir un poste de travail à l’aide de Job Scheduling Console, consultez le

manuel Tivoli Job Scheduling Console - Guide d’utilisation.

Création de l’instruction CPUREC

Commencez par créer l’instruction CPUREC pour le poste de travail dans

l’instruction d’initialisation TOPOLOGY. Cette dernière est utilisée pour définir les

paramètres relatifs à la topologie du réseau Tivoli Workload Scheduler connecté.

Une telle topologie est composée d’une ou plusieurs instructions DOMREC (une pour

chaque domaine) qui décrivent la topologie du réseau réparti et de plusieurs

instructions CPUREC (une pour chaque poste de travail tolérant aux pannes).

L’exemple ci-après illustre une instruction CPUREC pour un poste de travail d’agent

étendu R/3 du nom de R3XA. L’agent étendu est hébergé par un agent Tivoli

Workload Scheduler appelé TWSA, qui est également le gestionnaire de domaine de

DOMAINE1.

**************** MEMBRE TPLGINFO ***************************

/*********************************************************************/

/* DOMREC : Définition du domaine */

/*********************************************************************/

DOMREC DOMAIN(DOMAINE1)

DOMMNGR(TWSA)

DOMPARENT(MAITREDM)

/*********************************************************************/

/* CPUREC : Définition du poste de travail d’agent étendu */

/*********************************************************************/

CPUREC CPUNAME(R3XA)

CPUOS(OTHER)

CPUNODE(NOEUD1)

CPUDOMAIN(DOMAINE1)

CPUHOST(TWSA)


CPUTYPE(XAGENT)

CPUACCESS(r3batch)

CPUUSER(utilisateur_TWS)

CPUTZ(’Europe/Rome’)

/*********************************************************************/

/* CPUREC : Définition du poste de travail gestionnaire de domaine */

/*********************************************************************/

CPUREC CPUNAME(TWSA)

CPUNODE(NOEUD1)

CPUAUTOLINK(ON)

CPUDOMAIN(DOMAINE1)

CPUTYPE(FTA)

CPUUSER(utilisateur_TWS)

CPUTZ(’Europe/Rome’)

Les mots clés suivants définissent R3XA comme agent étendu :

CPUACCESS

Méthode d’accès associée à l’agent étendu. Pour R/3, il s’agit de r3batch.

CPUHOST

Nom du poste de travail Tivoli Workload Scheduler hébergeant l’agent

étendu. Il ne peut pas s’agir d’un autre agent standard ou étendu.

CPUTYPE

Type de poste de travail, à savoir XAGENT pour un agent étendu.

Pour plus d’informations sur CPUREC, consultez le manuel Tivoli Workload Scheduler

for z/OS Customization and Tuning.

Définition d’un poste de travail avec ISPF

La figure 19 à la page 36 illustre une définition ISPF pour R3XA.

Dans ISPF (ou dans Job Scheduling Console), définissez le poste de travail comme

Ordinateur Automatique, puis entrez Y dans la zone FT Work station. C’est

l’instruction CPUREC avec les trois mots clés décrits dans la section précédente qui

fournit la spécification de l’agent étendu.

Chapitre 4. Définition des postes de travail d’agent étendu 35

Remarque : Veillez à écrire l’instruction CPUREC avant de créer la définition ISPF ou

Job Scheduling Console, car ni l’un, ni l’autre n’a d’effet sans

l’instruction CPUREC.

--------------

CREATION D’INFORMATIONS GENERALES SUR UN POSTE DE TRAVAIL

--------------

Commande ===>

Entrez la commande R pour ressources, A pour disponibilité ou M pour méthode d’accès

ci-dessus, ou entrez les données ci-dessous :

WORK STATION NAME ===> R3XA

DESCRIPTION ===> Agent étendu pour méthode d’accès R/3____________________

WORK STATION TYPE ===> C G Général, C Ordinateur, P Imprimante

REPORTING ATTR ===> A A Automatique, S Démarrage et exécution manuels

C Exécution uniquement, N Pas de génération d’états

FT Work station ===> Y Poste de travail FT, Y ou N

PRINTOUT ROUTING ===> SYSPRINT Nom de domaine de l’ensemble des données du plan quotidien

SERVER USAGE ===> N Utilisation des serveurs parallèles C , P , B ou N

Options :

SPLITTABLE ===> N Interruption d’opération autorisée, Y ou N

JOB SETUP ===> N Modification de JCL autorisée, Y ou N

STARTED TASK, STC ===> N Support des tâches en cours, Y ou N

WTO ===> N WTO automatique, Y ou N

DESTINATION ===> ________ Nom de la cible

Valeurs par défaut :

TRANSPORT TIME ===> 00.00 Délai à partir du poste de travail précédent HH.MM

DURATION ===> ________ Durée d’une opération normale HH.MM.SS

Figure 19. Définition d’un poste de travail d’agent étendu


Chapitre 5. Définition des travaux d’agent étendu

Ce chapitre explique comment définir les travaux Tivoli Workload Scheduler

associés aux travaux externes que vous voulez exécuter via des agents étendus.

Pour exécuter et contrôler un travail PeopleSoft, R/3, Oracle ou z/OS avec Tivoli

Workload Scheduler, l’agent étendu (ou la méthode d’accès) requiert une définition

de travail Tivoli Workload Scheduler, où vous spécifiez le travail externe que vous

envisagez de planifier, le poste de travail (également défini dans Tivoli Workload

Scheduler) sur lequel il est supposer s’exécuter ainsi que les actions de

récupération souhaitées. Pour définir le travail, vous pouvez utiliser :

v Tivoli Job Scheduling Console,

v la ligne de commande Tivoli Workload Scheduler.

Si vous planifiez dans un environnement de bout en bout, vous devez utiliser les

boîtes de dialogue ISPF de Tivoli Workload Scheduler pour z/OS pour définir le

travail. De plus, vous devez créer un membre dans le fichier SCRIPTLIB avec une

instruction JOBREC pour le travail.

Les travaux d’agent étendu sont ajoutés aux flux de travaux et planifiés comme

tout autre travail dans Tivoli Workload Scheduler et Tivoli Workload Scheduler

pour z/OS.

Définition des travaux avec Job Scheduling Console

Les étapes décrites ici pour définir un travail d’agent étendu sont communes à

toutes les méthodes d’accès. En outre, la méthode d’accès pour R/3 propose des

fonctions supplémentaires, si vous utilisez la procédure de substitution décrite à la

section «Utilisation des fenêtres SAP de Job Scheduling Console» à la page 102.

Pour toutes les méthodes d’accès, suivez les étapes ci-après :

1. Dans la liste Actions de la fenêtre principale de Job Scheduling Console,

sélectionnez Nouvelle définition de travail.

2. Sélectionnez un moteur Tivoli Workload Scheduler et, dans la liste affichée,

cliquez sur Tâche d’agent étendu. La page Général de la fenêtre Propriétés -

Définition du travail s’affiche.


3. Cette page vous permet de fournir des informations sur le travail Tivoli

Workload Scheduler qui gérera le travail externe. Complétez les zones de cette

fenêtre à l’aide de la table suivante.

Tableau 7. Page Général de la fenêtre Propriétés - Définition du travail (Description des

zones).

Zone Description

Type de tâche Zone en lecture seule devant afficher Tâche d’agent étendu.

Nom Nom du travail Tivoli Workload Scheduler que vous définissez. Ce

travail est destiné à gérer le travail de l’application externe dont vous

spécifierez le nom dans la prochaine page de cette fenêtre. Le nom

peut contenir jusqu’à 8 caractères alphanumériques si la base de

données n’est pas étendue, ou 40, si elle est étendue. Il peut inclure

des tirets et des caractères de soulignement, mais doit débuter par

une lettre. Les espaces imbriqués ne sont pas autorisés. Il peut être

identique au nom du travail externe, dans la mesure où celui-ci est

valide dans Tivoli Workload Scheduler.

Poste de travail Nom du poste de travail d’agent étendu sur lequel le travail est censé

s’exécuter. Vous pouvez cliquer sur les points de suspension (...) pour

afficher une fenêtre de recherche et sélectionner un poste de travail

disponible.

Description Description du travail ne devant pas excéder 64 caractères

alphanumériques. Cette zone est facultative.

Figure 20. Page Général de la fenêtre Propriétés - Définition du travail.


Tableau 7. Page Général de la fenêtre Propriétés - Définition du travail (Description des

zones). (suite)

Zone Description

Connexion Nom d’utilisateur nécessaire à l’exécution du travail dans Tivoli

Workload Scheduler. Normalement, il s’agit de la valeur du

paramètre LJuser, spécifiée lors de l’installation de Tivoli Workload

Scheduler for Applications, qui se trouve dans le fichier d’options de

la méthode. Ce doit être un utilisateur valide sur le poste de travail

hôte Tivoli Workload Scheduler, qui doit également pouvoir accéder

au produit externe. Ce paramètre est requis pour planifier le travail

dans Tivoli Workload Scheduler, où il apparaît dans différents écrans.

Si nécessaire, cliquez sur Ajouter un paramètre pour ajouter des

paramètres prédéfinis à l’ID de connexion.

Options de

récupération

Réponse automatique de Tivoli Workload Scheduler si le travail

s’arrête de manière anormale. La valeur par défaut est Arrêter. Pour

plus d’informations sur les options de récupération, reportez-vous au

manuel Tivoli Workload Scheduler - Guide de référence.

Message Message facultatif devant apparaître lorsque le travail s’arrête de

manière anormale. Aucun message prédéfini n’est accepté ici.

Travail Nom du travail de récupération devant démarrer automatiquement

lorsque le travail s’arrête de manière anormale. Cliquez sur les points

de suspension (...) pour afficher une fenêtre de recherche et

répertorier les travaux existants.

Poste de travail Nom du poste de travail propriétaire du travail de récupération.

4. Cliquez sur Tâche pour accéder à la page suivante. La page Tâche de la fenêtre

apparaît.

5. Cette page vous permet de fournir des informations sur le travail (ou tâche)

externe qui sera géré par le travail défini à la page précédente. Notez que la

Figure 21. Page Tâche de la fenêtre Propriétés - Définition du travail.

Chapitre 5. Définition des travaux d’agent étendu 39

tâche doit déjà avoir été définie dans l’application externe. Complétez les zones

de cette fenêtre à l’aide de la table suivante.

Tableau 8. Page Tâches de la fenêtre Propriétés - Définition du travail (Description des

zones).

Zone Description

Type de tâche Zone en lecture seule devant afficher Tâche d’agent étendu.

Commande Spécifications du travail externe (tâche). Chaque application

externe utilise un jeu de paramètres différents :

v Pour les travaux Oracle Applications, reportez-vous à la

section «Paramètres de chaîne de tâches pour les travaux

Oracle Applications» à la page 49.

v Pour les travaux PeopleSoft, reportez-vous à la section

«Paramètres des chaînes de tâches des travaux PeopleSoft» à la

page 77.

v Pour les travaux R/3, reportez-vous à la section «Paramètres

de chaîne de tâches pour les travaux R/3» à la page 109.

v Pour les travaux z/OS, reportez-vous à la section «Syntaxe de

définition de tâche pour les travaux z/OS planifiés avec Tivoli

Workload Scheduler» à la page 153.

Ecrivez les paramètres dans une chaîne se présentant sous le

format suivant :

-paramètre1 valeur1 -paramètre2

valeur2...-paramètren

valeurn

Cliquez sur Ajouter un paramètre... pour afficher une fenêtre de

recherche de paramètres où vous pouvez répertorier et ajouter

des paramètres Tivoli Workload Scheduler prédéfinis à la zone

Commande.

Expression du mappage

de code retour

Expression logique définissant les codes retour qui indiquent la

réussite de la tâche. Vous pouvez utiliser des opérateurs de

comparaison et des opérateurs logiques. Par exemple,

l’expression RC≥6 indique qu’un code retour supérieur ou égal

à 6 signifie que la tâche a été exécutée avec succès.

6. Cliquez sur OK pour enregistrer la définition du travail.

Définition des travaux à partir de la ligne de commande Tivoli

Workload Scheduler

Il est également possible de définir les travaux dans une ligne de commande

Composer de Tivoli Workload Scheduler. L’exemple suivant illustre un travail

Tivoli Workload Scheduler appelé orajob2 qui s’exécute sur un poste de travail

d’agent étendu Oracle Applications appelé ora002. Il se connecte à UNIX en tant

que orajobs et lance un travail sous Oracle Applications. Le travail Oracle

Applications est appelé poxacr et son propriétaire est global. En cas d’incident,

Tivoli Workload Scheduler exécutera le travail de récupération recov2, puis

continuera le traitement.

ora002#orajob2

streamlogon orajobs

scriptname "-user global

-job fnd ’application developer’ po poxacr


-prn ps4 2

-v1 ’abc’"

description "oracle apps job #2"

recovery continue after recov2

Notez que les arguments de scriptname diffèrent d’une application à l’autre. Pour

référence, reportez-vous aux sections :

v «Paramètres de chaîne de tâches pour les travaux Oracle Applications» à la page

49.

v «Paramètres des chaînes de tâches des travaux PeopleSoft» à la page 77.

v «Paramètres de chaîne de tâches pour les travaux R/3» à la page 109.

v «Syntaxe de définition de tâche pour les travaux z/OS planifiés avec Tivoli


Pour plus d’informations sur la définition des travaux via une ligne de commande,

reportez-vous au manuel Tivoli Workload Scheduler - Guide de référence.

Définition des travaux pour une planification de bout en bout

Les travaux d’agent étendu planifiés pour s’exécuter dans un environnement de

bout en bout ne peuvent pas être définis via une ligne de commande Job

Scheduling Console ou Tivoli Workload Scheduler. Ils doivent être ajoutés au

fichier SCRIPTLIB de Tivoli Workload Scheduler pour z/OS.

Dans l’écran ISPF OPERATIONS de Tivoli Workload Scheduler pour z/OS, les travaux

d’agent étendu sont définis comme tout autre travail, mais le choix d’un poste de

travail d’agent étendu révèle leur type. L’exemple suivant illustre la définition d’un

travail appelé SAPJOB. Il s’agit du travail Tivoli Workload Scheduler pour z/OS

destiné à gérer l’exécution d’un travail R/3 (appelé BAPRINT46B comme vous le

verrez dans l’exemple suivant). Il s’avère être un travail d’agent étendu,

uniquement parce que le poste de travail associé est un poste de travail d’agent

étendu appelé R3XA.

Pour chaque travail, un membre doit être créé dans le fichier SCRIPTLIB de Tivoli

Workload Scheduler pour z/OS, les détails relatifs au travail étant spécifiés dans

une instruction JOBREC. Un membre SAPJOB a été créé pour le travail de l’exemple

précédent, avec une instruction JOBREC se présentant comme suit :

JOBREC

JOBCMD(’/-job BAPRINT46B -user MAESTRO -i 14160001 -c C’)

JOBUSR(twsila)

--------------------------------- OPERATIONS -----------------Row 1 to 1 of 1

Command ===> Scroll ===> PAGE

Enter/Change data in the rows, and/or enter any of the following

row commands:

I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete

S - Select operation details, J - Edit JCL

Enter the TEXT command above to include operation text in this list, or,

enter the GRAPH command to view the list graphically.

Application : APLL1 FTW appl

Row Oper Duration Job name Internal predecessors Morepreds

cmd ws no. HH.MM.SS -IntExt-

’’’’ R3XA 001 00.00.01 SAPJOB___ ___ ___ ___ ___ ___ ___ ___ ___ 0 0

******************************* Bottom of data ********************************

Figure 22. Définition d’un travail d’agent étendu dans le cadre d’une planification de bout en bout.

Chapitre 5. Définition des travaux d’agent étendu 41

La chaîne incluse dans JOBCMD est lue et interprétée par la méthode d’accès,

préalablement à l’exécution du travail. Le travail de cet exemple, BAPRINT46B, a été

précédemment défini dans R/3 et associé à l’ID 14160001, manuellement transcrit

dans JOBCMD.

L’exemple suivant concerne un travail PeopleSoft. Notez que la chaîne qui suit le

mot clé JOBCMD doit figurer entre des guillemets doubles plutôt qu’entre des

guillemets simples. Ceci ne s’applique que dans le cas de travaux PeopleSoft

complexes, où des guillemets simples sont déjà utilisés dans la chaîne.

JOBREC

JOBCMD("/-operator PS -process XRFWIN -type ’SQR Report’ -runcontrol TWS")

JOBUSR(PsBuild)

Les arguments de JOBCMD diffèrent d’une application à l’autre. Pour référence,

reportez-vous aux sections :

v «Paramètres de chaîne de tâches pour les travaux Oracle Applications» à la page

49.

v «Paramètres des chaînes de tâches des travaux PeopleSoft» à la page 77.

v «Paramètres de chaîne de tâches pour les travaux R/3» à la page 109.

v «Syntaxe de définition de tâche pour les travaux z/OS planifiés avec Tivoli



Partie 2. Méthode d’accès Oracle e-Business Suite


Chapitre 6. Introduction

IBM Tivoli Workload Scheduler for Applications pour Oracle e-Business Suite vous

permet de planifier des travaux Oracle e-Business Suite grâce aux fonctions de

planification évoluées de Tivoli Workload Scheduler.

Tout au long de ce manuel, les termes Oracle Applications et Oracle e-Business

Suite sont utilisés indifféremment pour se référer au même produit.

L’hôte Tivoli Workload Scheduler, l’agent étendu Tivoli Workload Scheduler pour

Oracle e-Business Suite et l’instance Oracle e-Business Suite doivent être installés

sur le même noeud physique.

Fonctions

v Utiliser les dépendances de travail standard de Tivoli Workload Scheduler (à

l’exception des dépendances Open File).

v Planifier des travaux Oracle e-Business Suite devant s’exécuter à des jours et

heures spécifiques, dans un ordre déterminé.

v Définir des interdépendances entre les travaux Oracle Applications et ceux

s’exécutant sur des systèmes différents, tels que R/3 et PeopleSoft.

v Définir des interdépendances entre les travaux Oracle Applications et ceux

s’exécutant sur des plateformes différentes.

v Personnaliser les codes retour d’exécution des travaux.

Configuration logicielle requise

Pour installer et utiliser IBM Tivoli Workload Scheduler for Applications pour

Oracle e-Business Suite, vous devez disposer des éléments suivants, à savoir :

v Un des systèmes d’exploitation pris en charge suivant :

– HP-UX 11.0 ou 11.i,

– Environnement d’exploitation Solaris Versions 7, 8 ou 9,

– IBM AIX 4.3.3 ou 5.1.v Les logiciels installés suivants &:

– IBM Tivoli Workload Scheduler version 7.0 ou supérieure,

– Oracle Applications 10.7 ou Oracle e-Business Suite version 11.0 ou 11.i,

– Pour les utilisateurs AIX et HP uniquement, le compilateur gcc pour la

plateforme considérée. Les fichiers binaires du compilateur gcc peuvent être

téléchargés à partir de différentes sources sur le Web.

Pour obtenir une liste mise à jour des plateformes prises en charge, contactez le

service d’assistance à la clientèle.

Tâches post-installation

Une fois le produit installé selon la procédure décrite au Chapitre 2, «Installation

d’IBM Tivoli Workload Scheduler for Applications», à la page 5, exécutez les étapes

suivantes pour terminer l’installation de la méthode d’accès pour Oracle e-Business

Suite :


1. Connectez-vous avec un ID d’utilisateur Unix Oracle Applications ayant accès

à tous les fichiers dans le répertoire principal d’Oracle Applications.

2. Accédez au répertoire d’installation :

cd <racine_TWS>/methods/OracleTMP

Remarque : Si vous utilisez la base de données de démonstration d’Oracle

Applications, remplacez le fichier indiqué aux étapes 3 et 4 par

APPDEMO.env. 3. Modifiez le fichier Oracle Applications APPLSYS.env comme suit :

a. Ajoutez MCM aux variables APPLSHAR et APPLFULL.

APPLSHAR=’ALR FF MCM’

APPLFUL=’FND AD AX AK GL RG INV OP MCM’

b. Définissez et exportez la variable de shell MCM_TOP :

MCM_TOP=$APPL_TOP/mcm/integration

export MCM_TOP

c. Ajoutez $MCM_TOP/bin à la variable PATH en entrant les lignes suivantes au

bas du fichier APPLSYS.env :

PATH=$PATH:$MCM_TOP/bin

export PATH

4. Exécutez le fichier APPLSYS.env pour définir l’environnement :

. APPLSYS.env

Remarque : Vérifiez que la connexion Oracle Applications dispose des droits

requis pour écrire dans les répertoires racine_TWS et methods. 5. Modifiez les caractéristiques de propriété Utilisateur et Groupe des fichiers

installés en leur attribuant celles du propriétaire Oracle Applications.

6. Accédez au répertoire /temp/usrxit.

7. Pour les utilisateurs AIX et HP uniquement :

v Etant donné le format des objets MCMxxx.o, vous devez utiliser le

compilateur gcc pour que votre plateforme puisse exécuter les étapes

suivantes. Les fichiers binaires du compilateur gcc peuvent être téléchargés

à partir de différentes sources sur Internet.

v Pour les utilisateurs AIX uniquement : personnalisez le script adrelink

fourni par Oracle pour les options de réédition de liens gcc :

a. Localisez la ligne suivante :

AIXRIOS) LDFLAGS=’-s -H512 -T512 -bhalt:4

-brtl -L$(ORACL ....’

b. Supprimez l’expression

-H512 -T512 -bhalt:4 -brtl

de cette ligne, afin qu’elle se présente comme suit :

AIXRIOS) LDFLAGS=’-s -L$(ORACL ....’

v Vérifiez que le compilateur gcc est configuré dans le chemin d’accès à

l’environnement du propriétaire de l’application. Vous pouvez également

modifier le fichier mcm.mk fourni avec le produit en y insérant le chemin

d’accès complet à gcc dans la ligne

CC="gcc"

Remarque : IBM Tivoli Workload Scheduler for Applications pour Oracle

e-Business Suite prend uniquement en charge la version 2.x du

compilateur gcc. La version 3.x n’est pas prise en charge.


8. Exécutez le script d’installation mcminstall à partir du répertoire Temp.

Utilisez la commande suivante :

sh mcminstall

Un écran Tivoli Oracle apparaît.

9. Répondez aux questions de l’écran en fonction de vos paramètres Oracle

Applications et de ceux de votre installation Tivoli Workload Scheduler.

Le processus d’installation tente à présent de créer des liens entre les

exécutables Tivoli Workload Scheduler for Applications et les bibliothèques

partagées d’Oracle Applications.

Une fois le processus d’édition des liens terminé, les exécutables ci-dessous

doivent se trouver dans le répertoire $MCM_TOP/bin :

v MCMLJ

v MCMSTAT

v MCMTJ

Ces fichiers binaires sont créés par l’utilitaire adrelink pour Oracle

Applications, qui enregistre également MCM comme module dans AOL.

Si vous rencontrez des problèmes lors de l’édition des liens, vous devez

absolument les corriger et réexécuter l’étape, car celle-ci est essentielle pour la

création des fichiers binaires qui permettent à Tivoli Workload Scheduler for

Applications d’interagir avec Oracle Concurrent Manager au niveau de la

soumission et du contrôle des travaux.

10. Editez le fichier d’options. Reportez-vous au Chapitre 8, «Informations de

référence sur le fichier d’options MCMAGENT», à la page 53 et au Chapitre 3,

«Définition des options à l’aide de l’Editeur d’options», à la page 27 pour plus

de détails.

L’installation est à présent terminée. Consultez la documentation IBM Tivoli

Workload Scheduler pour plus de détails sur le démarrage de Batchman, la

définition des postes de travail, des travaux et des autres opérations Tivoli

Workload Scheduler.

Programmes d’interface

L’interface entre Tivoli Workload Scheduler et Oracle e-Business Suite comprend

les programmes suivants :

MCMAGENT

Méthode d’accès d’IBM Tivoli Workload Scheduler for Applications pour

Oracle e-Business Suite.

MCMLJ

Soumet un travail à Oracle Concurrent Manager (OCM).

MCMSTAT

Surveille l’état du travail soumis.

MCMTJ

Termine le travail soumis, lorsque Tivoli Workload Scheduler envoie un

signal ″kill″.

mcm.mk

Utilitaire makefile permettant de lier les programmes ci-dessus avec Oracle

Applications.

Chapitre 6. Introduction 47

MCMAGENT.opts

Fichier d’options globales contenant les paramètres de configuration de la

méthode d’accès. Ce fichier est créé par le processus d’installation de Tivoli

Workload Scheduler for Applications, avec certaines valeurs que vous avez

entrées durant l’installation. Reportez-vous au Chapitre 8, «Informations de

référence sur le fichier d’options MCMAGENT», à la page 53 et au

Chapitre 3, «Définition des options à l’aide de l’Editeur d’options», à la

page 27 pour plus de détails.

<NOM_POSTE_DE_TRAVAIL>_MCMAGENT.opts

Fichier d’options locales contenant les paramètres de configuration de

l’agent étendu. Ce fichier est obligatoire pour chaque poste de travail

d’agent étendu que vous définissez. Reportez-vous au Chapitre 8,

«Informations de référence sur le fichier d’options MCMAGENT», à la

page 53 et au Chapitre 3, «Définition des options à l’aide de l’Editeur

d’options», à la page 27 pour plus de détails.


Chapitre 7. Informations sur la définition des travaux

Ce chapitre fournit des informations sur la définition des travaux Oracle

Applications dans Tivoli Workload Scheduler.

Définition des travaux dans Oracle Applications

Dans Oracle Applications, les travaux qui doivent être planifiés via Tivoli

Workload Scheduler sont définis de la même manière que les autres travaux Oracle

Applications (et peuvent être soumis dans OCM). Lorsque vous soumettez un

travail dans OCM, vous devez spécifier les informations de planification et de

resoumission. Lorsque vous soumettez le travail via Tivoli Workload Scheduler,

celui-ci prend en charge les informations de planification et de resoumission.

Pour définir un travail, utilisez les exécutables et les formulaires Define Concurrent

Program et entrez les informations générales sur le travail. Le travail peut alors

être planifié à partir de Tivoli Workload Scheduler ; il peut également être soumis

dans OCM.

Exécutions simultanées d’un même travail

Si un travail Oracle Applications est planifié pour s’exécuter plusieurs fois dans

Tivoli Workload Scheduler et que Tivoli Workload Scheduler lance les différentes

instances en parallèle, les travaux s’exécuteront normalement. Toutefois, si

l’utilisateur Oracle Applications a spécifié que plusieurs instances du travail ne

pouvaient pas s’exécuter simultanément, le deuxième travail sera mis en attente

(état WAIT) jusqu’à ce que le premier travail soit terminé.

Définition des travaux Oracle Applications dans Tivoli Workload

Scheduler

Une définition de travail Tivoli Workload Scheduler est requise pour chaque travail

Oracle Applications que vous envisagez de planifier. Les travaux Oracle

Applications sont définis dans Tivoli Workload Scheduler comme tout autre

travail ; ils incluent un nom de travail, un nom d’utilisateur et des options de

récupération. Reportez-vous au Chapitre 5, «Définition des travaux d’agent

étendu», à la page 37.

Paramètres de chaîne de tâches pour les travaux Oracle

Applications

Cette section décrit les paramètres des chaînes de tâches qui gèrent l’exécution des

travaux Oracle Applications. Vous devez les spécifier aux emplacements suivants

lorsque vous définissez les travaux Tivoli Workload Scheduler qui leur sont

associés :

v Dans la zone Commande de la page Tâche de la fenêtre Propriétés - Définition

du travail, si vous utilisez Job Scheduling Console.

v En tant qu’arguments du mot clé scriptname dans l’instruction de définition du

travail, si vous utilisez la ligne de commande Tivoli Workload Scheduler.

v En tant qu’arguments du mot clé JOBCMD dans l’instruction JOBREC du fichier

SCRIPTLIB de Tivoli Workload Scheduler pour z/OS, si vous planifiez dans un

environnement de bout en bout.


Ces paramètres sont décrits dans le tableau ci-après.

Tableau 9. Paramètres de chaîne de tâches pour les travaux Oracle Applications.

Paramètre Description

-user appslogin

Nom d’un utilisateur Oracle Applications valide

(Appslogin).

-job jobspecs

Attributs du travail Oracle Applications. Quatre

attributs doivent être spécifiés dans l’ordre suivant,

à savoir :

v le nom du module Applications utilisé pour se

connecter à Oracle Applications (par exemple,

FND),

v une autorité valide pour le module Applications

(par exemple, ‘développeur d’applications’, à

inclure entre des guillemets simples),

v le nom de l’application qui a enregistré le travail

(par exemple, PO),

v le nom du travail (par exemple, POXACR). Le nom

du travail doit être en majuscules.

Par exemple :

-job FND ’développeur d’applications’ PO POXACR

-prn printopts

Options d’impression du travail, au nombre de

deux. Ces options doivent être entrées dans l’ordre

suivant :

v nom de l’imprimante (facultatif). En cas

d’omission, l’imprimante par défaut spécifiée

dans le fichier d’options sera utilisée,

v nombre de copies.

Par exemple :

-prn ps4 2


Tableau 9. Paramètres de chaîne de tâches pour les travaux Oracle Applications. (suite)


[-vn (’valeur’|null|:paramètre)]

Paramètres du travail, s’ils existent. Cette chaîne est

facultative si aucun paramètre n’est spécifié pour le

travail dans Oracle Applications.

v n correspond au numéro du paramètre (v1, v2,

etc.),

v l’une des options suivantes :

valeur Valeur réelle. Faites figurer la valeur

entre des guillemets simples si elle

contient des caractères spéciaux.

:paramètre

Nom d’un paramètre Tivoli Workload

Scheduler déjà défini. Pour plus

d’informations sur les paramètres Tivoli

Workload Scheduler, reportez-vous au

manuel Tivoli Workload Scheduler - Guide

de référence.

La méthode d’accès ajoutera automatiquement

tous les paramètres que vous n’avez pas spécifiés

dans la définition en leur associant la valeur

null.

Voici deux exemples :

-v4 ’abc’

-v15 :p1

Voici, à titre d’exemple, comment peut se présenter une chaîne de tâches

complète :

-user GLOBAL -job FND ’Développeur d’applications’ PO POXACR -prn ps4 2 -v1

’abc’

Chapitre 7. Informations sur la définition des travaux 51

Etats des travaux Tivoli Workload Scheduler et Oracle Applications

Lorsqu’un travail Oracle Applications est lancé par Tivoli Workload Scheduler,

vous pouvez surveiller sa progression grâce à Conman. Les transitions d’état

utilisées dans Tivoli Workload Scheduler et leurs correspondances dans Oracle

Applications sont répertoriées ci-dessous.

Etats d’Oracle Concurrent Manager Etats de Tivoli Workload Scheduler

Request Failure ou Request not Found UT (unsup. task - tâche non prise en charge)

Inactive SUSP

Pending WAIT

Pending Normal ADD

Running Normal EXEC

Completed Normal SUCC

Completed Warning SUCC

Completed Error ABEND

Completed Terminated ABEND

Completed Canceled ABEND

Pour plus d’informations sur la gestion des travaux, reportez-vous au manuel

Tivoli Workload Scheduler - Guide de référence.


Chapitre 8. Informations de référence sur le fichier d’options

MCMAGENT

Cette section fournit des informations de référence détaillées sur le fichier

d’options IBM Tivoli Workload Scheduler for Applications pour Oracle e-Business

Suite.

Fichier d’options

Toute instance installée de la méthode d’accès Oracle doit avoir un fichier

d’options dédié. Celui-ci peut être créé au cours ou à l’issue de l’installation de la

méthode d’accès, avec l’Editeur d’options (voir Chapitre 3, «Définition des options

à l’aide de l’Editeur d’options», à la page 27) ou un quelconque éditeur de texte. Il

doit, en outre, répondre à la convention de dénomination

<NOM_POSTE_DE_TRAVAIL>_MCMAGENT.opts et être situé dans le répertoire

racine_TWS/methods. Si vous ne créez pas de fichier d’options, l’agent utilisera, par

défaut, le fichier d’options globales appelé MCMAGENT.opts.

Syntaxe des entrées

Le tableau suivant répertorie les options de la méthode d’accès MCMAGENT.

Tableau 10. Options MCMAGENT.

Option Description

ORACLE_HOME Répertoire Unix où le logiciel Oracle est installé.

ORACLE_SID Identificateur système Oracle de l’instance de base de

données à laquelle vous vous connectez. Correspond à la

valeur de la variable Oracle Applications $ORACLE_SID.

ORA_APP_TOPDIR Répertoire Unix où Oracle Applications est installé.

FND_TOPDIR Répertoire principal FND où réside la bibliothèque

Application Object.

PATH Paramètre de la variable PATH, incluant le chemin

existant, le chemin du répertoire bin d’Oracle

Applications, le chemin du répertoire include en aval du

répertoire principal FND et d’autres, le cas échéant.

ENV Fichier d’environnement à exécuter. Chaque instance

d’Oracle Applications a son propre fichier

d’environnement (APPLSYS.env ou APPDEMO.env). Le

nom de fichier .env attribué ici sera utilisé pour définir

dynamiquement l’environnement lorsque Tivoli

Workload Scheduler exécutera des travaux sur l’agent

étendu Oracle Applications.

USERID ID utilisateur de base de données ayant accès à tous les

modules Oracle Applications. Cet ID doit pouvoir lancer,

gérer et terminer des travaux dans Oracle Applications.

PASSWORD Mot de passe associé à l’ID utilisateur sélectionné. Pour

obtenir la valeur codée, utilisez l’utilitaire enigma fourni

avec le produit. Reportez-vous à la section «Chiffrage des

mots de passe utilisateur Oracle Applications» à la page

54.

PRINTER_NAME ID de l’imprimante par défaut.


Tableau 10. Options MCMAGENT. (suite)

Option Description

MIN_TIME Nombre de secondes à ajouter au précédent délai

d’invitation à émettre, à l’issue duquel le statut du travail

doit être contrôlé.

MAX_TIME Nombre de secondes à l’issue duquel le délai d’invitation

à émettre ne sera pas incrémenté.

Toutes les options sont obligatoires et doivent être écrites à raison d’une par ligne,

selon le format :

OPTION=VALEUR

sans aucun espace.

Exemple

Le fichier HP113_MCMAGENT.opts est un exemple de fichier d’options :

ORACLE_HOME=/general/ora716

ORACLE_SID=DEMO106

ORA_APP_TOPDIR=/apps106

FND_TOPDIR=$APPL_TOP/fnd/*

PATH=$PATH:$ORACLE_HOME/bin:$FND_TOP/include

ENV=$APPL_TOP/APPDEMO106.env

USERID=APPS_US

PASSWORD=APPS_US

PRINTER_NAME=PRINTER1

MIN_TIME=10

MAX_TIME=200

Chiffrage des mots de passe utilisateur Oracle Applications

Lorsque vous entrez des paramètres dans le fichier d’options, la valeur du mot de

passe est automatiquement chiffrée avant d’être écrite dans le fichier. Si vous

modifiez le fichier avec un éditeur de texte, vous devez exécuter le programme

enigma pour chiffrer le mot de passe avant de l’écrire dans le fichier. Exécutez le

programme enigma comme suit :

enigma [mot_de_passe]

Vous pouvez inclure le mot de passe dans la ligne de commande ou l’entrer dans

une réponse à une invite. Le programme renvoie une version chiffrée que vous

pouvez alors entrer dans le fichier d’options.


Partie 3. Méthode d’accès PeopleSoft



IBM Tivoli Workload Scheduler for Applications pour PeopleSoft vous permet

d’exécuter et de contrôler des travaux PeopleSoft à partir de l’environnement Tivoli

Workload Scheduler. Ces travaux peuvent être exécutés dans le cadre d’un

calendrier ou soumis en vue d’un traitement ponctuel. Les travaux d’agent étendu

PeopleSoft peuvent bénéficier des mêmes dépendances et options de récupération

que les autres travaux Tivoli Workload Scheduler. Les travaux PeopleSoft doivent

être documentés dans Tivoli Workload Scheduler pour être exécutés et contrôlés

dans l’environnement Tivoli Workload Scheduler.

Fonctions

v L’agent étendu pour les versions 7.0, 7.5 et 8.x de PeopleSoft a été certifié par

PeopleSoft sous Windows NT 4.0 avec le Service Pack 6 et sous Windows 2000.

v Prise en charge de PeopleSoft 8.x.

v Utiliser les dépendances de travail Tivoli Workload Scheduler standard pour les

travaux PeopleSoft.

v Planifier des travaux PeopleSoft devant s’exécuter à des jours et heures

spécifiques, dans un ordre déterminé.

v Définir des interdépendances entre les travaux PeopleSoft et les travaux Tivoli

Workload Scheduler s’exécutant sur des applications différentes, telles que R/3

et Oracle.

v Définir des interdépendances entre les travaux PeopleSoft et ceux s’exécutant sur

des plateformes différentes.


Principes de fonctionnement

Tivoli Workload Scheduler peut lancer et contrôler des travaux dans le

planificateur de traitement PeopleSoft à partir d’un poste de travail d’agent étendu

PeopleSoft. L’agent étendu PeopleSoft est décrit dans une définition de poste de

travail Tivoli Workload Scheduler standard. Cette définition est un nom de poste

de travail logique qui spécifie la méthode d’accès en tant que psagent. La méthode

d’accès est utilisée pour communiquer les demandes de travaux au planificateur de

traitement PeopleSoft.

Pour lancer un travail PeopleSoft, Tivoli Workload Scheduler exécute la méthode

psagent et lui transmet les informations relatives au travail. Un fichier d’options

fournit la méthode avec le chemin, l’exécutable et d’autres informations sur le

planificateur de traitement PeopleSoft et le serveur d’applications utilisé pour

lancer le travail. L’agent étendu peut alors accéder à la table des demandes de

traitement PeopleSoft et insérer une entrée dans la table pour lancer le travail. La

progression du travail et les informations de statut sont reportées dans le fichier

Stdlist du travail.


Travaux du planificateur de traitements PeopleSoft

Le planificateur de traitements PeopleSoft utilise les entrées de la table des

demandes de traitement (PSPRCSRQST) pour gérer ses décisions. Ces entrées

décrivent les traitements qui seront lancés par l’agent serveur du planificateur de

traitements. Elles contiennent également les informations requises pour déterminer

le statut du traitement. La méthode d’accès PeopleSoft peut insérer des entrées,

interroger le contenu et modifier les informations de statut à l’intérieur de cette

table (PSPRCSRQST).

Lorsqu’il documente un travail PeopleSoft dans Tivoli Workload Scheduler,

l’utilisateur définit de fait une demande de traitement qui sera insérée dans la table

des demandes de traitement (PSPRCSRQST). Une demande de traitement émanant de

Tivoli Workload Scheduler doit contenir trois éléments de données valides :

v une définition de traitement avec deux paramètres :

– type de traitement,

– nom du traitement,v un ID opérateur (non requis pour une exécution sous PeopleSoft 8.x),

v un ID de contrôle d’exécution.

Tous ces éléments sont requis pour qu’un travail PeopleSoft puisse s’exécuter. La

méthode d’accès PeopleSoft met directement à jour la table PSPRCSRQST pour

PeopleSoft 7.x (connexion à 2 niveaux), alors que pour PeopleSoft 8.x elle exploite

le serveur d’applications PeopleSoft via l’interface exposée par l’interface du

composant PROCESSREQUEST (connexion à 3 niveaux).

Notez que le planificateur de traitements et le serveur d’applications s’exécutent

sous Unix et sur les postes de travail FTA Windows pris en charge, alors que

l’agent étendu ne s’exécute que sous Windows NT ou sous Windows 2000.

Suivi des travaux PeopleSoft dans Tivoli Workload Scheduler

Dans PeopleSoft, un travail est constitué d’une collection de traitements qui

s’exécutent ensemble en tant qu’unité unique. Les travaux Tivoli Workload

Scheduler peuvent être définis à l’aide de l’une des méthodes suivantes :

v En tant que travaux PeopleSoft, c’est-à-dire sous forme de collection de

traitements PeopleSoft. Dans ce cas, le système effectue le suivi du statut du

travail PeopleSoft, et non de chaque traitement constituant le travail.

v En tant que traitement PeopleSoft. Dans ce cas, le suivi du statut de chaque

traitement est effectué et les calendriers Tivoli Workload Scheduler peuvent être

définis de manière à créer des interdépendances complexes et des options de

récupération entre les traitements PeopleSoft.

Sécurité

La sécurité des travaux PeopleSoft est traitée au niveau de la sécurité Tivoli

Workload Scheduler standard.

Remarques sur le support PeopleSoft Version 8.x

Le support PeopleTools 8.x comporte quelques modifications que vous devriez

connaître si vous envisagez d’utiliser la méthode x-agent dans votre

environnement.


v Le mot clé -operator utilisé dans les spécifications de travaux Tivoli Workload

Scheduler et le paramètre correspondant sont actuellement ignorés par la

méthode psagent et le contexte d’exécution. En conséquence, les travaux seront

soumis et s’exécuteront avec le même ID d’opérateur PS que celui utilisé pour la

connexion avec PeopleSoft. Vous n’avez pas à modifier vos définitions de

travaux Tivoli Workload Scheduler si vous migrez de PeopleTools 7.x vers

PeopleTools 8.x. La seule différence sera que tous les travaux soumis à un agent

étendu PeopleSoft 8.x s’exécuteront sous le même ID que celui spécifié dans le

fichier <NOM_CPU>_psagent.opts.

v Il n’est pas nécessaire d’installer la connectivité de base de données sur les

agents tolérants aux pannes hébergeant des agents étendus PeopleSoft, étant

donné que la méthode utilise actuellement l’architecture PeopleSoft à 3 niveaux.

Toutefois, vous devrez configurer au moins un serveur d’applications PeopleSoft

pour que l’agent étendu fonctionne. Le serveur d’applications doit être actif afin

de pouvoir soumettre les travaux au planificateur de traitements PeopleSoft.

v Il est inutile de charger TVPUPSFT.dms dans la base de données PeopleSoft 8.x

lorsque vous travaillez en mode 3 niveaux.

v Pour PeopleSoft 8.1x, la méthode requiert l’installation du support d’API externe

PeopleSoft sur l’agent tolérant aux pannes qui héberge la méthode d’agent

étendu. Le répertoire d’installation de l’API externe est utilisé durant les

traitements d’installation et de configuration de l’agent étendu, lorsque vous

devez spécifier le répertoire de base PeopleSoft ou le répertoire racine COBOL.

Pour installer l’API externe, utilisez l’exécutable setup.exe situé dans le

répertoire du serveur de fichiers PeopleSoft 8.1x appelé :

<racine_PS>\setup\PsExtAPI. L’installation de l’API externe PeopleSoft doit

s’effectuer avant celle de Tivoli Workload Scheduler for Applications. Vérifiez

l’installation de l’API externe selon les instructions de PeopleSoft, à savoir en

utilisant l’outil jnitest.exe situé dans le répertoire d’installation de l’API

externe PS. Vous devrez redémarrer votre poste de travail avant de pouvoir

utiliser l’installation de PsExtAPI. Si vous ne redémarrez pas votre poste de

travail, vous verrez apparaître une fenêtre (générée par TVPUPSFT.exe) avec le

message suivant :

"The application failed to initialize properly (0xc0000005). Click on OK to

terminate the application"


Chapitre 10. Planification d’implémentation

PeopleSoft version 7.5 ou antérieure

Cette section décrit la planification d’implémentation de l’agent étendu avec

PeopleSoft version 7.5 ou antérieure.

Configuration requise pour l’hôte

Le poste de travail hébergeant l’agent étendu doit répondre aux exigences

suivantes, à savoir :

v Etre un agent tolérant aux pannes (FTA) ou un agent standard (SA) de Tivoli

Workload Scheduler s’exécutant dans une version prise en charge de Windows.

v Disposer d’un accès réseau à la base de données PeopleSoft.

v Pouvoir être un poste de travail PeopleSoft.

v Avoir accès aux bibliothèques de support PeopleSoft et COBOL. Le support

COBOL doit être compatible avec le compilateur utilisé pour l’environnement du

planificateur de traitements NT.


IBM Tivoli Workload Scheduler for Applications pour PeopleSoft requiert les

logiciels suivants :

v Windows NT 4.0 avec Service Pack 6 ou Windows 2000 avec Service Pack 2,

v IBM Tivoli Workload Scheduler version 7.0 ou ultérieure,

v PeopleSoft version 7.0 ou 7.5,

v Compilateur COBOL PeopleSoft.

Remarques :

1. L’agent étendu pour PeopleSoft versions 7.0 et 7.5 est disponible avec

MicroFocus NetExpress 2.1 et MicroFocus NetExpress 3.1.

2. L’agent étendu pour PeopleSoft version 7.0 était également compilé avec le

compilateur COBOL MicroFocus version 4.1.

3. Pour les versions Peoplesoft 7.x, vous devez recompiler le planificateur de

traitements PeopleSoft sous Windows si vous voulez l’utiliser pour les travaux

gérés via Tivoli Workload Scheduler.

Configuration de l’utilisateur Windows

v Créez un ID utilisateur de domaine, ou local, ayant accès à la fois au logiciel

PeopleSoft et à Tivoli Workload Scheduler, ou configurez l’utilisateur existant

pour qu’il puisse accéder au logiciel PeopleSoft et à Tivoli Workload Scheduler.

Reportez-vous à la section «Configuration utilisateur pour Windows» à la page

65 pour plus de détails.

v Connectez-vous avec ce nouvel ID.

v Connectez-vous aux unités appropriées pour PeopleSoft et vérifiez que l’option

Se reconnecter à l’ouverture de session est sélectionnée. L’indicatif d’unité doit

être identique à celui que vous avez spécifié pour PSDRIVE dans le fichier

psagent.opts .

v Effectuez la configuration au niveau de PeopleSoft. Suivez les instructions

fournies avec votre logiciel PeopleSoft.


Vérification de l’environnement PeopleSoft

Vérifiez que votre environnement PeopleSoft est correctement configuré et que les

travaux PeopleSoft peuvent être exécutés sans incident par le planificateur de

traitements.

Remarques :

1. Vérifiez la connectivité avec la base de données PeopleSoft à l’aide de l’ID

utilisateur Windows créé précédemment. Pour tester la connexion, exécutez une

commande de base de données à partir d’un quelconque utilitaire ODBC.

2. Vérifiez l’accès au serveur de fichiers PeopleSoft ou la présence d’une copie

locale des exécutables.

Création d’un ID de traitement par lots dans PeopleSoft

Vous pouvez créer, dans PeopleSoft, un ID d’opérateur dédié à la planification des

lots. Tous les travaux soumis par Tivoli Workload Scheduler peuvent utiliser cet ID

d’opérateur.

Fichiers installés

Les fichiers suivants sont installés dans les répertoires Tivoli Workload Scheduler

et PeopleSoft lors de l’installation de Tivoli Workload Scheduler for Applications :

Destination Fichiers Propriétaire

racine_TWS

\methods\PeopleSoft

v TVPUPSFT7xx.dms, où xx

spécifie l’édition de

PeopleSoft version 7.

v PTCUDCOP.cbl

Utilisateur Tivoli

Workload Scheduler

racine_TWS\methods v psagent.exe

v enigma.exe

Utilisateur Tivoli

Workload Scheduler

<PSDRIVE_PSVER>\cblbin v TVPUPSFT.exe

v TVPUPSFT.gnt

Propriétaire de

PTPUPRCS.exe

Remarque : racine_TWS représente le nom du répertoire où vous avez installé

Tivoli Workload Scheduler.

PeopleSoft version 8.x

Cette section décrit le planning d’implémentation de l’agent étendu avec

PeopleSoft version 8.x.

Configuration requise pour l’hôte

Le poste de travail hébergeant l’agent étendu doit être un agent tolérant aux

pannes (FTA) ou un agent standard (SA) de Tivoli Workload Scheduler s’exécutant

sur une plateforme Windows prise en charge.

Si votre site compte plusieurs serveurs de processus pour une seule base de

données PeopleSoft, vous pouvez configurer un poste de travail d’agent étendu

(avec plusieurs fichiers d’options) pour traiter les travaux sur les différents

serveurs de processus.



IBM Tivoli Workload Scheduler for Applications pour PeopleSoft requiert les

logiciels suivants :

v Windows NT 4.0 avec Service Pack 6 ou Windows 2000 avec Service Pack 2,

v IBM Tivoli Workload Scheduler version 7.0 ou supérieure,

v PeopleSoft version 8.1x ou 8.4x,

v Pour PeopleSoft version 8.1x : API externes de PeopleTools version 8.1x.

v Pour PeopleSoft version 8.4x : accès à PeopleSoft File Server 8.4x ou présence

d’une copie locale des exécutables.

Création d’un ID de traitement par lots dans PeopleSoft

Vous pouvez créer, dans PeopleSoft, un ID d’opérateur dédié à la planification des

lots. Cet ID d’opérateur doit pouvoir utiliser l’interface de composants dans

l’environnement PeopleTools. Tous les travaux soumis par IBM Tivoli Workload

Scheduler peuvent utiliser cet ID d’opérateur.

Fichiers installés

Les fichiers suivants sont installés dans les répertoires IBM Tivoli Workload

Scheduler et PeopleSoft lors de l’installation de IBM Tivoli Workload Scheduler for

Applications pour PeopleSoft :

Destination Fichiers Propriétaire

racine_TWS\methods v psagent.exe

v enigma.exe

Utilisateur Tivoli Workload

Scheduler

répertoire PSAPI TVPUPSFT.exe Utilisateur Tivoli Workload

Scheduler

Remarque : racine_TWS représente le nom du répertoire où vous avez installé


Chapitre 10. Planification d’implémentation 63

Chapitre 11. Tâches post-installation

Ce chapitre décrit les tâches importantes qui doivent suivre l’installation de la

méthode d’accès.

Configuration utilisateur pour Windows

Lorsqu’un client PeopleSoft est utilisé pour soumettre des travaux via IBM Tivoli

Workload Scheduler for Applications pour PeopleSoft dans l’environnement à trois

niveaux, à l’aide d’une ressource partagée sur un serveur de fichiers PeopleSoft, la

connexion au flux (Streamlogon) spécifiée lors de la soumission du travail doit être

″connue″ à la fois du client soumettant le travail et du serveur de fichiers

PeopleSoft. Ce doit donc être :

v Soit un utilisateur de domaine.

v Soit un utilisateur local défini sur le serveur de fichiers PeopleSoft et sur le client

PeopleSoft avec les mêmes nom et mot de passe. L’utilisateur doit alors être

défini dans la base de données Tivoli Workload Scheduler.

Si cette condition n’est pas respectée, les événements suivants se produiront :

v Les travaux s’arrêteront de manière anormale.

v Deux messages d’erreur avec le texte suivant seront envoyés par le système

d’exploitation au fichier Stdlist du travail :

Logon failure: unknown user name or bad password.

procwork.cpp(328): The pipe has ended.

L’utilisateur doit également faire partie du groupe Administrateur sur le client

PeopleSoft. Si tel n’est pas le cas, les événements suivants se produiront :

v Les travaux passeront à l’état INTRO (et un signe Plus ″+″ sera ajouté, indiquant

un travail actif).

v Une fenêtre en incrustation apparaîtra sur le poste de travail Tivoli Workload

Scheduler hébergeant l’agent étendu, avec le titre psagent.exe - Application

Error et le texte suivant :

The application failed to initialize properly (0xc0000005).

Click on OK to terminate the application.

v Une fois que vous aurez cliqué sur le bouton OK, les travaux passeront à l’état

ABEND et le fichier Standlist du travail affichera uniquement la bannière du

programme JOBLNCH.

Création du fichier d’options

Les fichiers d’options d’agent étendu PeopleSoft spécifient, entre autres,

l’utilisateur avec lequel la méthode se connecte à la base de données PeopleSoft. Ils

sont également utilisés pour spécifier la fréquence d’interrogation appliquée au

module PeopleSoft pour la vérification du statut des travaux.

Ce fichier doit résider sur l’ordinateur hôte de l’agent étendu, dans le répertoire

racine_TWS\methods.


Pour créer un fichier d’options, vous pouvez utiliser soit le programme Editeur

d’options fourni avec ce produit, soit un éditeur de texte de votre choix.

Reportez-vous au Chapitre 3, «Définition des options à l’aide de l’Editeur

d’options», à la page 27 pour plus de détails sur la création ou la modification de

fichiers d’options avec l’Editeur d’options et à la section «Modification manuelle

des fichiers d’options» à la page 68 pour consulter des exemples de fichiers

d’options propres à cette méthode d’accès.

Le tableau suivant décrit les options de la méthode d’accès psagent :

Tableau 11. Options Psagent.

Option Description

LJuser ID de l’utilisateur Windows qui lance les travaux IBM Tivoli Workload

Scheduler. Cet utilisateur Windows doit être un utilisateur Tivoli Workload

Scheduler valide sur le poste de travail hôte.

CFuser ID de l’utilisateur Windows qui exécute un contrôle de fichiers. La valeur

par défaut correspond à celle de LJuser.

CheckInterval Intervalle de temps entre les vérifications de statut lors du contrôle d’une

demande de traitement. La valeur par défaut est de 2 minutes. Utilisez

l’option CheckIntervalUnits pour passer de minutes en secondes.

CheckIntervalUnits Spécifie que l’intervalle entre les vérifications de statut est en secondes

(valeur = 1) ou en minutes (valeur = 60).

PSXA_TRACE Entrez la valeur 1 pour activer l’exécution de la trace ou 0 pour la

désactiver.

PSDRIVE Identificateur d’unité Windows pour les fichiers PeopleSoft (par exemple,

N:).

PSVER Répertoire de base des fichiers PeopleSoft (par exemple, \PT7.5 ou \PT8)

pour toutes les version PeopleSoft, sauf 8.1x. Dans ce cas, il s’agit du

répertoire où le fichier TVPUPSFT.exe est installé (par exemple,

\PT817\bin\client\winx86_extapi).

COBROOT Pour PeopleSoft 7.x : chemin d’accès au répertoire principal des

bibliothèques COBOL Micro Focus (par exemple, N:\PT7.5).

Pour PeopleSoft 8.x : chemin d’accès au répertoire principal des API

externes PeopleSoft, qui est identique au répertoire de base PeopleSoft.


Tableau 11. Options Psagent. (suite)

Option Description

CONNECT Chaîne contenant les entrées suivantes :

Type de connexion

Type de SGBDR PeopleSoft. Choisissez l’une des options suivantes :

v APPSERV (PeopleSoft 8.x uniquement)

v ORACLE

v MICROSFT (Microsoft SQL Server)

v DB2 (DB2 for MVS)

v DB2UNIX

v SQLBASE

v DB2ODBC

v DB2400

v INFORMIX

v SYBASE

v DB2MDI

Nom du serveur de bases de données

Nom du serveur de bases de données, uniquement pour Informix et

Sybase. N’est pas utilisé pour PeopleSoft Version 8.x.

Nom du serveur

Nom (adresse IP) du serveur spécifié comme Type de connexion.

Pour APPSERV, cette entrée doit être, soit adresse IP:port TCP, soit

le nom IP.

Vous pouvez spécifier plusieurs entrées, dans la mesure où elles

sont séparées par des virgules.

ID d’opérateur

ID d’opérateur utilisé pour la connexion avec la base de données

PeopleSoft.

v Pour PeopleSoft version 7.x, les travaux ne seront pas exécutés

sous cet ID, mais sous l’ID spécifié dans la définition du travail


v Pour PeopleSoft version 8.x, tous les travaux seront exécutés sous

cet ID.

Mot de passe opérateur

Mot de passe chiffré pour l’ID d’opérateur. Si vous utilisez un

éditeur classique pour écrire le fichier d’options, vous devez

d’abord utiliser l’outil Enigma pour chiffrer ce mot de passe. Si

vous utilisez l’Editeur d’options, celui-ci s’en charge à votre place.

Serveur de processus par défaut

Serveur de processus par défaut exécutant les travaux dans

PeopleSoft.

Les entrées sont séparées par des barres obliques (/), de manière à ce que la

chaîne se présente sous la forme item1/item2/.../item6, et doivent être

répertoriées dans l’ordre où elles ont été décrites dans cette page.

Toutes les entrées sont obligatoires, à l’exception du Nom du serveur de

bases de données.

TWSXA_PT84_JVMPATH Chemin d’accès à Java Virtual Machine. Cette option n’est disponible

qu’avec PeopleTools version 8.4x.


Tableau 11. Options Psagent. (suite)

Option Description

UTF8cmdline Si la valeur est 0, cela signifie que la méthode d’agent étendu attend de

Tivoli Workload Scheduler qu’il envoie les données nécessaires au lancement

du travail dans la page de codes locale. Sinon, elle attend les données au

format UTF8. La valeur par défaut est 1 (par exemple, format UTF8).

TWSXA_CP Page de codes utilisée par la méthode d’agent étendu pour communiquer

avec l’application externe. Si cette option est absente ou comporte une valeur

non valide, la page de codes locale sera utilisée.

TWSMETH_CP Page de codes utilisée par la méthode d’agent étendu pour générer la sortie

standard. Si cette option est absente ou comporte une valeur non valide, la

page de codes locale sera utilisée.

TWSMETH_LANG Langue utilisée par la méthode d’agent étendu pour la sortie standard (à

savoir, le catalogue de messages spécifié qui sera ouvert). Si cette option est

absente ou comporte une valeur non valide, la langue locale sera utilisée.

TWSXA_LANG Non pris en charge pour l’agent étendu PeopleSoft.

Les noms d’option tiennent compte de la différence Maj./min. et doivent être

écrits, tels qu’ils apparaissent dans la colonne de gauche du tableau 11. Avant

d’utiliser un fichier d’options créé manuellement, vérifiez que tous les noms

d’option sont écrits correctement. Les options non conformes seront ignorées.

Modification manuelle des fichiers d’options

Outre l’Editeur d’options, vous pouvez utiliser un éditeur de texte classique pour

créer ou modifier un fichier d’options.

Voici deux exemples de fichier d’options, destinés à vous aider à déterminer les

exigences spécifiques à votre site. Votre fichier d’options peut différer des exemples

ci-dessous.

N’oubliez pas d’enregistrer le fichier dans le répertoire racine_TWS\methods.

Exemple pour PeopleSoft 7.x

LJuser=TwsUsr

CFuser=TwsUsr

PSDRIVE=N:

PSVER=\PS750

COBROOT=N:\PS750

CONNECT=ORACLE/HR75/PSUSA/#oqola4O7lxp5refgbAreV/PSNT

CheckInterval=15

CheckIntervalUnits=1

PSXA_TRACE=0

Exemple pour PeopleSoft 8.1x

LJuser=TwsUsr

CFuser=TwsUsr

CheckInterval=15

PSDRIVE=D:

PSVER=\pt81x\bin\client\winx86_extapi

COBROOT=D:\pt81x\bin\client\winx86_extapi

CONNECT=AppServ/PSOFT81X:9000/PSDEV/jp5l83nlWe7wh5jxk46qeV/PSUNX

CheckIntervalUnits=1

PSXA_TRACE=1


Connexion à plusieurs bases de données PeopleSoft

La méthode psagent doit parfois se connecter à plusieurs bases de données

PeopleSoft. Par exemple, une même installation de PeopleSoft peut avoir un

environnement TEST, DEMONSTRATION et PRODUCTION, chacun avec une base

de données séparée, ce qui implique que la méthode psagent utilise une chaîne de

connexion distincte pour chaque base de données.

Afin de prendre en charge cette connexion multiple, vous pouvez configurer

plusieurs postes de travail d’agent étendu PeopleSoft qui se connectent à la même

méthode, mais utilisent différents fichiers d’options. Lorsqu’un poste de travail

démarre la méthode, il commence par rechercher le fichier d’options avec le nom

du poste de travail d’agent étendu précédant psagent.opts. Par exemple, un agent

étendu PeopleSoft nommé jupiter sera associé au fichier d’options :

jupiter_psagent.opts

La méthode psagent recherche d’abord un fichier d’options avec le nom du poste

de travail d’agent étendu, puis le fichier par défaut psagent.opts. Ceci permet à

l’utilisateur de configurer un agent étendu pour chaque base de données

PeopleSoft.

Pour vous connecter à une seule base de données, utilisez le nom par défaut du

fichier d’options, à savoir psagent.opts.

Configuration d’un environnement PeopleSoft, version 7.5 ou

antérieure

La section ci-après explique comment configurer l’environnement PeopleSoft si

vous utilisez l’agent étendu avec PeopleSoft version 7.5 ou antérieure.

Personnalisation du serveur de processus

Indépendamment du type de système d’exploitation sur lequel les travaux Tivoli

Workload Scheduler seront exécutés, vous devez personnaliser l’exécutable du

serveur de processus correspondant à l’aide du source COBOL PTCUDCOP.cbl

fourni par IBM.

Vous devez remplacer le fichier PTCUDCOP.cbl fourni par PeopleSoft par son

équivalent fourni par IBM et recompiler le planificateur de traitements.

Vous trouverez des instructions complètes sur la recompilation du planificateur de

traitements dans les manuels d’installation PeopleSoft. Lorsque vous recevrez des

correctifs de PeopleSoft, vous devrez peut-être répéter le processus de

personnalisation du serveur, si le fichier PTCUDCOP.cbl est écrasé lors de

l’installation du correctif.

Vous trouverez, ci-après, la procédure à suivre pour personnaliser le serveur de

processus sous Windows et sous UNIX.

Personnalisation sous Windows

Si le planificateur de traitements PeopleSoft s’exécute sous Windows, reportez-vous

à la section ″Configuration de l’environnement de traitement par lots sous

Windows NT/2000″ dans le manuel d’installation PeopleSoft, pour accéder à des

informations mises à jour. Vous devez avoir installé un compilateur COBOL sur

votre serveur de lots et compiler à partir de cet emplacement. L’ordinateur

exécutant la compilation doit disposer d’un compilateur COBOL et pouvoir

accéder en écriture au serveur de fichiers.


Pour configurer un serveur de processus sous Windows :

1. Ouvrez une fenêtre avec une invite de commande DOS.

2. Définissez deux variables d’environnement, PS_HOME et COBROOT, sur

l’ordinateur à partir duquel vous envisagez de compiler le source COBOL.

Utilisez les commandes suivantes :

set PS_HOME=n:\PS750

set COBROOT=c:\netexpress\base

3. Vérifiez que le répertoire de compilation c:\temp\compile existe ; il doit déjà

exister si vous avez exécuté CBLBLD.BAT. S’il existe, supprimez les fichiers qui

y résident, par mesure de sécurité. S’il n’existe pas, créez-le à l’aide de la

commande suivante :

mkdir c:\temp\compile

Remarque : Assurez-vous que vous avez accès en écriture au répertoire de

compilation puisque le processus de compilation s’effectuera à cet

emplacement.

4. Accédez au répertoire <racine_PS>\setup.

5. Exécutez la commande suivante pour copier tous les fichiers du source COBOL,

du répertoire <racine_PS> vers le répertoire de compilation :

cblsrc <répertoire_source> <répertoire_compilation>

où <répertoire_source> représente l’unité et le répertoire où réside la source

(qui doit être identique à <racine_PS>) et <répertoire_compilation> représente

l’unité et le répertoire où les fichiers source doivent être copiés.

Par exemple, la commande suivante prendra la source COBOL de <racine_PS>

et copiera tous les fichiers nécessaires à l’emplacement où le processus de

compilation s’effectuera.

cblsrc <racine_PS> c:\temp\compile

6. Copiez le fichier PTCUDCOP.cbl fourni par IBM dans le répertoire de

compilation à l’aide de la commande suivante :

copy <racine_TWS>\PeopleSoft\PTCUDCOP.cbl c:\temp\compile

7. Une fois la commande CBLSRC terminée, accédez au répertoire de compilation

à l’aide de la commande suivante :

cd c:\temp\compile

8. Compilez à l’aide de la commande suivante :

CBLMAKE.BAT PTPUPRCS EXE

LIST

En cas d’incident lors de la compilation, consultez le fichier PTPUPRCS.lis pour

plus de détails et relancez la commande après avoir traité l’incident.

9. Une fois la commande CBLMAKE.BAT terminée, copiez les fichiers EXE, GNT

ou INT dans le répertoire <racine_PS>\cblbin à l’aide des commandes

suivantes :

copy

PTPUPRCS.exe <racine_PS>\cblbin

copy PTPUPRCS.gnt <racine_PS>\cblbin

Personnalisation sous UNIX

Si le planificateur de traitements PeopleSoft s’exécute sous UNIX, reportez-vous à

la section ″Configuration de l’environnement de traitement par lots sous UNIX″

dans le manuel d’installation PeopleSoft, pour accéder à des informations mises à

jour. Vous devez avoir installé un compilateur COBOL sur votre serveur de lots et


compiler à partir de cet emplacement. L’ordinateur exécutant la compilation doit

disposer d’un compilateur COBOL et doit pouvoir accéder en écriture au répertoire

<racine_PS>/cblbin.

Pour créer le serveur de processus sous UNIX :

1. Connectez-vous au serveur UNIX.

2. Accédez au répertoire principal PeopleSoft.

3. Exécutez le script psconfig.sh.

4. Accédez au répertoire $PS_HOME/src/cbl.

5. Renommez le fichier PTCUDCOP.cbl en PTCUDCOP.old à l’aide de la

commande suivante :

mv PTCUDCOP.cbl PTCUDCOP.old

6. Copiez PTCUDCOP.cbl depuis l’agent étendu (racine_tws/PeopleSoft) via FTP.

7. Exécutez les commandes suivantes :

cd ../../install

pscbl.mak PTPUPRCS LIST

8. Une fois l’exécution du script terminée, vérifiez la présence des nouveaux

fichiers dans les répertories de destination

<racine_PS>/src/cbl/int

<racine_PS>/src/cbl/lst

<racine_PS>/cblbin

Ils doivent avoir une longueur supérieure à zéro ainsi qu’un horodatage

correspondant aux paramètres horaires en cours. En cas d’incident lors de la

compilation, consultez le fichier PTPUPRCS.lis pour prendre connaissance des

erreurs, corrigez-les et relancez l’étape de compilation.

Configuration du client

Pour exécuter la méthode d’accès PeopleSoft pour un environnement

PeopleTools 7.x, vous devez travailler dans un environnement PeopleSoft à deux

niveaux et utiliser un poste de travail avec une connectivité appropriée à votre

base de données.

Vous devez installer le logiciel client de votre base de données sur le poste de

travail hébergeant l’agent étendu et devez le configurer pour qu’il puisse

communiquer en mode ODBC. Testez votre connexion à l’aide des outils de test

ODBC accompagnant votre logiciel client (par exemple test 32 bits ODBC pour

Oracle).

Vous devez également pouvoir accéder au serveur de fichiers PeopleSoft. Mappez

la ressource partagée du serveur de fichiers à une unité réseau de votre poste de

travail Windows.

Pour installer un poste de travail pour un environnement PeopleSoft 7.x:

1. Accédez à \\<serveur_fichiers>\<partage> en tant qu’unité partagée <d>: sur

votre ordinateur.

2. Définissez PS_HOME comme répertoire approprié sur la nouvelle unité

partagée, à l’aide de la commande :

set PS_HOME=<d>:\PS750

3. Exécutez :

%PS_HOME%\bin\CLIENT\WINX86\pscfg.exe


Une fenêtre de configuration, comme celle représentée à la figure 23, s’ouvre.

4. Sélectionnez l’onglet Configuration du client, spécifiez les valeurs requises et

vérifiez que la case Installer le pilote ODBC PeopleSoft est cochée. Si vous

exécutez SQL Server, vous devez également cocher la case Installer le

gestionnaire de pilotes ODBC 3.0.

Remarque : L’option Installer le pilote ODBC PeopleSoft installe un nom de

source de données utilisateur. Si vous avez besoin d’accéder à la

source de données d’un autre profil utilisateur, vous devrez créer

une source de données système correspondante (via ″Panneau de

configuration″-> ″Sources de données ODBC″) sur votre poste

WinNT/2000, ou exécuter à nouveau l’étape de personnalisation

pour tous les autres utilisateurs que vous voulez utiliser pour

soumettre des travaux d’agent étendu Tivoli Workload Scheduler.

Une fois l’opération terminée, le menu ″Démarrer/Programmes″ de votre

ordinateur devrait compter une nouvelle entrée (intitulée PeopleSoft 7.5).

Exécution du script de l’outil Déplacement de données

Une fois la séquence d’installation terminée, l’outil Déplacement de données

PeopleSoft est utilisé pour mettre ne place les procédures stockées pour l’agent

Figure 23. Fenêtre du gestionnaire de configuration 7.5.


étendu PeopleSoft. Pour plus d’informations sur le script de l’outil Déplacement de

données, consultez votre documentation Peoplesoft.

1. Cliquez sur l’icône Outil Déplacement de données dans le groupe PeopleSoft.

La fenêtre de connexion Peoplesoft apparaît.

2. Sélectionnez la base de données appropriée et cliquez sur OK. Une fenêtre de

connexion s’ouvre.

3. Complétez les zones et cliquez sur OK. La fenêtre de l’outil Déplacement de

données s’affiche.

4. Dans le menu Fichier de cette fenêtre, sélectionnez la commande Ouvrir.

Ouvrez le fichier suivant dans la fenêtre de l’outil Déplacement de données :

racine_TWS\PeopleSoft\TVPUPSFT.dms

5. Exécutez les scripts, après les avoir chargés dans la fenêtre de l’outil

Déplacement de données.

La fenêtre de l’outil Déplacement de données est scindée en deux sections. La

section supérieure affiche les instructions du script de l’outil Déplacement de

données. La section inférieure affiche le statut des instructions du script, telles

qu’elles s’exécutent.

6. Vérifiez que le script s’exécute correctement.

Figure 24. Fenêtre de connexion PeopleSoft.


Si certaines instructions échouent, vérifiez que les valeurs indiquées dans la

fenêtre de démarrage pour le nom de la base de données, l’ID de connexion et

le mot de passe sont correctes, puis répétez le processus. Si le script de l’outil

Déplacement de données ne s’exécute toujours pas correctement, contactez

votre administrateur de base de données pour déterminer si le problème ne

réside pas dans votre base de données.

Remarque : Le script de l’outil Déplacement de données doit être exécuté sur

chaque base de données que l’agent étendu PeopleSoft doit utiliser.

Pour exécuter les scripts sur une autre base de données, modifiez le

nom de la base de données et/ou le SGBDR dans la séquence de

connexion.

Configuration d’un environnement PeopleSoft version 8.1x

La section ci-après explique comment configurer l’environnement PeopleSoft si

vous utilisez l’agent étendu avec PeopleSoft version 8.1x.

Personnalisation du serveur d’applications

La méthode d’accès prenant en charge PeopleTools 8.1x ne peut fonctionner

qu’avec une architecture PeopleSoft à 3 niveaux. Vous devez donc déployer une

architecture PeopleSoft à 3 niveaux conformément aux instructions PeopleSoft. Du

fait du déploiement complet de l’architecture PeopleSoft, avec au moins un serveur

d’applications PeopleSoft et un serveur de processus, les contraintes en termes de

configuration logicielle et de dépendances seront réduites sur le poste de travail

d’agent étendu. Il n’est pas nécessaire d’installer la connectivité de la base de

données sur le poste de travail hébergeant l’agent étendu. De plus, il n’est pas

nécessaire de personnaliser le serveur de processus, comme cela était le cas avec

PeopleTools version 7.x, ni d’exécuter des scripts supplémentaires de l’outil

Déplacement de données pour personnaliser la base de données. Le serveur

d’applications doit être actif afin de pouvoir soumettre les travaux au planificateur

de traitements PeopleSoft.

Figure 25. Fenêtre de l’outil Déplacement de Données


Pour configurer correctement la méthode d’accès, vous devez obtenir les

informations suivantes de votre administrateur PeopleSoft :

v Nom d’hôte (ou adresse IP) du serveur d’applications,

v Port Jolt du serveur d’applications (généralement 9000),

v Nom du serveur de processus.

L’ID d’opérateur doit avoir les droits requis pour utiliser l’interface de composants

dans l’environnement PeopleTools.

Configuration du client

Pour exécuter l’agent étendu dans un environnement PeopleTools 8.1x, vous devez

installer le support d’API externe PeopleSoft sur le poste de travail Tivoli

Workload Scheduler hébergeant l’agent étendu.

L’installation de l’API externe PeopleSoft doit s’effectuer avant celle de Tivoli

Workload Scheduler for Applications pour PeopleSoft.

Les manuels d’installation PeopleSoft contiennent des informations sur cette étape

d’installation. Reportez-vous à la documentation PeopleSoft appropriée pour

prendre connaissance des instructions les plus récentes, en fonction de votre

version de PeopleSoft. Pour PeopleTools 8.17, vous devez appeler l’exécutable

setup.exe situé dans le répertoire %PS_HOME%\setup\PsExtAPI du serveur

d’applications PeopleSoft 8.

Notez le nom du répertoire où vous installez l’API externe, car vous en aurez

besoin lors de l’installation de l’agent étendu et lors de la configuration, quand le

système vous demandera le répertoire PSHome ou le répertoire racine Cobol.

Avant d’utiliser l’API externe, vérifiez votre installation conformément aux

instructions de PeopleSoft, à l’aide de l’utilitaire jnitest.exe situé dans le répertoire

de l’API externe. L’utilitaire jnitest.exe vérifie que vous avez MicroSoft Java Virtual

Machine for Java 3.2, version 5.00.3167 ou supérieure. Si jnitest.exe détecte une

version acceptable, vous pouvez charger MicroSoft Java Virtual Machine. Sinon,

vous pouvez avoir des difficultés à le charger correctement. L’API externe ne

fonctionnera pas tant que vous n’aurez pas une version correcte de MicroSoft Java

Virtual Machine.

Vous devrez également redémarrer votre poste de travail avant de pouvoir utiliser

l’installation de l’API externe PeopleSoft. Dans le cas contraire, lorsqu’un travail

PeopleSoft sera soumis via ITWS, vous verrez apparaître une fenêtre (générée par

TVPUPSFT.exe) avec le message suivant :

"The application failed to initialize properly (0xc0000005).

Click on OK to terminate the application."

Configuration d’un environnement PeopleSoft version 8.4x

Dans le cas de PeopleTools version 8.4x, il n’est plus nécessaire d’installer

séparément les API externes de PeopleSoft, celles-ci faisant partie intégrante du

client Windows standard ; vous pouvez y accéder via le répertoire

racine_PS\bin\client\winx86 du serveur de fichiers PeopleSoft. De plus,

conformément à l’ID de résolution 704309 de PeopleSoft, vous devez :

v Pouvoir accéder au répertoire racine_PS\class contenant le fichier psjoa.jar.

v Avoir accès à une JVM valide.


Remarque : La JVM fournie avec ce produit n’est pas valide dans le présent cas.

Vous devez utiliser une JVM prise en charge par PeopleSoft.

La méthode psagent.exe se chargera de définir/mettre à jour les variables

d’environnement CLASSPATH et PS_HOME, si elles ne le sont pas déjà dans

l’environnement où le travail est lancé. Si votre environnement de variables

système contient déjà un accès valide à jvm.dll, vous n’avez pas besoin d’y ajouter

d’autres détails. Sinon, vous devez spécifier une nouvelle option dans le fichier

psagent.opts à l’aide d’un éditeur de texte, afin que le fichier psagent.exe puisse

mettre à jour le chemin d’accès à la JVM. Pour ce faire, ajoutez la ligne suivante au

fichier d’options :

TWSXA_PT84_JVMPATH=<chemin d’accès à jvm.dll>

Les JVM valides sont déjà fournies par PeopleSoft avec les serveurs d’applications

qui prennent en charge l’architecture PIA, tels que ″BEA WebLogic Server″ (dans le

sous-répertoire jdk131\jre\bin\classic ou jdk131\jre\bin\hotspot) ou ″IBM

WebSphere Application Server″ (dans le sous-répertoire Java13\jre\bin\classic).

Par exemple, vous pouvez mettre à jour le fichier d’options à l’aide de l’une des

commandes suivantes :

v TWSXA_PT84_JVMPATH=D:\Program Files\IBM\Java13\jre\bin\classic

v TWSXA_PT84_JVMPATH=D:\bea\jdk131\jre\bin\classic

v TWSXA_PT84_JVMPATH=D:\bea\jdk131\jre\bin\hotspot

Si vous n’avez pas ce mot clé, ni une variable système valide permettant d’accéder

à jvm.dll, vous obtiendrez l’un des messages suivants :

v AWS140020078E Exception caught in file TVPUPSFT.cpp(#) during function Main

v AWS140020076E The problem encountered may be related to the environment settings:

please verify the following:

1) Your path contains a valid Java Virtual Machine directory or options file

contains TWSXA_PT84_JVMPATH

2) Your CLASSPATH environment variable contains a valid path to psjoa.jar

3) Your target Application Server is up and running

4) you have defined PS_HOME environment variable


Chapitre 12. Définition des travaux PeopleSoft

Ce chapitre fournit des informations sur la définition des travaux utilisant l’agent

étendu PeopleSoft.

Création de définitions de travaux PeopleSoft dans Tivoli Workload

Scheduler

Des définitions de travaux Tivoli Workload Scheduler sont requises pour chaque

travail PeopleSoft que vous envisagez de contrôler. Un travail Tivoli Workload

Scheduler est associé à un travail PeopleSoft déjà défini ; sa définition inclut :

v le nom du travail,

v le nom du propriétaire,

v les spécifications de fichier script,

v les options de récupération.

Pour plus de détails, reportez-vous au Chapitre 5, «Définition des travaux d’agent


Paramètres des chaînes de tâches des travaux PeopleSoft

Cette section décrit les paramètres des chaînes de tâches qui règlent l’exécution des

travaux PeopleSoft. Vous devez les spécifier aux emplacements suivants lorsque

vous définissez les travaux Tivoli Workload Scheduler qui leurs sont associés :


du travail, si vous utilisez Job Scheduling Console.





environnement de bout en bout. Notez que, dans ce cas, l’intégralité de la chaîne

suivant le mot clé JOBCMD doit figurer entre guillemets (″).

Le tableau ci-après liste les paramètres.

Tableau 12. Paramètres de chaîne de tâches pour les travaux PeopleSoft.

Paramètre Description Version PeopleTools

-operator ID de l’opérateur PeopleSoft

qui lance le travail.

7.x, 8.1x

-process Nom du traitement dans le

travail PeopleSoft.

7.x, 8.1x, 8.4x

-type Type de traitement dans le

travail PeopleSoft. Cette

entrée doit être placée entre

guillemets simples (’).

7.x, 8.1x, 8.4x

-runcontrol ID de contrôle d’exécution

du travail PeopleSoft.

7.x, 8.1x, 8.4x

-outputdest Destination de la sortie du

travail PeopleSoft.

8.1x, 8.4x


Tableau 12. Paramètres de chaîne de tâches pour les travaux PeopleSoft. (suite)

Paramètre Description Version PeopleTools

-outputtype Type de sortie du travail

PeopleSoft. Les valeurs

correctes sont les suivantes :

0 (Toutes)

1 (Aucune)

2 (Fichier)

3 (Imprimante)

4 (Fenêtre)

5 (Courrier électronique)

6 (Web)

7 (valeur par défaut)

8.1x, 8.4x

-outputformat Format de sortie du travail

PeopleSoft. Les valeurs

correctes sont les suivantes :

None

CSV

DOC

Default

HP

HTM

LP

OTHER

PDF

PS

RPT

RTF

SPF

TXT

WKS

XLS

8.1x, 8.4x

-runlocationdescr Planificateur de traitements

PeopleSoft en charge du

traitement du travail

PeopleSoft.

8.1x, 8.4x

-foldername Nom du dossier des rapports

utilisé pour ce travail. Ce

dossier doit déjà avoir été

créé via le gestionnaire de

rapports PeopleSoft.

8.4x

Remarque : Aucune vérification de syntaxe n’est effectuée sur les valeurs de

contrôle des sorties (outputdest, outputtype, outputformat et

foldername). Si ces valeurs ne sont pas reconnues, les valeurs par

défaut sont utilisées.

Voici un exemple d’une chaîne de tâches complète d’un travail PeopleSoft 8.1x :

-operator PS -process XRFWIN -type ’SQR Report’ -runcontrol 1 -runlocationdescr PSNT

Configuration de dépendances OPENS 7.x uniquement

Vous pouvez définir des dépendances OPENS Tivoli Workload Scheduler pour les

travaux PeopleSoft. Les dépendances OPENS Tivoli Workload Scheduler sont

mappées à une commande SQL “select count” avec une clause “where” adressée à

la base de données PeopleSoft. Cette commande SQL vérifie, en gros, que les


valeurs sélectionnées existent dans la base de données. Si les entrées spécifiées

existent dans la base de données, le nombre renvoyé sera une valeur différente de

zéro et le travail s’exécutera. A l’inverse, si les entrées spécifiées n’existent pas

dans la base de données, le nombre renvoyé sera zéro et le travail ne pourra pas

s’exécuter. Un résultat de zéro est considéré comme faux ; toute autre valeur est

considérée comme vraie.

Remarque : Lorsque vous créez une dépendance OPENS dans Job Scheduling

Console, la table est listée sous la zone de texte Fichier et les

qualifiants colonne et données sont listés dans la zone de texte

Qualifiants.

Par exemple :

opens /PSSERVERSTAT

se traduit par la commande SQL suivante :

select count(*) from PSSERVERSTAT;

Cette commande renvoie le nombre de lignes dans PSSERVERSTAT. Un résultat de

zéro est considéré comme faux ; toute autre valeur est considérée comme vraie.

Voici un autre exemple :

opens /PSSERVERSTAT ("SERVERNAME = ’PSNT’ AND

SERVERSTATUS = 3")

se traduit par la commande SQL suivante :

select count(*) from PSSERVERSTAT where SERVERNAME = ’PSNT’ AND SERVERSTATUS = 3;

Cette commande renvoie le nombre de lignes dans PSSERVERSTAT pour le serveur

PSNT dont le statut est 3 (en cours d’exécution).

Pour définir une dépendance OPENS pour un travail :

1. Editez le flux de travaux auquel vous voulez ajouter une dépendance OPENS

en mode ligne de commande.

2. Ajoutez la chaîne de commande suivante au travail :

cpu#job opens

/table(“colonne =

‘données’”)

où :

table Spécifie le nom de la table PeopleSoft que vous voulez ouvrir.

colonne

Spécifie le nom de la colonne que vous recherchez.

données

Spécifie les données de cette colonne correspondant à votre recherche.3. Enregistrez les modifications que vous venez d’effectuer et fermez le flux de

travaux.

Remarque : Les données que vous recherchez doivent être placées entre des

guillemets (″).

Chapitre 12. Définition des travaux PeopleSoft 79

Exemple de dépendances OPENS

Les flux de travaux suivants illustrent des exemples de dépendances OPENS.

Voici un premier exemple :

SCHEDULE PS_CPU#TEST01

ON EVERYDAY

:

PS_CPU#XRFWIN1

PS_CPU#XRFAPF1

PS_CPU#XRFPNP1 FOLLOWS XRFAPF1

PS_CPU#SYSAUDT1 FOLLOWS XRFWIN1

PS_CPU#PTPTEDT1 OPENS /PSPRCSRQST ("PRCSTYPE = ’SQR Report’ AND RUNSTATUS = 9")

PS_CPU#XRFILD1 FOLLOWS XRFPNP1,PTPTEDT1

PS_CPU#DDDAUDT1 FOLLOWS PTPTEDT1,TEST02.@

PS_CPU#TLS7011 FOLLOWS TEST02.@,DDDAUDT1

END

Voici un autre exemple :

SCHEDULE PS_CPU#TEST02

ON EVERYDAY

AT 1330

:

PS_CPU#XRFWIN2 OPENS /PSSERVERSTAT ("SERVERNAME = ’PSNT’ AND SERVERSTATUS = 3")

PS_CPU#XRFAPF2 FOLLOWS TEST01.XRFAPF1

PS_CPU#XRFPNP2 FOLLOWS XRFAPF2

PS_CPU#SYSAUDT2 FOLLOWS XRFWIN2

PS_CPU#PTPTEDT2 OPENS /PSPRCSRQST ("PRCSTYPE = ’SQR Report’ AND RUNSTATUS = 9

AND PRCSNAME = ’DDDAUDIT’")

PS_CPU#XRFILD2 FOLLOWS XRFPNP2,PTPTEDT2

PS_CPU#DDDAUDT2

END

Mappage de statut des travaux IBM Tivoli Workload Scheduler et

PeopleSoft

Lorsqu’un travail PeopleSoft est lancé par Tivoli Workload Scheduler, vous pouvez

surveiller sa progression à l’aide de Job Scheduling Console. Les transitions d’état

utilisées dans IBM Tivoli Workload Scheduler et leurs correspondances dans

PeopleSoft sont répertoriées ci-dessous.

Statut PeopleSoft

Statut IBM Tivoli

Workload Scheduler Description

CANCEL CANCEL/ABEND Un opérateur PeopleSoft ou la

méthode a demandé l’annulation de la

demande de traitement. La méthode

agit ainsi en réponse à une tâche TJ.

DELETE CANCEL Un opérateur PeopleSoft a demandé la

suppression de la demande de

traitement.

ERROR FAIL La tentative de lancement a échoué

pour une raison quelconque. Dans ce

cas, la demande de traitement n’a

jamais réellement démarré l’exécution.

HOLD HOLD Le traitement ne peut pas être lancé,

peut-être en raison de dépendances

non respectées.

QUEUED READY Prêt à être lancé.


Statut PeopleSoft

Statut IBM Tivoli

Workload Scheduler Description

INITIATED INIT Tentative de lancement.

PROCESSING EXEC Traitement en cours d’exécution.

CANCELLED CANCEL/ABEND* Traitement annulé.

SUCCESSFUL SUCC Exécution réussie.

NOT SUCCESSFUL ABEND Echec de l’exécution.

Remarques :

1. Les traitements annulés dans PeopleSoft seront abandonnés s’ils étaient déjà en

cours d’exécution. Le mappage de statut IBM Tivoli Workload Scheduler doit le

refléter. En d’autres termes, un traitement annulé qui n’avait pas encore été

initialisé, aura le statut CANCEL dans Tivoli Workload Scheduler. Un

traitement qui avait été initialisé aura le statut ABEND.

2. Une demande de traitement dont la suppression a été demandée dans le

planificateur de traitements ne pourra jamais être lancée. L’enregistrement est,

en effet, effacé de la table lors d’un processus de maintenance normal. En ce

qui concerne le traitement jnextday, de telles requêtes doivent être considérées

comme non existantes.

Chapitre 12. Définition des travaux PeopleSoft 81

Partie 4. Méthode d’accès R/3



IBM Tivoli Workload Scheduler for Applications pour R3 vous permet de créer,

planifier et contrôler des travaux R/3 grâce aux fonctions de planification de Tivoli

Workload Scheduler.

Champ d’application

IBM Tivoli Workload Scheduler for Applications pour R3 vous permet d’effectuer

les opérations suivantes :

v Utiliser les dépendances de travail et les contrôles Tivoli Workload Scheduler

standard pour les travaux R/3.

v Créer des travaux R/3 à l’aide de l’interface Tivoli Workload Scheduler.

v Planifier des travaux R/3 devant s’exécuter à des jours et heures spécifiques,

dans un ordre déterminé.

v Définir des interdépendances entre les travaux R/3 et les travaux Tivoli

Workload Scheduler s’exécutant sur des applications différentes, telles que

PeopleSoft et Oracle.

v Définir des interdépendances entre les travaux R/3 et ceux s’exécutant sur des

plateformes différentes.

v Définir les options de support de langue nationale.

v Définir comment utiliser les fonctionnalités du support Business Warehouse R/3.


v Utiliser les groupes de connexion R/3 pour l’équilibrage de la charge et la

tolérance aux pannes.

v Travailler avec des marques de réservation et des variables R/3.

v Exploiter le support d’interface BC-XBP 2.0.

Processus de planification pour l’agent étendu R/3

Tivoli Workload Scheduler lance des travaux dans R/3 par l’intermédiaire de

travaux définis pour s’exécuter sur un poste de travail d’agent étendu Tivoli

Workload Scheduler. Un poste de travail d’agent étendu R/3 est défini en tant que

poste de travail Tivoli Workload Scheduler hébergé par un agent FTA ou un poste

de travail principal utilisant la méthode d’accès r3batch. Le poste de travail

d’agent étendu R/3 utilise la méthode d’accès r3batch pour transmettre les

informations spécifiques au travail R/3 à des instances R/3 prédéfinies. La

méthode d’accès utilise les informations fournies dans un fichier d’options, objet

d’une discussion ultérieure dans ce guide, pour se connecter et lancer des travaux

sur une instance R/3. Vous pouvez définir plusieurs postes de travail d’agent

étendu utilisant le même hôte, en paramétrant différentes entrées ou différents

fichiers d’options. Les travaux R/3 définis dans Tivoli Workload Scheduler doivent

correspondre à des travaux existant dans l’environnement R/3. Utilisant le nom

d’agent étendu R/3 comme une clé, r3batch se base sur le fichier d’options

correspondant pour déterminer l’instance R/3 qui exécutera le travail. Il fait une

copie d’un modèle de travail dans R/3 et le marque comme exécutable avec,

comme heure de départ, Démarrage immédiat. Ensuite, il contrôle le travail jusqu’à

son terme, consignant la progression de celui-ci et les informations sur son état

dans une liste de sortie des instances, sur le poste de travail hôte.


Pour plus d’informations sur la gestion des travaux, reportez-vous au manuel IBM

Tivoli Workload Scheduler - Guide de référence SH19-4556.

Support d’interface XBP 2.0

Tivoli Workload Scheduler for Applications pour R3 prend intégralement en charge

l’interface XBP 2.0. Vous bénéficiez ainsi des avantages suivants :

v Suivi des travaux enfant.

Un travail Tivoli Workload Scheduler reste à l’état EXEC jusqu’à ce que toute son

arborescence de travaux R/3 ait été exécutée. Les journaux des travaux R/3

sont extraits et stockés dans le fichier stdlist de Tivoli Workload Scheduler,

avec les listes de spoule de toutes les étapes ABAP.

v Interception des travaux R/3.

Les travaux planifiés par les utilisateurs R/3 peuvent être interceptés avant leur

exécution, sur la base des attributs du travail. Un travail de collecte des

interceptions est planifié périodiquement sous forme de commande Unix ou

Windows. Lors de chaque exécution, ce travail collecte les travaux R/3

interceptés et les soumet au plan en cours, sur la base d’un modèle.

v Tous les attributs de travaux sont conservés lors de la réexécution des travaux.

Les limitations dues à l’utilisation d’anciennes copies de travaux réexécutés,

affectant les paramètres d’archivage ou d’impression ainsi que la classe de

travail, sont supprimées.

v Etapes de commande externes.

Pour plus de détails, reportez-vous à la section «Utilisation du support

d’interface XBP 2.0» à la page 98.


Chapitre 14. Installation

Cette section contient des informations sur l’installation d’IBM Tivoli Workload

Scheduler for Applications pour R3.


Pour installer IBM Tivoli Workload Scheduler for Applications pour R3, vous

devez exécuter les logiciels suivants :

v IBM Tivoli Workload Scheduler version 7.0 ou ultérieure, ou IBM Tivoli

Workload Scheduler pour z/OS dans un environnement de bout en bout.

v R/3 Version 3.1g, 3.1h, 3.1i, 4.0x, 4.5x, 4.6x, 4.7, 6.10 ou 6.20.

v Pour les versions antérieures à 6.20, le Support Package R/3 approprié, tel

qu’indiqué dans le tableau ci-dessous :

Tableau 13. Support Packages R/3.

Versions R/3 Notes R/3

R/3 3.1x 393708, 430087, 357924, 517672

R/3 4.0x 393708, 430087, 111696, 357924, 517672

R/3 4.5x 148436, 172245, 326202, 326752, 393708,

399449, 357924, 517672

R/3 4.6x 326752, 352606, 399449, 453135, 435111,

357924, 517672, 610480

R/3 4.7 610480

R/3 6.10 399449, 435111, 453135, 357924, 517672,

610480

Remarque : Les notes R/3 399449 et 430087 résolvent les problèmes de paramètres

d’impression. Les notes 357924, 517672 et 519137 sont indépendantes

de la version.

Généralités sur l’installation

Cette section présente les étapes d’installation de la méthode d’accès Tivoli

Workload Scheduler for Applications pour R/3. Avant d’installer la méthode

d’accès, vérifiez que Tivoli Workload Scheduler est correctement installé sur le

poste de travail hôte.

1. Sur le système qui hébergera l’agent étendu R/3, exécutez les étapes

suivantes :

a. Si la plateforme sur laquelle vous effectuez l’installation est Compaq Tru64,

suivez les instructions décrites à la section «Installation sur des plateformes

Tier2» à la page 88. Sinon, suivez les instructions décrites au Chapitre 2,

«Installation d’IBM Tivoli Workload Scheduler for Applications», à la page

5.2. Installez les modules ABAP r3batch sur le système R/3. Pour ce faire :

a. Connectez-vous à l’instance R/3 en tant qu’administrateur système de base

ou utilisateur disposant des autorisations requises.

b. Importez les fichiers de correction et de transfert.


Installation sur des plateformes Tier2

1. Connectez-vous en tant que root et accédez au répertoire racine_TWS.

2. A partir du CD-ROM d’installation, extrayez le logiciel :

tar xvf chemin_cd/TWS4APPS_R3BATCH_OSF.TAR

où chemin_cd représente le nom du chemin de l’unité de CD-ROM.

3. Vérifiez que r3setup et r3btar.Z ont été extraits dans le répertoire en cours.

4. Exécutez le script r3setup pour décompresser les fichiers, effectuer l’installation

initiale et créer le fichier r3options :

/bin/sh r3setup -new|-update

où :

-new

spécifie une nouvelle installation. -update

spécifie que vous installez sur une version préexistante.

Vous serez ensuite invité à entrer les informations ci-dessous. Pour plus de

détails, reportez-vous au Chapitre 20, «Fichiers d’options de la méthode d’accès

R/3», à la page 119.

v Le nom d’utilisateur Tivoli Workload Scheduler si celui-ci est différent de la

valeur par défaut, à savoir maestro.

v Le répertoire où l’agent étendu doit être installé (c’est-à-dire le chemin

d’accès à racine_TWS).

v L’utilisateur_exécution LJuser (par défaut, maestro). Il s’agit du nom de

l’utilisateur Tivoli Workload Scheduler qui exécute r3batch. Ce doit être un

compte UNIX valide.

v L’utilisateur_info IFuser (par défaut, maestro). Il s’agit du nom de l’utilisateur

Tivoli Workload Scheduler qui extrait les informations relatives au travail.

IFuser doit être identique à LJuser.

v Le type de définition des travaux JobDef (par défaut, r3batch). Il s’agit du

type d’interface utilisé pour la définition des travaux Tivoli Workload

Scheduler. Vous pouvez choisir :

a. r3batch (valeur par défaut) qui fournit une interface de définition des

travaux spécifique aux travaux R/3.

b. maestrogen ou rien, qui fournit une interface de définition des travaux

standard, sans zone d’entrée spécifique à R/3.v Le nom de cpu de l’hôte pour la définition de l’agent étendu Tivoli Workload

Scheduler.

v Le nom d’hôte du serveur d’applications R/3.

v Si vous voulez spécifier un hôte passerelle R/3 distinct, tapez NO.

v L’ID système R/3 à trois caractères (par exemple, OSS ou TRN).

v Le numéro d’instance R/3 à deux chiffres (par exemple, 00 ou 01).

v Le numéro de client R/3 à trois chiffres (par exemple, 100 ou 900).

v L’ID utilisateur R/3 pour les appels RFC (par exemple, rfcuser).

v Le mot de passe associé à l’ID utilisateur RFC R/3.

v Le niveau d’audit de l’interface R/3 (par défaut, 0).

v Si vous souhaitez définir la langue de connexion SAP R/3 pour l’agent

étendu sur ce système R/3 (par défaut, No).


v Si vous souhaitez définir une autre instance de l’agent étendu. Si vous

agréez, vous serez invité à fournir un autre jeu de paramètres. Une entrée

supplémentaire est insérée dans le fichier d’options R/3.5. Ouvrez Tivoli Job Scheduling Console ou le programme Composer et créez une

définition de poste de travail dans Tivoli Workload Scheduler pour chaque

instance de R/3.

Chiffrement des mots de passe utilisateur R/3

Lorsque vous ajoutez des entrées à votre fichier d’options, la valeur de r3pass est

automatiquement codée avant d’être écrite dans le fichier. Si vous modifiez le

fichier avec un éditeur de texte, vous devez exécuter le programme enigma pour

chiffrer le mot de passe avant de l’écrire dans le fichier. Pour ce faire, exécutez la

commande suivante :

enigma [mot_de_passe]

Vous pouvez inclure le mot de passe dans la ligne de commande ou l’entrer en

réponse à une invite. Le programme renvoie une version codée que vous pouvez

alors entrer dans le fichier d’options.

Chapitre 14. Installation 89

Chapitre 15. Configuration de l’environnement R/3

Pour communiquer et contrôler l’exécution des travaux sur des systèmes R/3 à

l’aide de la méthode d’accès pour R/3, vous devez exécuter les étapes de

configuration suivantes sur l’environnement R/3.

Les étapes décrites dans ce chapitre requièrent un administrateur système de base

R/3.

Présentation

Vous trouverez, ci-après, un résumé de la procédure de personnalisation :

1. Création d’un nouvel ID utilisateur RFC dans R/3 pour Tivoli Workload

Scheduler.

2. Création du profil d’autorisation, comme décrit à la section «Création du profil

d’autorisation pour l’utilisateur Tivoli Workload Scheduler».

3. Copie des fichiers de correction et de transfert, du serveur Tivoli Workload

Scheduler vers le serveur R/3.

4. Importation des fichiers de correction et de transfert dans R/3 et vérification de

l’installation.

Remarque : La procédure d’importation ajoute uniquement de nouveaux modules

fonctionnels ABAP/4 et de nouvelles tables internes au système R/3.

Elle ne modifie pas les objets existants.

Création de l’utilisateur RFC pour IBM Tivoli Workload Scheduler

Pour que Tivoli Workload Scheduler puisse communiquer avec R/3, vous devez

créer un ID utilisateur dans R/3 pour le traitement par lots Tivoli Workload

Scheduler. Pour des raisons de sécurité, utilisez plutôt un nouvel ID utilisateur

qu’un ID existant.

1. Créez un nouvel ID utilisateur RFC.

2. Attribuez à ce nouvel ID utilisateur RFC les attributs suivants :

v Un type utilisateur CPIC ou Communications, en fonction de la version de

R/3.

v Un mot de passe d’une longueur d’au moins six caractères. Tivoli Workload

Scheduler requiert ce mot de passe pour démarrer et contrôler les

travaux R/3. Si ce mot de passe est modifié dans R/3, vous devrez mettre à

jour le fichier d’options utilisé par r3batch en conséquence.

v Attribuez les profils de sécurité appropriés, en fonction de votre version de

R/3.

Création du profil d’autorisation pour l’utilisateur Tivoli Workload

Scheduler

Vous pouvez utiliser l’une des deux méthodes ci-après pour exécuter cette tâche :

v Utiliser la transaction SU02 et créer manuellement le profil.

v Utiliser le générateur de profils (transaction PFCG).


Utilisation de la transaction SU02 pour la création manuelle

du profil

Procédez comme suit :

1. Saisissez un nom de profil, par exemple Z_TWS, et une description.

2. Ajoutez manuellement les autorisations conformément à la table suivante :

Objet Description Autorisation

S_ADMI_FCD Autorisations système S_ADMI_ALL

S_BTCH_ADM Traitement en arrière-plan :

Administrateur du

traitement en arrière-plan

S_BTCH_ADM

S_BTCH_JOB Traitement en arrière-plan :

Opérations sur des travaux

en arrière-plan

S_BTCH_ALL

S_BTCH_NAM Traitement en arrière-plan :

Nom de l’utilisateur

d’arrière-plan

S_BTCH_ALL

S_PROGRAM ABAP : Contrôles de

l’exécution du programme

S_ABAP_ALL

S_RFC Contrôle des autorisations

pour l’accès RFC

S_RFC_ALL

S_SPO_ACT Spoule : Actions S_SPO_ALL

S_SPO_DEV Spoule : Autorisations des

périphériques

S_SPO_DEV_AL

S_XMI_LOG Autorisations d’accès

interne pour le journal XMI

S_XMILOG_ADM

S_XMI_PROD Autorisation pour les

interfaces de gestion

externes (XMI)

S_XMI_ADMIN

Les autorisations sont situées dans la classe d’objets ″Système de base :

Administration″.

En fonction de la version de R/3, il est possible que l’autorisation S_RFC_ALL

se trouve dans la classe ″Objets d’autorisation inter-applications″ ou ″Objets

d’autorisation non spécifiques de l’application″.

3. Enregistrez le profil.

4. Accédez à la fenêtre de gestion des utilisateurs et attribuez le profil à

l’utilisateur R/3 Tivoli Workload Scheduler.

5. Enregistrez les données utilisateur.

Utilisation de la transaction PFCG (Générateur de profils)

Procédez comme suit :

1. Entrez un nom, par exemple ZTWS, dans Nom du rôle.

2. Cliquez sur Créer rôle et tapez une description du rôle, par exemple, ″Rôle de

l’utilisateur TWS″.

3. Enregistrez le rôle.

4. Sélectionnez l’onglet Autorisations.

5. Cliquez sur Modifier données d’autorisation.

6. Dans la fenêtre suivante, sélectionnez Modèles.


7. Ajoutez manuellement les objets d’autorisation suivants :

Objet Description

S_ADMI_FCD Autorisations système

S_BTCH_ADM Traitement en arrière-plan : Administrateur du


S_BTCH_JOB Traitement en arrière-plan : Opérations sur des

travaux d’arrière-plan

S_BTCH_NAM Traitement en arrière-plan : nom de l’utilisateur

d’arrière-plan

S_PROGRAM ABAP : Contrôles de l’exécution du programme

S_RFC Contrôle des autorisations pour l’accès RFC

S_SPO_ACT Spoule : Actions

S_SPO_DEV Spoule : Autorisations des périphériques

S_XMI_LOG Autorisations d’accès interne pour le journal XMI

S_XMI_PROD Autorisation pour les interfaces de gestion externes

(XMI)

8. Entrez les valeurs conformément au schéma suivant :

S_ADMI_FCD Autorisations système

v Fonction d’administration système : Autorisation

globale

S_BTCH_ADM Traitement en arrière-plan : Administrateur du


v ID administrateur du traitement en arrière-plan :

Autorisation globale

S_BTCH_JOB Traitement en arrière-plan : Opérations sur des

travaux d’arrière-plan

v Opérations sur les travaux : Autorisation globale

v Récapitulatif des travaux d’un groupe :


S_BTCH_NAM Traitement en arrière-plan : Nom de l’utilisateur

d’arrière-plan

v Nom de l’utilisateur d’arrière-plan pour le

contrôle des autorisations : Autorisation globale

S_PROGRAM ABAP : Contrôles de l’exécution du programme

v Programme ABAP/4 sur les actions utilisateur :


v Programme ABAP/4 sur les groupes

d’autorisations : Autorisation globale

S_RFC Contrôle des autorisations pour l’accès RFC

v Activité : Autorisation globale

v Nom du RFC à protéger : Autorisation globale

v Type d’objet RFC à protéger : Autorisation

globale

Chapitre 15. Configuration de l’environnement R/3 93

S_SPO_ACT Spoule : Actions

v Zone d’autorisation pour les actions de spoule :


v Valeur pour le contrôle des autorisations :


S_SPO_DEV Spoule : Autorisations des périphériques

v Spoule - Noms de périphérique longs :


S_XMI_LOG Autorisations d’accès interne pour le journal XMI

v Méthode d’accès pour le journal XMI :


S_XMI_PROD Autorisation pour les interfaces de gestion externes

(XMI)

v Journalisation XMI - Nom de l’entreprise :

TIVOLI*

v Journalisation XMI - Nom du programme :

MAESTRO*

v ID interface : Autorisation globale

9. Enregistrez les autorisations.

10. Générez un profil. Utilisez le même nom que celui que vous avez entré dans

la zone Nom du rôle.

11. Fermez la fenêtre de gestion des autorisations et sélectionnez l’onglet

Utilisateur.

12. Ajoutez l’utilisateur Tivoli Workload Scheduler au rôle.

13. Enregistrez le rôle.

Copie des fichiers de correction et de transfert

Le fichier d’installation charge deux fichiers de correction et de transfert dans le

répertoire de base Tivoli Workload Scheduler. Vous devez copier ces fichiers sur le

serveur R/3 et les importer dans la base de données R/3, comme suit :

1. Sur le serveur de base de données R/3, connectez-vous à votre système R/3 en

tant qu’administrateur.

2. Copiez le fichier de commandes et le fichier de données, du répertoire

racine_TWS \methods vers les répertoires de votre serveur de base de

données R/3 suivants :

copiez fichier_commandes /usr/sap/trans/cofiles/

copiez fichier_données /usr/sap/trans/data/

Les noms fichier_commandes et fichier_données varient d’une version à l’autre. Les

fichiers sont installés dans le répertoire racine_TWS\methods et ont les noms de

fichier et format suivants : K000xxx.TV1 (fichier de commandes) et

R000xxx.TV1 (fichier de données), où xxx est une valeur fonction de la version.

Importation de modules ABAP/4 dans R/3

Cette procédure génère, active et valide de nouveaux modules fonctionnels

ABAP/4 sur votre système R/3 ainsi que de nouvelles tables internes. Aucun objet

système R/3 existant n’est modifié.

1. Accédez au répertoire suivant :

cd /usr/sap/trans/bin


2. Ajoutez le fichier de transfert au tampon :

tp addtobuffer sid transfert

où :

transfert

représente le fichier de demande de transfert. sid

représente votre ID système R/3.

Sous le répertoire racine_TWS\methods, se trouve fichier nommé

K000xxx.TV1 ; la demande de transfert est donc tv1K000xxx.

3. Exécutez la commande tp tst pour tester l’importation :

tp tst sid transfert

Après l’exécution de cette commande, consultez les messages d’erreur des

fichiers journaux dans le répertoire /user/sap/trans/log. Les avertissements

d’un niveau de sévérité 4 sont normaux.

S’il y a des erreurs, demandez l’avis d’une personne expérimentée en matière

de correction et de transfert, ou essayez d’utiliser les modes inconditionnels

pour effectuer l’importation.

4. Exécutez la commande suivante pour importer tous les fichiers dans le

tampon :

tp import sid transfert

Cette commande génère les nouveaux modules ABAP/4 et les valide dans la

base de données R/3. Ils sont automatiquement activés.

Après l’exécution de cette commande, consultez les messages d’erreur des

fichiers journaux dans le répertoire /user/sap/trans/log. Les avertissements

d’un niveau de sévérité 4 sont normaux.

Si vous rencontrez un problème, utilisez un mode inconditionnel pour exécuter

cette étape :

tp import sid transfert U126

5. Une fois la procédure terminée, examinez les fichiers journaux pour vérifier

que l’importation a réussi. Les fichiers journaux se trouvent dans le répertoire

/usr/sap/trans/log.

Installation des modules ABAP r3batch sur le système R/3

Installez les modules ABAP r3batch sur le système R/3. Pour plus de détails sur

l’installation des modules ABAP r3batch, reportez-vous au Chapitre 15,

«Configuration de l’environnement R/3», à la page 91. Ce chapitre contient des

instructions pour la création d’un utilisateur RFC et l’installation des modules

ABAP suivants :

J_1O1_BDC_STATUS

J_1O1_DATE_TIME

J_1O1_JOB_ABAP_STEP_MODIFY

J_1O1_JOB_ADD_ABAP_STEP

J_1O1_JOB_ADD_EXTPGM_STEP

J_1O1_JOB_CLOSE

J_1O1_JOB_COPY

J_1O1_JOB_DEFINITION_GET

J_1O1_JOB_DELETE

J_1O1_JOB_EXTPGM_STEP_MODFY

J_1O1_JOB_FIND

J_1O1_JOB_FINDALL

J_1O1_JOB_HAS_EXTENDED_VARIANT

J_1O1_JOB_LOG

J_1O1_JOB_LOG_READ


J_1O1_JOB_OPEN

J_1O1_JOB_START

J_1O1_JOB_STATUS

J_1O1_JOB_STATUS_CHECK

J_1O1_JOB_STOP

J_1O1_RAISE_EVENT

J_1O1_REPORT_ALL_SELECTIONS

J_1O1_REPORT_DYNSEL_GET_DEF

J_1O1_REPORT_GET_TEXTPOOL

J_1O1_TABLE_GET_NAMETAB

J_1O1_VARIANT_COPY

J_1O1_VARIANT_COPY_4X

J_1O1_VARIANT_CREATE

J_1O1_VARIANT_CREATE_NEW

J_1O1_VARIANT_DELETE

J_1O1_VARIANT_DELETE_NEW

J_1O1_VARIANT_EXISTS

J_1O1_VARIANT_GET_DEFINITION

J_1O1_VARIANT_GET_DEF_NEW

J_1O1_VARIANT_GET_HELP_VALUES

J_1O1_VARIANT_INFO_GET

J_1O1_VARIANT_MAINTAIN_CNT_TBL

J_1O1_VARIANT_MAINTAIN_SEL_TBL

J_1O1_VARIANT_MODIFY

J_1O1_VARIANT_MODIFY_NEW

Identification et résolution des incidents

Si vous ne pouvez pas soumettre de travaux R/3 via Tivoli Workload Scheduler

après avoir configuré R/3, effectuez les tests suivants :

v Vérifiez que vous pouvez exécuter une commande Ping sur le système R/3 à

partir du système Tivoli Workload Scheduler. Ceci prouvera une connectivité

réseau de base.

v Notez que l’utilisation de routeurs R/3 pour accéder au système R/3 peut

excéder la taille des tampons internes de la bibliothèque RFC utilisée pour

stocker le nom d’hôte du système R/3. Si tel est le cas, le nom d’hôte est

tronqué, ce qui entraîne l’échec de la connexion R/3. Pour contourner ce

problème, n’utilisez pas le nom qualifié complet des routeurs R/3, ou utilisez

les adresses IP.

v Utilisez la commande telnet suivante pour vérifier la connectivité :

telnet nom_système 33xx

où nom_système correspond au nom du système ou à l’adresse IP du

serveur R/3 et xx correspond à l’instance R/3.

v Connectez-vous à R/3 en tant qu’administrateur et vérifiez que l’utilisateur RFC

Tivoli Workload Scheduler (créé à la section «Création de l’utilisateur RFC pour

IBM Tivoli Workload Scheduler» à la page 91) existe.

v Créez un nouveau travail IBM Tivoli Workload Scheduler à exécuter sous R/3

et ajoutez les options avancées suivantes :

-debug

-trace

Vous pouvez sélectionner ces options via les boutons d’option correspondant

dans la page Propriétés - Définition du travail de Job Scheduling Console.

L’option -debug permet d’inclure des informations de débogage

supplémentaires dans le fichier stdlist du travail (dans Tivoli Workload

Scheduler).


Lorsque vous utilisez l’option -trace, un fichier de trace est créé dans le

répertoire de base Tivoli Workload Scheduler. Sous UNIX, ce fichier s’appelle

dev_rfc, sous Windows, il s’appelle rfcxxxxx_xxxxx.trc. Veillez à supprimer

l’option -trace du travail après avoir exécuté les procédures de débogage. Le

fichier de trace peut, en effet, devenir très volumineux et ingérable.

Remarque :En règle générale, ces options sont destinées au débogage de

l’agent étendu et ne doivent pas être utilisées dans la production standard.v Si, pour une raison quelconque, la passerelle R/3 tronque la chaîne de

connexion, remplacez le nom IP par l’adresse IP.

v Si vous effectuez l’installation sur un système AIX qui n’utilise pas

l’anglais U.S., vous devez installer l’environnement de langue U.S. sur le

poste de travail IBM Tivoli Workload Scheduler et sur celui hébergeant la base

de données R/3. Sinon, l’erreur BAD TEXTENV (ou un message d’erreur

similaire) apparaîtra dans le fichier de trace dev_rfc et les connexions à R/3

échoueront.

Modification du mot de passe de l’ID utilisateur RFC au niveau de

Tivoli Workload Scheduler

Si le mot de passe de l’ID utilisateur RFC Tivoli Workload Scheduler a été modifié

après l’installation initiale, le fichier d’options utilisé par r3batch doit être mis à

jour en conséquence.

Sous UNIX, connectez-vous en tant que root au système où Tivoli Workload

Scheduler est installé.

Sous Windows, connectez-vous en tant qu’administrateur et ouvrez un shell DOS

sur le système où Tivoli Workload Scheduler est installé, en procédant comme

suit :

1. Générez une version codée du nouveau mot de passe en exécutant la

commande enigma dans racine_TWS/methods. Pour ce faire, tapez dans le shell

de commandes :

enigma nouveau_mot

où nouveau_mot correspond au nouveau mot de passe de l’ID utilisateur RFC


La commande enigma renvoie une version codée du mot de passe.

2. Copiez le mot de passe codé dans le fichier d’options qui se trouve dans le

répertoire racine_TWS/methods. Ce fichier peut être modifié dans un n’importe

quel éditeur de texte.

Veillez à recopier le mot de passe correctement, en respectant les majuscules, les

minuscules et les signes de ponctuation. Voici un exemple de mot de passe codé :

#TjM-pYm#-z82G-rB

Si le mot de passe codé est mal saisi, Tivoli Workload Scheduler ne pourra ni

lancer, ni contrôler les travaux par lots R/3.

Migration à partir de versions précédentes

Cette version de l’agent étendu Tivoli Workload Scheduler pour R/3 prend en

charge toutes les versions R/3 listées au tableau 13 à la page 87. Pour répondre

aux exigences de la certification XBP R/3 intégrée aux versions 4.0 et 4.5 de R/3,

quelques modifications ont été apportées à l’agent de planification. L’agent étendu


Tivoli Workload Scheduler pour R/3 version 4.x utilise les interfaces

officielles RFC R/3 pour la planification des travaux, à savoir :

v L’interface SXMI_XBP pour les versions 3.1g à 4.0x de R/3 ;

v L’interface BAPI_XBP à partir de la version 4.5a.

Pour éviter les conflits avec d’autres fournisseurs, les modules ABAP pour Tivoli

Workload Scheduler appartiennent désormais à l’espace annuaire J_1O1_xxx des

partenaires Tivoli Workload Scheduler. Dès que les procédures d’importation

décrites à la section «Importation de modules ABAP/4 dans R/3» à la page 94 ont

été exécutées, les modules de fonction RFC J_1O1_xxx sont installés sur votre

système.

Si vous avez déjà installé l’agent étendu Tivoli Workload Scheduler pour R/3 sur

votre système, vous pouvez supprimer les modules suivants de votre

système R/3 :

Z_MAE2_BDC_STATUS

Z_MAE2_DATE_TIME

Z_MAE2_JOB_COPY

Z_MAE2_JOB_DELETE

Z_MAE2_JOB_FIND

Z_MAE2_JOB_FINDALL

Z_MAE2_JOP_OPEN

Z_MAE2_JOB_LOG

Z_MAE2_JOB_START

Z_MAE2_JOB_STATUS

Z_MAE2_JOB_STOP

Il s’agit d’anciennes versions des modules ABAP Tivoli, qui appartiennent à

l’espace annuaire de l’utilisateur. Vous pouvez également supprimer le groupe

fonctionnel YMA3. Il n’est pas obligatoire de supprimer ces éléments, mais vous

pouvez le faire pour nettoyer votre système.

Utilisation du support d’interface XBP 2.0

L’interface SAP pour la planification des travaux externes (BC-XBP) a été

récemment étendue de manière à remédier aux limitations mises en évidence par

les clients et les partenaires. Elle est fournie par Basis Support Packages pour

toutes les versions de R/3, à compter de WAS 4.6B.

Les limitations suivantes ont été supprimées :

v La classe de travail n’est plus limitée à C,

v Tous les paramètres d’impression sont disponibles.

Les fonctionnalités suivantes ont été ajoutées :

v Relation parent-enfant,

v Interception des travaux,

v Prise en charge des travaux à l’aide d’étapes de commandes externes.

Consultez et appliquez les notes SAP suivantes avant d’utiliser l’interface XBP 2.0:

v 602683

v 612564

v 604496


Création du profil d’autorisation pour l’utilisateur Tivoli

Workload Scheduler

Il existe deux méthodes pour ajouter l’objet d’autorisation correspondant au profil

d’autorisations de l’utilisateur Tivoli Workload Scheduler :

v Utilisation de la transaction SU02,

v Utilisation du générateur de profils.

Utilisation de la transaction SU02

Ajoutez l’objet suivant :

Objet Description Autorisation

S_RZL_ADM CCMS : Administration système S_RZL_ALL

Utilisation du générateur de profils

Procédez de la manière suivante :

1. Ajoutez manuellement l’objet suivant :

Objet Description

S_RZL_ADM CCMS : Administration système

2. Attribuez à la zone Activité la valeur Autorisation globale.

Incidents dus aux paramètres d’impression et à la classe de travail

L’agent étendu R/3 utilise les interfaces RFC officielles des versions R/3 4.x à 6.20

pour la planification des travaux. Lorsque vous migrez de précédentes versions de

R/3, il peut y avoir des problèmes au niveau des paramètres d’impression dans les

travaux lancés par Tivoli Workload Scheduler, et ce, en raison des limitations dues

aux interfaces RFC.

Ces limitations n’existent plus avec XBP 2.0.

Le tableau ci-après indique les paramètres d’impression pris en charge par BAPI

XBP 1.0.

Paramètre

d’impression 3.1x 4.0x

4.5x et ultérieure

unité de sortie U U U

impression

immédiate

U U U

suppression après

sortie

U U U

nombre de copies U U U

mode d’archivage U U U

autorisation U U U

sélection de la page

de garde

x U U

page de garde SAP U U U

période de rétention

du spoule

U U U


Paramètre

d’impression 3.1x 4.0x

4.5x et ultérieure

destinataire x x U

lignes x x U

colonnes x x U

Pour résoudre la perte des paramètres d’impression durant la copie d’un travail,

installez le Support Package R/3 approprié comme indiqué dans les notes R/3

399449 et 430087.

Il en va de même pour la classe de travail. Les interfaces R/3 officielles ne

prennent en charge que les travaux de la classe C. L’installation du Support

Package R/3 résout également cet incident.


Chapitre 16. Définition des travaux d’agent étendu R/3

Pour contrôler l’exécution de travaux sur un poste de travail R/3 à partir de Tivoli

Workload Scheduler, vous devez définir :

v Des travaux R/3 que vous voulez exécuter sous le contrôle de Tivoli Workload

Scheduler. Vous pouvez définir ces travaux à l’aide des outils R/3 standard ou

des fenêtres SAP de Job Scheduling Console.

v Des travaux Tivoli Workload Scheduler qui correspondent à des travaux R/3.

Les définitions de travaux Tivoli Workload Scheduler sont utilisées pour la

planification et la définition des dépendances, mais ce sont les travaux R/3 qui

sont exécutés.

Définition d’un travail dans R/3

Pour créer des travaux R/3 contrôlés par Tivoli Workload Scheduler, vous pouvez

utiliser :

v les outils R/3 standard pour la définition des travaux, ou

v les fenêtres SAP de Job Scheduling Console.

Reportez-vous à la documentation R/3 pour plus d’informations sur la création

des travaux avec les outils R/3. Lorsque vous créez des travaux dans R/3, ne

spécifiez ni l’heure de début, ni leurs dépendances. Ces paramètres sont spécifiés

et contrôlés dans Tivoli Workload Scheduler. Le travail est identifié dans Tivoli

Workload Scheduler par son nom et son ID de travail R/3. Le même travail peut

être planifié pour être exécuté à plusieurs reprises par Tivoli Workload Scheduler,

sans qu’il y ait besoin de le redéfinir à chaque fois dans R/3.

Remarque : Pour les travaux R/3 contrôlés par Tivoli Workload Scheduler, la

sortie dans le journal des travaux R/3 se trouve sous le nom

d’utilisateur défini dans l’option r3user du fichier d’options.

Définition d’un travail dans Tivoli Workload Scheduler

Pour définir un travail Tivoli Workload Scheduler, vous pouvez utiliser :

v Tivoli Job Scheduling Console.

v La ligne de commande Tivoli Workload Scheduler.

v Les boîtes de dialogue ISPF de Tivoli Workload Scheduler pour z/OS, si vous

envisagez de planifier le travail dans un environnement de bout en bout.

Pour plus de détails, reportez-vous au Chapitre 5, «Définition des travaux d’agent


Les procédures décrites au Chapitre 5, «Définition des travaux d’agent étendu», à

la page 37 sont communes à tous les agents étendus Tivoli Workload Scheduler.

L’agent étendu pour R/3 propose une procédure supplémentaire via Job

Scheduling Console.

Dans Job Scheduling Console, lorsque vous sélectionnez le type de tâche pour une

nouvelle définition de travail, vous pouvez choisir entre deux types :


Tâche d’agent étendu

Ce type de tâche est commun à tous les agents étendus. Si vous choisissez

cette option :

v Le travail R/3 associé doit être déjà défini dans la base de données R/3

et vous devez connaître son nom.

v Vous pouvez utiliser la zone Commande dans l’une des fenêtres de

définition du travail pour entrer les paramètres nécessaires à l’exécution

du travail R/3.

v Les postes de travail d’agent étendu que vous avez définis pour R/3 (en

spécifiant r3batch comme méthode d’accès) sont listés comme postes de

travail génériques d’agent étendu.

SAP Ce type de tâche est spécifique aux travaux d’agent étendu R/3. Si vous

choisissez cette option :

v Vous pouvez définir ou mettre à jour le travail R/3 ainsi que les

variables SAP ou les paramètres d’exécution du travail à partir des

fenêtres Job Scheduling Console, comme si vous opériez dans R/3.

v Les postes de travail d’agent étendu R/3 sont considérés comme des

postes de travail R/3. Ils n’apparaissent pas dans les listes de postes de

travail génériques d’agent étendu qui s’affichent lorsque vous cliquez

sur les points de suspension en regard de la zone Poste de travail. Vous

devez connaître le nom pour pouvoir l’entrer dans la zone.

Pour que SAP soit affiché comme tâche optionnelle dans Job Scheduling Console,

vous devez attribuer la valeur r3batch à l’option jobdef dans le fichier d’options

r3batch.opts (situé dans le sous-répertoire methods de racine_TWS) du poste

maître Tivoli Workload Scheduler.

Pour savoir comment définir un travail d’agent étendu R/3 via les fenêtres Tâche

d’agent étendu, reportez-vous au Chapitre 5, «Définition des travaux d’agent

étendu», à la page 37. Pour savoir comment définir un travail d’agent étendu R/3

via les fenêtres de tâche SAP, accédez à la section suivante.

Utilisation des fenêtres SAP de Job Scheduling Console

Pour créer une définition de travail R/3 dans la base de données Tivoli Workload

Scheduler, exécutez les étapes suivantes :

1. Dans la liste Actions de la fenêtre principale de Job Scheduling Console,

sélectionnez Nouvelle définition de travail.

2. Sélectionnez un moteur Tivoli Workload Scheduler et, dans la liste affichée,

cliquez sur SAP. La fenêtre Propriétés - Définition du travail s’affiche.


3. Dans la page Général, définissez le travail Tivoli Workload Scheduler qui

pilotera le travail R/3. Renseignez les zones suivantes :

a. Dans la zone Nom, entrez un nom Tivoli Workload Scheduler pour le

travail R/3. Ce nom peut contenir jusqu’à huit caractères alphanumériques,

ou quarante si vous utilisez une base de données étendue. Il doit

commencer par une lettre.

b. Dans la zone Poste de travail, cliquez sur les points de suspension (...) pour

ouvrir une fenêtre de recherche et sélectionnez un poste de travail

disponible.

c. Dans la zone Description, entrez une description du travail. Il s’agit d’une

zone optionnelle qui peut comporter jusqu’à 64 caractères alphanumériques.

d. Dans la zone Connexion, entrez l’ID de connexion Tivoli Workload

Scheduler utilisé pour exécuter le travail.

e. Cliquez sur Ajouter un paramètre pour ajouter des paramètres prédéfinis à

l’ID de connexion.

f. Dans les zones Options de récupération, spécifiez les options de

récupération pour le travail R/3. Pour plus de détails sur les options de

récupération, reportez-vous au manuel IBM Tivoli Workload Scheduler - Guide

de référence.4. Sélectionnez Tâche. La page Tâche s’affiche.

Figure 26. Fenêtre Propriétés - Définition du travail

Chapitre 16. Définition des travaux d’agent étendu R/3 103

Cette page vous permet de fournir des informations sur le travail R/3 qui sera

géré par le travail Tivoli Workload Scheduler défini à la page précédente. Vous

pouvez également utiliser cette page pour créer des travaux R/3 standard

(mais non des InfoPackages ou des chaînes de processus) dans le système SAP.

5. Pour spécifier un travail R/3 existant :

a. Dans la page Tâche, spécifiez le type de travail et cliquez sur les points de

suspension ...) en regard de la zone Nom du travail. La fenêtre Liste de

réquisition SAP apparaît.

b. Utilisez la liste de réquisition pour trouver et sélectionner un travail R/3 et

cliquez sur OK. Les informations sur le travail sont affichées dans les zones

de la page Tâche précédente :

v zone Nom du travail,

v zone ID de travail,

v bouton Type de travail R/3.

Si le type de travail est Travail R/3 standard, vous pouvez le modifier et

afficher ses détails et son statut.

Si le type de travail est Business Warehouse InfoPackage ou Chaîne de

processus, vous ne pouvez afficher que ses détails.6. Pour créer un travail R/3 standard :

a. Dans la page Tâche, sélectionnez Travail R/3 standard et cliquez sur

Nouveau. La page Travail R/3 de la fenêtre Définition du travail SAP

s’affiche.

Figure 27. Propriétés - Définition du travail : Tâches


b. Dans la page Travail R/3, entrez les informations relatives au travail à

créer :

1) Entrez le nom du travail dans la zone Nom du travail.

2) Laissez la zone ID du travail vide. Un ID sera attribué par le

système R/3 lorsque vous enregistrerez la définition du travail.

3) Tapez le nom du poste de travail R/3 où ce travail doit s’exécuter dans

la zone Hôte cible.

4) Cliquez sur Etapes pour accéder à la page suivante.

Figure 28. Page Travail R/3 de la fenêtre Définition du travail SAP.


c. Dans la page Etapes, vous pouvez spécifier un ou plusieurs module(s)

ABAP ou des programme externe pour le travail R/3. Répétez les étapes

suivantes autant de fois que vous avez d’étapes à définir :

1) Cliquez sur le bouton Ajouter une ligne pour ajouter une ligne à la

table des étapes.

2) Double-cliquez dans la zone Type et choisissez s’il s’agit d’un module

ABAP ou d’un programme externe.

3) Dans la zone Nom, entrez le nom d’un module ABAP ou le chemin

complet d’un programme externe.

4) Dans la zone Utilisateur, entrez le nom de l’utilisateur R/3 qui exécute

cette étape.

5) si nécessaire, dans la zone Var/Parm, entrez un nom de variable ou un

paramètre. Les variables sont utilisées avec les modules ABAP, et les

paramètres avec les programmes externes, mais tous deux sont

facultatifs. Certains modules ABAP ne requièrent pas de variables, tout

comme certains programmes externes ne requièrent pas de paramètres.

Des points de suspension (...) sont disponibles en regard de la zone. Ils

Figure 29. Page Etapes de la fenêtre Définition du travail SAP.


permettent d’afficher la liste des variables associées au module ABAP.

Vous pouvez utiliser cette liste pour sélectionner une variable ou pour

créer ou modifier des définitions de variables. Reportez-vous à la section

«Définition ou mise à jour des variables R/3 dans Job Scheduling

Console» pour plus de détails.

6) Dans la zone Hôte cible, entrez le poste de travail R/3 où doit

s’exécuter cette étape. Les hôtes cible ne sont obligatoires que pour les

programmes externes.

7) Entrez les spécifications des paramètres d’impression et des indicateurs

de contrôle, conformément aux exigences de R/3.d. Une fois que vous avez paramétré les différentes étapes de module ABAP

ou de programme externe, cliquez sur OK. La définition du travail R/3 est

alors enregistrée dans la base de données R/3 et la fenêtre se ferme. Si le

travail R/3 a été correctement enregistré dans la base de données R/3, la

page Tâche de la fenêtre Propriétés - Définition du travail doit à présent

afficher un ID de travail R/3.7. Cliquez sur OK dans la fenêtre Propriétés - Définition du travail pour

enregistrer la définition du travail dans la base de données Tivoli Workload

Scheduler.

Définition ou mise à jour des variables R/3 dans Job Scheduling

Console

Si vous cliquez sur les points de suspension en regard de la zone Var/Parm dans la

fenêtre Définition du travail SAP, la fenêtre Liste des variantes apparaît. Cette

fenêtre liste toutes les variables associées au module ABAP indiqué dans la zone

Nom de la fenêtre Définition du travail SAP et ressemble à celle représentée

ci-dessous.

Dans cette fenêtre, en plus des autres actions, vous pouvez créer ou mettre à jour

des variables. Pour ce faire, cliquez sur Nouveau ou sur Editer. Une fenêtre Cadre

Figure 30. Fenêtre Liste des variantes.


de variante, similaire à celle illustrée ici, s’ouvre (si vous êtes en phase de

modification, les zones et les sélections ne seront pas vides) :

Dans la page Informations sur la variante, procédez comme suit :

1. Entrez/modifiez le nom et la description de la variable.

2. Si nécessaire, dans la zone Propriétés, cochez l’une des cases suivantes :

Arrière-plan

La variable ne peut être utilisée que dans un traitement en arrière-plan.

Protégé

La variable ne peut être modifiée par aucun autre utilisateur.

Invisible

La variable n’apparaîtra pas dans la liste appelée par la touche F4, dans

l’interface utilisateur SAP.

Etendu

Autorise l’utilisation de marques de réservation et de compteurs

comme variables. Si vous cochez cette case, le bouton Compteur

devient actif.

Pour les variables étendues, vous pouvez utiliser des marques de réservation et

des compteurs qui éliminent le réglage des valeurs comportant souvent des

erreurs et réduisent considérablement la gestion des variables. Les marques de

réservation et les compteurs sont traités à l’avance par Tivoli Workload

Scheduler et les valeurs sont automatiquement ajustées lorsque le travail est

lancé. Les marques de réservation et les compteurs pris en charge sont les

suivants :

Tableau 14. Marques de réservation et compteurs pour les variables étendues.

Symbole Signification Syntaxe

$S Horodatage AAAAMMJJHHMM

$D Jour du mois JJ

$_D Date AAAAMMJJ

$M Mois MM

$Y Année AA

$_Y Année AAAA

Figure 31. Page Informations sur la variante de la fenêtre Liste des variantes.


Tableau 14. Marques de réservation et compteurs pour les variables étendues. (suite)

Symbole Signification Syntaxe

$H Heure HH

$T Minute MM

$_T Heure HHMMSS

$Nx Compteurs 10 compteurs : $N0 - $N9

($N = $N0)

$(expression_date) Expression date Identique à commande

datecalc, au format $(...).

$[expression_arithmétique] Expression arithmétique Expressions arithmétiques

autorisant des opérations +,

−, * et / entre des entiers et

des compteurs.

Dans la page Valeurs de variante, les zones et les valeurs sont créées de manière

dynamique par r3batch en fonction des caractéristiques de la variable ou de

l’étape et sont identiques à celles contenues dans la fenêtre SAP équivalente.

Paramètres de chaîne de tâches pour les travaux R/3

Cette section décrit les paramètres des chaînes de tâches qui gèrent l’exécution des

travaux R/3. Vous devez les spécifier aux emplacements suivants lorsque vous

définissez les travaux Tivoli Workload Scheduler qui leur sont associés :


du travail, si vous utilisez Job Scheduling Console et sélectionnez Tâche d’agent

étendu (et non SAP) lors de la définition d’un nouveau travail.

v En tant qu’arguments du mot clé SCRIPTNAME dans l’instruction de définition du




environnement de bout en bout.

La syntaxe de la chaîne est la suivante :

-job nom_travail ( -user nom_utilisateur | -i (id_travail|ipack_|pchain_) )

[-client client_définition] [-exec_client client_exécution] [-debug] [-trace]

Ces paramètres sont décrits dans le tableau ci-après.

Tableau 15. Paramètres de chaîne de tâches pour les travaux R/3.


-job nom_travail

Nom de la tâche à exécuter. Il s’agit soit

d’un de nom de travail R/3, d’un nom de

zone technique InfoPackage ou d’un nom

de chaîne de processus (ProcessChain). Ce

paramètre est obligatoire.

-user nom_utilisateur

Utilisateur R/3 propriétaire du travail

cible. Ce paramètre ne peut être utilisé que

lorsque le système R/3 cible n’a qu’un

seul travail du nom spécifié, pour

l’utilisateur spécifié. Il n’a aucun effet sur

des travaux de type InfoPackage ou

ProcessChain, ni si un ID de travail a été

spécifié dans la définition du travail.


Tableau 15. Paramètres de chaîne de tâches pour les travaux R/3. (suite)


-i id_travail

L’un des ID suivants :

v ID de travail R/3 unique, si le travail

cible est un travail standard.

v ipack_, si le travail cible est un

InfoPackage.

v pchain_, si le travail cible est une chaîne

de processus.

Les paramètres -user, -client et

-exec_client n’auront aucun effet si vous

spécifiez un ID de travail. Pour les travaux

InfoPackage et ProcessChain, ce paramètre

est obligatoire.

-client client_définition

Numéro identifiant le client R/3 où doit

se trouver la définition du travail,

indépendamment du numéro de client

défini par le mot clé r3client dans le

fichier d’options. Ce paramètre n’a aucun

effet sur des travaux de type InfoPackage

ou ProcessChain, ni si un ID de travail a

été spécifié dans la définition du travail.

-exec_client client_exécution

Numéro identifiant le client R/3 où le

travail doit s’exécuter, indépendamment

du numéro de client défini par le mot clé

r3client dans le fichier d’options. Ce

paramètre n’a aucun effet sur des travaux

de type InfoPackage ou ProcessChain, ni si

un ID de travail a été spécifié dans la

définition du travail.

-debug

Active la trace r3batch la plus explicite.

-trace

Active la trace RFC SAP.

Remarques :

1. Vous pouvez spécifier à la fois -i et -user dans une même définition de travail,

mais le nom d’utilisateur sera ignoré.

2. Lorsque vous spécifiez un ID de travail, -client et -exec_client sont ignorés

puisque l’ID est le même pour l’ensemble du système R/3.

Voici un exemple de travail R/3 appelé BVTTEST, ayant pour ID 03102401 et pour

utilisateur mon_utilisateur :

-job BVTTEST

–i 03102401 -debug

Voici un exemple de travail InfoPackage dont le nom de zone technique est

ZPAK_3LZ3JRF29AJDQM65ZJBJF5OMY :

-job

ZPAK_3LZ3JRF29AJDQM65ZJBJF5OMY -i ipak_


Etats des travaux dans Tivoli Workload Scheduler et dans R/3

Lorsqu’un travail R/3 est lancé par Tivoli Workload Scheduler, vous pouvez

surveiller sa progression. Les transitions d’état utilisées dans Tivoli Workload

Scheduler (statut interne) et les statuts correspondants utilisés dans R/3 sont listés

dans le tableau ci-dessous.

Etat du travail dans Tivoli Workload Scheduler Etat du travail dans R/3

INTRO N/A

WAIT Prêt

EXEC Actif

SUCC Terminé

ABEND Annulé

L’état INTRO indique que Tivoli Workload Scheduler est en train d’introduire le

travail mais que le travail n’est pas encore considéré comme prêt dans R/3,. Etant

donné qu’il peut prendre un certain temps pour qu’un travail soit mis en file

d’attente et placé dans la colonne Prêt, l’état INTRO peut durer quelques minutes

si le système R/3 est très occupé.

Bien qu’un travail puisse être terminé dans R/3, Tivoli Workload Scheduler le

gardera avec l’état EXEC si ses sessions BDC ne sont pas achevées ou que vous

n’avez pas sélectionné l’option Désactivation de l’attente BDC. Pour utiliser cette

option, reportez-vous au Chapitre 21, «Attente BDC», à la page 127.


Chapitre 17. Réexécution de travaux

Avant de réexécuter un travail R/3 avec Tivoli Workload Scheduler, vous avez la

possibilité de préciser le nom d’une étape de ce travail. Si vous procédez ainsi, cela

influe sur r3batch de la manière suivante : si le nom de l’étape se présente sous le

format “xnnnnnn” ou “nnnnnnn” (où “x” représente un caractère non numérique

et “n” un caractère numérique), il est alors utilisé comme numéro d’étape de

démarrage pour la réexécution du travail R/3.

Dans tous les autres cas, cette valeur n’a aucun effet sur la réexécution du travail,

qui est réexécuté à partir de sa première étape.

Ce n’est que lorsque r3batch réexécute un travail à partir de sa première étape, soit

parce que l’utilisateur a spécifié celle-ci comme étape de démarrage, soit qu’il n’a

rien spécifié du tout, qu’il utilise la fonction de nouvelle copie (si la version de R/3

le permet). Si l’étape de démarrage est supérieure à un, alors r3batch utilise

l’ancienne copie pour réexécuter le travail.

La section ci-dessous explique la principale différence entre la nouvelle et

l’ancienne copie d’un travail à réexécuter.

Ancienne et nouvelle copies d’un travail à réexécuter

Lorsque la méthode d’accès R/3 doit lancer un travail, elle effectue une copie d’un

modèle de travail et l’exécute.

La fonction Nouvelle copie est disponible à partir des versions 3.1i de R/3. Elle

copie un travail entièrement, tout en préservant les étapes, la classe de travail et

tous les paramètres d’impression et d’archivage. Elle utilise un nouveau module

fonctionnel R/3 qui fait partie du Support Package R/3, comme indiqué dans les

notes R/3 399449 et 430087.

A l’inverse, la fonction d’ancienne copie, basée sur les modules fonctionnels R/3

standard, crée un nouveau travail R/3 et ajoute les étapes avec une boucle qui

démarre à partir du nom ou du numéro de l’étape que vous avez spécifié. Notez

que, sauf si vous disposez du support XBP 2.0 :

v L’ancienne copie ne préserve pas tous les paramètres d’impression et

d’archivage.

v La classe de travail de la copie est toujours ″C″.

Reportez-vous à la section «Incidents dus aux paramètres d’impression et à la

classe de travail» à la page 99 pour savoir comment résoudre les problèmes de

perte des paramètres d’impression et d’archivage et de la classe de travail.


Chapitre 18. Business Information Warehouse

Prise en charge de Business Information Warehouse - InfoPackages

Business Information Warehouse (BIW) est une solution de Data Warehousing

conçue spécialement pour R/3. Elle facilite le contrôle de gestion et la prise de

décisions.

Autorisations utilisateur

Tivoli Workload Scheduler for Applications pour R3 permet de gérer les

InfoPackages BIW R/3 ainsi que les chaînes de traitement. Afin de pouvoir utiliser

la fonctionnalité BIW R/3, vous devez définir un utilisateur Tivoli Workload

Scheduler R/3 avec les autorisations supplémentaires suivantes :

Les autorisations du tableau ci-dessous ne sont requises que si vous envisagez

d’utiliser les fonctionnalités BIW de l’agent étendu.

Objet Texte Autorisation

S_DEVELOP ABAP Workbench E_ABAP_ALL

Remarque : En plus du profil Z_MAESTRO, le profil S_RS_ALL doit être ajouté à

l’utilisateur Tivoli Workload Scheduler.

Composants Business Information Warehouse

R/3 prend en charge deux composants BIW principaux, les InfoPackages et les

chaînes de traitement.

Un InfoPackage constitue le point d’entrée du processus de chargement d’une

InfoSource spécifique (c’est-à-dire un conteneur logique de source de données,

génériquement appelé InfoObject). Techniquement, un InfoPackage est un travail

SAP concret ayant pour tâche de charger les données. Comme tout autre

travail R/3, il contient des paramètres spécifiques au travail, tels que l’heure de

début, les dépendances, etc.

Une chaîne de traitement est une chaîne complexe de différents processus et de

leurs relations. Les processus d’une chaîne ne se limitent pas à des processus de

chargement de données ou à des InfoPackages, mais peuvent également inclure :

v l’exécution de modifications d’attributs ou de hiérarchie,

v le cumul d’agrégats,

v le programme ABAP,

v une autre chaîne de traitement,

v l’intégration de clients.


Définition des travaux d’agent étendu pour BIW

Les InfoPackages et les chaînes de traitement ne peuvent être créés qu’à partir de

l’environnement R/3. Toutefois, le niveau 1.3 de Job Scheduling Console prend en

charge les listes de sélection d’InfoPackages et de chaînes de traitement, si bien que

vous pouvez dès à présent définir des travaux d’agent étendu Tivoli Workload

Scheduler pour ces objets.

Pour savoir comment définir des travaux d’agent étendu via les fenêtres SAP de

Job Scheduling Console, reportez-vous à la section «Utilisation des fenêtres SAP de

Job Scheduling Console» à la page 102.

Pour savoir comment définir des travaux d’agent étendu via les fenêtres Tâche

d’agent étendu de Job Scheduling Console ou via le programme Composer,

reportez-vous au Chapitre 5, «Définition des travaux d’agent étendu», à la page 37.

Pour connaître les paramètres de chaîne de tâches utilisés pour la spécification des

InfoPackages et des chaînes de traitement lorsque vous définissez des travaux

d’agent étendu via les fenêtres Tâche d’agent étendu de Job Scheduling Console ou

via le programme Composer, reportez-vous à la section «Paramètres de chaîne de

tâches pour les travaux R/3» à la page 109.

Options de planification R/3 d’un InfoPackage

Pour pouvoir planifier des InfoPackages via IBM Tivoli Workload Scheduler, les

options de planification d’InfoPackage doivent être configurées comme suit :

v Le type de démarrage doit avoir pour valeur ″Démarrage ultérieur en

arrière-plan″.v L’heure de démarrage doit être définie comme ″Immédiat″.


Chapitre 19. Connexion au système R/3

Tivoli Workload Scheduler for Applications pour R3 utilise la bibliothèque RFC

(appel de connexion distante) de SAP pour se connecter au système R/3. L’adresse

de connexion d’un système R/3 est appelée chaîne de connexion.

Connexions à un serveur d’applications spécifique

Dans sa forme primaire, une chaîne de connexion est constituée du nom d’hôte (ou

nom IP) d’un serveur d’applications R/3, par exemple :

/H/hemlock.tivlab.raleigh.ibm.com

Ce type de chaîne de connexion fonctionne uniquement dans des environnements

réseau très simples, dans lesquels tous les serveurs d’applications sont directement

accessibles via TCP/IP. Généralement, les entreprises modernes utilisent des

topologies réseau plus complexes, avec un certain nombre de sous-réseaux qui ne

peuvent pas communiquer directement via TCP/IP. Pour pouvoir prendre en

charge ce type de réseau, la bibliothèque RFC de SAP utilise des dispositifs appelés

routeurs SAP, qui sont placés à la limite des sous-réseaux et font office de proxys.

Dans ce cas, la chaîne de connexion finale est composée des chaînes de connexion

de base de chaque routeur SAP, auxquelles s’ajoute la chaîne de connexion de base

du système R/3 cible, par exemple :

/H/litespeed/H/amsaix33/H/hemlock.tivlab.raleigh.ibm.com

De plus, il est possible de protéger les routeurs SAP par des mots de passe afin

d’éviter les tentatives d’accès non autorisées. Dans ce cas, la chaîne de connexion

de base du routeur SAP est suivie de /P/ et du mot de passe du routeur.

Remarque : La bibliothèque RFC de SAP limite la longueur de la chaîne de

connexion à un maximum de 128 caractères, ce qui constitue une

réelle restriction dans les environnements réseau complexes. Pour

contourner cet obstacle, il est recommandé d’utiliser des noms d’hôte

simples, sans nom de domaine lorsque c’est possible. Vous pouvez

également utiliser les adresses IP, bien que ce ne soit pas recommandé

du fait de la lourdeur de gestion qu’elles imposent.

Tivoli Workload Scheduler for Applications pour R3 prend en charge les deux

types de chaînes de connexion, de base et composée, où :

r3host Est la chaîne de connexion.

r3instance

Est le numéro de l’instance R/3.

r3sid Est l’ID système R/3.

Par exemple :

r3host=/H/litespeed/H/amsaix33/H/hemlock.tivlab.raleigh.ibm.com

r3instance=00

r3sid=TV1


Groupes de connexion

Dans les installations R/3 plus vastes, les serveurs d’applications sont

généralement configurés en groupes de connexion à des fins d’équilibrage de la

charge et de tolérance aux pannes. L’équilibrage de la charge est effectué par un

serveur dédié, appelé serveur de messages. Ce serveur affecte automatiquement

les utilisateurs au serveur d’applications ayant la charge la plus faible du groupe

de connexion qu’il contrôle.

Définissez les options suivantes pour configurer r3batch dans le cadre d’un groupe

de connexion :

r3host Nom d’hôte du serveur de messages.

r3group

Nom du groupe de connexion.

r3sid ID système R/3.

Par exemple :

r3host=pwdf0647.wdf.sap-ag.de

r3group=PUBLIC

r3sid=QB6


Chapitre 20. Fichiers d’options de la méthode d’accès R/3

Les fichiers d’options de la méthode d’accès R/3 sont les suivants :

r3batch.opts

Fichier de configuration commun pour la méthode d’accès r3batch, dont

les paramètres affectent toutes les instances r3batch. Il fonctionne comme

un fichier de configuration “global”.

NOM_CPU_r3batch.opts

Fichier de configuration propre à chaque poste de travail d’agent étendu

IBM Tivoli Workload Scheduler - nommé de manière

générique“NOM_CPU” - à l’aide de la méthode d’accès r3batch. Ses

options affectent uniquement l’instance r3batch utilisée par ce poste de

travail en particulier. Il fonctionne comme un fichier de configuration

“local”.

Par exemple, si vous souhaitez définir deux agents étendus nommés wkst1 et wkst2

qui accéderont à deux systèmes R/3 - SAP1 et SAP2 - avec la méthode d’accès

r3batch, vous devez définir les fichiers de configuration suivants :

v Le fichier global r3batch.opts

v Le fichier local wkst1_r3batch.opts

v Le fichier local wkst2_r3batch.opts

Remarque : Si r3batch trouve le fichier de configuration local d’un agent étendu, il

ignore les informations contenues dans r3options.

Options de configuration

Cette section décrit les options à configurer dans r3batch.opts et dans

NOM_CPU_r3batch.opts.

Options globales

Le tableau suivant répertorie les options que vous devez définir dans le fichier de

configuration global r3batch.opts. Ces options n’ont d’effet que lors de l’exécution

d’un agent étendu Tivoli Workload Scheduler dans un environnement Unix.

Remarque : Ces options ne prennent effet que si elles sont définies r3batch.opts.

Tableau 16. Options de configuration globale R3batch.

Option Description

job_sem_proj ID projet du sémaphore du travail.

var_sem_proj ID projet du sémaphore de la variante.

icp_sem_proj ID projet du sémaphore d’interception du

travail.

Les options job_sem_project et var_sem_project sont deux paramètres avancés qui

vous permettent de personnaliser la synchronisation des travaux. Le système R/3

synchronise l’accès à la base de données à l’aide d’un système de gestion du

verrouillage. Lorsque Tivoli Workload Scheduler for Applications pour R3


fonctionne dans le système R/3, les modules de la fonction ABAP correspondante

verrouillent et déverrouillent différents objets dans la base de données. Lorsque

vous essayez de verrouiller un objet, le système de gestion du verrouillage ne

permet d’attendre que pendant un temps limité avant le rejet de la tentative de

verrouillage assorti d’un message d’erreur. Lorsque ce cas se produit, le module de

la fonction courante est également abandonné. Le temps maximal en secondes

alloué à chaque tentative de verrouillage est indiqué dans le paramètre système

enque/delay_max.

Le code retour du module de fonction est trop général pour distinguer le

dépassement du temps d’attente maximal du verrouillage des autres erreurs de la

base de données. Par conséquent, la méthode d’accès pour R/3 ne peut pas

continuer et signale une erreur. Si ce cas se produit pendant l’exécution d’un

travail R/3, celui-ci est à l’état abort.

Cette situation s’aggrave lorsque Tivoli Workload Scheduler démarre plusieurs

travaux simultanément. En fonction du temps d’attente maximal, certains d’entre

eux doivent être abandonnés en raison de l’expiration des tentatives de

verrouillage.

Pour résoudre cet incident, Tivoli Workload Scheduler for Applications pour R3

utilise des sémaphores au niveau d’OS pour synchroniser les appels des modules

de fonctions ABAP importantes. Cette méthode permet d’éviter réellement

l’incident décrit. Un sémaphore est utilisé pour les tâches associées au travail et un

autre pour les tâches liées à la maintenance de variante.

Afin de se donner rendez-vous sur la même structure IPC dans un environnement

UNIX, les deux parties doivent se mettre d’accord sur un identificateur pour cette

structure. Il existe plusieurs façons de choisir cet identificateur. Tivoli Workload

Scheduler for Applications pour R3 utilise deux paramètres : un nom de chemin et

un ID projet (valeur de type caractère). Le nom du chemin est transmis du chemin

absolu au fichier d’options. L’ID projet est l’une des options décrites dans le

tableau 16 à la page 119. Si ces options sont omises, Tivoli Workload Scheduler for

Applications pour R3 utilise les valeurs par défaut, lesquelles conviennent à la

majorité des installations.

Options locales

Le tableau suivant répertorie les options à définir dans les fichiers de configuration

locaux.

Tableau 17. Options de configuration locale de R3batch.

Option Description

r3client Numéro du client R/3. Cette option est

requise.

r3gateway Nom d’hôte de la passerelle R/3.

r3group Nom du groupe de connexion R/3.

r3gwservice Numéro de service de la passerelle R/3.

r3host Nom d’hôte du serveur de messages R/3

lorsque vous utilisez des groupes de

connexion ou le nom d’hôte du serveur

d’applications dans tous les autres cas. Cette

option est requise.

r3instance Numéro d’instance R/3. Cette option est

requise.


Tableau 17. Options de configuration locale de R3batch. (suite)

Option Description

r3password Mot de passe associé à r3user. Cette valeur

doit respecter la casse. Cette option est

requise.

r3sid ID système R/3. Cette option est requise.

r3user Nom de l’utilisateur R/3 avec lequel la

méthode d’accès se connecte au système R3.

Cette option est requise.

r3version Oblige la méthode d’accès à fonctionner

uniquement avec les systèmes R/3

comportant la version indiquée. Utilisez

cette option avec précaution.

xbpversion Oblige la méthode d’accès à fonctionner

avec les systèmes R/3 prenant en charge la

version XBP indiquée. Utilisez cette option

avec précaution.

Options générales

Le tableau suivant répertorie les options supplémentaires que vous pouvez définir

dans l’un des fichiers de configuration.

Tableau 18. Options de configuration générale R3batch.

Option Description Par défaut

r3auditlevel Niveau d’audit de XBP.

Nombre compris entre 0 et 3.

3

short_interval Intervalle court, en secondes,

pour les vérifications d’état.

Valeur supérieure à 10

secondes.

10

long_interval Intervalle long en secondes,

pour les vérifications d’état.

Valeur inférieure à 3600

secondes.

3600

twsxa_cp Codage que r3batch doit

utiliser pour ouvrir les

connexions RFC avec les

systèmes R/3. Il peut s’agir

de l’une des valeurs

suivantes :

v 1100

v 1103

v 8000

v 8300

v 8400

1100

twsxa_lang Langue utilisée pour la

connexion aux systèmes R/3.

Vous pouvez choisir :

v DE pour l’allemand

v EN pour l’anglais

v JA pour le japonais

EN

Chapitre 20. Fichiers d’options de la méthode d’accès R/3 121

Tableau 18. Options de configuration générale R3batch. (suite)


twsmeth_cp Codage que r3batch doit

utiliser pour écrire sa sortie

R/3. Il peut s’agir de l’une

des pages de code TIS

existantes.

Page de code locale

twsmeth_lang Langue utilisée pour signaler

les messages.

Langue locale

utf8cmdline Valeur égale à 0 ou 1 et qui

indique si r3batch doit

attendre des paramètres

étendus codés en UTF-8. La

valeur 1 signifie une réponse

affirmative.

1

retry Nombre de relances d’appels

de module de fonction R/3.

Nombre supérieur à 0.

5

nojobdefs Autoriser/interdire la

définition de nouveaux

travaux R/3 par l’interface

graphique de Tivoli

Workload Scheduler.

0

oldcopy Oblige la méthode d’accès à

utiliser l’ancienne méthode

de copie. Indiquez une

valeur différente de zéro

pour activer cette option.

0

old_picklist_mode Cette option s’applique

uniquement aux versions 4.5

et ultérieures de R/3. Si cette

option est désactivée (valeur

0), la liste de sélection des

travaux est extraite par le

module de fonction

BAPI_XBP_JOB_SELECT. Si elle

est activée (valeur différente

de zéro), elle est extraite par

le module de fonction

BAPI_XBP_JOB_COUNT. Cette

option doit être désactivée

car le module de fonction

BAPI_XBP_JOB_COUNT connaît

des incidents lors de son

exécution.

0

rfc_open_retry Nombre de relances pour

l’ouverture d’une connexion

RFC avec le système R/3. La

valeur est supérieure à 0

pour limiter le nombre de

relances et -1 pour un

nombre illimité de relances.

5

rfc_open_delay Temps d’attente maximal en

secondes entre deux appels

consécutifs avant l’ouverture

d’une connexion RFC.

1800


Tableau 18. Options de configuration générale R3batch. (suite)


log_r3syslog Si cette option est activée, la

méthode d’accès écrit les

dernières entrées de R/3

syslog dans son fichier de

trace lorsqu’un RFC renvoie

un message d’erreur

générale. Indiquez ON pour

activer l’option et OFF pour la

désactiver.

OFF

rcmap Active les capacités de

mappage RC de Tivoli

Workload Scheduler for

Applications pour R3.

Indiquez ON pour activer

l’option et OFF pour la

désactiver.

ON

max_name_counter Valeur maximale du

compteur de noms de

variante. Si le compteur de

noms atteint la valeur

indiquée, il recommence à

partir de 0.

40

name_counter_policy Règles du compteur de

noms :

step Le compteur de

noms est augmenté

à chaque étape.

job Le compteur de

noms est augmenté

une fois pour le

travail.

travail

max_n0_counter Valeur maximale du

compteur N0. Si celui-ci

atteint la valeur indiquée, il

recommence à partir de 0.

2^15 - 1

n0_counter_policy Règles du compteur N0 :

step Le compteur N0 est

augmenté à chaque

étape.

job Le compteur N0 est

augmenté une fois

pour le travail.

travail

Utilisation des options de configuration

Le format du fichier de configuration nom_CPU_r3batch.opts est le suivant :

option1=valeur1

option2=valeur2

option3=valeur3

...

sans espace avant l’option et après la valeur, ni entre elles et le signe égal.


Dans r3batch.opts, vous pouvez inscrire toutes les informations communes, telles

que les optionsLJuser, IFuser, JobDef et LogFileName, tandis que vous pouvez

inscrire dans un fichier de configuration local (par exemple, wkst1_r3batch.opts)

des données personnalisées pour le système R/3 cible de l’agent étendu (par

exemple, SAP1).

Vous pouvez indiquer une option locale dans le fichier de configuration global si

vous devez indiquer la même option pour toutes les instances r3batch. Si le nom

d’utilisateur R/3 est identique dans tous les systèmes R/3, vous pouvez définir

l’option r3user dans le fichier global sans dupliquer ces informations dans les

fichiers de configuration locaux.

Notez que ces fichiers de configuration ne sont pas créés au cours de l’installation.

Une option globale, telle que job_sem_proj, n’a d’effet que dans le fichier de

configuration global. Si vous la définissez dans un fichier local, elle n’aura aucun

effet.

r3batch lit d’abord le fichier de configuration global, puis le fichier local. Par

conséquent, toutes les options (sauf les options globales) contenues dans le fichier

de configuration local remplacent celles des fichiers globaux. Par exemple, si les

deux fichiers de configuration contiennent l’option r3user, r3batch utilise le fichier

local.

r3batch nécessite six options obligatoires ; vous pouvez les définir toutes dans le

fichier de configuration local ou les répartir entre le fichier global et le fichier local.

Par exemple, vous pourriez définir r3user et r3password dans le fichier de

configuration global et r3sid, r3instance, r3client et r3host dans le fichier local.

L’option r3user est à la fois locale et obligatoire. Elle doit être définie dans le

fichier de configuration global ou dans le fichier local.

Migration des fichiers de configuration

Cette section donne un exemple de migration d’un fichier de configuration de

r3options dans plusieurs fichiers .opts locaux (CPU_r3batch.opts).

Dans un fichier r3options avec le contenu suivant :

xacpu1 sap1 tv1 00 100 maestro 2QGp4-7JU5-MY2A-mX 30 300 2

xacpu1 sap2 d04 10 200 tws z57I-U5MY-2Amp-4X 30 100 2

vous pouvez créer deux fichiers locaux, xacpu1_r3batch.opts et

xacpu2_r3batch.opts.

Voici le contenu de xacpu1_r3batch.opts :

R3host=sap1

R3sid=tv1

R3instance=00

R3client=100

R3user=maestro

R3password=2QGp4-7JU5-MY2A-mX

short_interval=30

long_interval=300

R3auditlevel=2


Voici le contenu de xacpu2_r3batch.opts :

R3host=sap2

R3sid=d04

R3client=200

R3instance=10

R3user=tws

R3password=z57I-U5MY-2Amp-4X

short_interval=30

long_interval=100

R3auditlevel=2

Le script Perl offre un exemple de migration automatique. A partir du fichier

r3options, il produit les fichiers de configuration locaux.

$r3options = "r3options";

unless (-e $r3options) {

die "Error: file $r3options not found\n";

}

unless (-r $r3options) {

die "Error: file $r3options unreadible \n";

}

format OPTSFORMAT =

R3host=@<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

$host

R3sid=@<<<

$sid

R3instance=@<<

$inst

R3client=@<<<

$client

R3user=@<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

$user

R/3password=@<<<<<<<<<<<<<<<<<

$passwd

short_interval=@<<<<

$sint

long_interval=@<<<<

$lint

R3auditlevel=@<<

$audit

.

open (INPUT, "<$r3options");

while (<INPUT>) {

if(!/^#/ && !/^(\s)+$/) {

($cpu,$host,$sid,$inst,$client,$user,$passwd,$sint,$lint,$audit)=split(/ /);

$optsfile = $cpu . "_r3batch.opts";

open (OPTSFORMAT,">$optsfile") || die "can not create $optsfile file";

write (OPTSFORMAT);

close OPTSFORMAT;

}

}

close INPUT;

Pour utiliser ce modèle :

1. Installez un interpréteur PERL sur votre ordinateur.

2. Copiez le modèle dans un fichier nommé migrate.pl et stockez-le dans le

répertoire<racine_TWS>/methods.

3. Exécutez perl migrate.pl.

Les fichiers de configuration locaux sont créés dans le répertoire

<racine_TWS>/methods.


Chapitre 21. Attente BDC

Grâce à l’option d’attente (Batch Data Collector), vous pouvez spécifier qu’un

travail R/3 lancé par IBM Tivoli Workload Scheduler ne sera pas considéré comme

achevé tant que toutes ses sessions BDC ne seront pas terminées. Ceci évite que

d’autres travaux IBM Tivoli Workload Scheduler dépendant du même travail R/3

ne soient lancés tant que les sessions BDC associées à ce travail ne sont pas

terminées.

Pour utiliser cette option, un travail R/3 doit écrire des messages d’information

dans le journal des travaux. Pour ce faire, il convient d’ajouter une instruction de

message au rapport BDCREXX fourni par SAP (voir exemple ci-dessous), soit en

utilisant un nom de session BDC (12 caractères maximum), soit en utilisant un ID

de file d’attente BDC (20 caractères maximum). Plusieurs messages peuvent être

écrits pour permettre le contrôle de plusieurs sessions BDC.

Si vous ne voulez pas apporter de modifications à R/3, vous pouvez également

copier BDCRECXX sous un autre nom, par exemple ZBDCRECXX, faire les

modifications dans cette copie et inclure celle-ci dans tous vos programmes

générant des sessions BDC. Vous devez le faire manuellement pour chaque travail.

Si vos sessions BDC ne sont pas créées à l’aide de la transaction SM35, mais

directement par un composant SAP, elles ne peuvent pas utiliser le rapport

BDCRECXX. Dans ce cas, vous pouvez effectuer les modifications dans le module

fonctionnel BDC_OPEN_GROUP fourni par SAP, comme décrit ci-dessous. Notez

que vous devez modifier le rapport BDCRECXX (ou sa copie ZBDCRECXX) ou le

module fonctionnel BDC_OPEN_GROUP, mais pas les deux objets.

Remarque : L’état d’achèvement d’un travail R/3 lancé par IBM Tivoli Workload

Scheduler, que ce soit SUCC ou ABEND, est entièrement basé sur le

statut d’exécution du travail. Il ne dépend aucunement du succès ou

de l’échec de l’une des sessions BDC, qui sont considérées comme

terminées, indépendamment du fait qu’il y ait eu (ou non) des erreurs

durant le traitement BDC. Si vous voulez réagir aux erreurs d’une

session BDC, vous pouvez utiliser la fonction de mappage des codes

retour de Tivoli Workload Scheduler, comme décrit au Chapitre 28,

«Bibliothèque de mappage de code retour», à la page 181.

Utilisation des noms de session BDC

Pour utiliser les noms de session BDC, modifiez le formulaire open_group dans

l’objet R/3 BDCRECXX comme suit :

v Pour les versions SAP antérieures à 4.6c :

form open_group.

if session = ’X’.

skip.

write: /(20) ’Create group’(i01), group.

skip.

* open batchinput group

call function ’BDC_OPEN_GROUP’

exporting client = sy-mandt

group = group

user = user

keep = keep


holddate = holddate.

message i001(92) with group.

write: /(30) ’BDC_OPEN_GROUP’(i02), (12) ’returncode:’(i05), sy_subrc.

endif.

endform.

v Pour les versions SAP 4.6c et ultérieures :

form open_group.

skip.


skip.




group = group

user = user

keep = keep

holddate = holddate.

message i001(92) with group.


endform.

Lorsque des sessions BDC sont spécifiées par leur nom, Tivoli Workload Scheduler

n’attend pas qu’une session BDC soit terminée s’il y a d’autres sessions BDC de

même nom en cours.

Exemple

Un travail R/3 lancé par Tivoli Workload Scheduler démarre trois sessions BDC

avec le nom ORD2 et émet le message BDCWAIT suivant :

BDCWAIT:ORD2

Une fois la première session ORD2 terminée, le travail R/3 a pour statut SUCC

dans Tivoli Workload Scheduler. r3batch ne fait pas la différence entre les

sessions BDC de même nom.

Un autre problème de l’utilisation des noms de sessions BDC réside probablement

dans les différentes heures système d’un environnement R/3 réparti.r3batch

analyse les sessions BDC avec les noms spécifiés, générés lors de l’exécution du

travail créateur. Si le travail créateur ne fait rien d’autre que de démarrer des

sessions BDC, le temps d’exécution peut être très court. S’il n’y a aucune

synchronisation temporelle, l’heure système des différents postes de travail diffère

généralement dans un environnement R/3 réparti. Cette différence peut être

supérieure au temps d’exécution du travail. Il est donc possible qu’un intervalle de

temps erroné soit pris en compte et que des sessions BDC ne soient jamais

détectées.

Il est donc vivement recommandé d’utiliser la méthode des ID de file

d’attente BDC décrite dans les sections suivantes.

Utilisation des ID de file d’attente BDC avec le rapport BDCRECXX

Pour résoudre les problèmes causés par l’identification des sessions BDC par leur

nom, vous pouvez spécifier celles-ci par un ID de file d’attente à 20 chiffres. Etant

donné que chaque ID de file d’attente R/3 est unique, un message BDCWAIT doit

être émis pour chaque ID de file d’attente à contrôler.


Pour déterminer l’ID de file d’attente, modifiez le formulaire open_group dans

l’objet R/3 BDCRECXX comme suit :

v Pour les versions SAP antérieures à 4.6c :

form open_group.

if session = ’X’.

skip.


skip.




group = group

user = user

keep = keep

holddate = holddate

importing qid = myquid.

message i001(92) with myqid.


endif.

endform.

v Pour les versions SAP 4.6c et ultérieures :

form open_group.

skip.


skip.




group = group

user = user

keep = keep

holddate = holddate

importing qid = myquid.

message i001(92) with myqid.


endform.

N’oubliez pas de définir la variable myqid dans BDCRECXX. Avec cette approche,

vous modifiez de manière totale votre système R/3.

Utilisation des ID de file d’attente BDC avec le module fonctionnel

BDC_OPEN_GROUP

Les sessions BDC non créées par la transaction SM35 mais par un composant SAP,

ne peuvent pas utiliser le rapport BDCREXX. Dans ce cas, la meilleure solution

pour suivre ces sessions BDC consiste à modifier le module fonctionnel SAP

BDC_OPEN_GROUP comme suit :

FUNCTION BDC_OPEN_GROUP.

...

CALL ’BDC_OPEN_GROUP’ ID ’CLIENT’ FIELD CLIENT

ID ’GROUP’ FIELD GROUP

ID ’USER’ FIELD USER

ID ’KEEP’ FIELD KEEP

ID ’HOLDDATE’ FIELD HOLDDATE

ID ’DESTINATION’ FIELD DEST

ID ’QID’ FIELD QID

ID ’RECORD’ FIELD RECORD

ID ’PROG’ FIELD PROG.

*

IF SY-SUBRC EQ 0.

Chapitre 21. Attente BDC 129

BQID = QID.

BUSER = SY-MSGV1.

BGROUP = GROUP.

* CALL FUNCTION ’DB_COMMIT’.

CALL FUNCTION ’ENQUEUE_BDC_QID’

EXPORTING DATATYP = ’BDC ’

GROUPID = BGROUP

QID = BQID

EXCEPTIONS FOREIGN_LOCK = 98

SYSTEM_FAILURE = 99.

IF SY-SUBRC EQ 0.

message i001(92) with qid.

ENDIF.

ENDIF.

*

PERFORM FEHLER_BEHANDLUNG USING SY-SUBRC.

*

*

ENDFUNCTION.

Notez que les paramètres réels de l’appel de la fonction ″C″ (CALL

‘BDC_OPEN_GROUP’ ID ...) peuvent dépendre du numéro de la version SAP.

Avec cette approche, vous modifiez de manière totale votre système R/3.


Chapitre 22. Fonctions d’interception des travaux et fonctions

parent-enfant

Ce chapitre explique comment les fonctions d’interception des travaux et les

fonctions parent-enfant de BC-XBP 2.0 sont prises en charge par Tivoli Workload


Interception des travaux

L’interception des travaux est une fonction de l’interface BC-XBP 2.0. Elle permet à

Tivoli Workload Scheduler de contrôler très étroitement les travaux lancés par les

utilisateurs R/3 à partir de l’interface graphique de SAP.

Le mécanisme d’interception devient actif lorsque le planificateur de travaux R/3

est sur le point de démarrer un travail R/3 (à savoir, lorsque les conditions start

d’un travail R/3 sont remplies). Il compare les paramètres du travail (job name,

creator et client) aux entrées du tableau R/3 TBCICPT1, et, dès que ces paramètres

répondent aux critères, le travail R/3 est ramené à l’état scheduled et marqué par

un indicateur précisant qu’il a été intercepté.

Si Tivoli Workload Scheduler a été défini pour gérer l’interception de travaux, il

exécute de temps en temps son propre travail pour extraire la liste des travaux

interceptés et les replanifie. Ce travail peut être appelé collecte d’interception.

Pour configurer Tivoli Workload Scheduler de façon à traiter l’interception de

travaux dans un environnement R/3 :

1. Installez l’interface BC-XBP 2.0.

2. Activez la fonction d’interception de l’interface BC-XBP 2.0.

3. Définissez un travail Tivoli Workload Scheduler pour collecter de temps en

temps les travaux R/3 interceptés.

4. Indiquez les critères d’interception dans le système R/3.

5. Indiquez ces mêmes critères sur Tivoli Workload Scheduler.

Notez que les travaux lancés par Tivoli Workload Scheduler ou par tout autre

planificateur externe utilisant l’interface BC-XBP ne peuvent pas être interceptés.

Cela est dû au mécanisme d’interception qui ne prend en compte que les travaux

dont les conditions ont été remplies, en raison des restrictions de temps ou

d’événement SAP.

Implémentation de l’interception de travaux

Cette section décrit l’action à effectuer pour implémenter l’interception de travaux.

Activation de la fonction d’interception de travaux

Reportez-vous à la note SAP 604496 pour savoir si votre système R/3 comporte

déjà l’interface BC-XBP 2.0 ou quel est le module de support SAP à installer pour

l’activer.

Afin d’activer la fonction d’interception, exécutez le rapport ABAP INITXBP2. Ce

rapport indique l’état actuel des fonctions d’interception de travaux et

parent-enfant et vous permet de basculer entre les états des deux fonctions.


Collecte périodique des travaux interceptés

Puisque les travaux interceptés restent à l’état scheduled jusqu’à ce qu’ils soient

relancés, vous devez définir un travail Tivoli Workload Scheduler pour les collecter

et les démarrer.

Voici la syntaxe de la définition de travail pour la collecte d’interception dans

Tivoli Workload Scheduler :

NOM_CPU#NOM_TRAVAIL

SCRIPTNAME "racine_TWS/methods/r3batch -HIJ -c NOM_CPU"

DESCRIPTION "Collecte les travaux interceptés sur SAP XA NOM_CPU"

STREAMLOGON utilisateur_TWS

RECOVERY STOP

où :

NOM_CPU

Nom du poste de travail d’agent étendu.

NOM_TRAVAIL

Nom que vous souhaitez utiliser pour le travail Tivoli Workload Scheduler.

racine_TWS

Chemin d’accès complet à votre installation Tivoli Workload Scheduler.

utilisateur_TWS

Nom de l’utilisateur de Tivoli Workload Scheduler qui doit démarrer la


Le programme de collecte d’interception doit être exécuté périodiquement, par

exemple toutes les 10 minutes. Il extrait tous les travaux qui ont été interceptés

depuis la dernière exécution du programme de collecte d’interception et les relance

d’après un modèle sous la forme d’un texte décrit.

Configuration des critères d’interception sur le système R/3

Sur R/3, les critères d’interception figurent dans le tableau TBCICPT1. Seuls les

travaux répondant aux critères de ce tableau sont interceptés lorsque leurs

conditions start sont remplies. Tous les autres travaux sont exécutés normalement.

Vous pouvez gérer les entrées de ce tableau à l’aide de la transaction se16. Vous

pouvez définir les valeurs suivantes :

v Numéro de client

v Masque de travail

v Masque d’utilisateur

Configuration des critères d’interception sur Tivoli Workload

Scheduler

Sur Tivoli Workload Scheduler, les critères d’interception sont définis et utilisés par

l’une des valeurs suivantes :

v Fichiers des critères d’interception

v Fichiers modèle

Utilisation des fichiers des critères d’interception : Les critères d’interception de

chaque système R/3 sont stockés dans un fichier séparé nommé

NOM_CPU_r3batch.icp et situés dans le répertoire racine_TWS/methods/r3batch_icp

de l’hôte Tivoli Workload Scheduler. Ce fichier est lu par r3batch lors de

l’exécution du programme de collecte d’interception.


Chaque ligne du fichier est considérée comme un critère d’interception et

caractérisée par la syntaxe suivante :

client masque_travail masque_utilisateur modèle

où client, masque_travail et masque_utilisateur correspondent aux colonnes du

tableau TBCICPT1, tandis que modèle est le nom du modèle à utiliser par le

programme de collecte d’interception pour exécuter le travail R/3. Les paramètres

sont séparés par un ou plusieurs espaces. Vous pouvez utiliser n’importe quel

éditeur de texte pour gérer le contenu de ce fichier.

Utilisation des fichiers modèle : Un modèle est un fichier comportant l’extension

.jdf et situé dans le même répertoire(racine_TWS/methods/r3batch_icp) que le

fichier des critères d’interception. Le fichier modèle contient des instructions pour

le programme de collecte d’interception sur l’exécution du travail R/3 intercepté

sous le contrôle de Tivoli Workload Scheduler. Sa syntaxe correspond à celle de

docommand dans conman. Vous pouvez utiliser n’importe quel éditeur de texte pour

gérer ce fichier.

Si le fichier modèle de l’utilisateur est vide, un fichier modèle nommé default.jdf

est utilisé. Si default.jdf n’existe pas, les instructions suivantes sont utilisées :

alias=SAP_$RUN_$JOBNAME_$JOBCOUNT

Par conséquent, les travaux R/3 doivent être relancés immédiatement, en raison de

l’absence de l’option de travailat=. Leurs noms Tivoli Workload Scheduler sont

composés de la chaîne SAP_, du numéro d’exécution actuel du programme de

collecte d’interception et du nom et de l’ID du travail R/3.

Par conséquent, l’ensemble des instructions permettant de relancer un travail R/3

doit être extrait comme suit :

1. A partir du fichier modèle si un modèle existant est indiqué dans le fichier des

critères d’interception.

2. A partir du fichier modèle par défaut si le modèle est indiqué dans le fichier

des critères d’interception mais n’existe pas ou si le modèle n’est pas indiqué

dans le fichier des critères d’interception.

3. A partir de l’ensemble d’instructions par défaut si le fichier modèle par défaut

n’existe pas.

Exemple d’interception des travaux : Les critères d’interception des travaux sur

R/3 contiennent l’entrée suivante :

000 * fa*

Les critères d’interception des travaux sur Tivoli Workload Scheduler contiennent

l’entrée suivante :

000 * fa* at1700

Le fichier modèle at1700.jdf contient l’entrée suivante :

alias;at=1700

En conséquence, tous les travaux démarrés dans le client 000 par des utilisateurs

R/3 dont les noms d’utilisateur commencent par fa seront interceptés. Le

programme de collecte d’interception redémarrera les travaux à l’aide des

instructions du fichier modèle at1700.jdf. Les travaux R/3 seront redémarrés à

17h00 avec un nom au hasard, en raison de la commande alias.

Chapitre 22. Fonctions d’interception des travaux et fonctions parent-enfant 133

Utilisation des marques de réservation : Dans les fichiers modèle, vous pouvez

utiliser un certain nombre de marques de réservation remplacées par le

programme de collecte d’interception lors de l’exécution. Elles sont répertoriées

dans le tableau suivant.

Tableau 19. Marques des fichiers modèle d’interception de travaux.

Marque de réservation Description

$CPU Nom du poste de travail d’agent étendu sur lequel le

programme de collecte d’interception s’exécute.

$CLIENT Numéro client du travail R/3 intercepté.

$JOBNAME Nom du travail R/3 intercepté.

$JOBCOUNT ID du travail R/3 intercepté.

$USER Nom de l’utilisateur qui a lancé le travail R/3.

$JOBNUM Numéro de travail du programme de collecte

d’interception.

$EXECUTION Numéro d’exécution actuel du programme de collecte

d’interception.

$SCHED Nom de planification du programme de collecte

d’interception.

$RAND Nombre au hasard.

Par conséquent, le modèle

alias=ICP_$RAND_$JOBNAME_$JOBCOUNT_$CLIENT;at=1000

dit au programme d’interception de redémarrer le travail R/3 nommé DEMO_JOB

avec l’ID de travail 12345678 sur le client 100 à 10h00 en tant que travail Tivoli

Workload Scheduler

ICP_1432_DEMO_JOB_12345678_100

La fonction parent-enfant

Dans certaines situations, un travail R/3 engendre de manière dynamique un

certain nombre d’autres travaux, par exemple, pour distribuer la charge de travail

aux serveurs d’applications libres. Les travaux d’activité de masse du composant

FI-CA R/3 constituent un exemple édifiant. Avant BC-XBP 2.0, cette situation était

difficile à gérer pour les planificateurs externes, car le processus métier ne se

termine en général pas avec la fin du travail initial (travail parent), mais avec la fin

de tous les travaux enfant.

L’interface BC-XBP 2.0 permet de déterminer si un travail a lancé des travaux

enfant, ainsi que leur nom et leur ID, si bien qu’il est désormais possible d’en

effectuer le suivi.

Pour activer cette fonction, utilisez le rapport INITXBP2 ABAP, qui sert également à

modifier l’état d’interception des travaux.

Lorsque la fonction parent-enfant est active, Tivoli Workload Scheduler considère

un travail R/3 comme terminé uniquement après la fin de tous ses travaux

enfant ; en d’autres termes, l’état d’un travail Tivoli Workload Scheduler reste EXEC

tant que le travail parent ou l’un de ses travaux enfant est en cours d’exécution.


L’état du travail Tivoli Workload Scheduler devient SUCC si le travail parent et tous

les travaux enfant sont terminés. Si l’un des travaux s’est terminé par une erreur,

l’état du travailTivoli Workload Scheduler devient ABEND.

Notez que la fonction parent-enfant peut interférer avec l’interception des travaux,

car, même si le travail parent ne peut pas intercepté, tous ses travaux enfant

correspondant aux critères d’interception peuvent l’être. Dans ce cas, le travail

Tivoli Workload Scheduler reste à l’état EXEC jusqu’à ce que le travail enfant

intercepté ait été relancé et soit terminé.

Les journaux des travaux enfant sont ajoutés dans le fichier stdlist Tivoli

Workload Scheduler après le journal du travail parent.

Chapitre 22. Fonctions d’interception des travaux et fonctions parent-enfant 135

Chapitre 23. Support de la langue nationale

Grâce au nouveau schéma de fichiers de configuration comprenant des fichiers de

configuration locaux et globaux, vous pouvez configurer r3batch pour utiliser des

pages de codes et des langues différentes pour la sortie et la connexion avec un

système R/3 distant.

Cette fonction permet d’installer r3batch sur un poste de travail Tivoli Workload

Scheduler localisé et d’utiliser des caractères localisés pour les noms de travail

Tivoli Workload Scheduler, les flux de travaux et les variantes SAP.

Remarque : Tenez compte des configurations prises en charge et des limites de

cette fonction.

Options de support de la langue nationale

L’option TWSXA_CP affecte la page de codes utilisée pour établir la connexion entre

r3batch et le système R/3 cible. La valeur de l’option peut correspondre à l’une

des pages de codes R/3 installées sur le système R/3. La valeur par défaut

correspond à la page de codes SAP 1100 (similaire à la page de codes ISO8859-1

standard).

TWSXA_LANG affecte la langue utilisée par r3batch pour la connexion. Les valeurs

possibles sont les suivantes :

1. Anglais (par défaut, EN)

2. Allemand (GE)

3. Japonais (JA)

TWSMETH_CP représente la page de codes utilisée par r3batch pour la sortie. Cette

option avancée peut modifier la sortie et le fichier journal. La valeur par défaut

correspond à la page de codes utilisée par le poste de travail Tivoli Workload

Scheduler qui héberge r3batch. Il est recommandé d’utiliser cette option avec

précaution.

Remarque : Cela s’applique si vous utilisez le niveau 1.2 de Job Scheduling

Console. Le niveau 1.3 interagit avec r3batch via UTF-8, cette limite

n’est donc plus valable.

TWSMETH_LANG affecte la langue de catalogue utilisée par r3batch. Cette version

contient le catalogue de messages anglais. Par conséquent, cette option n’a pas

d’effet.


Pages de codes R/3 prises en charge

Tivoli Workload Scheduler for Applications pour R3 peut communiquer avec R/3

grâce aux pages de codes suivantes :

Tableau 20. Pages de codes R/3 prises en charge

Pages de codes R/3 Description

1100 8859-1 (par défaut)

1103 MS 850

8000 SJIS (Shift-Japanese Industrial Standard)

8300 BIG5 (chinois traditionnel)

8400 GBK (chinois simplifié)

Configurations prises en charge et limites

Les remarques suivantes s’appliquent si vous utilisez le niveau 1.2 de Job

Scheduling Console. Le niveau 1.3 interagit avec r3batch via UTF-8, cette limite

n’est donc plus valable.

Tivoli Workload Scheduler for Applications pour R3 doit être installé sur un poste

de travail utilisant une page de codes compatible avec l’un des systèmes R/3 cible.

Par exemple, si vous souhaitez utiliser un système R/3 japonais qui utilise la page

de codes SAP 8000, vous devez installer r3batch sur un poste de travail qui utilise

une page de codes japonaise comme SJIS ou MS932. Si vous souhaitez récupérer la

sortie r3batch avec Job Scheduling Console, vous devez exécuter Job Scheduling

Console sur un système qui utilise la même page de codes que le poste de travail

Tivoli Workload Scheduler sur lequel r3batch est installé. Si l’agent d’hébergement

utilise MS932, vous devez exécuter Job Scheduling Console sur un système

japonais utilisant cette page de codes.


Partie 5. Méthode d’accès z/OS



IBM Tivoli Workload Scheduler for Applications pour z/OS vous permet de

planifier et de contrôler des travaux OS/390 ou z/OS grâce aux fonctions de

planification évoluées de Tivoli Workload Scheduler.

Remarque : Dans tout le manuel, le terme z/OS est également utilisé pour faire

référence aux versions prises en charge d’OS/390. Reportez-vous à la

section sur la configuration logicielle requise.

Fonctions

v Utilisez Tivoli Workload Scheduler pour planifier l’exécution des travaux z/OS à

des heures spécifiques et dans un ordre défini.

v Définissez des dépendances entre des travaux Tivoli Workload Scheduler

exécutés sur des plateformes et des systèmes différents.

v Définissez des dépendances pour les travaux Tivoli Workload Scheduler en

fonction de l’exécution de travaux z/OS qui n’ont pas été lancés par Tivoli

Workload Scheduler.

v Définissez des dépendances pour les travaux Tivoli Workload Scheduler en

fonction de l’existence de fichiers sur un système z/OS.


IBM Tivoli Workload Scheduler for Applications nécessite la configuration logicielle

suivante :

Configuration logicielle requise Versions

IBM Tivoli Workload Scheduler 7.0 ou version ultérieure.

Système d’exploitation OS390 2.10 ou version ultérieure, ou z/OS.

TCP/IP L’une des versions suivantes : IBM 3.1 ou

version ultérieure ; Interlink 3.1 ou version

ultérieure ; Open Connect 2.3 ou version

ultérieure.

Interface de planification des travaux v JES2 ou JES3.

v Interface OPC : OPC 2.3.0 ou IBM Tivoli

Workload Scheduler pour z/OS.

v Interface CA7 : toute version actuellement

prise en charge.

Présentation de l’installation

Le logiciel IBM Tivoli Workload Scheduler for Applications pour z/OS comprend

la méthode d’accès z/OS qui doit résider sur l’hôte Tivoli Workload Scheduler et le

logiciel passerelle qui réside sur z/OS. Le logiciel passerelle peut être installé à

partir d’une cartouche de bande 3480 ou du CD-ROM d’IBM Tivoli Workload


Avant d’installer la méthode d’accès, vérifiez que Tivoli Workload Scheduler est

correctement installé sur le poste de travail hôte.


1. Le système qui hébergera la méthode d’accès pour z/OS, si la plateforme où

vous effectuez l’installation est l’une des suivantes :

v Compaq Tru64

v SGI Irix

v IBM Sequent Dynix

suivez les instructions de la section «Installation sur des plateformes de niveau

2».

Sinon, suivez les instructions du Chapitre 2, «Installation d’IBM Tivoli

Workload Scheduler for Applications», à la page 5.

2. Installez le logiciel passerelle sur z/OS.

3. Définissez les autorisations requises sur z/OS.

Installation sur des plateformes de niveau 2

Le logiciel de la méthode d’accès z/OS pour les plateformes de niveau 2 est fourni

sous la forme d’un fichier tar sur CD. Pour l’installer, procédez comme suit :

1. Arrêtez Tivoli Workload Scheduler sur le poste de travail où vous installez la

méthode.

2. Connectez-vous avec des droits racine et changez votre répertoire en

racine_tws/methods.

3. Montez le CD d’installation et restaurez le fichier tar avec la commande

suivante :

tar xvf dossier_cd/fichier_tar

où :

Paramètre tar Description

dossier_cd Chemin d’accès de votre unité de CD ou de votre dossier.

fichier_tar Fichier TAR en fonction de la plateforme cible. Il peut s’agir de

l’un des suivants :

v TWS4APPS_ZOSAGENT_DYNIX.TAR pour IBM Sequent

Dynix

v TWS4APPS_ZOSAGENT_IRIX.TAR pour SGI Irix

v TWS4APPS_ZOSAGENT_OSF.TAR pour Compaq True 64

4. Exécutez la commande suivante à partir du répertoire racine_tws/methods :

./mvsinstall.sh -user utilisateur_tws

Installation sous z/OS

Le module passerelle est fourni sur les deux supports suivants :

v Une cartouche de bande 3480 qui a été écrit au format non-IDRC (non condensé)

v Le CD-ROM d’IBM Tivoli Workload Scheduler for Applications.

Les deux supports contiennent les deux fichiers suivants :

v La bibliothèque de chargement

v Les modèles des deux procédures

Il vous appartient de choisir le support de téléchargement des fichiers, les deux

supports étant identiques.


Téléchargement des fichiers à partir du CD-ROM

Les fichiers passerelle sont stockés dans le répertoire ZOS du CD-ROM du produit

et sont nommés :

v LOADLIB

v SAMPLES

Pour décharger les fichiers sur votre système z/OS :

1. A partir de votre émulateur de session TSO, sélectionnez le shell de commande

ISPF (commande TSO) et utilisez l’utilitaire File Transfer (Send to Host) pour

transférer la bibliothèque LOADLIB et le membre SAMPLES du CD-ROM au

système z/OS, en définissant le transfert pour une longueur d’enregistrement

logique de 80 et un format d’enregistrement fixe.

2. Recevez les membres dans des fichiers de sortie à l’aide de l’option INDSN. 11

modules de chargement sont ainsi chargés dans la bibliothèque de sortie et 2

exemples dans l’exemple de bibliothèque.

Téléchargement des fichiers à partir de la bande

Modifiez et soumettez un JCL semblable au suivant pour télécharger la bande.

Personnalisez la carte de travail et modifiez les deux paramètres suivants en

fonction de vos normes d’environnement :

v Entrez un nom de travail approprié.

v Identifiez une unité de bande 3480.//MVSXAUNL JOB (876903,D07),’OPCL3’,MSGLEVEL=(1,1),

// MSGCLASS=A,CLASS=A,NOTIFY=&SYSUID

//**********************************************************************

//* *

//* THIS IS THE JOB THAT UNLOADS THE TIVOLI WORKLOAD SCHEDULER FOR *

//* APPLICATIONS z/OS Access Method Version 8.2.0 TO CUSTOMIZE *

//* *

//**********************************************************************

//STEP01 EXEC PGM=IEBCOPY

//SYSPRINT DD SYSOUT=*

//INDD DD DSN=TWSX.V8R2M0.SAMPLES,

// DISP=(OLD,PASS),UNIT=600,

// VOL=SER=IBM001,

// LABEL=(1,SL)

//OUTDD DD DSN=TWSX.V8R2M0.SAMPLES,

// DISP=(NEW,CATLG),

// SPACE=(32760,(2,2,10)),

// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),

// UNIT=3390,VOL=SER=OPC00C

//SYSUT3 DD UNIT=SYSDA,SPACE=(TRK,(20,1,10))


//SYSIN DD *

COPY OUTDD=OUTDD,INDD=((INDD,R))

//STEP02 EXEC PGM=IEBCOPY

//SYSPRINT DD SYSOUT=*

//INDD DD DSN=TWSX.V8R2M0.SERVICE.APFLIB1,

// DISP=(OLD,PASS),UNIT=600,

// VOL=SER=IBM001,

// LABEL=(2,SL)

//OUTDD DD DSN=TWSX.V8R2M0.SERVICE.APFLIB1,

// DISP=(NEW,CATLG),

// SPACE=(32760,(50,50,50)),

// DCB=(RECFM=U,BLKSIZE=32760),

// UNIT=3390,VOL=SER=OPC00C



//SYSIN DD *

COPY OUTDD=OUTDD,INDD=((INDD,R))

//*


Présentation de l’installation

Les deux composants du programme z/OS de la passerelle Tivoli Workload

Scheduler sont :

EEWTCP02

Ce programme permet à Tivoli Workload Scheduler d’assurer le suivi sur

le système z/OS. Il est démarré par le travail EEWSPACE.

EEWTCP00

Programme “passerelle” qui gère les communications TCP/IP entre Tivoli

Workload Scheduler et le système z/OS. Il est démarré par le travail

EEWSERVE. EEWTCP00 convertit les commandes Tivoli Workload

Scheduler dans leurs équivalents sur z/OS, réachemine les informations

z/OS vers Tivoli Workload Scheduler et effectue des conversions de

données EBCDIC-ASCII.

Les deux programmes sont exécutés comme des tâches démarrées avec un

paramètre TIME=NOLIMIT. EEWTCP02 est toujours démarré en premier, suivi par

EEWTCP00. Si les programmes doivent être interrompus pour une raison

quelconque, ils doivent être arrêtés, et non annulés, pour garantir un arrêt sans

incident et sans incidence sur les autres programmes utilisant la sortie IEFU84.

Définition des autorisations sous z/OS

Après avoir installé le produit sous z/OS, autorisez la bibliothèque de chargement.

Pour ce faire, procédez comme suit :

1. Exécutez la commande SETPROG dans le journal. Par exemple :

SETPROG APF,ADD,DSN=twsx.SERVICE.APFLIB1,

VOL=xxxxxx

, où : xxxxxxx est le numéro de série du volume où se trouve la bibliothèque

de chargement, ou :

SETPROG APF,ADD,DSN=twsx.SERVICE.APFLIB1,VOL=SMS

qui indique un volume sous le contrôle de SMS.

2. Mettez à jour le membre PROGxx de SYS1.PARMLIB, sinon l’autorisation sera

perdue lors de la prochaine procédure de chargement initial.

3. Ajoutez EEWTCP00 à la section AUTCHCMD NAMES de

SYS1.PARMLIB(IKJTSOxx).

Remarques supplémentaires

Les sections fournissent des informations supplémentaires pour le fonctionnement

de l’agent étendu.

Sortie IEFU84

L’agent étendu de z/OS effectue le suivi des flux de travaux à l’aide de la sortie

IEFU84. Cette sortie doit être activée dans le membre paramètre SMF de

SYS1.PARMLIB. IBM distribue avec le système d’exploitation une sortie IEFU84 qui

est un programme IEFBR14. Le travail EEWSPACE (traité plus tard) se relie de

manière dynamique à la sortie IEFU84. Si la sortie IEFU84 est en cours

d’utilisation, EEWSPACE la “devance”, obtient les informations nécessaires et se

connecte aux sorties utilisateur existantes. Lorsque l’exécution du travail

EEWSPACE est terminée, il se retire de la chaîne et la restaure dans son état initial.

Il est important de remarquer qu’EEWSPACE n’a aucun effet sur les sorties IEFU84

existantes, lesquelles continuent à fonctionner normalement.


Sécurité

La sécurité est assurée dans plusieurs domaines, généralement RACF, Top Secret,

ACF2, etc. Le travail EEWSERVE (traité plus tard) doit pouvoir soumettre des

travaux exécutés sous les ID utilisateur fournis dans le JCL à soumettre. Le JCL ne

doit pas contenir de mot de passe. Pour autoriser les mots de passe, vous pouvez

utiliser les ressources de classe SURROGAT dans RACF, ainsi que les équivalents

dans ACF2 et Top Secret. Les ressources de classe PROPCNTL dans RACF doivent

être utilisées pour empêcher l’exécution des travaux soumis sous l’ID utilisateur

EEWSERVE. Les équivalents ACF2 et Top Secret doivent également être utilisés. La

classe de ressources JESJOBS dans RACF et ses équivalents ACF2 ou Top Secret

permettent de déterminer quels sont les noms de travaux et les ID utilisateur (avec

ou sans mot de passe) qui peuvent être soumis par EEWSERVE.

Tivoli Workload Scheduler ne prend pas en charge l’utilisation de la sécurité CA-7.

Sécurité de la console

Le travail EEWSERVE (traité plus tard) est entièrement propriétaire de la console

lors de l’affichage du flux de travaux et de l’envoi de commandes à CA-7. Il doit

être autorisé à utiliser une console étendue. Contactez votre administrateur de

sécurité pour vous en assurer. Notez que CA-7 doit être configuré pour permettre à

des utilisateurs d’émettre des commandes modify via les consoles principales ou

étendues. OPERCMDS doit être modifié pour permettre cette fonctionnalité, si ce

n’est déjà fait. Reportez-vous également à la section «Variables SYSTSIN» pour

plus d’informations sur l’indication d’un ID utilisateur d’autorité.

La sécurité externe (voir Sécurité ci-dessus) permet d’autoriser l’utilisateur CA-7

indiqué pour EEWSERVE, car Workload Scheduler ne prend pas en charge

l’utilisation d’un mot de passe avec le nom d’utilisateur.

Démarrage

Exécutez les étapes suivantes :

1. Personnalisez et lancez la procédure EEWSPACE (en suivant les instructions

commentées incluses) pour démarrer l’agent étendu Gateway Data Space. Le

travail doit être une tâche démarrée et ne doit pas être annulé. Reportez-vous à

la section «Variables SYSTSIN»pour une description des paramètres.

EEWSPACE crée l’espace mémoire et installe la sortie IEFU84. Pour terminer le

travail, utilisez la commande STOP EEWSPACE à partir de n’importe quelle

console z/OS.

Remarques :

a. EEWSPACE doit être en fonctionnement avant le démarrage d’EEWSERVE.

b. Arrêtez EEWSERVE avant d’arrêter EEWSPACE.2. Personnalisez et lancez la procédure EEWSERVE en suivant les instructions

commentées incluses. Reportez-vous à la section «Variables SYSTSIN» pour une

description des paramètres.

3. Pour terminer le travail, utilisez la commande STOP EEWSERVE à partir de

n’importe quelle console z/OS.

Variables SYSTSIN

Les variables SYSTSIN sont décrites ci-dessous. Vous pouvez modifier les

paramètres en fonction de la configuration de votre site. Les paramètres par défaut

sont indiqués entre parenthèses.


Tableau 21. Variables SYSTSIN

Variable Description

CA7INTERFACE(CONSOLE) CONSOLE, seule interface prise en

charge pour CA-7, est la valeur par

défaut de cette variable.

Attribuez-lui la valeur Non pour ne

pas utiliser cette interface.

CA7NAME(CA7ONL) Nom de l’espace adresse de la

région de contrôle CA-7. Ignoré si

CA-7 n’est pas utilisé.

CA7OPTIONS(X’32’) Options de l’édition CA-7. La

valeur par défaut est déterminée

par l’entrée du tableau des vecteurs

du sous-système CA-7 et ne doit

pas être modifiée sauf sur

indication du personnel de

maintenance d’IBM.

CA7SPAN(9999) Cette variable s’applique

uniquement à l’interface CA7. Le

nombre représente l’intervalle

minimal (en heures et minutes)

au-delà duquel il est possible de

lancer le même travail à partir de

Tivoli Workload Scheduler sans

indiquer de valeur différente pour

SCHID. La valeur par défaut est

définie volontairement sur 9999,

valeur incorrecte, de façon à

pouvoir distinguer les cas où la

variable n’est pas utilisée. Le cas

échéant, elle doit être indiquée au

format HHMM. Par exemple :

v CA7SPAN(0010) signifie 10

minutes.

v CA7SPAN(0130) signifie 1 heure

30 minutes.

Pour plus d’informations,

reportez-vous à la section «Autres

conseils pour CA-7» à la page 161.

Intervalle minimal en minutes

(quatre chiffres) au-delà duquel il

est possible de lancer le même

travail à partir de Tivoli Workload

Scheduler sans indiquer de valeur

différente pour SCHID. Ignorez

cette variable si vous attribuez à

CA7INTERFACE la valeur NO.

CA7SUBSYSTEM(UC07) Nom du sous-système CA-7.

CA7USER(CA7CNSL) ID utilisateur utilisé pour exécuter

des commandes CA-7. Il est ignoré

si CA-7 n’est pas utilisé.


Tableau 21. Variables SYSTSIN (suite)


COMPLETIONCODE(LASTSTEP/MAXSTEP) Option de code d’achèvement de

travail à plusieurs étapes JES.

LASTSTEP, valeur par défaut,

indique que le code d’achèvement

d’un travail à plusieurs étapes JES

est déterminé par la dernière étape

exécutée du travail. MAXSTEP

indique que le code d’achèvement

est déterminé par le code

d’achèvement le plus élevé de

toutes les étapes exécutées du

travail. Cette variable détermine la

valeur par défaut des travaux dont

l’option n’est pas remplacée dans la

configuration Tivoli Workload

Scheduler.

DEBUG(NO) Si cette variable a la valeur YES, la

passerelle émet des messages de

diagnostic. Utilisée uniquement

avec le personnel de maintenance

IBM.

INTERLINKSUBSYSTEM(ACSS) Nom du sous-système utilisé par la

pile TCPIP Interlink. Ignoré si

Interlink n’est pas utilisé comme

pile TCPIP.

JESCMDCHR($) Caractère de reconnaissance de

commande de travail. La valeur par

défaut est le symbole du dollar ($)

pour les systèmes JES2 et un

astérisque (*) pour les systèmes

JES3. Cette variable doit être

modifiée uniquement si un

caractère de reconnaissance de

commande différent est utilisé.

MAXWAIT(500) Temps d’attente maximal d’une

réponse aux commandes en

centièmes de seconde. Ignorez cette

variable si vous attribuez à


MCSSTORAGE(3) Quantité de mémoire, en

mégaoctets, utilisée par chaque

console étendue elle-même utilisée

par la passerelle. Ignorez cette

variable si vous attribuez à


OPCINTERFACE(PIF) PIF, seule interface prise en charge

pour OPC ou Tivoli Workload

Scheduler pour z/OS est la valeur

par défaut de cette variable.

Attribuez-lui la valeur NO pour ne

pas utiliser cette interface.




OPCMSGCLASS(*) Classe de message pour les

journaux de messages alloués de

manière dynamique et utilisés par

OPC ou Tivoli Workload Scheduler

pour z/OS. L’astérisque permet de

définir la classe de manière

identique à EEWSERVE. Ignoré si

OPC ou Tivoli Workload Scheduler

pour z/OS n’est pas utilisé.

OPCSUBSYSTEM(OPCS) Nom de sous-système utilisé pour

les communications avec la région

de contrôle OPC ou Tivoli

Workload Scheduler pour z/OS.

PEERADDRESS(0 0 0 0) La valeur par défaut, 0 0 0 0,

permet l’accès par n’importe quel

hôte. Pour une meilleure sécurité,

entrez l’adresse IP de l’hôte

Workload Scheduler de z/OS

x-agent. Remarque : N’incluez pas

le ″.″ (point) entre les 0 dans votre

code. Les points apparaissent à

l’affichage !

PORT(5000) Numéro de port TCP utilisé par

Tivoli Workload Scheduler et la

passerelle pour les communications.

Il doit être identique à la valeur

entrée dans la zone Adresse TCP de

la définition du poste de travail

z/OS x-agent.

PUTLINE(YES) Lorsque cette variable a la valeur

YES, les informations de trace sont

acheminées dans DDNAME

SYSTSPRT.

QLIMIT(2000) Nombre maximal de messages à

mettre en file d’attente dans une

console étendue.

SUBSYS(UNIS) Préfixe utilisé par l’agent étendu de

z/OS sous la forme des quatre

premiers caractères des noms de

console étendus. Il est également

utilisé sous la forme des quatre

premiers caractères du programme

de lecture interne DDNAMES. Ne

le modifiez que sur instruction du

personnel de maintenance IBM.

SVCDUMP(NO) Lorsque cette variable a la valeur

YES, les fins anormales entraînent

un vidage SVC. Utilisée

uniquement avec le personnel de

maintenance IBM.

TCPIPSTACK(IBM) Fournisseur de pile TCPIP (IBM,

INTERLINK ou OPENCONNECT).




TCPNAME(TCPIP) Nom de l’espace adresse TCPIP

lorsque la version IBM de la pile

TCPIP est utilisée.

TERMINATOR(X’25’) Caractère de résiliation de

transaction. Ne modifiez pas la

valeur par défaut, sauf sur

instruction du personnel de

maintenance IBM.

WTP(NO) Lorsque cette variable a la valeur

YES, les informations de trace sont

acheminées dans SYSLOG sous la

forme d’informations WTP. Cela

peut s’avérer utile si SYSTSPRT ne

répond pas à vos besoins.

Lorsque vous utilisez CA-7,

PUTLINE(YES) et WTP(NO) sont

nécessaires en cas de présence de la

variable DEBUG(YES).

ZOSV1R2(NO) Définie sur la valeur YES si vous

utilisez l’interface JES3 avec z/OS

V1R2 ou une version ultérieure. Ce

paramètre est ignoré si vous

n’utilisez pas l’interface JES3 , car :

v Si vous utilisez l’interface JES2, le

niveau du système d’exploitation

n’a aucune incidence sur le

produit.

v Si vous utilisez les interfaces

CA7 ou Tivoli Workload

Scheduler pour z/OS, la prise en

charge de z/OS V1R2 ou version

ultérieure est assurée si l’édition

du ou des sous-systèmes

correspondants le permet.

Version de la passerelle z/OS

La version d’EEWSERVE (et EEWSPACE) apparaît dans la première ligne du

journal EEWSERVE (et EEWSPACE). Par exemple :

EEWTCP10 VERSION RELEASE MODIFICATION LEVEL = VxRyMz

, où VxRyMz contient la version, l’édition et les niveaux de modification.


Chapitre 25. Configuration et fonctionnement

Tivoli Workload Scheduler lance les travaux sur un agent étendu pour poste de

travail fonctionnant sous z/OS. L’agent étendu pour z/OS est défini dans une

définition de poste travail Tivoli Workload Scheduler standard, laquelle lui attribue

un nom et identifie la méthode d’accès à utiliser. L’agent étendu pour poste de

travail z/OS est une définition de poste de travail liée à une instance du système

z/OS.

Pour lancer un travail sur un agent étendu pour poste de travail z/OS, Tivoli

Workload Scheduler exécute la méthode d’accès et transmet les informations

relatives au travail. La méthode d’accès communique avec l’instance de l’hôte

z/OS et contrôle le travail jusqu’à la fin, en écrivant les informations sur la

progression et l’état du travail dans le fichier de liste standard du travail.

Ce chapitre explique comment :

v Créer un fichier d’options pour sélectionner des options pour une méthode

v Définir un agent étendu pour un travail z/OS

v Planifier un agent étendu pour un travail z/OS.

Reportez-vous au Chapitre 4, «Définition des postes de travail d’agent étendu», à

la page 31 pour savoir comment définir un poste de travail agent étendu dans


Fichiers d’options de méthode

Sur toutes les plateformes prises en charge, sauf Compaq Tru64, SGI Irix, et IBM

Sequent Dynix, utilisez l’éditeur d’option pour créer les fichiers d’options

nécessaires. Pour plus de détails, reportez-vous à la section Chapitre 3, «Définition

des options à l’aide de l’Editeur d’options», à la page 27.

Fichiers d’options de méthodes sur les plateformes de niveau

2

Sur Compaq Tru64, SGI Irix et IBM Sequent Dynix, créez un fichier d’options pour

sélectionner les options d’une méthode. Le fichier doit présenter le même nom de

chemin que la méthode, avec l’extension opts. Par exemple, créez les fichiers

suivants sous UNIX (en supposant que le répertoire principal Tivoli Workload

Scheduler est /usr/lib/tws) :

/usr/lib/tws/methods/mvsca7.opts

/usr/lib/tws/methods/mvsjes.opts

/usr/lib/tws/methods/mvsopc.opts

Sinon, créez les fichiers suivants sous Windows (en supposant que Tivoli Workload

Scheduler est installé dans le chemin C:\WIN32APP\tws) :

c:\win32app\tws\methods\mvsca7.opts

c:\win32app\tws\methods\mvsjes.opts

c:\win32app\tws\methods\mvsopc.opts


Pour mvsca7, mvsjes et mvsopc, les entrées du fichier d’options sont :

Entrées du fichier d’options Description

LJuser=nom Attribue le nom d’utilisateur dont se sert la méthode

d’accès pour lancer des travaux. Il doit s’agir d’un

utilisateur UNIX ou Windows qui soumet les travaux

locaux et peut se connecter à la passerelle z/OS de

Tivoli Workload Scheduler sur le système z/OS. La

valeur par défaut est le paramètre de connexion dans

la définition de travail.

CFuser=nom (Obligatoire) Attribue le nom d’utilisateur dont se

sert la méthode d’accès pour vérifier les dépendances

de fichier. Peut être identique à LJuser.

GSuser=nom (Facultatif) Attribue le nom d’utilisateur dont se sert

la méthode d’accès pour vérifier les travaux non

lancés par Tivoli Workload Scheduler sur z/OS et qui

servent de dépendances. La valeur par défaut est

root.

CheckInterval=min (Facultatif) Définit la vitesse d’interrogation en

minutes, permettant de vérifier l’état des travaux

z/OS lancés par la méthode. Les valeurs à virgule

sont admises, par exemple, 0,5 pour 30 secondes ou

1,5 pour une minute et 30 secondes. La valeur par

défaut est 2.

Lors de la vérification de travaux non lancés par

Tivoli Workload Scheduler sur z/OS et utilisés

comme dépendances, la méthode utilise l’option

locale de Tivoli Workload Scheduler bm check status

au lieu de CheckInterval pour déterminer la vitesse

d’interrogation.

BlockTime=min (Facultatif) Définit le temps en minutes pendant

lequel la méthode attend une réponse à une

vérification d’état avant d’expirer. Cette valeur doit

être inférieure à la valeur de CheckInterval (décrite

ci-dessus) et à l’option locale de Tivoli Workload

Scheduler bm check status. Les valeurs à virgule sont

admises, par exemple, 0,5 pour 30 secondes ou 1,5

pour une minute et 30 secondes. La valeur par défaut

est 2.

RetryCount=nombre (Facultatif) Définit le nombre de tentatives de

vérification d’état avant que Tivoli Workload

Scheduler écrive un message de dépassement de

délai dans le fichier stdlist d’un travail et l’inscrive à

l’état abend. Pour plus d’informations, reportez-vous

à CheckInterval et BlockTime ci-dessus. La valeur

par défaut est 10.

Définition de travaux dans z/OS

Dans z/OS, les travaux planifiés avec Tivoli Workload Scheduler sont définis

comme prescrits pour JES, CA-7 et OPC ou Tivoli Workload Scheduler pour z/OS.


Définition de travaux z/OS dans Tivoli Workload Scheduler

Des définitions de travaux Tivoli Workload Scheduler sont requises pour chaque

travail z/OS que vous envisagez de planifier et de lancer avec Tivoli Workload

Scheduler. Ils sont définis comme les autres travaux Tivoli Workload Scheduler et

comprennent un nom de travail, un nom d’utilisateur, des options de nom de

script spécial et des options de récupération facultatives.

Pour plus de détails, reportez-vous à la section Chapitre 5, «Définition des travaux

d’agent étendu», à la page 37.

Syntaxe de définition de tâche pour les travaux z/OS planifiés

avec Tivoli Workload Scheduler

Voici des descriptions de la syntaxe de définition de tâche (ligne de commande

“scriptname”) pour les travaux z/OS que Tivoli Workload Scheduler planifie et

lance via les postes de travail d’agent étendu à l’aide des méthodes mvsjes

(travaux JES2/3), mvsca7 (travaux CA-7) ou mvsopc (travaux OPC ou IBM Tivoli

Workload Scheduler pour z/OS).

Vous devez spécifier ces paramètres de chaîne de tâche aux emplacements suivants

lorsque vous définissez les travaux Tivoli Workload Scheduler qui leur sont

associés :


du travail, si vous utilisez Job Scheduling Console


travail, si vous utilisez la ligne de commande Tivoli Workload Scheduler


SCRIPTLIB de Tivoli Workload Scheduler pour z/OS, si vous procédez à une

planification dans un environnement de bout en bout

Pour les travaux JES :

La syntaxe est la suivante :

jeu_données [<|= code_cond]

où :

jeu_données

Nom du jeu de données JES ou du jeu de données partitionné.

code_cond

Code de condition qui indique l’aboutissement d’un travail. S’il est précédé

du signe <, le code de condition doit être inférieur ou égal à cette valeur.

S’il est précédé du signe =, le code de condition doit être égal à cette

valeur. S’il est omis, “= 0000” est utilisé. Notez que l’opérateur (< ou =)

doit être précédé et suivi d’un espace.

Exemple :

gold.apayable.cntl(apayjob1) = 0004

Pour les travaux CA-7 :


nom_travail [SCHID(nnn)] [CC(nnnn) ] [...]

[RO(EQ|LT|GT|GE|LE|NE|#S|IG|NO) ]

[SET(SKP|NTR|NDB) ]

Chapitre 25. Configuration et fonctionnement 153

où :

nom_travail

Nom du travail dans CA-7.

SCHID

ID d’agenda (nombre compris entre 1 et 255) à affecter au travail.

CC Code de condition utilisé avec RO et indiquant l’aboutissement d’un

travail.

RO Opérateur relationnel pour le code de condition CC.

SET Définit des options de travail permettant d’ignorer la prochaine exécution

planifiée (SKP), de désactiver le déclenchement normal du travail (NTR) ou

d’ignorer le chargement de la base de données lors de l’exécution (NDB).

Pour avoir des descriptions complètes des paramètres, reportez-vous à votre guide

de commandes CA-7.

Exemple :

ARCVJOB SCHID(203) CC(0001) RO(EQ) SET(NDB)

Pour les travaux OPC ou Tivoli Workload Scheduler pour z/OS :


appl [IA(aammjjhhmm)|IATIME(hhmm) ] [...]

[DEADLINE(aammjjhhmm)|DEADLINETIME(hhmm) ]

[PRIORITY(pri) ]

[CPDEPR(Y|N|P|S) ]

où :

appl Nom de l’application OPC ou Tivoli Workload Scheduler pour z/OS à

insérer dans le plan actuel.

IA Date et heure d’arrivée de l’entrée au format : aammjjhhmm .

IATIME

Heure d’arrivée de l’entrée au format : hhmm.

DEADLINE

Date et heure d’arrivée du délai au format : aammjjhhmm.

DEADLINETIME

Heure d’arrivée du délai au format : hhmm.

PRIORITY

Priorité (1-9) d’exécution de l’application.

CPDEPR

Sélection de la résolution de dépendance du plan actuel.

Y Ajouter toutes les dépendances successeurs et prédécesseurs.

N Ne pas ajouter de dépendances. (Valeur par défaut.)

P Ajouter des dépendances prédécesseurs.

S Ajouter des dépendances successeurs.

Pour avoir une description complète des paramètres, reportez-vous à votre

documentation OPC ou Tivoli Workload Scheduler pour z/OS.

Exemple :


PREFABJOB44 IA(0202181000) PRIORITY(5) CPDEPR(Y)

Syntaxe de définition de tâche pour les travaux z/OS

Voici la description de la syntaxe de définition de tâche (ligne de commande

“scriptname”) pour les travaux z/OS qui n’ont pas été lancés par Tivoli Workload

Scheduler, mais dont l’exécution doit être contrôlée. L’exécution des travaux z/OS

peut être utilisée comme dépendance “follows” pour les travaux lancés par Tivoli

Workload Scheduler. Les travaux non Tivoli Workload Scheduler peuvent être JES,

CA-7, OPC ou Tivoli Workload Scheduler pour z/OS.

La syntaxe de base est la suivante :

travail_tws follows agent_étendu::"travail_mvs"

où :

travail_tws

Nom du travail Tivoli Workload Scheduler qui dépend de la fin du travail

z/OS indiqué.

agent_étendu

Nom du poste de travail agent étendu Tivoli Workload Scheduler associé

avec le planificateur d’un travail z/OS — à savoir, agent défini avec la

méthode mvsjes, mvsca7 ou mvsopc. Notez que les deux signes

deux-points sont un délimiteur obligatoire.

travail_mvs

Identification du travail z/OS. Notez que cette chaîne doit être délimitée

par des guillemets. Reportez-vous aux descriptions de syntaxe ci-dessous.

Pour les travaux JES :


"nom_travail[<|= code_cond]"

où :

nom_travail

Nom du travail dans JES.

code_cond

Code de condition qui indique l’aboutissement d’un travail. S’il est précédé

du signe <, le code de condition doit être inférieur ou égal à cette valeur.

S’il est précédé du signe =, le code de condition doit être égal à cette

valeur. S’il est omis, “= 0000” est utilisé. Notez que l’opérateur (< ou =)

doit être précédé et suivi d’un espace.

Exemple :

travail5 follows poste_travail_jes::"apayable = 0004"

Pour les travaux CA-7 :


"nom_travail [SCHID(nnn) ] [...]"

[DATE(*|*aajjj)} ]

[SPAN( {* }) ]

{portée }

{date }

{(date_début,heure_début,portée) }

{(date_début,heure_début,portée) }


où :

nom_travail

Nom du travail dans CA-7.

SCHID

ID d’agenda (nombre compris entre 1 et 255) du travail.

DATE Date de journal spécifique à rechercher pour le travail.

SPAN Etendue des enregistrements de journal à rechercher pour le travail.

Pour obtenir une description complète des paramètres, reportez-vous à votre guide

de commandes CA-7. Par exemple :

travaila follows poste_travail::"arcvjob schid(203) span(12)"

Reportez-vous également à la section «Autres conseils pour CA-7» à la page 161

Pour les travaux OPC ou Tivoli Workload Scheduler pour z/OS :


"application[IA(aammjjhhmm)|IATIME(hhmm)][...]"

[JOBNAME(nom_travail) ]

[OPNO(num) ]

où :

application

Nom de l’application (flux de travaux) OPC or Tivoli Workload Scheduler

pour z/OS du plan actuel.

IA Date et heure d’arrivée de l’entrée.

IATIME

Heure d’arrivée de l’entrée.

JOBNAME

Nom du travail z/OS.

OPNO

Numéro d’opération (1 à 255). S’il est inclus, l’application est considérée

comme terminée lorsqu’elle atteint ce nombre.

Pour obtenir une description complète des paramètres, reportez-vous à votre

documentation OPC ou Tivoli Workload Scheduler pour z/OS. Par exemple

travaila follows poste_travail_opc::"PREFABJOB44 IA(0202181000) JOBNAME(PFJ3)"

Syntaxe des dépendances de fichier (OPENS) sur les fichiers

z/OS

Les travaux et les flux de travaux Tivoli Workload Scheduler peuvent utiliser les

fichiers z/OS comme dépendances. La syntaxe de base est la suivante :

travail_tws opens agent_étendu#"hlq1.hlq2.hlq3"

où :

travail_tws

Nom du travail Tivoli Workload Scheduler qui dépend du fichier z/OS

indiqué.

agentx Nom du poste de travail d’agent étendu Tivoli Workload Scheduler associé


au planificateur d’un travail z/OS — à savoir, agent défini avec la méthode

mvsjes, mvsca7 ou mvsopc. Notez que le signe # est un délimiteur

obligatoire.

hlq1.hlq2.hlq3

Identification du fichier z/OS en termes de qualifiant de haut niveau.

Notez que cette chaîne doit être délimitée par des guillemets.

Reportez-vous à la section «Vérification des fichiers sur z/OS» à la page 163 pour

plus d’informations.


Chapitre 26. Informations de référence

Présentation technique

Ce chapitre décrit les états des travaux pour un fonctionnement sous JES, CA-7,

OPC ou Tivoli Workload Scheduler pour z/OS dans l’environnement Tivoli

Workload Scheduler.

Fonctionnement sous JES

Les informations ci-dessous s’appliquent au fonctionnement sous JES.

Lancement des travaux JES

Pour lancer et contrôler un travail JES, Tivoli Workload Scheduler transmet le nom

des données JCL ou l’ensemble de données cloisonné à exécuter à la passerelle

z/OS, qui, en retour, le soumet à JES. Les soumissions s’effectuent à l’aide de

programmes de lecture interne attribués de manière dynamique dans JES. La

passerelle attribue un programme de lecture interne au démarrage de chaque

tâche, puis lui soumet le travail.

Lors de la soumission d’un travail, le nom du travail et l’ID de travail JES sont

également entrés dans l’espace de table. Lorsqu’un enregistrement SMF contenant

des données de planification pertinentes est transmis via la sortie IEFU84, les

informations sur le code de condition et le travail sont rendues accessibles à Tivoli

Workload Scheduler. Or, dans la mesure où Workload Scheduler garde la trace du

nom du travail et de l’ID de travail JES, il est à même de rechercher la tâche

spécifique qu’il a soumise. (La passerelle utilise actuellement des enregistrements

SMF de type 30, ainsi que des sous-types 1,4 et 5.)

Tivoli Workload Scheduler vérifie à intervalles réguliers si les travaux soumis sont

actifs. Si un travail soumis par Tivoli Workload Scheduler n’est pas actif et

qu’aucune information n’est disponible à son sujet par la sortie IEFU84, ce travail

est marqué comme fin anormale sur les écrans de Tivoli Workload Scheduler. Cette

situation peut se produire si un travail échoue pour des raisons de sécurité ou de

problèmes de syntaxe JCL.

Etats des travaux pour JES : Le tableau suivant répertorie les états des travaux

JES relatifs à Tivoli Workload Scheduler.

Etat des travaux

de Tivoli

Workload

Scheduler Etat des travaux JES Commentaire

intro na Workload Scheduler démarre la méthode.

wait Queued

wait na Si cet état est maintenu pour ce travail, cela

peut être dû à une violation de la sécurité dans

z/OS. Vérifiez le travail dans le système z/OS.

exec En cours d’exécution Le travail est en cours d’exécution.

succ Terminé Le code de condition du travail répond aux

critères d’exécution dans la définition du travail

de Tivoli Workload Scheduler.


Etat des travaux

de Tivoli

Workload

Scheduler Etat des travaux JES Commentaire

abend Terminé Le code de condition du travail ne remplit pas

les critères d’exécution dans la définition du

travail de Tivoli Workload Scheduler, ou bien

une fin anormale liée au système ou à

l’utilisateur s’est produite. Les codes de fin

anormale du système, en mode hexadécimal,

ont pour préfixe ″S″, tandis que les codes de fin

anormale pour les utilisateurs, en mode

décimal, ont pour préfixe ″U″. Les deux types

de code sont écrits dans le fichier stdlist du

travail.

extrn na Etat inconnu. Cet événement ne peut se

produire que lorsque la tâche vérifiée est

utilisée comme une dépendance.

Vérification des travaux JES : Pour vérifier un travail JES qui n’a pas été lancé

par Tivoli Workload Scheduler, le nom de ce travail est transmis à la passerelle par

Tivoli Workload Scheduler. Dans la mesure où Tivoli Workload Scheduler n’a pas

soumis le travail, l’ID de travail JES n’est pas disponible. La passerelle entre le

nom dans l’espace de table et attend que les informations sur la tâche apparaissent

dans les enregistrements SMF transmis via la sortie IEFU84.

Fonctionnement avec CA-7

Les informations ci-dessous s’appliquent au fonctionnement avec CA-7.

Lancement des travaux CA-7

Pour lancer et contrôler un travail CA-7, Tivoli Workload Scheduler transmet le

nom du travail, et accessoirement le schedID de CA-7, à exécuter sur la passerelle

z/OS. Au moment de la demande de soumission, la passerelle reçoit le numéro de

travail CA-7 utilisé pour assurer le suivi de toutes les activités à venir pour ce

travail. Il est important de noter que CA-7 doit lui-même être autorisé à accepter

les commandes provenant de la console pour que ce mécanisme puisse fonctionner.

Reportez-vous à la documentation sur CA-7 pour plus d’informations sur les

commandes de modification et de connexion.

Etats des travaux pour CA-7

Le tableau suivant liste les états des travaux CA-7 relatifs à Tivoli Workload

Scheduler.

Etat du travail

de Tivoli

Workload

Scheduler

Etat du travail de

CA-7 Commentaire

intro na Workload Scheduler démarre la méthode.

wait Request Queue ou

Ready Queue

L’état wait peut aussi indiquer que le travail a été

déplacé de la file d’attente Active à la file

d’attente Request suite à une fin anormale. Le

travail reste dans la file d’attente Request, avec

une invite de redémarrage, jusqu’à ce que

l’opérateur procède à son redémarrage ou à son

annulation.


Etat du travail

de Tivoli

Workload

Scheduler

Etat du travail de

CA-7 Commentaire

exec Active Queue

succ Terminé Le code de condition du travail répond aux


de Tivoli Workload Scheduler.

abend na Le code de condition du travail ne remplit pas les


de Tivoli Workload Scheduler. Prenez également

connaissance des remarques ci-après.

extrn na Etat inconnu. Cet événement ne peut se produire

que lorsque la tâche recherchée est utilisée

comme une dépendance. Prenez également

connaissance des remarques ci-après.

Remarque : Si l’état abend ou extrn est maintenu pour ce travail, cela peut être dû

à une violation de la sécurité dans z/OS. Vérifiez le travail dans le

système z/OS.

Vérification des travaux CA-7

Pour vérifier un travail CA-7 qui n’a pas été lancé par Tivoli Workload Scheduler,

le nom de ce travail, et accessoirement le schedID de CA-7, est transmis à la

passerelle par Tivoli Workload Scheduler. Pour voir si le travail est actuellement en

cours de planification ou d’exécution par CA-7, la passerelle recherche les files

d’attente suivantes, dans cet ordre : Request Queue, Ready Queue et Active

Queue. Si le travail n’est pas trouvé, Tivoli Workload Scheduler procède à une

revérification à une vitesse définie par la valeur bm check status dans son fichier

d’options locales.

Autres conseils pour CA-7

v Lors de l’utilisation de CA-7, CA7USER doit aussi correspondre à un id UNIX

valide.

v La limitation qui, dans les versions précédentes du produit, obligeait les

utilisateurs à identifier les occurrences de manière unique lors de la définition

des travaux CA-7 dans Tivoli Workload Scheduler (c’est-à-dire en ajoutant les

opérandes SCHID et/ou SPAN) est désormais supprimée grâce au nouveau

paramètre d’initialisation CA7SPAN.

La logique relative à l’implémentation de CA7SPAN est la suivante : si SPAN est

spécifié dans la définition Tivoli Workload Scheduler d’un travail, alors

CA7SPAN est ignoré. Si SPAN n’est pas spécifié (ou ne peut pas être spécifié,

comme dans le cas des travaux lancés par Tivoli Workload Scheduler), alors

CA7SPAN est pris en considération et sa valeur est utilisée dans les

interrogations de type SPAN à CA7. Cela contourne la limitation selon laquelle

chaque occurrence doit être identifiée de manière unique tout en gardant la

possibilité de lancer le même travail à partir de Tivoli Workload Scheduler avec

le même opérateur SCHID, à la seule condition que l’intervalle entre 2

soumissions soit supérieur à la valeur spécifiée avec CA7SPAN.

Il est important de savoir que, si elle est spécifiée, la valeur de CA7SPAN sera

utilisée dans toutes les interrogations à CA7 (si elles concernent des travaux

démarrés par Tivoli Workload Scheduler ou si elles sont émises pour vérifier les

dépendances inter-réseau pour les travaux qui ne sont pas lancés par Tivoli


Workload Scheduler) à l’exception des travaux pour lesquels SPAN est spécifié

dans leur définition Tivoli Workload Scheduler.

v Si vous exécutez des produits qui suppriment les messages de la console

(comme AFOPER), assurez-vous qu’ils ne suppriment pas les messages CA-7.

Fonctionnement avec l’interface OPC ou avec Tivoli Workload

Scheduler pour z/OS

Les informations ci-dessous s’appliquent au fonctionnement avec l’interface OPC

ou avec Tivoli Workload Scheduler pour z/OS.

Lancement d’un travail OPC ou Tivoli Workload Scheduler pour

z/OS

Pour Lancer et contrôler un travail OPC ou Tivoli Workload Scheduler pour z/OS,

Tivoli Workload Scheduler transmet le nom de l’application et les autres

paramètres facultatifs à exécuter sur la passerelle z/OS. Si l’application existe dans

la base de données OPC ou Tivoli Workload Scheduler pour z/OS, elle est insérée

dans le plan en cours. La date et l’heure d’arrivée entrés, l’échéance de la date et

l’heure d’arrivée, le niveau de priorité et les paramètres de résolution de

dépendance automatiques, le cas échéant, remplacent toutes valeurs spécifiées dans

OPC ou Tivoli Workload Scheduler pour z/OS.

A une vitesse définie par la valeur CheckInterval du fichier d’options de la

méthode, Tivoli Workload Scheduler vérifie l’état de l’occurrence (application) dans

OPC ou Tivoli Workload Scheduler pour z/OS.

Etats de fonctionnement d’OPC et de Tivoli Workload Scheduler

pour z/OS

Le tableau suivant répertorie les différents états de fonctionnement d’OPC et de

Tivoli Workload Scheduler pour z/OS relatifs au programme Tivoli Workload

Scheduler.

Etat du travail Tivoli Workload

Scheduler

Etat du fonctionnement d’OPC ou de Tivoli

Workload Scheduler pour z/OS

wait suspendu

wait indéterminé

wait wait

wait prêt

exec lancé

succ terminé

abend interrompu

abend erreur

abend supprimé

abend non disponible

extrn non disponible

Etats des occurrences d’OPC et de Tivoli Workload Scheduler

pour z/OS

Le tableau suivant liste les états des occurrences de fonctionnement d’OPC et de

Tivoli Workload Scheduler pour z/OS relatifs au programme Tivoli Workload

Scheduler.


Etat du flux de travaux de

Tivoli Workload Scheduler

Etat des occurrences d’OPC ou de Tivoli Workload

Scheduler pour z/OS

wait suspendu

wait indéterminé

exec lancé

succ terminé

abend erreur

abend supprimé

abend non disponible

extrn Etat ″non disponible″ inconnu. Ne peut se produire que lors

de la vérification d’un travail utilisé comme une dépendance.

Prenez également connaissance des remarques ci-après.

Vérification de travaux OPC ou Tivoli Workload Scheduler pour

z/OS

Pour vérifier un travail OPC ou Tivoli Workload Scheduler pour z/OS qui n’a pas

été lancé par Tivoli Workload Scheduler, le nom de l’application, et éventuellement

l’opération, est transmis à la passerelle. Cette vérification permet de voir si

l’occurrence ou l’opération se trouve dans le plan actuel. Si elle n’est pas trouvée,

Tivoli Workload Scheduler procède à une revérification à une vitesse définie par la

valeur bm check status dans son fichier d’options locales.

Vérification des fichiers sur z/OS

Un fichier peut être utilisé comme une dépendance d’un travail dans Tivoli

Workload Scheduler. Pour rechercher l’existence d’un fichier sur z/OS, Tivoli

Workload Scheduler transmet le nom de ce fichier à la passerelle. Le nom de

fichier se voit affecter la valeur DISP=OLD et est considéré comme existant si les

conditions ci-après sont remplies :

v Les données sont inscrites dans le fichier catalogue.

v Elles sont allouées.

v Elles ne sont pas utilisées par une autre tâche.

Si le fichier (ensemble des données) n’existe pas, Tivoli Workload Scheduler

continue à patienter et recherche le fichier à intervalles prédéfinis.

Notez que Tivoli Workload Scheduler ne peut utiliser que des noms de fichier

complets pour les fichiers non partitionnés. Si un nom de groupe de fichiers de

génération doit être utilisé, le nom complet doit être spécifié, par opposition au

nom relatif (par ex. xxxxx.xxxxx(-1) ne peut pas être utilisé).

Considérations de délais

Lors de la vérification de travaux z/OS qui n’ont pas été lancés par Tivoli

Workload Scheduler, certaines questions de délai sont essentielles pour garantir

que les dépendances de travaux associés sont correctement résolues. Ces questions

sont la conséquence de la conception par Tivoli Workload Scheduler d’une journée

de traitement. Des explications complètes se trouvent dans le manuel Tivoli

Workload Scheduler - Guide de référence. En bref, Tivoli Workload Scheduler régénère

la planification de sa production quotidiennement à une heure prédéfinie ; par

exemple, à 6h00 tous les matins. Pour maintenir une relation entre les travaux

exécutés sous z/OS et ceux exécutés sous Tivoli Workload Scheduler, une

synchronisation entre les deux environnements s’impose. Si, par exemple, un


travail z/OS est démarré en dehors de Tivoli Workload Scheduler et qu’il se

termine avant le début de la journée de traitement de Tivoli Workload Scheduler, il

ne sera pas visible dans Tivoli Workload Scheduler et ne devra pas être utilisé dans

une dépendance de travail Tivoli Workload Scheduler. Tivoli Workload Scheduler

n’essaie pas de déterminer l’état des travaux qui se sont terminés avant le début

prédéfini de sa journée.

Si la synchronisation n’est pas prise en compte, telle qu’elle est expliquée ci-dessus,

Tivoli Workload Scheduler peut patienter indéfiniment pour résoudre une

dépendance de travail. Un problème similaire peut se produire suite à un échec de

communication entre les environnements z/OS et Tivoli Workload Scheduler,

empêchant Tivoli Workload Scheduler de déterminer l’état d’un travail z/OS pour

répondre à une de ses dépendances.

Informations relatives au diagnostic

Les travaux z/OS soumis par Tivoli Workload Scheduler peuvent ne pas se

terminer pour plusieurs raisons. Lors de l’exécution de la soumission, l’étape

correspondant à l’échec d’un travail détermine la quantité d’informations

disponible et fournie par Tivoli Workload Scheduler :

v Si un travail échoue avant d’avoir effectivement démarré (ce qui est

généralement le résultat d’un problème JCL ou de sécurité), Tivoli Workload

Scheduler reconnaît que ce travail n’existe plus et le marque comme terminé

anormalement dans les affichages du gestionnaire de console (Conman). Aucune

information supplémentaire n’est fournie.

v Si un travail échoue après avoir démarré, Tivoli Workload Scheduler :

1. Obtient son code de condition et son code de fin anormale par l’utilisateur, le

cas échéant

2. Les écrit dans le fichier de liste standard du travail

3. Marque le travail comme abend dans le gestionnaire de console (Conman)

ou dans les affichages de la Job Scheduling Console

Les listes standard de travaux peuvent être affichées dans le gestionnaire de

console (Conman) et à l’aide de Job Scheduling Console.

Messages de la passerelle

Des messages informatifs sont créés dynamiquement par le programme de

passerelle pour z/OS. En plus des informations relatives à la condition, ces

messages peuvent comprendre :

v Un horodatage au format aammjj hhmmss

v Un nom de module

v Un libellé au sein du module

v Le nom d’une macro

v Un code motif (registre 0)

v Un code retour (registre 15)

Les messages de passerelle z/OS sont répertoriés ci-dessous. Pour les noms de

module (module), voir ci-dessous.

EEWI01E yymmdd hhmmss module FAILED, MACRO macro NEAR LABEL label WITH RETURN

CODE = code & REASON CODE = code


CODE = code & ERROR NUMBER = err


EEWI03I yymmdd hhmmss module ISSUED, MACRO macro NEAR LABEL label TO OBTAIN

SOCKET DESCRIPTOR = desc

EEWI04I yymmdd hhmmss module ISSUED, MACRO macro NEAR LABEL label

TO OBTAIN HOSTNAME = host

EEWI05I yymmdd hhmmss module TCPIP ADDRESS = ipaddress

EEWI06I yymmdd hhmmss module name = name

EEWI07I yymmdd hhmmss module ISSUED, MACRO macro NEAR LABEL label FOR num

CHARACTER MESSAGE = msg

EEWI08S yymmdd hhmmss module FAILED AT OFFSET offset


CODE = code

EEWI10S yymmdd hhmmss module ABENDED WITH ASSOCIATED REASON CODE code

EEWI11I yymmdd hhmmss module CONSOLE name ACTIVATED WITH CONSOLE ID id

EEWI12I yymmdd hhmmss module SUBTASK name COMPLETED WITH COMPLETION CODE code

EEWI13I yymmdd hhmmss module CALL TO "name" NEAR LABEL label COMPLETED WITH

COMPLETION CODE code

EEWI14S yymmdd hhmmss module INVALID DATA SPACE FOUND NEAR LABEL label

EEWI15E yymmdd hhmmss module DATASET "dset" DDNAME "dd" FAILED TO OPEN

NEAR LABEL label

EEWI16I yymmdd hhmmss module SUBMITTED JOB "job" WITH JES IDENTIFICATION "id"

EEWI17I yymmdd hhmmss module PEERADDRESS = ipaddress

EEWI18E yymmdd hhmmss module INVALID TERMINATOR term

EEWI19E yymmdd hhmmss module NEAR LABEL label INVALID VALUE FOUND name = value

EEWI20E yymmdd hhmmss module NEAR LABEL label FAILED TO FIND ACTIVE SMF IEFU84

EXIT

EEWI21E yymmdd hhmmss errmsg

EEWI22I yymmdd hhmmss TASK task MODULE module ISSUED, MACRO macro NEAR

LABEL label TO CLOSE SOCKET DESCRIPTOR socket

EEWI24E yymmdd hhmmss module NEAR LABEL label

EEWI25I yymmdd hhmmss module NEAR LABEL label APPLICATION appl WAS INSERTED IN

CURRENT PLAN WITH INPUT ARRIVAL DATE AND TIME iadatetime

EEWI26I yymmdd hhmmss module NEAR LABEL label JOB jobname(jobid)

EEWI27I yymmdd hhmmss APPLICATION appl WAS INSERTED IN CURRENT

PLAN WITH INPUT ARRIVAL DATE AND TIME iadatetime

EEWI28W yymmdd hhmmss APPLICATION appl WAS NOT INSERTED IN

CURRENT PLAN WITH INPUT ARRIVAL DATE AND TIME iadatetime

EEWI29I yymmdd hhmmss TASK task MODULE module ISSUED, MACRO macro NEAR LABEL label

WITH RETURN CODE = code AND ERROR NUMBER = err

EEWI30S yymmdd hhmmss module CA7SPAN MUST BE 4 DIGITS IN FORMAT HHMM

Les noms de module sont :

Nom du module Description

EEWPRE84 Sortie SMF précédente

EEWTCP00 Routine de traitement principale

EEWTCP01 Véhicule des tests serveur

EEWTCP02 Routine principale pour la création de l’espace de données

EEWTCP05 Fait émettre le message d’échec par la routine ESTAE

EEWTCP07 Recherche le nom de l’ensemble de données associé à l’ACB/DCB

ouvert



EEWTCP08 Recherche le nom de l’ensemble de données associé au nom de la

définition des données

EEWTCP10 Initialise et examine les variables

EEWTCP15 Localise et initialise les blocs de contrôle

EEWTCP20 Localise et initialise les blocs de contrôle

EEWTCP21 Véhicule des tests client



EEWTCP25 Serveur concurrent

EEWTCP26 Fournisseur Interlink de protocole TCP/IP pour serveurs

concurrents

EEWTCP27 Serveur concurrent pour la pile TCP/IP Openconnect

EEWTCP30 Tâche du serveur enfant

EEWTCP31 Tâche du serveur enfant pour la pile TCP/IP Interlink

EEWTCP32 Tâche du serveur enfant

EEWTCP84 Sortie de l’enregistrement SMF pour SMFEWTM

EEWTCP87 Interface OPC

EEWTCP88 Affichage de l’interface OPC

EEWTCP89 CA7 BTI

EEWTCP90 Emet la commande et attend la réponse

EEWTCP91 Emet la commande TERROR pour mettre en forme les messages

et émet la commande WTOS

EEWTCP92 Recherche une sous-chaîne au sein d’une chaîne

EEWTCP93 Emet la commande CA-7 et attend la réponse

EEWTCP94 Sortie de STIMER pour soumettre ECB via un paramètre

EEWTCP95 Appelle IKJEFF02 pour extraire la mémoire tampon à l’aide

d’EEWTCP99

EEWTCP96 La routine ESTAE émet un message d’échec

EEWTCP97 Appelle IKJEFF19 (DAIRFAIL/VSAMFAIL) pour émettre un

message

EEWTCP98 Appelle IKJEFF02 pour émettre un message à partir de

EEWTCP99

EEWTCP99 Tableau de messages

EEWTCPC7 Vérification du travail CA7

EEWTCPCA Vérification du gestionnaire de demandes d’applications

EEWTCPCF Vérification du gestionnaire de demandes de fichiers

EEWTCPCJ Vérification du gestionnaire de demandes de travaux

EEWTCPCO Vérification du gestionnaire de demandes d’opérations

EEWTCPCV Enumération des travaux

EEWTCPED Chiffrement/déchiffrement de la chaîne

EEWTCPEJ Gestionnaire de demande d’énumération de travaux

EEWTCPFJ Gestionnaire de demande de travaux gratuits



EEWTCPIA Insertion d’une application

EEWTCPIE Initialisation d’une chaîne

EEWTCPKJ Gestionnaire de demande de suppression des travaux

EEWTCPKO Suppression de l’application OPC

EEWTCPL7 Lancement du gestionnaire de demande de travaux CA-7

EEWTCPLJ Lancement du gestionnaire de demande de travaux

EEWTCPLO Insertion de l’application OPC

EEWTCPQ7 Interrogation du gestionnaire de demande de travaux CA-7

EEWTCPQJ Interrogation du gestionnaire de demande de travaux

EEWTCPQO Interrogation de l’application OPC

EEWTCPQS Interrogation du gestionnaire de demande de sous-systèmes

EEWTCPRC Code retour

EEWTCPSC Fin anormale de l’opération du système

EEWTCPSE Chiffrement/déchiffrement de la chaîne

EEWTCPUC Fin anormale en raison de l’utilisateur

EEWTCPWT Attendre pendant le délai spécifié

EEWTCPXX Gestionnaire de demandes incorrect

Pour l’identification des incidents, faites en sorte d’obtenir le journal JES pour les

tâches EEWSPACE et EEWSERVE lancées. Cela vous aidera à déterminer le

contexte dans lequel un message a été émis. En fonction de l’interface de

planification des travaux que vous utilisez, vous pouvez obtenir d’autres

informations utiles à partir d’autres journaux. Par exemple, si vous utilisez CA-7,

vous devez obtenir les éléments suivants :

v Le journal CA-7

v Le journal de l’intervalle couvrant la période de test

v Le journal des travaux spécifiant le travail qui a provoqué l’erreur (le cas

échéant)

v Le fichier script UNIX relatif à ce travail


Partie 6. Maintenabilité commune


Chapitre 27. Référence aux agents étendus

Ce chapitre décrit l’interface d’agent étendu et fournit des informations aux

programmeurs désireux de créer des méthodes d’accès personnalisées.

Que sont les agents étendus ?

Les agents étendus permettent d’étendre les fonctions de planification de travaux

de Tivoli Workload Scheduler vers d’autres systèmes et vers d’autres applications.

Un agent étendu est un poste de travail disposant d’un hôte et d’une méthode

d’accès. L’hôte peut correspondre à n’importe quel autre poste de travail à

l’exception d’un autre agent étendu. La méthode d’accès correspond à un script ou

à un programme fourni par l’utilisateur ou par IBM, qui est exécuté par l’hôte

chaque fois que l’agent étendu est référencé dans le plan de production. Par

exemple, pour lancer un travail sur un agent étendu, l’hôte exécute la méthode

d’accès en transmettant les informations relatives au travail sous la forme d’options

de ligne de commande. La méthode d’accès communique avec le système ou

l’application externe pour lancer le travail et renvoie le statut de ce travail.

Définition de poste de travail

Tous les agents étendus doivent présenter une définition de poste de travail

logique. Ce poste de travail logique doit être hébergé par un poste de travail

physique Tivoli Workload Scheduler : un poste de travail maître, un poste de

travail gestionnaire de domaine ou un poste de travail tolérant aux pannes. La

définition du poste de travail de l’agent étendu référence le nom de la méthode

d’accès ainsi que le nom du poste de travail de l’hôte. Lorsque des travaux sont

lancés sur le poste de travail de l’agent étendu, la méthode d’accès est appelée. Elle

transmet les informations relatives aux travaux au système externe.

Interface de méthode d’accès

L’interface entre Tivoli Workload Scheduler et une méthode d’accès est composée

des informations transmises à la méthode par la ligne de commande et des

messages renvoyés au planificateur dans stdout.

Syntaxe de la ligne de commande de la méthode

L’hôte du planificateur exécute une méthode d’accès à l’aide de la syntaxe de ligne

de commande suivante :

nomméthode -t tâche options -- chaînetâche

où :

nomméthode

Désigne le nom de fichier de la méthode d’accès. Toutes les méthodes

d’accès doivent figurer dans le répertoire : racine_TWS/methods

-t tâche

Désigne la tâche à effectuer, où tâche correspond à l’une des tâches

suivantes :

LJ Lance un travail.


MJ Gère un travail lancé précédemment. Cette option permet de se

resynchroniser si une tâche LJ précédente s’est arrêtée de manière

inattendue.

CF Vérifie la disponibilité d’un fichier. Cette option permet de vérifier

les dépendances opens de fichier.

GS Obtient le statut d’un travail. Cette option permet de vérifier les

dépendances follows de fichier.

options Désigne les options associées à la tâche. Pour plus d’informations,

reportez-vous à la section «Options de tâche».

chaînetâche

Une chaîne comportant jusqu’à 255 caractères associée à la tâche.

Reportez-vous à la section «Options de tâche».

Options de tâche

Les options de tache sont répertoriées dans le tableau ci-après. Un X signifie que

l’option est admise pour la tâche.

Tâche Options

Chaîne de

la tâche

-t -c -n -p -r -s -d -l -o -j -q -w -S

LJ X X X X X X X X X X ljstring

MJ X X X X X X X X X mjstring

CF X X X X cfstring

GS X X X X X X gsstring

-c agentétendu,hôte,principal

Désigne les noms de planificateur de l’agent étendu, de l’hôte et du

gestionnaire de domaine principal, chacun étant séparé par une virgule.

-n nomnoeud

Désigne le nom de noeud de l’ordinateur associé à l’agent étendu, s’il

existe. Ce nom est défini dans la zone Noeud de la définition de poste de

travail de l’agent étendu.

-p numéroport

Désigne le numéro du port TCP associé à l’agent étendu, s’il existe. Ce

numéro est défini dans la zone Adresse TCP de la définition de poste de

travail de l’agent étendu.

-r exécutioncourante,exécutionspécifique

Désigne le numéro d’exécution en cours du planificateur et le numéro

d’exécution spécifique associé au travail, séparés par une virgule. Les

numéros d’exécution en cours et spécifiques peuvent être distincts si le

travail a été reporté depuis une exécution antécédente.

-s fluxtravaux

Désigne le nom du flux de travaux du travail.

-d dateplanification,période

Désigne la date de planification (aammjj) ainsi que la période équivalente,

séparée par une virgule.

-l utilisateur

Désigne le nom de l’utilisateur du travail. Ce nom est défini dans la zone

Connexion de la définition du travail.


-o listestd

Désigne le chemin d’accès complet du fichier de liste standard du travail.

Toute sortie émanant de ce travail doit figurer dans ce fichier.

-j nomtravail,id

Indique le nom du travail et l’identificateur unique affecté par le

planificateur, séparés par une virgule. Ce nom est défini dans la zone Nom

du travail de la définition du travail.

-q qualifiant

Désigne le qualifiant qui doit être utilisé dans une commande de test émise

par une méthode pour un fichier.

-w délai

Indique le temps, exprimé en secondes, pendant lequel le planificateur

attend une réponse sur un travail externe avant d’envoyer un signal

SIGTERM à la méthode d’accès. La valeur par défaut est 300.

-S nouveau nom

Indique que le travail est réexécuté à l’aide de ce nom, à la place du nom

de travail d’origine. Dans un script de travail, vous pouvez utiliser la

commande jobinfo pour revenir au nom du travail, puis exécuter le script

différemment pour chaque itération. Pour plus d’informations, consultez la

description de la commande conman rerun dans le manuel IBM Tivoli

Workload Scheduler - Guide de référence.

-- ljstring

Utilisé avec la tâche LJ. La chaîne provenant de la zone Fichier Script ou

la zone Commande de la définition du travail.

-- mjstring

Utilisé avec la tâche MJ. CDIl s’agit des informations fournies au

planificateur par la méthode dans une réponse %CJ à une tâche LJ.

Généralement, elles identifient le travail qui a été lancé. Par exemple, une

méthode Unix peut fournir l’ID processus (PID) pour le travail qu’elle a

lancé, qui est ensuite transmis par le planificateur comme faisant partie

d’une tâche MJ.

-- cfstring

Utilisé avec la tâche CF. Pour une dépendance opens de fichier, correspond

à la chaîne figurant dans la zone Opens Files de la définition du flux de

travaux.

-- gsstring

Utilisé avec la tâche GS. Désigne le travail dont le statut est vérifié. Le

format est le suivant :

followsjob[,idtravail]

où :

followsjob

Correspond à la chaîne figurant dans la liste Follows Sched/Job de

la définition de flux de travaux.

idtravail

Correspond à un identificateur de travail facultatif reçu par le

planificateur dans une réponse %CJ à une tâche GS précédente.

Chapitre 27. Référence aux agents étendus 173

Messages de réponse de méthode

Les méthodes renvoient des informations à Tivoli Workload Scheduler sous la

forme de messages écrits dans stdout. Toutes les lignes commençant par le

symbole de pourcentage (%) et finissant par une nouvelle ligne sont considérées

comme un message. Les messages présentent le format suivant :

%CJ statut [mjstring | idtravail]

%JS

[tempsuc]

%RC cr

%UT [messageerreur]

où :

CJ Change le statut du travail.

statut Le statut par lequel le travail est changé. Tous les statuts de

travaux du planificateur sont valides à l’exception de hold et

ready. Pour la tâche GS, les statuts suivants sont également

valides :

ERROR

Une erreur s’est produite.

EXTRN

Le statut est inconnu.

mjstring

Chaîne pouvant comporter jusqu’à 255 caractères, que le

planificateur inclut dans toute tâche MJ associée au travail.

Reportez-vous à la page 173.

idtravail

Chaîne pouvant comporter jusqu’à 64 caractères, que le

planificateur inclut dans toute tâche GS associée au travail.

Reportez-vous à la page 173.

JS [tempsuc]

Indique qu’un travail a abouti et fournit la durée de son exécution en

secondes.

RC cr cr est un nombre interprété par Tivoli Workload Scheduler comme code

retour du travail de l’agent étendu. Le code retour est pris en compte

uniquement si une condition de code retour a été définie dans la définition

du travail de l’agent étendu. Si ce n’est pas le cas, il est ignoré et

l’exécution du travail de l’agent étendu est indiquée par la présence du

message %JS [tempsuc]. Ainsi, si la méthode n’envoie pas le message %RC,

l’aboutissement du travail de l’agent étendu est indiqué par la présence du

message %JS [tempsuc].

UT [messageerreur]

Indique que la tâche requise n’est pas supportée par la méthode. Affiche

une chaîne pouvant comporter jusqu’à 255 caractères, que le planificateur

inclura dans son message d’erreur.


Fichier d’options de méthode

Un fichier d’options de méthode vous permet de spécifier des informations

relatives à la connexion ainsi que d’autres options. Le planificateur lit le fichier, si

ce dernier existe, avant d’exécuter une méthode. Si ce fichier est modifié après le

démarrage du planificateur, les modifications ne prennent effet que lorsque celui-ci

a été arrêté puis relancé.

Ce fichier peut contenir des options du planificateur ainsi que toute autre

information relative à la méthode. Les options reconnues par le planificateur sont

les suivantes :

LJuser=nomutilisateur

CFuser=nomutilisateur

GSuser=nomutilisateur

GStimeout=secondes

où :

LJuser=utilisateur

Désigne la connexion à utiliser pour les tâches LJ et MJ. La valeur par

défaut correspond à la connexion figurant dans la définition du travail.

CFuser=nomutilisateur

Désigne la connexion à utiliser pour la tâche CF. La valeur par défaut est

root pour Unix ; pour Windows, il s’agit du nom utilisateur du compte sur

lequel le planificateur a été installé.

GSuser=nomutilisateur

Désigne la connexion à utiliser pour les tâches GS. La valeur par défaut est

root pour Unix ; pour Windows, il s’agit du nom utilisateur du compte sur

lequel le planificateur a été installé.

GStimeout=secondes

Indique le temps, exprimé en secondes, pendant lequel le planificateur

attend une réponse avant de supprimer la méthode d’accès. La valeur par

défaut est 300.

Remarque : Si l’hôte de l’agent étendu fonctionne sous Windows, l’utilisateur doit

être défini en tant qu’objet utilisateur du planificateur.

Le fichier d’options doit présenter le même nom de chemin que ses méthodes

d’accès, avec l’extension de fichier .opts. Par exemple, pour Windows, le nom du

chemin d’accès d’un fichier d’options pour une méthode intitulée netmth est :

v racine_TWS\methods\netmth.opts (global).

v racine_TWS\methods\<nom_unité_centrale>_netmth.opts (local).

Exécution de méthode

Les sections ci-après décrivent les échanges entre Tivoli Workload Scheduler et une



Tâche de lancement d’un travail (LJ)

La tâche LJ charge la méthode de l’agent étendu de lancer un travail sur une

application ou un système externe. Avant d’exécuter la méthode, Tivoli Workload

Scheduler crée un environnement d’exécution. Le paramètre LJuser, lu à partir du

fichier d’options de la méthode, indique avec quel compte utilisateur la méthode

doit être exécutée. Si ce paramètre ne figure pas dans le fichier d’options ou que le

fichier d’options n’existe pas, le compte utilisateur qui sera utilisé correspond à

celui défini dans la zone Connexion de la définition du travail. En outre, les

variables d’environnement suivantes sont définies :

HOME

Le répertoire principal de l’utilisateur de la connexion.

LOGNAME

Le nom de l’utilisateur de la connexion.

PATH Pour Unix, il est défini sur /bin:/usr/bin. Pour Windows, il est défini sur

%SYSTEM%\SYSTEM32.

TZ Le fuseau horaire.

Si la méthode ne peut pas être exécutée, le travail se voit affecter le statut fail.

Lorsqu’une méthode est en cours d’exécution, elle écrit des messages à son stdout

pour indiquer le statut du travail sur le système externe. Ces messages sont décrits

dans le tableau ci-après.

Tâche Réponse de la méthode Action Tivoli Workload Scheduler

LJ et MJ %CJ statut [mjstring] Affecte le statut state au travail. Inclut

mjstring dans toute tâche MJ ultérieure.

%JS [tempsuc] Affecte le statut succ au travail.

Code de sortie = différent de

zéro

Affecte le statut abend au travail.

%UT [messageerreur ] et code

de sortie = 2

Affecte le statut abend au travail et affiche

messageerreur.

Une séquence typique est constituée d’un ou de plusieurs messages %CJ indiquant

un changement dans l’état du travail, puis un message %JS avant que la méthode

n’existe indiquant que le travail a abouti. Si le travail n’aboutit pas, la méthode

doit exister sans écrire le message %JS. Une méthode qui ne supporte pas la tâche

LJ écrit un message %UTvers stdout et renvoie le code de sortie 2.

Tâche de gestion du travail (MJ)

La tâche MJ assure la synchronisation avec un travail précédemment lancé dans le

cas où le planificateur détermine que la tâche LJ s’est achevée de façon inattendue.

Le planificateur configure l’environnement de la même façon que pour la tâche LJ

et transmet mjstring. Pour plus d’informations, reportez-vous à la section «Tâche de

lancement d’un travail (LJ)».

Si la méthode localise le travail indiqué, elle renvoie les mêmes messages qu’une

tâche LJ. Si la méthode ne parvient pas à localiser le travail, elle quitte l’application

avec un code de sortie différent de zéro ; le planificateur affecte alors le statut

abend au travail.


Suppression d’un travail

Lors de l’exécution d’une tâche LJ ou MJ, la méthode doit capter un signal

SIGTERM (signal 15). Ce signal est envoyé lorsqu’un opérateur lance une

commande Kill via le gestionnaire de console du planificateur. A la réception du

signal, la méthode doit essayer de supprimer (kill) le travail et sortir sans qu’un

message %JS ne soit généré.

Tâche de vérification d’un fichier (CF)

La tâche CF charge la méthode de l’agent étendu de vérifier la disponibilité d’un

fichier sur le système externe. Avant d’exécuter la méthode, le planificateur crée un

environnement d’exécution. Le paramètre CFuser, lu à partir du fichier d’options

de la méthode, indique avec quel compte utilisateur la méthode doit être exécutée.

Si ce paramètre ne figure pas dans le fichier d’options ou si ce dernier n’existe pas,

l’utilisateur root est utilisé sous Unix ; sous Windows, le nom de l’utilisateur du

compte sur lequel le planificateur a été installé est utilisé. Si la méthode ne peut

pas être exécutée, la dépendance opens du fichier est marquée comme échouée,

c’est-à-dire que le statut du fichier est défini sur NO et qu’aucun flux de travaux

ou travail dépendant n’est autorisé à s’exécuter.

Lorsqu’elle est exécutée, la méthode exécute une commande test ou son équivalent

pour le fichier utilisant le qualifiant qui lui est transmis dans l’option de ligne de

commande -q. Si la valeur du fichier test est true, la méthode existe avec un code

de sortie 0. Si la valeur du fichier test est false, la méthode existe avec un code de

sortie différent de 0. Voir le tableau ci-dessous.


CF Code de sortie = 0 Définit le statut du fichier à YES.

Code de sortie = différent de

zéro

Définit le statut du fichier à NO.


de sortie = 2

Définit le statut du fichier à NO.

Une méthode qui ne supporte pas la tâche CF écrit un message %UT vers stdout

et sort en renvoyant le code de sortie 2.

Tâche d’obtention d’un état (GS)

La tâche GS charge la méthode de l’agent étendu de vérifier le statut d’un travail.

Cette opération est nécessaire lorsque l’exécution d’un autre travail dépend du

succès de l’exécution d’un travail externe. Avant l’exécution de la méthode, le

paramètre GSuser est lu à partir du fichier d’options de la méthode pour

déterminer le compte utilisateur avec lequel la méthode doit être exécutée. Si ce

paramètre ne figure pas dans le fichier d’options ou si ce dernier n’existe pas,

l’utilisateur root est utilisé sous Unix ; sous Windows, le nom de l’utilisateur du

compte sur lequel le planificateur a été installé est utilisé. Si la méthode ne peut

pas être exécutée, le travail ou le flux de travaux dépendant ne peut pas être

exécuté. Si l’idtravail d’une précédente tâche GS est disponible, il est transmis à la

méthode.

La méthode vérifie le statut du travail indiqué et le renvoie dans un message %CJ

écrit vers stdout. Elle existe alors avec le code de sortie 0. A une fréquence définie

par l’option locale bm check status, la méthode est réexécutée avec une tâche GS

jusqu’à ce que l’un des statuts de travail suivant soit renvoyé :

abend Le travail s’est arrêté de manière anormale.


succ Le travail a abouti.

cancl Le travail a été annulé.

done Le travail a été effectué sans savoir s’il a abouti ou s’il a échoué.

fail Le travail n’a pas pu être exécuté.

error Une erreur s’est produit dans la méthode lors de la vérification du statut

du travail.

extrn La vérification du travail a échoué ou le statut du travail n’a pas pu être

déterminé.

Notez que GStimeout dans le fichier d’options de la méthode indique le temps

pendant lequel le planificateur attend une réponse avant de supprimer la méthode.

Pour plus d’informations, reportez-vous à la section «Fichier d’options de

méthode» à la page 175.

Les réponses de méthode sont décrites dans le tableau ci-après.


GS %CJ statut [idtravail] Définit le statut du travail à statut et inclut

idtravail dans toute tâche GS suivante.


de sortie = 2

Le statut du travail est inchangé.

Une méthode qui ne supporte pas la tâche GS écrit un message %UT à stdout et

sort avec le code de sortie 2.

La commande cpuinfo

La commande cpuinfo peut être utilisée dans une méthode d’accès pour renvoyer

des informations à partir d’une définition de poste de travail. Pour obtenir des

informations complètes sur la commande, consultez le manuel IBM Tivoli Workload

Scheduler - Guide de référence.

Identification et résolution des incidents

Les sections suivantes décrivent comment identifier et déboguer des problèmes

survenus au niveau d’agents étendus et de méthodes d’accès.

Messages d’erreur de la liste standard d’un travail

Tous les messages en sortie émanant d’une méthode d’accès, exceptés ceux

commençant par un symbole de pourcentage (%), sont écrits dans le fichier de la

liste standard (stdlist) du travail. Pour les tâches GS et CF qui ne sont pas

associées aux travaux du planificateur, les messages sont écrits dans le fichier de

liste standard du planificateur. Pour obtenir des informations relatives à tout

problème, reportez-vous à ces fichiers.


Méthode non exécutable

Si une méthode d’accès ne peut pas être exécutée, les événements suivants se

produiront :

v Pour des tâches LJ et MJ, le travail se voit affecter le statut fail.

v Pour la tâche CF, la dépendance par rapport à un fichier n’est pas résolue et le

travail dépendant conserve le statut hold.

v Pour la tâche GS, la dépendance par rapport à un travail n’est pas résolue et le

travail dépendant conserve le statut hold.

Pour plus d’informations, consultez la liste des fichiers standard ( stdlist) pour le

travail et le planificateur.

Messages du gestionnaire de consoles

Le message d’erreur ci-après s’affiche si vous émettez une commande start, stop,

link ou unlink pour un agent étendu :

Error executing command: Not implemented for extended

agents. [2202.58]

Ce message d’erreur n’est pas affiché si des caractères génériques ont été utilisés

pour la sélection d’un agent étendu.

Messages du programme Composer et Compiler

Les messages d’erreur suivants sont générés lorsque le programme Composer

rencontre une syntaxe non valide dans une définition de poste de travail :

ACCESS METHOD is syntactically invalid [1116.45]

Duplicate ACCESS keyword [1116.46]

Missing or invalid ACCESS METHOD [1116.47]

Si un agent étendu est défini avec une méthode d’accès mais sans hôte, le message

suivant s’affiche :

"Method needs a Host CPU"

Messages de Jobman

Pour les agents étendus, les messages d’information, d’avertissement ou d’erreur

sont générés dans le fichier stdlist de Jobman.

Un travail dont le lancement a abouti génère le message suivant :

Launched job jobname for wkstation, #Jjobid for user username.

Un travail dont le lancement n’a pas abouti génère le message suivant :

Error launching jobname for wkstation: errortext

L’échec d’une tâche de vérification de fichier génère le message suivant :

Error invoking methodname for wkstation: errortext

L’échec d’une tâche de gestion de fichier génère le message suivant :

Error managing jobname for wkstation using methodname: errortext

Lorsqu’un méthode envoie un message à Jobman qui n’est pas reconnu, le message

suivant est généré :

Error: message invalid for jobname, #jjobnumber for

wkstation using methodname.

"first 64 characters of the offending message"


Chapitre 28. Bibliothèque de mappage de code retour

La fonctionnalité de mappage du code retour fournit un moyen classique de

mapper les messages dans des valeurs de code retour. De plus, le mappage du

code retour peut être personnalisé par les utilisateurs. Cette fonctionnalité est

disponible pour les méthodes d’accès aux programmes suivants :

v Oracle eBusiness Suite

v Peoplesoft

v R/3

Cette fonctionnalité offre une meilleure stratégie de définition des règles de succès

et d’échec des travaux, ainsi qu’une meilleure flexibilité dans le contrôle des flux

d’exécution de travaux sur la base des résultats d’exécution. Le mappage du code

retour du travail offre les capacités suivantes :

v Les utilisateurs peuvent définir un état de résiliation du travail (avec succès ou

échec) basé sur une condition appliquée au code retour pour l’exécution du

programme ou du script du travail.

v Le code retour peut également être fourni au travail de reprise associé à la

définition de ce travail. Cela implique que le travail de reprise effectue des

traitements différents en fonction du code retour.

Fichier de mappage du code retour

Ce fichier vous permet de personnaliser vos propres codes retour en respectant

certaines conditions pouvant affecter un travail en cours d’exécution. Il est alors

possible de définir la condition du succès du travail à partir de laquelle Tivoli

Workload Scheduler peut évaluer si ce travail se termine avec succès ou si une

erreur est générée. Le code retour est envoyé à Tivoli Workload Scheduler sous la

forme d’un message %RC nnnn. Si ce message est reçu, l’état du travail est mis à

jour en conséquence.

Syntaxe

La syntaxe du fichier de mappage du code retour est la suivante :

[#] “modèle1” “modèle2”...“modèlen” = valeur RC

Paramètres

# Commentaire facultatif. Les lignes commençant par ce symbole (#) ne sont

pas utilisées pour le mappage.

modèlen

Chaînes de métacaractères délimitées par des guillemets doubles (“ et ”). Si

vous n’utilisez qu’une seule chaîne de métacaractères, vous pouvez omettre

les guillemets doubles. Si cette chaîne de métacaractères comprend un

symbole guillemet double, celui-ci doit être précédé d’une barre oblique

inversée (\). La chaîne peut contenir les caractères génériques et les

caractères spéciaux suivants :

L’astérisque (*)

Remplace plusieurs caractères.

Le point d’interrogation (?)

Remplace un seul caractère.


La barre oblique inversée (\)

Caractère d’échappement.

Valeur RC

Valeur du code retour. Cette valeur est envoyée par la méthode au Tivoli

Workload Scheduler via un message %RC nnnn.

Exemples

Dans l’exemple ci-dessous d’un fichier de mappage de code retour, les numéros de

ligne en gras ne font pas partie du fichier ; ils sont indiqués à titre de référence :

1. # Il s’agit d’un fichier de mappage RC pour le journal des travaux.

2.

3. “Utilisateur * manquant ” = 102

4. “\*\*\*” = 103

5. “Utilisateur \

6. * \

7. “ manquant = 102

où :

v La ligne 1 est un commentaire, et, à ce titre, elle n’est pas utilisée pour le

mappage.

v La ligne 2 est vide et donc ignorée. Tous les blancs précédant ou suivant une

chaîne de métacaractères sont ignorés, de même que ceux situés entre le signe

égal et la valeur de code retour.

v La ligne 3 prend en compte tous les messages qui commencent par la chaîne

Utilisateur et qui se terminent par la chaîne manquant.

v La ligne 4 prend en compte tous les messages qui commencent par trois

astérisques (*) suivis par un caractère blanc. Lorsque vous utilisez l’astérisque

comme tel et non comme un caractère générique, vous devez le faire suivre

d’une barre oblique inversée.

v Les lignes 5 à 7 contiennent une chaîne s’étalant sur plusieurs lignes. Cette

chaîne prend en compte les mêmes messages que le format de la ligne 3.

Commentaires

Prenez connaissance des informations suivantes :

v L’ordre des lignes de chaînes est important car c’est la première ligne de chaîne

concordante qui sert à créer la valeur du code retour.

v Les chaînes de métacaractères vides (“”) sont ignorées par la procédure de mise

en correspondance des chaînes.

Par exemple, la séquence de modèles ci-dessous est correcte. La première ligne est

plus restrictive que la deuxième.

“625” “Utilisateur * manquant” = 104

“” “Utilisateur * manquant” = 102

La séquence de modèles suivante est syntaxiquement correcte ; toutefois, le

modèle présenté en deuxième ligne n’est jamais utilisé car la première ligne est

toujours mise en correspondance avant la deuxième.

“” “Utilisateur * manquant” = 102

“625” “Utilisateur * manquant” = 104

Mappage du code retour pour Psagent et MCMAGENT

Pour les méthodes d’accès de PeopleSoft et Oracle e-Business Suite, vous pouvez

écrire des fichiers de mappage de code retour qui associent les états internes

répertoriés dans le tableau 22 à la page 183 et dans le tableau 23 à la page 184.


Si aucun fichier de mappage de code retour n’a été défini ou si une chaîne

retournée par la méthode d’accès ne répond à aucun des modèles de

correspondance du fichier de mappage, les méthodes utilisent les codes retour

standard respectifs répertoriés dans les mêmes tableaux.

Tableau 22. Etats des travaux et codes retour de la méthode d’accès de PeopleSoft

Etat du travail de Psoft Code retour de Psoft

″CANCEL″ 1

″DELETE″ 2

″ERROR″ 3

″HOLD″ 4

″QUEUED″ 5

″INITIATED″ 6

″PROCESSING″ 7

″CANCELLED″ 8

″SUCCESS″ 9

″NO SUCCESSPOSTED″ 10

″POSTED″ 11

″NOT POSTED″ 12

″RESEND″ 13

″POSTING″ 14

″GENERATED″ 15

Chapitre 28. Bibliothèque de mappage de code retour 183

Tableau 23. Etats des travaux et codes retour de la méthode d’accès d’Oracle e-Business

Suite.

Etat du travail MCMAGENT Code retour de MCMAGENT

″RUNNING″ 1

″PENDING″ 2

″COMPLETE″ 3

″INACTIVE″ 4

″NORMAL″ 5

″TERMINATING″ 6

″PAUSED″ 7

″RESUMING″ 8

″STANDBY″ 9

″SCHEDULED″ 10

″WAITING″ 11

″WARNING″ 13

″ERROR″ 14

″TERMINATED″ 15

″DELETED″ 16

″ON HOLD″ 17

″DISABLED″ 18

″NO MANAGER″ 19

″SUSPENDED″ 20

″TEST FAILURE″ 21

″NOT FOUND″ 22


Exemples : L’agent étendu d’Oracle e-Business Suite retourne la chaîne

TERMINATED. Le code retour qui en résulte devrait être le suivant, en fonction des

conditions énoncées :

v Il n’existe pas de fichier de mappage de code retour. Dans ce cas, la méthode

envoie la valeur de code retour 15, comme indiqué dans le tableau 23 à la page

184.

v Il existe un fichier de mappage de code ; il s’agit de :

"NORMAL"=0

"TERMINATED","DELETED"=1

Dans ce cas, la méthode recherche le modèle correspondant et envoie la valeur

de code retour 1.

v Le fichier de mappage du code retour est

"NORMAL"=0

"ERROR","DELETED"=1

Dans ce cas, la méthode ne recherche pas le modèle correspondant ; elle envoie

la valeur de code retour 15, comme indiqué dans le tableau 23 à la page 184.

Chapitre 28. Bibliothèque de mappage de code retour 185

Noms de fichier de mappage de code retour

Chaque méthode possède son propre ensemble de fichiers destiné à mapper les

messages en valeurs de codes retour. Les fichiers de mappage peuvent être locaux

ou communs pour un poste de travail.

Les fichiers de mappage des codes retour spécifiques à un poste de travail sont

nommés selon le schéma suivant :

<racine_TWS>/methods/rcm/<nom_méthode>-<type>-<postetravail>.rcm

Le nom des fichiers communs de mappage doit suivre le schéma suivant :

<racine_TWS>/methods/rcm/<nom_méthode>-<type>.rcm

Pour les méthodes d’accès de PeopleSoft et d’Oracle e-Business, le type est toujours

égal à rcmap. Pour la méthode d’accès à R/3, le type correspond à la description

faite dans la section ci-après.

Noms de fichier de mappage de code retour pour r3batch

La méthode de R3 utilise les fichiers communs de mappage de code retour

suivants :

<racine_TWS>/rcm/methods/r3batch-joblog.rcm

Permet de mapper les messages issus du journal des travaux d’un travail

R3 en valeurs de code retour. Si ce fichier est absent, les messages du

journal des travaux sont ignorés.

<racine_TWS>/rcm/methods/r3batch-pchainlog.rcm

Permet de mapper les messages issus du protocole d’une chaîne de

traitement en valeurs de code retour. Si ce fichier est absent, les messages

de ce protocole sont ignorés.

<racine_TWS>/rcm/methods/r3batch-spool.rcm

Permet de mapper les messages dans la liste de spoule d’un travail SAP en

valeurs de code retour. Si ce fichier est absent, les messages de la liste de

spoule sont ignorés.

<racine_TWS>/rcm/methods/r3batch-syslog.rcm

Permet de mapper les messages dans le syslog d’un système SAP en

valeurs de code retour. Si ce fichier est absent, les messages du syslog sont

ignorés.

<racine_TWS>/rcm/methods/r3batch-msgrc.rcm

Permet de mapper les exceptions ABAP / codes retour BAPI des modules

de la fonction d’appel de fonction distante en valeurs de code retour. Si ce

fichier est absent, le mappage s’effectue à l’aide d’une table définie dans le

code.


Chapitre 29. Configuration de l’utilitaire de trace

Toutes les méthodes d’accès offrent la possibilité de configurer les options de la

fonction de trace. Vous pouvez ainsi modifier certaines propriétés de traçage dans

le fichier de configuration <nom_méthode_accès>.properties situé dans le

sous-répertoire methods de racine_TWS.

Vous pouvez configurer les propriétés de trace suivantes :

v Niveau de traçage (MIN, MID, MAX),

v Emplacement du fichier de trace (en termes de chemin absolu).

L’exemple suivant représente un fichier de configuration pour la méthode

d’accès R/3, ayant pour nom r3batch.properties. Les mots-clés commentés dans

cette section sont mis en évidence par souci de lisibilité :

r3batch.organization=IBM

r3batch.product=TWS4APPS

r3batch.component=R3BATCH

r3batch.trace.tracers.level=DEBUG_MIN

r3batch.trace.tracers.listenerNames=r3batch.trace.handlers.traceFile

r3batch.trace.handlers.traceFile.fileDir=home/maestro/methods

r3batch.trace.handlers.traceFile.appending=true

r3batch.trace.handlers.traceFile.formatterName=r3batch.trace.formatter

Grâce au mot clé level, le mécanisme de traçage prend en charge trois niveaux de

trace :

DEBUG_MIN

Seules les erreurs fatales sont répertoriées. Il s’agit de l’option par défaut.

DEBUG_MID

Les messages d’information et les avertissements sont également

répertoriés.

DEBUG_MAX

Un résultat plus explicite en termes de débogage est affiché.

Les paramètres du fichier de propriétés affectent toutes les exécutions de la

méthode d’accès correspondante. Pour définir un paramètre de trace différent dans

le cadre d’un travail particulier, ajoutez l’option suivante dans la définition du

travail :

-tracelvl=(1|2|3)

où :

v 1 = DEBUG_MIN

v 2 = DEBUG_MID

v 3 = DEBUG_MAX

Dans le cas de la méthode d’accès R/3 (et uniquement dans ce cas), vous pouvez

cocher la case Débogage dans la fenêtre Propriétés - Définition du travail de Job

Scheduling Console pour définir le niveau de trace sur DEBUG_MAX pour un travail

spécifique. Notez que la case Trace active la trace RFC SAP.

Les traces sont écrites au format XML. Par défaut, les fichiers de trace sont stockés

dans le répertoire methods. Pour modifier ce chemin, vous pouvez utiliser le mot


clé fileDir. Vérifiez que le nouveau chemin indiqué a déjà été créé en tant que

chemin absolu, avec des droits en écriture. Utilisez toujours des barres obliques (ou

des barres obliques inversées) lorsque vous spécifiez un nouveau chemin, même si

vous êtes sous Windows.

Les fichiers de trace donnent des informations sur l’exécution de la méthode au

niveau de détails désiré. Le niveau de trace minimum est toujours actif, de manière

à garantir un outil de diagnostic de premier niveau (FFDC).

La valeur de la clé appending détermine si un nouveau fichier de trace est ajouté à

l’ancien fichier (true) ou le remplace ( false). La valeur true est recommandée

dans tous les cas. En particulier, elle ne doit pas être modifiée en false lors de

l’exécution de travaux, étant donné que cela entraînerait la perte des traces.


Chapitre 30. Identification et résolution des incidents

Le présent chapitre répertorie les incidents que vous pouvez rencontrer lorsque

vous installez ou utilisez Tivoli Workload Scheduler for Applications ou les

méthodes d’accès.

Tableau 24. Identification des incidents

Zone Incidents

Installation :

Reconnaissance

des instances

Tivoli Workload

Scheduler

Incident : Si vous êtes sous Unix et avez plusieurs installations de Tivoli Workload Scheduler,

version 7.0 ou 8.1, qui n’ont pas été correctement installées dans un répertoire de base

/home/utilisateur_TWS, le programme d’installation affiche alors, au hasard, une seule de ces

instances et l’appelle <unknown>.

Solution : Pour chacune de ces instances, créez un répertoire de base désignant le répertoire

d’installation courant de Tivoli Workload Scheduler. Procédez de la manière suivante :

1. Sur root, créez un répertoire /home/utilisateur_TWS qui désigne le répertoire dans lequel le

produit est installé.

2. Dans le fichier /usr/unison/components, ajoutez l’entrée /home/utilisateur_TWS qui

désigne l’entrée de cette instance spécifique.

Installation :

Installation de

psagent

Incident : Lors de l’installation de la méthode d’accès de la fonction PeopleSoft, le message

instantané suivant peut s’afficher :

Impossible de trouver le nombre ordinal 6654 dans la bibliothèque DLL MFC42u.dll

Ce message apparaît si une ancienne version de MFC42u.dll a été trouvée dans le répertoire

système de Windows.

Solution : Pour résoudre l’incident, vous devez remplacer la bibliothèque DLL MFC42u.dll par

une version plus récente. Pour récupérer une version plus récente, consultez le répertoire de

base PeopleSoft.

r3batch :

Planification de

travaux R/3

Incident : Lorsque vous créez un travail SAP, le message suivant apparaît si vous tentez

d’afficher les détails d’une variante ABAP :

AWSO0101E

Sous-programme ABAP manquant.

J_101_REPORT_ALL_SELECTIONS Veuillez installer la dernière version du sous-programme

ABAP pour Maestro !!

Solution : Cet incident est causé par une erreur du module de fonction SAP. SAP décrit cet

incident et les solutions possibles dans les notes SAP 0351293 et 0116354.

Environnement

mixte : Messages

des journaux de

travaux de

psagent et

zosagent

Si votre environnement de planification comprend Tivoli Workload Scheduler version 8.1 et

Tivoli Workload Scheduler for Applications version 8.2, les messages des journaux de travaux

des méthodes d’accès pour z/OS et PeopleSoft affichent des préfixes doubles :

v AWSxxxx EEWIaaaa <texte de message> for zosagent

v AWSxxxx EEWNaaaa <texte de message> for psagent

Environnement

mixte : Codes

retour des travaux

d’agent étendu

Si votre environnement de planification comprend Tivoli Workload Scheduler version 8.2 et

Tivoli Workload Scheduler for Applications version 8.1.1, l’élément affiché comme code retour

d’un travail d’agent étendu soumis (via Job Scheduling Console ou conman) correspond en

réalité au code de sortie du travail. Il ne doit pas être interprété comme le code retour.


Identification des incidents lors de l’installation de la méthode d’accès

PeopleSoft

Pour installer cette méthode d’accès, vous devez définir l’environnement

PeopleSoft comme répertoire dépendant de votre version de PeopleSoft. Certains

fichiers exécutables de méthode d’accès sont installés ici. Le tableau suivant

présente les répertoires et les fichiers que vous devez consulter si vous identifiez

des incidents dans votre installation.

Tableau 25. Chemins de l’environnement PeopleSoft.

Version de

PeopleSoft

Nom de répertoire Fichiers à rechercher

7.x <RACINE_PS>\cblbin

où <RACINE_PS> représente le répertoire de base

du serveur de fichiers PeopleSoft. Il est accessible

en local ou à distance à partir du poste de travail

exécutant la méthode d’accès.

TVPUPSFT.exe

cblrtss.dll

8.1x <REP_API_EXT>\bin\client\winx86_extapi

où <REP_API_EXT> représente le répertoire dans

lequel les API externes PeopleSoft sont installées.

TVPUPSFT.exe

pspiadapter.dll

8.4x <RACINE_PS>\\bin\client\winx86

où <RACINE_PS> représente le répertoire de base

du serveur de fichiers PeopleSoft. Il est accessible

en local ou à distance à partir du poste de travail

exécutant la méthode d’accès.

TVPUPSFT.exe

pspiadapter.dll


Chapitre 31. Fichiers installés

Ce chapitre fournit la liste des fichiers que vous devez trouver sur votre système à

l’issue de l’installation de Tivoli Workload Scheduler for Applications. Les

informations sont classées par plateforme et fonction. Cette liste n’inclut pas les

fichiers installés pour le support Java, autres que ceux requis pour la

désinstallation du produit.

Le tableau ci-après répertorie les fichiers installés sous Windows.

Tableau 26. Fichiers installés sous Windows.

Fonction Fichiers

Méthode d’accès PeopleSoft racine_TWS\catalog\C\peoplesoft.cat

racine_TWS\methods\PeopleSoft\PTCUDCOP.bl

racine_TWS\methods\PeopleSoft\TVPUPSFT700.dms

racine_TWS\methods\PeopleSoft\TVPUPSFT750.dms

racine_TWS\methods\defs\psagent.def

racine_TWS\methods\enigma.exe

racine_TWS\methods\msvcrt.dll

racine_TWS\methods\oslayer.dll

racine_TWS\methods\psagent.exe

racine_TWS\methods\psagent.opts

racine_TWS\methods\psagent.properties

Pour PeopleTools 7.0x et Merant NetExpress 2 :PSHOME70CBL2\cblbin\TVPUPSFT.exe

PSHOME70CBL2\cblbin\TVPUPSFT.gnt



PeopleTools 7.0x et MF COBOL Workbench 4.x :PSHOME70CWB4\cblbin\TVPUPSFT.exe

PSHOME70CWB4\cblbin\TVPUPSFT.gnt





Pour PeopleTools 8.1x :PSHOME81X\bin\client\winx86_extapi\TVPUPSFT.exe

Pour PeopleTools 8.4x :PSHOME84X\bin\client\winx86\TVPUPSFT.exe


Tableau 26. Fichiers installés sous Windows. (suite)

Fonction Fichiers

Méthode d’accès R/3 racine_TWS\methods\K000443.TV1

racine_TWS\methods\R000443.TV1

racine_TWS\methods\r3batch.exe

racine_TWS\methods\r3batch.opts

racine_TWS\methods\r3batch.properties

racine_TWS\methods\r3batch_cp.map

racine_TWS\methods\librfc32.dll

racine_TWS\methods\enigma.exe


racine_TWS\methods\msvbvm60.dll

racine_TWS\methods\msvcp60.dll

racine_TWS\methods\defs\r3batch.def

racine_TWS\catalog\C\r3batch.cat

Méthode d’accès z/OS racine_TWS\methods\mvsca7.exe

racine_TWS\methods\mvsca7.opts

racine_TWS\methods\mvsca7.properties

racine_TWS\methods\mvsjes.exe

racine_TWS\methods\mvsjes.opts

racine_TWS\methods\mvsjes.properties

racine_TWS\methods\mvsopc.exe

racine_TWS\methods\mvsopc.opts

racine_TWS\methods\mvsopc.properties

racine_TWS\methods\oslayer.dll

racine_TWS\methods\defs\mvsca7.def

racine_TWS\methods\defs\mvsjes.def

racine_TWS\methods\defs\mvsopc.def


racine_TWS\catalog\C\mvs.cat

Installation commune racine_TWS\methods\opted\jakarta-oro-2.0.6.jar

racine_TWS\methods\opted\opted.bat

racine_TWS\methods\opted\tws4apps.jar

racine_TWS\methods\opted\tws4appsbeans.jar

racine_TWS\methods\opted\uil.jar

racine_TWS\methods\opted\xercesImpl.jar

racine_TWS\methods\opted\xmlParserAPIs.jar

racine_TWS\methods\opted.exe

Désinstallation racine_TWS\methods\_xauninst\uninstall.dat

racine_TWS\methods\_xauninst\uninstall.jar

racine_TWS\methods\_xauninst\uninstaller.exe

Le tableau ci-après répertorie les fichiers installés sous Unix (plateformes de

niveau 1).


Tableau 27. Fichiers installés sous Unix (plateformes de niveau 1).

Fonction Fichiers

Méthode d’accès Oracle

e-Business Suite

racine_TWS/catalog/C/mcm.cat

racine_TWS/methods/MCMAGENT.opts

racine_TWS/methods/MCMAGENT.properties

racine_TWS/methods/OracleTMP/MCMAGENT

racine_TWS/methods/OracleTMP/MCMLJ.o

racine_TWS/methods/OracleTMP/MCMSTAT.o

racine_TWS/methods/OracleTMP/MCMTJ.o

racine_TWS/methods/OracleTMP/MCMprod.txt

racine_TWS/methods/OracleTMP/libusr.a

racine_TWS/methods/OracleTMP/mcm.mk

racine_TWS/methods/OracleTMP/mcminstall

racine_TWS/methods/OracleTMP/mcmoptions

racine_TWS/methods/defs/MCMAGENT.def

racine_TWS/methods/enigma

Méthode d’accès R/3 racine_TWS/catalog/C/r3batch.cat

racine_TWS/methods/K000443.TV1

racine_TWS/methods/R000443.TV1

racine_TWS/methods/defs/r3batch.def

racine_TWS/methods/enigma

racine_TWS/methods/r3batch

racine_TWS/methods/r3batch.opts

racine_TWS/methods/r3batch.properties

racine_TWS/methods/r3batch_cp.map

Méthode d’accès z/OS racine_TWS/catalog/C/mvs.cat

racine_TWS/methods/defs/mvsca7.def

racine_TWS/methods/defs/mvsjes.def

racine_TWS/methods/defs/mvsopc.def

racine_TWS/methods/mvsca7

racine_TWS/methods/mvsca7.opts

racine_TWS/methods/mvsca7.properties

racine_TWS/methods/mvsjes

racine_TWS/methods/mvsjes.opts

racine_TWS/methods/mvsjes.properties

racine_TWS/methods/mvsopc

racine_TWS/methods/mvsopc.opts

racine_TWS/methods/mvsopc.properties

Installation commune racine_TWS/methods/opted.bin

racine_TWS/methods/opted/jakarta-oro-2.0.6.jar

racine_TWS/methods/opted/opted.sh

racine_TWS/methods/opted/tws4apps.jar

racine_TWS/methods/opted/tws4appsbeans.jar

racine_TWS/methods/opted/uil.jar

racine_TWS/methods/opted/xercesImpl.jar

racine_TWS/methods/opted/xmlParserAPIs.jar

Désinstallation racine_TWS/methods/_xauninst/uninstall.dat

racine_TWS/methods/_xauninst/uninstall.jar

racine_TWS/methods/_xauninst/uninstaller

Chapitre 31. Fichiers installés 193

Partie 7. Annexes


Remarques

Le présent document peut contenir des informations ou des références concernant

certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus

de détails, référez-vous aux documents d’annonce disponibles dans votre pays, ou

adressez-vous à votre partenaire commercial IBM. Toute référence à un produit,

logiciel ou service IBM n’implique pas que seul ce produit, logiciel ou service

puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être

utilisé, s’il n’enfreint aucun droit d’IBM. 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 IBM.

IBM peut détenir des brevets ou des demandes de brevet 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 brevet. 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

La Défense 5

2, avenue Gambetta

92066 - Paris-La Défense CEDEX

France

Pour le Canada, veuillez adresser votre courrier à :

IBM Director of Commercial Relations

IBM Canada Ltd.

3600 Steeles Avenue East

Markham, Ontario

L3R 9Z7

Canada

Les informations sur les licences concernant les produits utilisant un jeu de

caractères double octet peuvent être obtenues par écrit à l’adresse suivante :

IBM World Trade Asia Corporation

Licensing

2-31 Roppongi 3-chome, Minato-ku

Tokyo 106, Japan

Le paragraphe suivant ne s’applique ni au Royaume-Uni, ni dans aucun pays

dans lequel il serait contraire aux lois locales :

LE PRESENT DOCUMENT EST LIVRE EN L’ETAT. IBM DECLINE TOUTE

RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS

QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES

GARANTIES DE VALEUR MARCHANDE OU D’ADAPTATION A VOS BESOINS.


Certaines juridictions n’autorisent pas l’exclusion des garanties implicites, auquel

cas l’exclusion ci-dessus ne vous sera pas applicable.

Le présent document peut contenir des inexactitudes ou des coquilles. Il est mis à

jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut

modifier sans préavis les produits et logiciels décrits dans ce document.

Les références à des sites Web non IBM sont fournies à titre d’information

uniquement et n’impliquent en aucun cas une adhésion aux données qu’ils

contiennent. Les éléments figurant sur ces sites Web ne font pas partie des

éléments du présent produit IBM et l’utilisation de ces sites relève de votre seule

responsabilité.

IBM pourra utiliser ou diffuser, de toute manière qu’elle jugera appropriée et sans

aucune obligation de sa part, tout ou partie des informations qui lui seront

fournies.

Les licenciés souhaitant obtenir des informations permettant : (i) l’échange des

données entre des logiciels créés de façon indépendante et d’autres logiciels (dont

celui-ci), et (ii) l’utilisation mutuelle des données ainsi échangées, doivent adresser

leur demande à :

IBM Corporation

2Z4A/101

11400 Burnet Road

Austin, TX 78758 U.S.A.

Ces informations peuvent être soumises à des conditions particulières, prévoyant

notamment le paiement d’une redevance.

Le logiciel sous licence décrit dans ce document et tous les éléments sous licence

disponibles s’y rapportant sont fournis par IBM conformément aux dispositions de

l’ICA, des Conditions internationales d’utilisation des logiciels IBM ou de tout

autre accord équivalent.

Les données de performance indiquées dans ce document ont été déterminées dans

un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière

significative selon l’environnement d’exploitation utilisé. Certaines mesures

évaluées sur des systèmes en cours de développement ne sont pas garanties sur

tous les systèmes disponibles. En outre, elles peuvent résulter d’extrapolations. Les

résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de

vérifier si ces données sont applicables à leur environnement d’exploitation.

Les informations concernant des produits non IBM ont été obtenues auprès des

fournisseurs de ces produits, par l’intermédiaire d’annonces publiques ou via

d’autres sources disponibles. IBM n’a pas testé ces produits et ne peut confirmer

l’exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoir

aucune réclamation concernant des produits non IBM. Toute question concernant

les performances de produits non IBM doit être adressée aux fournisseurs de ces

produits.

Le présent document peut contenir des exemples de données et de rapports utilisés

couramment dans l’environnement professionnel. Ces exemples mentionnent des


noms fictifs de personnes, de sociétés, de marques ou de produits à des fins

illustratives ou explicatives uniquement. Toute ressemblance avec des noms de

personnes, de sociétés ou des données réelles serait purement fortuite.

Si vous visualisez ces informations en ligne, il se peut que les photographies et

illustrations en couleur n’apparaissent pas à l’écran.

Marques

IBM, le logo IBM, Tivoli, AIX, AS/400, Dynix, MVS/ESA, OS/390, RACF, RS/6000,

Sequent, z/OS et zSeries sont des marques d’International Business Machines

Corporation aux Etats-Unis et/ou dans certains autres pays.

Microsoft et Windows NT sont des marques de Microsoft Corporation aux

Etats-Unis et/ou dans certains autres pays.

UNIX est une marque enregistrée de The Open Group aux Etats-Unis et/ou dans

certains autres pays.

Java et toutes les marques et logos incluant Java sont des marques de Sun

Microsystems, Inc. aux Etats-Unis et/ou dans certains autres 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 199

Glossaire

A

agent étendu : Les agents étendus sont utilisés pour

intégrer les fonctions de contrôle des travaux de Tivoli

Workload Scheduler à d’autres systèmes d’exploitation

(par exemple MVS) et à d’autres applications (comme

Oracle, Peoplesoft et R/3). Ils utilisent des scripts

appelés méthodes d’accès pour communiquer avec des

systèmes externes.

agent réseau : Type d’agent étendu servant à créer des

dépendances entre les travaux et les flux de travaux de

différents réseaux Tivoli Workload Scheduler. Voir aussi

“dépendances inter-réseaux (INET)”.

agent tolérant aux pannes : 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 : La base de données contient toutes

les définitions que vous avez créées pour les objets de

planification tels que les travaux, les flux de travaux,

les ressources, les postes de travail, etc. La base de

données contient également d’autres informations

importantes, telles que les statistiques sur l’exécution

des travaux et des flux de travaux, l’ID de l’utilisateur

qui a créé un objet et la dernière date de modification

d’un objet. En revanche, le plan contient uniquement

les travaux et les flux de travaux planifiés à des fins

d’exécution pour la production du jour, ainsi que les

objets qui en dépendent.

base de données étendue : Les bases de données

étendues acceptent 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 sous

forme d’option lors de l’installation. Ne développez 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 jour

de traitement de 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 comprenant une liste de

dates de planification. S’agissant d’un objet unique

défini dans la base de données, il peut être affecté à de

multiples flux de travaux. L’affectation d’un calendrier

à un flux de travaux permet l’exécution de ce dernier

aux dates indiquées 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

acceptés par 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 servent généralement à affiner une

recherche sur un ou plusieurs objets de la base de

données. Par exemple, pour afficher tous les postes de

travail, vous pouvez taper le caractère générique *

(astérisque). Pour obtenir la liste de tous les postes de

travail site1 à site8, vous pouvez entrer site%.

classe de poste de travail : Une classe de poste de

travail correspond à un groupe de postes de travail.

Elle peut contenir un nombre illimité de postes. Des

flux de travaux et des travaux peuvent lui être affectés

en vue d’exécution. Ainsi, la réplication d’un travail ou

d’un flux de travaux à travers plusieurs postes de

travail en est facilitée.

Composer : Application en mode ligne de commande

permettant de gérer les définitions de vos objets de

planification dans la base de données.

Conman : Conman (Console Manager) est une

application en mode ligne de commande qui permet la

gestion de l’environnement de production. Conman

effectue les tâches suivantes : démarrage et arrêt des

processus de production, modification et affichage des

calendriers et des travaux dans le plan, contrôle de la

connexion des postes de travail dans un réseau.

cycle d’exécution : Cycle d’exécution précisant les

jours où un flux de travaux doit être exécuté. Dans

Tivoli Workload Scheduler, vous pouvez indiquer l’un

des trois types de cycles d’exécution suivants pour un

flux de travaux : cycle d’exécution simple, cycle

d’exécution hebdomadaire ou cycle d’exécution basé

sur un calendrier (couramment appelé calendrier).

Notez que chaque type de cycle d’exécution peut être

inclusif ou exclusif. En d’autres termes, chaque cycle

d’exécution peut définir aussi bien les jours où le flux

de travaux sera inclus dans le cycle de production que

ceux où il en sera exclu. Lorsque vous définissez

plusieurs cycles d’exécution pour un flux de travaux et

que les cycles d’exécution inclusifs et exclusifs

indiquent les mêmes jours, les cycles exclusifs ont alors

la priorité.


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 exclusifs

sont prioritaires par rapport aux cycles d’exécution

inclusifs.

cycle d’exécution hebdomadaire : Cycle d’exécution

précisant les jours de la semaine où un flux de travaux

doit être exécuté. Par exemple, vous pouvez indiquer

qu’un flux de travaux doit être exécuté tous les lundis,

mercredis et vendredis à l’aide d’un cycle d’exécution

hebdomadaire. Il est défini pour un flux de travaux

spécifique et ne peut être utilisé pour plusieurs flux de

travaux. Pour plus de détails, voir “cycle d’exécution”.

cycle d’exécution inclusif : Cycle d’exécution

précisant les jours où un flux de travaux doit être

exécuté. Les cycles d’exécution exclusifs sont

prioritaires par rapport aux cycles d’exécution inclusifs.

cycle d’exécution simple : Ensemble de jours définis

par l’utilisateur pendant lesquels un flux de travaux est

exécuté. Il est défini pour un flux de travaux spécifique

et ne peut être utilisé pour plusieurs flux de travaux.

Pour plus de détails, voir “cycle d’exécution”.

D

dépendance : Condition préalable à 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 fixé à 40. Les quatre types de dépendances

utilisées par Tivoli Workload Scheduler sont les

dépendances prédécesseur/successeur, les dépendances

par rapport à une ressource, les dépendances par

rapport à un fichier et les dépendances par rapport à

une invite.

dépendances inter-réseaux (INET) : Dépendance entre

les travaux et les flux de travaux dans les différents

réseaux Tivoli Workload Scheduler. Voir aussi “agent

réseau”.

dépendances prédécesseur/successeur : Dépendance

selon laquelle un travail ou un flux de travaux ne peut

être lancé tant que les autres travaux ou flux de

travaux n’ont pas abouti.

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. Tous les domaines, à

l’exception du domaine principal, ont un domaine

parent.

durée : Délai prévu pour l’exécution d’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 un

flux de travaux ne peuvent plus être exécutés. Il s’agit

de l’heure limite du module Maestro existant.

F

fichier stdlist : Fichier liste standard créé pour chaque

travail lancé par Tivoli Workload Scheduler. Ces fichiers

peuvent contenir des bannières d’en-tête et de fin, des

commandes echo ainsi que des messages d’erreur et

d’avertissement. Ils peuvent être utilisés pour résoudre

les incidents survenus lors de l’exécution de travaux.

fichier Symphony : Fichier contenant les informations

de planification nécessaires au processus de contrôle de

production (batchman) pour exécuter le plan. Il est

généré et chargé durant la phase de pré-production.

Lors de la phase de production, il est mis à jour en

temps réel pour refléter 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 comme un

ensemble (application de sauvegarde hebdomadaire,

par exemple), et accompagnés des heures, des priorités

et de toute autre dépendance déterminant l’ordre exact

d’exécution des travaux.

flux de travaux FINAL : Dernier flux lancé lors d’un

jour de production, contenant un travail qui exécute le

fichier script Jnextday.

G

gestionnaire de domaine : Concentrateur de gestion

d’un domaine Tivoli Workload Scheduler. Toutes les

communications à destination et en provenance des

agents du domaine sont acheminées via le gestionnaire

de domaine.

gestionnaire de domaine principal : Dans un réseau

Tivoli Workload Scheduler, le gestionnaire de domaine

principal gère les fichiers servant à documenter les

objets de planification. 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 de début 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 à une

estimation basée sur l’expérience acquise lors de

l’exécution d’un travail ou d’un 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

bord gauche de la barre d’activité bleu marine. Pour les

instances de travaux, l’heure de début calculée par IBM

Tivoli Workload Scheduler pour z/OS 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 le

planificateur estime qu’une instance de travail

débutera. Cette estimation se base sur l’heure de début

des 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 planificateur, à 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”.

invite : Les invites peuvent servir de dépendances

pour les travaux et flux de travaux. Une réponse

affirmative doit être donnée à une invite pour que le

travail ou le flux de travaux correspondant puisse être

lancé. Il existe deux types d’invites : prédéfinies et ad

hoc. Une invite ad hoc est définie dans les propriétés

d’un travail ou d’un flux de travaux et est spécifique à

ce travail ou ce flux de travaux. Une invite prédéfinie

est définie dans la base de données du planificateur et

peut être utilisée par n’importe quel travail ou flux de

travaux.

L

limite : La limite d’un travail permet de définir le

nombre spécifique de travaux que Tivoli Workload

Scheduler est autorisé à lancer. Une limite de travail

peut être définie pour chaque flux de travaux et pour

chaque poste de travail. Par exemple, avec une limite

de 25, le planificateur peut exécuter simultanément un

maximum de 25 travaux sur un poste de travail.

liste : Une liste affiche 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 listes : 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 : Une méthode d’accès est un

exécutable utilisé par les agents étendus pour connecter

et contrôler l’exécution des travaux sur d’autres

systèmes d’exploitation (par exemple, MVS) et

applications (par exemple, Oracle, Peoplesoft et R/3).

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 : Les options globales sont définies

sur le gestionnaire de domaine principal dans le fichier

globalopts et s’appliquent à tous les postes de travail

du réseau Tivoli Workload Scheduler. Voir aussi

“options locales”.

options locales : Les options locales sont définies dans

le fichier localopts. Chaque poste de travail du réseau

Tivoli Workload Scheduler doit avoir un fichier

localopts. Les paramètres de ce fichier s’appliquent

uniquement à ce poste de travail. Voir aussi “options

globales”.

P

paramètre : Les paramètres permettent de remplacer

des valeurs dans les travaux et les flux de travaux.

Lorsque vous utilisez un paramètre dans un script de

travail, la valeur de celui-ci 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 dans les scripts

des travaux d’agent étendu.

plan : Le plan contient toute l’activité de planification

des travaux prévue pour une journée. Dans Tivoli

Workload Scheduler, le plan est créé toutes les 24

heures et est constitué de tous les travaux, flux de

travaux et dépendances dont l’exécution est planifiée

pour cette journée. Tous les flux de travaux pour

lesquels vous avez créé des cycles d’exécution sont

automatiquement planifiés et intégrés dans le plan. Au

fur et à mesure de la progression du cycle d’exécution,

les travaux et flux de travaux du plan sont exécutés

conformément aux restrictions temporelles et autres

dépendances les affectant. Tout travail ou flux de

travaux ayant échoué est intégré au plan du jour

suivant.

poste de travail : Un poste de travail est généralement

un ordinateur individuel sur lequel sont exécutés les

travaux et flux de travaux. Ils sont définis dans la base

de données Tivoli Workload Scheduler en tant qu’objet

unique. Une définition de poste de travail est requise

pour chaque ordinateur exécutant des travaux ou des

flux de travaux dans le réseau Workload Scheduler.

Glossaire 203

prédécesseur : Travail dont la réussite est nécessaire à

l’exécution des travaux successeurs.

priorité : Le planificateur possède un système de file

d’attente pour les travaux et les flux de travaux du

plan. Vous pouvez associer un niveau de priorité à

chaque travail ou flux de travaux, de 0 à 101. Un

travail avec une priorité de 0 ne sera pas exécuté.

priorité limite : La priorité limite d’un travail permet

de contrôler l’exécution de celui-ci sur un poste de

travail. Elle constitue également un niveau de priorité

qu’un travail ou un flux de travaux doit dépasser afin

de pouvoir être exécuté. Une priorité limite de 40, par

exemple, empêche le lancement des travaux dont la

priorité est inférieure ou égale à 40.

R

ressource : Les ressources peuvent représenter des

ressources physiques ou logiques sur votre système.

Une fois définies dans la base de données Tivoli

Workload Scheduler, elles peuvent servir de

dépendances pour des 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 avec une dépendance requérant

deux lecteurs de bandes disponibles. Les travaux liés à

cette dépendance ne pourront 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 : Des restrictions temporelles

peuvent être définies pour les travaux et les flux de

travaux. Vous pouvez spécifier l’heure de début

d’exécution des travaux ou celle après laquelle ils ne

seront plus entrepris. En précisant les deux, vous

définissez un intervalle de temps pendant lequel un

travail ou un flux de travaux doit être exécuté. Vous

pouvez également indiquer la fréquence de répétition

des travaux. Par exemple, vous pouvez configurer

Tivoli Workload Scheduler de sorte que le même travail

soit lancé toutes les 30 minutes entre 8 heures 30 et

13 heures 30.

S

statut : Reflète l’état en cours du travail ou du flux de

travaux dans Job Scheduling Console. Le statut de Job

Scheduling Console est commun à Tivoli Workload

Scheduler et à IBM Tivoli Workload Scheduler pour

z/OS. Voir aussi “statut interne”.

statut du travail : Voir “statut”.

statut interne : Reflète l’état en cours des travaux et

flux de travaux dans le moteur du planificateur. Le

statut interne est propre à Tivoli Workload Scheduler.

Voir aussi “statut”.

successeur : Travail ne pouvant pas être lancé avant

que tous les travaux prédécesseurs dont il dépend ne

soient terminés.

T

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 dans la base de données du planificateur

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 et

l’échéance prévues.

travail externe : Travail d’un flux de travaux donné,

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 inter-réseaux (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 : Le traitement de la pré et de la

post-production peut être entièrement automatisé en

planifiant l’exécution du travail Jnextday à la fin de

chaque journée. Un exemple de travail jnextday est

fourni dans racine_TWS\Jnextday. Le travail Jnextday

effectue les opérations suivantes : il configure le

traitement du jour suivant (contenu dans le fichier

Symphony), il imprime des états, il reporte des flux de

travaux non terminés, il arrête et relance le

planificateur.

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 le planificateur pour lancer

les travaux.

utilitaires : Ensemble d’exécutables de ligne de

commande permettant la gestion du planificateur.

V

vue Arborescence : Vue située dans la partie gauche

de Job Scheduling Console et dans laquelle s’affiche le

serveur du planificateur, les groupes de listes par

défaut et les groupes de listes créées par l’utilisateur.


X

X-agent : Voir “agent étendu”.

Glossaire 205

Index

Caractères spéciauxNOM_POSTE_DE_TRAVAIL_MCMAGENT.opts 48

Aaccessibilité xv

agentstandard 45

tolérance aux pannes 45

agent de planificationprésentation 85

agent étendudéfinition de poste de travail 171

présentation 171

référence 171

agent étendu Oracle Applicationsfonctions 45

Attente BDC 127

Bbases de données Peoplesoft 69

bm check status 161, 163

CCA7INTERFACE 146

CA7NAME 146

CA7OPTIONS 146

CA7SPAN(9999) 146

CA7SUBSYSTEM 146

CA7USER 146

CFuser 152

CheckInterval 152

chiffrage des mots de passe 54

chiffrage des mots de passe utilisateur 54

commande de publications xiv

commentaires sur les publications xv

compatibilité 87

COMPLETIONCODE 147

configuration logicielle requise 61, 63

configuration requise pour l’hôte 61

connexion à plusieurs bases de données 69

connexion R/3 96

connexion R/3, dépannage 96

contact par courrier électronique xv

contrôle de l’exécution des travaux 101

conventionstypographiques xv

conventions typographiques xv

création d’un travail 102

création d’un travail dans R/3 101

création d’une dépendance OPENS 78

création de travaux d’agent étendu 77

création du profil d’autorisation 91

Ddébogage 96

DEBUG 147

définition de travaux Oracle Applicationsdans Tivoli Workload Scheduler 49

définition des travaux dans Oracle Applications 49

définition des travaux dans PeopleSoft 58

définition des travaux dans R/3 101

définitions de travaux 77

démarrage 145

dépannage d’une connexion R/3 96

dépendance OPENS 78

dépendance sur des travaux z/OS 155

dépendances de travail z/OS 155

dépendances OPENS, exemple 80

Eenigma 54

étapes, ajout 106

états, travail 111

états de l’application OPC 162

états de l’occurrence pour OPC 162

états des travauxMaestro et Oracle Applications 52

états des travaux pour CA7 160

états des travaux pour JES 159

états des travaux pour OPC 162

états des travaux R/3 111

exécution d’un travail 203

exemple de dépendances OPENS 80

Ffichier d’options 57

fichier d’options, R3OPTIONS 85

fichier de commandes 94

fichier de données 94

fichier mcmagent.optsexemple 54

présentation 53

syntaxe des entrées 53

Fichier script 154

fichiers d’options psagent 65

fichiers de correction et de transfert 94

fonctions 45, 57, 141

Ggénéralités sur l’installation 87

généralités sur le fonctionnement avec CA7 160

généralités sur le fonctionnement avec JES 160

généralités sur le fonctionnement avec l’interface JES 159

généralités sur le fonctionnement avec l’interface OPC 162

Hhôte cible 105


Iinformations relatives au diagnostic 164

installation 149

installation des modules ABAP 91

INTERLINKSUBSYSTEM 147

introduction 57

JJCL pour télécharger la bande 143

JESCMDCHR 147

journal des travaux 127

LLJuser 152

logicielconfiguration requise 45

Mmanuels

voir publications xii, xiv

mappage de statut des travaux 80

MAXWAIT 147

MCMAGENT 47

MCMAGENT.opts 48

MCSSTORAGE 147

messages 167

messages d’erreur 167

messages de la passerelle 167

méthode 85

méthode R3BATCH 85

modification du mot de passe, utilisateur RFC 97

module ABAP, ajout 106

modules ABAP 106

modules ABAP, importation 94

mot de passe de l’utilisateur RFC 97

mot de passe utilisateur R/3, chiffrement 89

multiples bases de données Peoplesoft 69

Nnoms de chemin, notation xvi

noms de répertoire, notation xvi

notationnoms de chemin xvi

typographie xvi

variables d’environnement xvi

OOPCINTERFACE 147

OPCMSGCLASS 148

OPCSUBSYSTEM 148

OPERCMDS 145

option d’attente BDC 97

options psagent 65

Ppasserelle z/OS

téléchargement des fichiers à partir de la bande 143

téléchargement des fichiers à partir du CD-ROM 143

PEERADDRESS 148

pile TCPIP 148

PORT 148

présentation 57

présentation technique 159

profil d’autorisation, création 91

profil RFC 91

programme enigma 89

programme externe 106

programme externe, ajout 106

programmescomposants 47

programmes d’interface 47

psagent 57, 69

publications xii

accès en ligne xiv

commande xiv

publications en ligneaccès xiv

PUTLINE 148

QQLIMIT 148

RR3OPTIONS, fichier 85

Ssécurité 145

sécurité de la console 145

service d’assistance à la clientèlevoir service de support xv

service de supportcontact xv

sortie IEFU84 144

statut des travaux, mappage 80

SUBSYS 148

SVCDUMP 148

syntaxe, fichier mcmagent.opts 53

TTCPIPSTACK 148

TCPNAME 149

TERMINATOR 149

Tivoli Software Information Center xiv

trace 96

travauxétats des travaux 111

travaux, mappage de statut 80

travaux CA7 153

travaux JES 153

travaux OPC 154

travaux Oracle Applicationsdéfinition 49

Uutilisateur RFC 96


Vvariables, notation des xvi

variables d’environnement, notation xvi

variables SYSTSIN 145

version TCP/IP 141

WWTP 149

ZZOSV1R2 149

Index 209

��

SC11-2011-00

IBM Tivoli Workload Scheduler for Applications - Guide d...

Documents

Transcript of IBM Tivoli Workload Scheduler for Applications - Guide d...