vt admin guide

The job scheduling company

Net job scheduler

Visual TOMGuide

d’administration

Visual TOM-Guide d’ administration

2/65 vt-admin-guide.doc Copyright © ABSYSS. All rights reserved13/09/02

SOMMAIRE

1 AVANT-PROPOS ......................................................................................................................... 5

2 PRÉSENTATION DE VISUAL TOM ............................................................................................ 5

3 ARCHITECTURE DE VISUAL TOM ............................................................................................ 63.1 VISUAL TOM SERVEURS (RÉFÉRENTIEL, ORDONNANCEUR).............................................................. 63.2 VISUAL TOM XVISION (VT-XVI = CONCEPTION, PILOTAGE) ............................................................. 63.3 VISUAL TOM CLIENTS (EXÉCUTION DES TÂCHES SUR UNE MACHINE)................................................. 73.4 VISUAL TOM MODULES OPTIONNELS ............................................................................................... 73.5 EXEMPLES D’ARCHITECTURE............................................................................................................ 8

3.5.1 Architecture centralisée ......................................................................................................... 83.5.2 Architecture répartie ou districbuée....................................................................................... 9

4 PRINCIPES DE FONCTIONNEMENT DES PROCESSUS DE VISUAL TOM.......................... 104.1 PROCESSUS DU MODULE SERVEUR................................................................................................. 10

4.1.1 Les processus de gestion de la production ......................................................................... 104.1.2 Les processus d’ordonnancement....................................................................................... 11

4.2 PROCESSUS DU MODULE CLIENT .................................................................................................... 124.3 PROCESSUS DU MODULE INTERFACE GRAPHIQUE............................................................................ 124.4 ARCHITECTURE TECHNIQUE ........................................................................................................... 13

5 ADMINISTRATION DES PROCESSUS DE VISUAL TOM ....................................................... 145.1 ADMINISTRATION SOUS UN SYSTÈME UNIX ...................................................................................... 14

5.1.1 Appel du menu : admins ...................................................................................................... 145.1.2 Appel du menu : adminc ...................................................................................................... 15

5.2 ADMINISTRATION SOUS UN SYSTÈME WINDOWS NT......................................................................... 165.2.1 Processus du Serveur ......................................................................................................... 165.2.2 Processus du Client............................................................................................................. 165.2.3 Processus de l’IHM.............................................................................................................. 16

6 CONFIGURATION DU SERVEUR VISUAL TOM...................................................................... 176.1 LES PORTS DE COMMUNICATION DU SERVEUR VISUAL TOM............................................................. 176.2 LES VARIABLES D’ENVIRONNEMENT DE L’ADMINISTRATEUR DE VISUAL TOM POUR UN SERVEUR UNIX 176.3 LES VARIABLES D’ENVIRONNEMENT SYSTÈME POUR UN SERVEUR WINDOWS.................................... 186.4 LE FICHIER DE CONFIGURATION VTOM.INI ........................................................................................ 196.5 PARAMÉTRAGE DE LA PROCÉDURE DE COMMUNICATION DES MOTEURS AVEC LES CLIENTS. ............... 196.6 PRODUCTION DE TABLEAUX DE BORDS DES JOURNÉES D’EXPLOITATION PRÉCÉDENTES..................... 196.7 PRODUCTION DE TABLEAUX DE BORD DE L’EXPLOITATION DES JOURNÉES D’EXPLOITATION FUTURES :PLANNING PRÉVISIONNEL.......................................................................................................................... 206.8 LA MISE EN PLACE DES TRACES DES MOTEURS................................................................................ 21

6.8.1 Fonctionnement des Traces sous Visual TOM.................................................................... 216.8.2 Options des traces dans vtom.ini......................................................................................... 226.8.3 Visualisation d'un fichier de traces ...................................................................................... 226.8.4 Modification des options d'un fichier de traces.................................................................... 23

7 LES COMMANDES DU SERVEUR VISUAL TOM .................................................................... 247.1 DÉMARRAGE ET ARRÊT DES PROCESSUS DU SERVEUR .................................................................... 24

7.1.1 Démarrage du démon serveur de données......................................................................... 247.1.2 Démarrage du démon serveur de notifications.................................................................... 24

Visual TOM – Guide d’administration

Copyright © ABSYSS. All rights reserved13/09/02

vt-admin-guide.doc 3/65

7.1.3 Démarrage du démon serveur de graphisme...................................................................... 247.1.4 Arrêt d’un processus démon Visual TOM............................................................................ 24

7.2 SAUVEGARDE ET RESTAURATION D’UNE BASE ................................................................................. 257.2.1 Sauvegarde du répertoire de la base de données .............................................................. 257.2.2 Liste le contenu de la base dans un fichier texte................................................................. 257.2.3 Import des objets définis dans un fichier texte .................................................................... 25

7.3 LA GESTION DES MOTEURS ............................................................................................................ 267.3.1 Démarrage d’un moteur sur un Environnement .................................................................. 267.3.2 Arrêt d’un moteur sur un Environnement............................................................................. 267.3.3 Remise à OFF du flag moteur de l’interface graphique pour un environnement ................ 267.3.4 Test de présence d’un moteur actif pour un environnement ............................................... 26

7.4 GESTION DE LA PRODUCTION ......................................................................................................... 277.4.1 Production d’un fichier d’analyse des exécution des traitements........................................ 277.4.2 Purge des statistiques ......................................................................................................... 28

7.5 GESTION DE LA PLANIFICATION....................................................................................................... 297.5.1 Demande de planification d’un travail « à la demande »..................................................... 297.5.2 Forçage à A VENIR des traitements d’un environnement................................................... 297.5.3 Evaluation de planification pour un Traitement ou une Application..................................... 297.5.4 Affichage de la planification d'une application ou d'un traitement pour une période donnée307.5.5 Vérification des blocages de date........................................................................................ 30

8 CONFIGURATION DU CLIENT VISUAL TOM .......................................................................... 318.1 LES PORTS DE COMMUNICATION UTILISÉS PAR UN CLIENT ................................................................ 318.2 LES VARIABLES D’ENVIRONNEMENT DE L’ADMINISTRATEUR DU CLIENT VISUAL TOM SOUS UNIX......... 318.3 LES VARIABLES D’ENVIRONNEMENT SYSTÈME WINDOWS D’UN CLIENT VISUAL TOM .......................... 328.4 LE FICHIER DE CONFIGURATION VTOM.INI ........................................................................................ 338.5 GESTION DES RESSOURCES DE TYPE FICHIER ................................................................................. 338.6 PROCÉDURE DE MISE EN PLACE DE LA GESTION DES UTILISATEURS PAR UN CLIENT VISUAL TOM SOUSWINDOWS NT OU WINDOWS 2000............................................................................................................ 33

8.6.1 Démarrage du service AbsyssBatchManager ..................................................................... 338.6.2 Gestion des utilisateurs par le client Visual TOM................................................................ 34

8.7 LES QUEUE BATCH ......................................................................................................................... 358.7.1 Configuration d’une queue batch sous un client Unix ......................................................... 358.7.2 Configuration d’une queue batch sous un client Windows.................................................. 36

8.8 LES SUBMITTER ............................................................................................................................ 368.9 GESTION DES LOGS ....................................................................................................................... 378.10 GESTION DES PRIORITÉS D’EXÉCUTION DANS LES QUEUE BATCH .................................................. 38

9 LES COMMANDES DU CLIENT VISUAL TOM ........................................................................ 409.1 DÉMARRAGE ET ARRÊT DU DÉMON CLIENT ...................................................................................... 40

9.1.1 Démarrage du démon client ................................................................................................ 409.1.2 Arrêt du démon client........................................................................................................... 40

9.2 STATISTIQUES D’UTILISATION DES FILES D’ATTENTE DU CLIENT ......................................................... 409.3 STATISTIQUES D’UTILISATION DES FILES D’ATTENTE PAR UN UTILISATEUR.......................................... 419.4 LA GESTION DE L’ORDONNANCEMENT ............................................................................................. 41

9.4.1 Valorisation ou consultation d’une ressource ...................................................................... 419.4.2 Ajout d'un élément dans une pile......................................................................................... 419.4.3 Suppression du 1er élément d'une pile ............................................................................... 419.4.4 Suppression de tous les éléments d'une pile ...................................................................... 42

9.5 LA GESTION DU CODE RETOUR ET DES REPRISES DES TRAITEMENTS ................................................ 429.5.1 Envoi du statut de fin d’un traitement au serveur ................................................................ 429.5.2 Notification du label de reprise ............................................................................................ 42

10 CONFIGURATION D’UNE IHM VISUAL TOM .......................................................................... 4410.1 LES PORTS DE COMMUNICATION UTILISÉS PAR UNE IHM .............................................................. 4410.2 LES VARIABLES D’ENVIRONNEMENT DE L’ADMINISTRATEUR DE L’IHM SOUS UNIX.......................... 4410.3 LES VARIABLES D’ENVIRONNEMENT SYSTÈME WINDOWS D’UNE IHM............................................. 4510.4 LE FICHIER DE CONFIGURATION VTOM.INI .................................................................................... 4510.5 MISE EN PLACE DES FONCTIONNALITÉS DOCUMENTATION ET CONSIGNES...................................... 4610.6 MISE EN PLACE DE LA FONCTION IMPRESSION DES LOGS ET DES SCRIPTS ..................................... 47

11 CONCEPTION ET PILOTAGE DE LA PRODUCTION EN MODE COMMANDE ..................... 4811.1 AJOUT OU MODIFICATION D’OBJETS DANS LE DOMAINE D’EXPLOITATION ........................................ 48



11.1.1 liste des objets définis dans le domaine d'exploitation ........................................................ 4811.1.2 Ajout ou modification d'une date d'exploitation.................................................................... 4911.1.3 Suppression d'une date d'exploitation ................................................................................. 4911.1.4 Ajout ou modification d'une ressource................................................................................. 4911.1.5 Ajout ou modification d'un utilisateur ................................................................................... 4911.1.6 Suppression d'un utilisateur................................................................................................. 5011.1.7 Modification du nom d'une machine .................................................................................... 5011.1.8 Ajout d’une queue................................................................................................................ 50

11.2 AJOUT ET MODIFICATION D’UNE APPLICATION .............................................................................. 5111.3 AJOUT OU MODIFICATION D'UN TRAITEMENT................................................................................. 5311.4 SUPPRESSION D'UN TRAITEMENT ................................................................................................ 5511.5 SUPPRESSION D’UN LIEN ............................................................................................................ 55

12 SERVEUR DE BACKUP ............................................................................................................ 5612.1 SYNCHRONISATION DES BASES................................................................................................... 5612.2 MÉCANISME DE BASCULEMENT AUTOMATIQUE ............................................................................. 5612.3 PROCÉDURE DE BASCULEMENT ................................................................................................. 5712.4 RETOUR AU MODE NORMAL ........................................................................................................ 57

13 CONFIGURATION DES MODULES I-SUPERVISER ET WEBDOC ...................................... 5813.1 CONFIGURATION DE LA PASSERELLE I-SERVER............................................................................ 58

13.1.1 Fonctionnement de la passerelle I-server ........................................................................... 5813.1.2 Démarrage et arrêt de la passerelle I-Server ...................................................................... 5813.1.3 Fichier de configuration iserver.ini ...................................................................................... 5913.1.4 Fichier securty.ini ................................................................................................................. 59

13.2 CONFIGURATION DU I-SUPERVISER............................................................................................. 6013.3 CONFIGURATION DU WEBDOC..................................................................................................... 60

14 GUIDE DE L’UTILISATEUR DU SUPPORT STANDARD......................................................... 6214.1 ASSISTANCE TELEPHONIQUE ............................................................................................ 62

14.1.1 Comment nous contacter..................................................................................................... 6214.1.2 Avant d’appeler le support ................................................................................................... 6214.1.3 Informations à fournir pour toute demande d’assistance technique.................................... 6214.1.4 Dans quels cas appeler le support ...................................................................................... 6214.1.5 Conditions d’accès au support............................................................................................. 63

14.2 MAINTENANCE DES SYSTEMES VISUAL TOM .................................................................. 6314.2.1 Sauvegarde et restauration ................................................................................................. 6314.2.2 Environnement de test......................................................................................................... 6314.2.3 Gestion de vos espaces ...................................................................................................... 6414.2.4 Installation de version .......................................................................................................... 64




1 Avant-ProposCe document décrit principalement le fonctionnement, l’administration et l’utilisation en modeadministrateur des modules Visual TOM suivants :

- Serveur Unix- Serveur Windows NT- Serveur de Backup- Client Unix- Client Windows NT- Interface graphique Unix- Interface graphique Windows 95/98/NT- I-server- Isuperviser- Webdoc

2 Présentation de Visual TOMVisual TOM, acronyme de Visual Time Operation Manager, est un automate qui libère lesservices d’exploitation des contraintes liées aux systèmes hétérogènes.

Visual TOM a pour but de libérer le service exploitation des tâches répétitives et descontraintes de manipulations existant entre tous les travaux qui doivent être effectués sur unsite informatique.

Visual TOM permet :

� La mise en œuvre de la production par modélisation graphique (le GPI). Lesschémas d’exploitation sont ainsi définis dynamiquement (objets, couleurs, textes).

� La planification de travaux périodiques ou à la demande, c’est-à-dire non-planifiablesà l’avance.

� La synchronisation de l’ensemble des contraintes (dépendances et événements)entre toutes les entités de votre exploitation (réception de fichiers, événementsutilisateurs, événements extérieurs…).

� Visual TOM prend en charge les actions et le planning à mettre en œuvre en tempsréel.

� La préparation automatique des travaux (Visual TOM calcule les dates et lesvariables d’environnement nécessaires à la préparation des travaux).

� L’administration centralisée par l’intermédiaire d’un pilote qui donne une vuesynthétique de l’état d’avancement de l’exploitation (suivi des tests réalisés et desdécisions prises par le moteur grâce à des comptes-rendus d’activité ou fichiers delogs)

� La gestion centralisée des incidents (détecter les incidents, effectuer les relancesautomatiques et les déplanifications des traitements en fonction de l’exécution desjobs terminés).

� Une simulation de contrôle permettant de prévoir les évolutions et valider les règlesqui ordonnancent la production.

� L’édition de tableaux de bord et d’états de contrôle sur le déroulement del’exploitation (analyser l’activité passée et produire des tableaux prévisionnels).



3 Architecture de Visual TOML’architecture de base de Visual TOM est décomposée en trois familles de modules

3.1 Visual TOM Serveurs (Référentiel, Ordonnanceur).

• Visual TOM Enterprise Server (VT-SES)Visual TOM Enterprise Server est l’élément de base de toute architecture. Il inclut leréférentiel de production, le système de planification et d’ordonnancement, les APIs. Ilpeut être installé indifféremment sur des machines UNIX ou Windows NT.

• Visual TOM Departmental Server (VT-SDS)Serveur secondaire pour gérer l'autonomie des sites répartis ou répartir la chargedans une architecture distribuée. Il nécessite la présence d’un module EnterpriseServer. Il peut être installé indifféremment sur des machines UNIX ou NT.

• Visual TOM Back Up Server (VT-SBU)Serveur relayant automatiquement un serveur Visual TOM en cas d’incident.Ce module est systématiquement mis en place dans les productions nécessitant unniveau de sécurité optimal. Il peut être installé indifféremment sur des machines UNIXou NT.

3.2 Visual TOM XVision (VT-XVI = Conception, Pilotage)

• Visual TOM IHMInterface graphique locale ou déportée sur un LAN ou un Wan connecté à tout type deserveur Visual TOM (y compris les NetClients). Elle permet la modélisation, la gestionet le pilotage de la production. Elle peut être installée sur des plates-formes UNIX etWindows NT/95.

• Visual TOM I-SuperviserEnsemble de fonctionnalités permettant de suivre le déroulement d'une productiongérée par Visual TOM. Cette fonctionnalité a été étudiée pour permettre le suivi de laproduction via un réseau bas débit (RTC, Internet).

• Visual TOM WebDocInterface internet permettant de visualiser les caractéristiques des objets de vosdomaines d’exploitation Visual TOM : ressources, calendriers, environnements,applications, traitements ….




3.3 Visual TOM Clients (Exécution des tâches sur une machine)

• Visual TOM Client (VT-CS)Ce module dépend d’un ou de plusieurs Visual TOM serveur; ils reçoivent les ordresde soumission en provenance de ceux-ci et exécutent les traitements batch. (ex. :Exécution d’une tâche sur une machine). Il peut être installé indifféremment sur desmachines UNIX ou NT, VAX/VMS, Open VMS, AS400, GCOS7 et GCOS8.• Visual TOM Net Client (VT-CN)Client Visual TOM possédant en local son propre référentiel de production luigarantissant l’autonomie de fonctionnement. Il peut être installé indifféremment surUNIX ou NT.

3.4 Visual TOM Modules optionnels

• Visual TOM Xframework (VT-XFR) :Modules d’intégration avec une plate-forme de supervision systèmes et réseaux et/ouapplicative. Dans le cas d’OpenMaster et de PATROL, les modules sont livrés sousforme d'agents packagés et certifiés offrant ainsi une intégration optimale.

• Visual TOM XApplication (VT-XAP) :module d’intégration entre l’application Visual TOM et les grands progiciels du marché(comme SAP R/3, BAAN, JDE, ORACLE APPLICATIONS, …).



3.5 Exemples d’architecture

3.5.1 Architecture centraliséeUn Serveur est responsable de un ou plusieurs clients dépourvus d’intelligence locale. Labase de données est centralisée sur le serveur. Visual TOM XVision est installé sur une desmachines UNIX, Windows du réseau et accède à un Visual TOM Enterprise Server.Cette architecture sera utilisée pour le pilotage Client/Serveur des applications sur le réseaulocal (LAN).

Architecture Centralisée

Mono-site Multi-systèmes VT Client

VT Xvision

VT Enterprise server

VT Client Mainframe

VT Net client

Synchronisation inter-systèmes.Gestion des environnements de test et de production.

VT Backup server




3.5.2 Architecture répartie ou districbuéeLa base modèle est sur le serveur de référence (Visual TOM Enterprise Server).Chaque Visual TOM Departmental Server dispose de sa base locale et est responsable d’unou plusieurs Visual TOM Clients. Cette architecture pourra être utilisée pour la gestion àdistance des serveurs à travers le réseau distant (Wan).

Architecture Répartie

Multi-sites Multi-systèmes

XvisionAdministration

Centrale

Client Mainframe

Net Client

Departmental Serveur

Net client

Client simple

W A N

Enterprise Server

Xvision Administration

Locale

Departmental Serveur

Client simple

Synchronisation inter-sites,Gestion coopérative de la production,Mode commande.



4 Principes de fonctionnement des processusde Visual TOM

Les processus de Visual TOM fonctionnent en mode Client/Serveur basé sur le protocole decommunication TCP/IP.

Le principe de fonctionnement d’un processus en mode Serveur basé sur le protocoleTCP/IP est que lorsque ce type de processus démarre, il établit une liaison interne à unsocket (une ressource TCP), permanente, de la machine locale et se met à l’écoute desrequêtes arrivant sur un port TCP. Cette liaison permanente permet aux clients de ceprocessus de lui envoyer des requêtes. Ce principe de fonctionnement est le même quecelui utilisé par les applications telles que : serveur telnet, serveur ftp, serveur http, ….La syntaxe de la commande d’affichage des connexions et des ports d’écoute est :

netstat –a.Une manière de valider le bon fonctionnement du mode Client/Serveur entre les machinesutilisant des modules de Visual TOM est de tester une ouverture de session telnet, rlogin,ftp, … .

Le principe de fonctionnement d’un processus en mode Client basé sur le protocole TCP/IPest que lorsque ce type de processus est activé, il établit une liaison TCP/IP avec leprocessus Serveur en utilisant l’adresse IP de la machine et le numéro de port du processusServeur.

4.1 Processus du module serveur

Deux types de processus sont présents dans un module serveur :

- Les processus de gestion de objets de la production : la base de données, lesconnections avec les IHM et les mises à jour des ces IHM. Ces processuscommuniquent en mode serveur avec les processus des modules Clients et IHM deVisual TOM

- Les processus d’ordonnancement de la production appelés moteurs. Ces processusfonctionne en mode client avec les modules Clients de Visual TOM

4.1.1 Les processus de gestion de la productionDans chaque module serveur, il y a trois processus : dserver, pserver et gserver.Sous Unix, les exécutables associés à ces processus sont installés dans le répertoireréférencé par la variable $TOM_BIN.Sous Windows, les exécutables associés à ces processus sont installés dans le répertoire<répertoire_installation>\vtom\services.

4.1.1.1 Le processus de gestion de la base de données :dserverLe processus dserver gère la base de données de la production. Lorsqu’il est démarré il esten écoute sur le port tomDB. Pour vérifier que le processus est bien en état d’écoute sur leport tomDBD, il suffit de lancer la commande d’affichage des connexions et ports d’écoute :

netstat –a | grep tomDBd

Le processus dserver reçoit des requêtes des modules :- IHM : demandes de connexion, de modification ou d’ajout d’objets dans la base de

données, ..- Clients : indication de fin de traitement, demande de valorisation d’une ressource, …- Moteurs : demande des caractéristiques des objets d’un environnement, …




4.1.1.2 Le processus des gestion des connections avec les IHM : pserverCe processus utilise le port ntfy, et il reçoit de la part du dserver les notifications demodifications de la base de données et la liste des modules IHM connectées.Pour chaque fenêtre graphique (fenêtres de conception et du pilote) d’une IHM, leprocessus pserver maintient en activité un socket sur le port ntfy.Pour connaître le nombre de fenêtres des IHM ouvertes, il suffit de lancer la commande : netstat –a | grep ntfy

A intervalles de temps réguliers, le processus pserver est interrogé par les modules IHMconnectés au serveur pour prendre connaissance des modifications des contenus desfenêtres graphiques. Les contenus de ces modifications sont fournies par le processusgserver.

4.1.1.3 Le processus de gestion des mises à jour des IHM : gserverCe processus utilise le port gwd ; il reçoit des requêtes de la part des IHM connectées auserveur pour qu’il leur fournisse les modifications des contenus des fenêtres graphiquesouvertes.

4.1.2 Les processus d’ordonnancementA chaque environnement actif est associé un processus tengine appelé moteur.L’exécutable associé aux moteurs est localisé sur le répertoire pointé par la variabled’environnement TOM_BIN.

Pour chaque environnement actif, le moteur ou tengine effectue cycliquement des tâchesd’ordonnancement et de surveillance de l’activité des clients de Visual TOM.

Pour chaque entité d’un environnement (application et traitement) les tâchesd’ordonnancement sont les suivantes :

- l’évaluation de la planification- l’évaluation des contraintes des horaires de début et de fin- l’évaluation des dépendances ou liens- l’évaluation des ressources

Pour chaque traitement en attente ou en cours de soumission le moteur supervise l’activitédu Client Visual TOM qui a la responsabilité de soumettre le traitement.

Un moteur dialogue- d’une part, avec le processus dserver pour lire les caractéristiques de chaque

application et chaque traitement d’un ’environnement- et d’autre part, avec les clients pour soumettre les traitements et surveiller le

déroulement de l’exécution des traitements

Le Moteur utilise le fichier de configuration du serveur pour déterminer la procédure àsuivre dans le cas de non réponse à une demande envoyée à un module client Visual TOM.Un moteur peut envoyer une demande de soumission d’un traitement ou une demande detest d’activité d’un traitement en cours de soumission. Cette procédure est déterminée parles paramètres suivants :- le délai d’attente de la réponse du client ; paramètre delaiWait dont la valeur par défaut

est de 30 secondes- le délai entre deux tentatives de renvoi de la même demande au client ; paramètre

delaiRetrydont la valeur par défaut est de 60 secondes- le nombre de tentatives de renvoi de la même demande au module client ; paramètre

nbWaitRetry dont la valeur par défaut est de 10- le statut futur d’un traitement qui n’a pas pu être soumis ; paramètre StatusFailSubmit

dont la valeur par défaut est ENCOURS



- le statut futur d’un traitement que le client a accepté de soumettre mais n’a pas réponduà la demande de test d’activité du traitement ; paramètre StatusFailExist dont la valeurpar défaut est ENCOURS

4.2 Processus du module client

La communication avec le module client Visual TOM s’effectue à l’aide du processusbdaemon qui fonctionne en mode Serveur sur le port bdaemon.Sous Unix, l’exécutable associé au processus bdeamon se trouve dans le répertoireréférencé par la variable $ABM_BIN.Sous Windows, l’exécutable associé au processus bdeamon se trouve dans le répertoire<répertoire_installation>\abmservices.

Le processus bdaemon reçoit des demandes :- de soumission d’un traitement envoyée par les moteurs- tests d’activité des traitements en cours de soumission- d’éditions de scripts envoyées par les modules IHM- de consultations et de suppressions des log envoyées par les IHM

Les commandes telles que l‘indication de fin d’un traitement (tsend), la valorisation d’uneressource (tval), sont envoyées par d’autres processus que le processus bdaemon. Cesprocessus sont localisées sur la machine cliente et utilisent le port de communicationtomDBd ; d’où la nécessité de déclarer le port tomDBd sur chaque machine cliente VisualTOM.

Sous Unix, le processus bdaemon utilise les droits de root à travers un setuid afin de pouvoirsoumettre les traitement de tous les utilisateurs habilités.

Sous Windows NT, le processus bdaemon est représenté par le serviceAbsyssBatchManager. Ce service est démarré par défaut sous le compte système local; ilpeut être démarré sous le compte d’un utilisateur en paramétrant le fichier de configurationdu client (voir paramétrage de vtom.ini pour un module client).

4.3 Processus du module Interface graphique

Le processus vtom permet de lancer l’interface graphique. Ce processus fonctionne enmode client avec les processus dserver, pserver, gserver et bdaemon ; d’où la nécessité dedéclarer les ports tomDBd, ntfy, gwd et bdaemon sur chaque machine qui possède unmodule IHM de Visual TOM. Sous Unix, l’exécutable associé au processus vtom se trouve dans le répertoire associé à lavariable $TOM_VISUALSous Windows, l’exécutable associé au processus vtom se trouve dans le répertoire<répertoire_installation>\visual.

Le processus vtom utilise :- le port tomDBd pour ouvrir une session avec le serveur Visual TOM- les ports gwd et ntfy pour la mise à jour des fenêtres grahiques : modification ou ajout

d’un objet, mise à jour de la couleur du statut, …- et le port bdaemon pour éditer les scripts, consulter et supprimer les logs




4.4 Architecture technique

Architecture technique

VtomserveurVT-SDSVT-SES

Tcp/ip

dservergserverpserver

VtomclientVT-CS bdaemon

tomDBd

gwd

ntfy

bdaemon

tomDBd

VtomVT-XVISION

gwd

ntfy

tomDBd

Tengine

vtom

Queues batchs

Mr TOM Affichage Scriptbatch et log

Gestion référentiel de production

Gestion graphique

Gestion des événements

Soumission des batchs

Queue kshQueue SAP

VtombackupserveurVT-SBU

dservergserverpserver

tomDBd

gwd

ntfy

Rép

licat

ion

en te

mps

réel



5 Administration des processus de Visual TOM

5.1 Administration sous un système Unix

Deux menus d’administration des processus de Visual TOM sont disponibles dans lerépertoire $TOM_ADMIN : admins et adminc. Ces menus sont accessibles à l’administrateurde Visual TOM.

5.1.1 Appel du menu : admins

Administration de Visual TOM - serveur ${HOST}

1 Etat de Visual TOM - Serveur

2 Demarrage des Serveurs Visual TOM

3 Arret des Serveurs Visual TOM

4 Gestion des Moteurs Visual TOM

5 Gestion du client Visual TOM

6 Visual TOM

7 Sauvegarde de la base de donnees

q Quitter

commande :

Option 1 - Etat de Visual TOMCette option permet de connaître l’état de tous les processus liés à Visual TOM :

- démons présents partie serveur (dserver, pserver et gserver)- démons présents partie cliente (bdaemon)- interfaces graphiques (vtom)

Pour chacun des processus existants sont affichées les informations suivantes:nom du process : utilisateur pid date ou heure baseSi le serveur Visual TOM est actif sur la machine, on trouve l'état des moteurs sur lesdifférents environnements :nom de l’environnement : ON/OFF

Options 2 et 3 - Démarrage et arrêt des serveurs Visual TOMCes fonctions permettent de lancer ou d'arrêter les trois démons de la partie serveur :dserver, gserver et pserver.Les lancements et arrêts des serveurs sont tracés dans le fichier $TOM_TRACES/serveur.

Remarque : Il est possible que le démarrage des processus serveurs de Visual TOMdurent plusieurs minutes. Dans ce cas il faut purger le fichier des statistiques




stats.dbf par la commande tpurge (voir chapitre commandes du serveur) et supprimerles fichiers message.dbf et message.cdx.

Option 4 - Gestion des moteurs Visual TOMCette option appelle le sous menu de Gestion des moteurs. Ce sous-menu n'est accessibleque si les serveurs Visual TOM ont été activés.La liste des environnements est affichée, avec pour chacun l’état du processus tengineassocié (ON ou OFF).Il est possible de gérer tous les moteurs simultanément (entrez start pour les démarrer, stoppour les arrêter) ou individuellement (entrez le nom de l'environnement). Dans ce derniercas, si le moteur est actif sur l'environnement alors il est arrêté, s'il est inactif alors il estdémarré.

Remarques :- L'arrêt et le démarrage des moteurs peuvent prendre quelques secondes.

Lors du réaffichage, il est possible que les statuts n'aient pas encore étéactualisés. Pour rafraîchir la liste des états, appuyez sur la touche Entrée.

- Le cycle du moteur est fixé par défaut à 10 secondes, mais il est possibled'indiquer un autre cycle en suivant le nom de l'environnement d'unevirgule et de la valeur du cycle (ex: start,30 ; production,60 ...).

Option 5 - Gestion du clientIl s’agit d’un appel au menu adminc (cf. paragraphe suivant).

Option 6 - Visual TOMLancement de l’interface graphique. Pour être opérationnelle cette option nécessite que lesserveurs Visual TOM (dserver, gserver et pserver) soient lancés.

Option 7 - Sauvegarde de la base de donnéesCette option permet de sauvegarder la base de données , même si un ou plusieurs moteurssont actifs sur la base.Le répertoire base est copié dans le répertoire $TOM_BACKUP, référence par le jour etl'heure.

5.1.2 Appel du menu : adminc

Administration de Visual TOM - client ${HOST}

1 Etat de Visual TOM - Client

2 Démarrage du Client Visual TOM

3 Arrêt du Client Visual TOM

q Quitter

commande :

Option 1 - Etat du client Visual TOMSi le client est actif, l'état de chacune des queues batch est affiché.

Options 2 et 3 - Démarrage et arrêt du Client Visual TOMCes fonctions permettent de lancer ou d'arrêter le client Visual TOM.




6 Configuration du serveur Visual TOMLa configuration d’un serveur Visual TOM se base sur les définitions de trois types deparamètres :

- les numéros de port des communication des processus dserver, pserver etgserver et bdaemon qui ont pour noms respectifs tomDBd, ntfy, gwd etbdaemon

- les variables d’environnements de l’administrateur de Visual TOM pour unserveur Unix et les variables d’environnement système pour un serveurWindows NT

- les paramètres de configuration définis dans vtom.ini

6.1 Les ports de communication du serveur Visual TOM

Les numéros de ports de communication doivent être définies dans le fichier /etc/servicespour un système Unix ou dans le fichier %windir%\systtem32\drivers\etc\services pour unsystème Windows NT.Pour un système Unix, les définitions des numéros de ports doivent être faites manuellementà la fin de l’installation du serveur.Pour un système Windows, les définitions des numéros de port sont faites automatiquementau cours de la phase d’installation du serveur.Ces numéros de communication doivent avoir des valeurs identiques sur toutes lesmachines utilisant Visual TOM .Les valeurs par défaut de ces ports de communication sont les suivantes :TomDBd 20001Gwd 20002Ntfy 20003Bdaemon 20004

6.2 Les variables d’environnement de l’administrateur de VisualTOM pour un serveur Unix

Les variables d’environnement de l’administrateur du serveur de Visual TOM sont définiesdans le fichier vtom_init.[$SHELL] ; la valeur de la variable $SHELL indique le type de shellassocié à l’administrateur du serveur de Visual TOM : ksh pour korn shell, …Les valeurs de ces variables d’environnement sont positionnées lors de l’ouverture d’unesession par l’administrateur de Visual TOM et elles sont utilisées par les différents processusde Visual TOM ; par exemple la variable $TOM_BASES qui contient le nom du répertoire dela base de données de Visual TOM est utilisée comme argument lors du lancement desprocessus dserver, pserver et gserver.Le fichier vtom_init.[$SHELL] est généré automatiquement dans le sous-répertoire$TOM_ADMIN lors de l’installation du module serveur de Visual TOM, et il est intégré aufichier .profile de l’administrateur de Visual TOM.



Ci dessous un tableau qui donne la liste des variables d’environnement utilisées par lemodule serveur de Visual TOM

GénéralesHOST Nom de la machineTOM_HOME Répertoire d’installation de Visual TOMTOM_ADMIN Répertoire des scripts d’administrationTOM_USER_ADMIN Administrateur Visual TOM

ServeurVTOM Répertoire de la partie serveurTOM_BACKUP Répertoire de backup des basesTOM_BASES Répertoire de la base de données Visual TOMTOM_BIN Répertoire des exécutables serveurTOM_STATS Répertoire des statiquesTOM_TRACES Répertoire des traces moteur et serveursPATH Le path comprend le répertoire vtom/bin

6.3 Les variables d’environnement système pour un serveurWindows

Les variables d'environnement système créées lors de l’installation d’un serveur Visual TOMWindows NT sont les suivantes :

- TOM_BIN = répertoire des exécutables du serveur Visual TOM- TOM_STATS = Répertoire des statiques- TOMSTATS = Répertoire des statiques

Le répertoire contenant la base de données du serveur Visual TOM est défini dans le fichiervtom.ini (voir paragraphe suivant).

La visualisation des valeurs des variables d’environnement système de Windows se fait àl’aide de la fonction Demarrer\Panneau de configuration\Systeme\Environnement.

Le paramétrage d’une variable d’environnement système sous Windows se fait en modifiantla registry ; pour cela il faut exécuter la procédure suivante :

1. lancer l'utilitaire de modification de la registry : \winnt\system32\regedt32.exe

2. Ouvrir la fenêtre HKEY_LOCAL_MACHINE. Aller dans : System, CurrentControlSet, Control, Session Manager, Environment

3. Aller dans le Menu Edit et sélectionner Add Value ou Ajouter une valeur. Value Name = TOM_BIN par exemple, faire OK

String = <nom_répertoiree>, faire OK

Pour que le système d’exploitation prenne en compte la modification de la registry , il estnécessaire de redémarrer la machine. Après le redémarrage, la variable positionnée doitapparaître dans la partie réservée aux variables système (Demarrer\Panneau deconfiguration\Systeme\Environnement).




6.4 Le fichier de configuration vtom.ini

Sous Unix, ce fichier est généré dans répertoire $TOM_ADMIN lors de l’installation duserveur; c’est un fichier caché .vtom.ini.Sous Windows, ce fichier est généré au cours de la phase d’installation du serveur dans lerépertoire %windir%V.Le fichier vtom.ini ne contient pas toutes les options, et toute modification de ce fichiernécessite un arrêt et une relance des processus de Visual TOM pour être prise en compte.La description des différentes options du fichier vtom.ini est abordée dans les chapitres quidécrivent les mises en place des fonctionnalités associées à ces options.La structure de ce fichier est organisée en sections.

6.5 Paramétrage de la procédure de communication des moteursavec les clients.

Les paramètres à mettre en place doivent être intégrées dans la section [general] pour Unixet dans section [GLOBALES] pour Windows.

[GLOBALES]delaiWait:30 Délai d'attente "en secondes" d'une réponse d’un client suite à une demandede soumission d’un traitement ou une demande sur l’état d’exécution d’un traitement

delaiRetry:60 Délai d’attente "en secondes" avant une nouvelle tentative de contact avec unclient qui n’a pas répondu à une demande

nbWaitRetry:10 Nombre de tentatives de contact avec un client avant la modification dustatut d’un traitement

StatusFailSubmit:ENCOURSNouveau statut d'un traitement qui n'a pas pu être soumis à unclient

StatusFailExist:ENCOURS Nouveau statut d'un traitement dont on a perdu le contact

[CS_VERSIONS]RemoteFunctions:0 Inhibition des fonctions d u Planning prévisionnel et Simulation

6.6 Production de tableaux de bords des journées d’exploitationprécédentes

Au cours de son activité quotidienne, les moteurs de Visual TOM alimentent la table de labase de données stats.dbf, appelée fichier des statistiques. Les fonctions d’analyse detraitements permettent de produire les tableaux de bord de l’exploitation réalisée (cf Guideutilisateur Analyse des traitements).Ces tableaux de bord sont générés à partir du fichier des statistiques stats.dbf.Attention : le fichier stats.dbf n’est pas purgé automatiquement par Visual TOM ; ce quipeut provoquer un ralentissement de l’activité des processus du serveur. La commandetpurge permet de purger le fichier des statistiques.

Sous Unix, la fonction d’alimentation du fichier des statistiques est active par défaut, parcontre sous Windows, il faut mettre la valeur du paramètre stats à 1 pour que cette fonctionsoit active ou mettre la valeur 0 pour inhiber cette fonction. Le paramètre stats se trouvedans le fichier vtom.ini.

[GLOBALES]



bases=e:\vtom\bases Répertoire de la base de données de Visual TOMstats=1 Activation de la fonction analyse des traitements

Il est bien sûr possible d’automatiser la production de ces tableaux de bord dans untraitement soumis par Visual TOM en utilisant la commande tstat.Sous UNIX, un traitement d’analyse des traitements est disponible ($TOM_ADMIN/anatrait)et peut devenir votre modèle de traitement des statistiques, qui pourra être exécuté dans uneapplication de votre production.

6.7 Production de tableaux de bord de l’exploitation des journéesd’exploitation futures : Planning prévisionnel

Cette fonction permet de produire les tableaux de bord relatifs à l’exploitation qui devrait sedérouler dans les journées futures. Cette fonction n’est pas disponible sous Windows.La fonction Planning prévisionnel utilise deux ports de communication qui doivent êtredéclarés dans le fichier /etc/services :

PLANPREV_tomDBd 20006/tcp01_tomDBd 20007/tcp

De plus, il faut mettre à jour le fichier vtom.ini :

CS_VERSIONS]RemoteFunctions:0 la valeur 0 inhibe les fonctions Planning prévisionnel et

Simulation

La fonction Planning prévisionnel est accessible à travers l’interface graphique (cf GuideUtilisateur).Il est possible d’automatiser la production de ces tableaux de bord, dans un traitementsoumis par Visual TOM. Sous UNIX, un traitement générant le planning prévisionnel estdisponible dans $TOM_ADMIN/planprev et peut devenir votre modèle de génération de planningprévisionnel. Celui-ci pourra être exécuté dans une application de votre production.




6.8 La mise en place des traces des moteurs

6.8.1 Fonctionnement des Traces sous Visual TOM



6.8.2 Options des traces dans vtom.iniToutes les options de traces sont regroupées dans la section [TRACES].mode = [none, local , remote, both] ( Mode de fonctionnement des traces) - none : pas de traces - local : traces sur fichier local - remote : traces vers machine distante (à venir) - both : local + remote (à venir)

family=[N, S, L, O, A ] ( Définit les familles de traces prises en compte) - (N)etwork : DNS, ports, client/server... - (S)ystem : espace disque, droits... - (L)ogical : logique Visual TOM - (O)ther : Autres .... - (A)ll : toutes les traces. Plusieurs options peuvent être sélectionnées (exemple NS pour Network et System)

level=[C, E , I , D] (Définit les niveau de traces pris en compte) - (C)ritic : Problèmes critiques. - (E)rror : Problèmes corrigibles. - (I)nfo : Informations - (D)ebug : Informations détaillées. Un niveau positionne tous les niveaux supérieurs.

directory= path (Répertoire des traces. La valeur par défaut est le répertoire courant)

filename= nom (Nom du fichier de traces) La valeur par défaut est vtom.trc. Pour les moteurs le nom de l'environnement est utilisé avec l'extension trc.

filesize= taille-du-fichier Taille du fichier de traces en Mo. La valeur par défaut est 10. 0 définie un fichier continu.

Note: Sous UNIX le séparateur = est remplacé par le symbole :

6.8.3 Visualisation d'un fichier de tracesCette fonction s'applique à un fichier de traces donné. Elle permet de : - Visualiser le contenu d'un fichier de traces. - Sélectionner les traces en fonction de leur niveau - Sélectionner les traces en fonction de leur famille - Sélectionner les traces pour un intervalle de temps donné. - Obtenir des statistiques (nombre de traces, nombre d'erreur...)

Syntaxe de la commande : traceview nom-de-fichier [paramètres]

Les paramètres suivants sont optionnels.

-B date début des traces (JJ/MM/AA) -E date fin des traces (JJ/MM/AA) -b heure début des traces (HHMMSS) -e heure fin des traces (HHMMSS) -L niveau des traces (C)ritic (E)rror <I>nfo (D)ebug -F famille des traces (N)etwork (S)ystem (L)ogical (O)ther <A>ll




-s statistiques -S statistiques seules -H Affiche l'aide

6.8.4 Modification des options d'un fichier de traces.Cette fonction s’applique à un fichier de traces donné. Elle permet de : - Modifier la taille d'un fichier de traces. - Modifier les familles de traces devant être écrites. - Modifier les niveaux de traces devant être écrits. - Vider un fichier de traces.

Syntaxe de la commande : traceset nom-de-fichier [paramètres]

Les paramètres suivants sont optionnels :

-L Fixe le niveau des traces enregistrées : (C)ritic (E)rror <I>nfo (D)ebug -F Fixe les Familles des traces enregistrées : (N)etwork (S)ystem (L)ogical (O)ther <A>ll -S Taille du fichier en Mo, 0 pour continu -E Efface le contenu du fichier -H Affiche l'aide

Exemple : traceset vtom.trc -L D -F A -ECette commande efface le fichier vtom.trc et lui dit d'enregistrer toutes les traces(mode debug).



7 Les commandes du serveur Visual TOM Sous Unix :La gestion courante des serveurs Visual TOM sur UNIX par le menu d'administration VisualTOM. Les traces d'arrêt et de relance des serveurs sont tracées dans le fichier servers.logque vous trouverez dans le répertoire de base d'installation $TOM_HOME, vous pouvezaussi appeler les scripts utilisés dans admins : start_servers et stop_servers .La gestion des moteurs se fait par l'option 4 - Gestion des moteurs du menu admins. Ce menufait appel aux scripts start_moteurs et stop_moteurs.

Sous Windows :La gestion courante des serveurs Visual TOM se fait par les fichiers « .bat » du sous-répertoire tools du répertoire vtom.

7.1 Démarrage et arrêt des processus du serveur

7.1.1 Démarrage du démon serveur de donnéesPour UNIX : dserver $TOM_BASESPour NT : voir tom-go.bat

Démarre le démon Visual TOM dserver sur le port de communication TCP/IP tomDBd avec labase de données définie par la variable $TOM_BASES.

7.1.2 Démarrage du démon serveur de notificationsPour UNIX : pserver $TOM_BASESPour NT : voir tom-go.bat

Démarre le démon Visual TOM pserver sur le port de communication TCP/IP ntfy avec labase de données définie par la variable $TOM_BASES.

7.1.3 Démarrage du démon serveur de graphismePour UNIX : gserver $TOM_BASESPour NT : voir tom-go.bat

Démarre le démon Visual TOM gserver sur le port de communication TCP/IP gwd avec labase de données définie par la variable $TOM_BASES.

7.1.4 Arrêt d’un processus démon Visual TOMPour UNIX : dcs tomDBd

dcs ntfydcs gwd

Pour NT : voir stop.bat

Arrête respectivement les démons Visual TOM dserver, pserver, et gserver.




7.2 Sauvegarde et restauration d’une base

On peut sauvegarder une base de production en utilisant :- la commande tbackup- ou la commande texport

7.2.1 Sauvegarde du répertoire de la base de donnéestbackup /target=<path_de_sauvegarde>

Cet outil de sauvegarde de la base de données fonctionne en client/serveur, c'est-à-dire quel'on peut réaliser une sauvegarde de la base depuis une autre machine en positionnant lavariable TOM_REMOTE_SERVER avec le nom de la machine sur laquelle on veut faire lasauvegarde de la base de données Visual TOM.Sous le répertoire défini par le path_de_sauvegarde est créé un répertoire qui correspond à laJJMMAA-HHMMSS sous lequel l'ensemble des fichiers de la base de données estsauvegardé.Pour restaurer une base, Il faut dans un premier temps arrêter tous les process Vtom puiscopier la base sauvegardée puis relancer les services Vtom et l’IHM.

7.2.2 Liste le contenu de la base dans un fichier textetexport > nom_fichier (base)

Options : texport env/app/job > nom_fichier

Liste le contenu de la base de données dans un fichier ASCII (cf. Les tableaux comparatifsdes options des commandes taddjob et taddapp et leurs formats au mode import/export).Il est possible d'exporter tout le contenu de la base (comportement par défaut) ou desélectionner un environnement, une application ou un traitement.Le fichier généré peut être modifié (en tenant compte des règles syntaxiques) avant d'êtreimporté dans une autre base de données (ou dans la même base de données).

7.2.3 Import des objets définis dans un fichier textetimport nom_fichier

La commande timport permet de récupérer des objets exportés d'une autre base de donnéespar la commande texport (cf. Les tableaux comparatifs des options des commandes taddjob ettaddapp et leurs formats au mode import/export).Les objets définis dans le fichier d'export sont créés dans la base de données courante, ous'ils existent déjà, sont mis à jour. Si les applications ou les traitements exportés utilisent desobjets qui n'existent pas dans la base de données courante, ceux-ci sont créés tels quedéfinis dans le fichier d'export.

� Attention, pour les valeurs par défaut, on récupère les valeurs pardéfaut de la nouvelle base de données (environnement ouapplications).



7.3 La gestion des moteurs

7.3.1 Démarrage d’un moteur sur un Environnementtengine nom_environnement [cycle_du_moteur]

Démarre le moteur de Visual TOM pour l’environnement nom_environnement avec un cyclede scrutation de la base d’une valeur fixée par [cycle_du_moteur] en secondes. Le cycle estsur Unix de 10 secondes par défaut, et sur NT de 120 secondes par défaut.Le tengine peut générer des traces sur la sortie écran, il est possible de les rediriger soit versun fichier ( > nom_du_fichier) soit de les supprimer ( > /dev/null)

Message de retour :Affiche les traces définies par le fichier de configuration .vtom.ini

7.3.2 Arrêt d’un moteur sur un Environnementestop nom_environnement

Demande l’arrêt du moteur Visual TOM pour l’environnement [nom_environnement].L’arrêt effectif du moteur n’aura lieu qu’à la fin du cycle courant.

Messages de retour :environnement non trouvel’environnement a été trouvé, mais le moteur n’est pas actifarret du moteur demandel’environnement a été trouvé, mais le moteur n’est pas actif

7.3.3 Remise à OFF du flag moteur de l’interface graphique pour unenvironnement

eclear nom_environnement

Force à OFF le flag signalant un Moteur actif pour l’environnement [nom_environnement](dans le cas où le flag moteur est à ON mais aucun process tengine n’y est associé).

Message de retour possibles :

Aucun moteur ne tourne sur cet environnementl’environnement a été trouvé, mais le moteur n’est pas actifEnvironnement trouve , absence d’un ;moteur signalée dans la basel’environnement a été trouvé, mais le moteur n’est pas actifarrêt du moteur demandel’environnement a été trouvé, mais le moteur n’est pas actif

7.3.4 Test de présence d’un moteur actif pour un environnementepresent nom_environnement

Signale si un Moteur est actif pour l’environnement [nom_environnement]




7.4 Gestion de la production

7.4.1 Production d’un fichier d’analyse des exécution des traitementsPour Unix :

tstat -B date_debut -E date_fin -e environnement [options]

- date_debut ,date_fin : format JJ-MM-AAAA (sous Unix, résultat de la commande `date +%d-%m-%Y`)

- environnement : any pour produire le tableau de statistiques pour tous les environnements

Cette commande permet d'obtenir les état des traitements statués entre date_début et date_finLes fichiers générés (format .tab ou .lis) peuvent être très simplement repris sous Excel.

Pour NT :

Générer le fichier ana.cfg à l’aide du menu AnalyseDans l’invite de commande dos, taper tstat ana.cfg

Liste des Options de la fonction tstat pour UNIX:

-o Ordre Définit les champs à afficher et leur ordred'affichage. Voir plus bas la liste des mots-clés pourl'option -o

-p séparateur depages

Par défaut, deux pages sont séparées par deuxlignes vides. Cette option permet de positionner à laplace un saut de page.

-f <fichier> fichier de sortie La sortie par défaut des résultats de tstat se faitdans deux fichiers dans le répertoire $TOM_STATS.Les noms des fichiers sont générés avec commebase le type de report (ex.: anatrait) plus une chaînedérivée des dates de début et fin. Leur extension est.tab ou .lis selon le format de rapport produit.L'option '-f' permet de transmettre la base du nomdes fichiers de sortie.Si l'option '-f' est utilisée avec l'argument '-' , la sortiese fait sur la sortie standard

-l Format du rapport :listing/tableau

Par défaut, le rapport est produit sous forme detableau sans mise en page, les colonnes étantséparées par des ';' (fichier de sortie avec extension.tab)L'option -l permet une sortie avec une mise en page(fichier d'extension .lis)

-x <sep> séparateur dechamp (modetableau)

Par défaut, le séparateur de champ en mode tableauest le ';'.Cette option permet de définir l'argument commeséparateur.

-v <champs> Ventilation Ajoute au tableau produit par défaut trois tableaux:job volume (nombre de jobs exécutés)incidents volume (nombre d'incidents)temps en minutes (d'exécution)Les lignes représentent les dates (de la date dedébut à la date de fin du tstat), les colonnes



représentent les différents champs des argumentsdéfinis pour la ventilationLes deux champs possibles sont machines etapplications.

-Z NON PLANIFIES inclut les jobs non planifiés-s<id> Simulation Cette option permet l'analyse des traitements de la

simulation <id> (n°du filtre de simulation)� Attention, cette option doit être le premierargument de la commande tstat

-T type de statistiques Cette option est utilisée par les scripts appelésdepuis l'interface graphique (anatrait, planprev etanasimu). Les trois valeurs possibles sont :prévisionnel : planning prévisionnelanalyse : analyse des traitements effectuésanalyse_simulation

Liste des filtres possibles

-m Machines -u user-a Application -c calendrier-F Famille -q queue

�� Attention : Si une option a plusieurs arguments, ils doivent être séparés par desvirgules.

(ex. : -m Jupiter, Uranus)

Liste complète des mots-clés associés à l’option -o pour la fonction tstat:

ix_id Env appl jobname Famillemachine status daytype date_debut date_finDuree CP IO jobtype CalMode Sysdate systime nom_dp valeur_dprelances Queue user periodicite Cyclesituation Rattrapage message ressource

7.4.2 Purge des statistiquesPour UNIX : tpurge nom_environnement date_limite $TOM_BASESPour NT : idemOu (UNIX et NT) : tpurge ‘*’ date limite $TOM_BASES

(purge tous les environnements d’une base)

Purge l’historique Visual TOM situé dans les fichiers stats.dbf et stats.cdx du répertoire$TOM_BASES pour l’environnement [nom_environnement] des informations enregistrées avantla date [date_limite] incluse.

Utilisé sans arguments, tpurge retourne son usage :Usage : tpurge [environnement] [date] <directory>

'environnement' is thé environnement to clean'date' is DD-MM-YY[YY] or DD-month-YY[YY]




� Exemple tpurge Exploitation 12-jan-00 $TOM_BASES

7.5 Gestion de la planification

7.5.1 Demande de planification d’un travail « à la demande »Pour UNIX : tstart environnement application [job] [par=xxx,yyy,…,zzz]Pour NT : idem

Demande l'exécution immédiate (passage au statut EN COURS) d'une application ou d'untraitement (équivalent à l'option Demander dans le pilote graphique)Tout job soumis par Visual TOM peut « demander » (planifier) un Traitement ou uneApplication « à la demande ».

7.5.2 Forçage à A VENIR des traitements d’un environnementPour UNIX : treset nom_environnement nom_date_exploitationPour NT : idem

Force A VENIR tous les jobs de l’Environnement [nom_environnement] qui sont rattachés àla date [nom_date_exploitation] :

RésultatSTATUS :OKEnvironnement inexistantDate inexistanteUn moteur tourne dans cet environnement - Arretez le avant tresetFAILED (une erreur s’est produite)�� Remarque : treset ne fonctionne que si aucun moteur ne tourne sur cetenvironnement.

7.5.3 Evaluation de planification pour un Traitement ou une ApplicationPour UNIX : tform nom_environnement nom_application [nom_Traitement / all]Pour NT : tform nom_environnement nom_application [nom_Traitement] / all

Evalue la planification du Traitement ou de l’Application pour la valeur courante de sa dated’exploitation.Retourne la date rattachée au job ou à l’application, suivi de VRAI si le planning est vérifié cejour ou FAUX si l’application ou le traitement n’est pas planifié.� Exemple 1Vérification du planning de l’application AP01 de l’environnement exploitation :

tform exploitation AP01today is 08-01-97Planning returns :>> VRAI <<(0x1)

L’application AP01 de l’environnement exploitation est planifiée le 8 janvier 1997.

� Exemple 2Vérification du planning de tous les traitements de l’application AP01 de l’environnementexploitation :

tform exploitation AP01 alltoday is for job imp012 08-01-97Planning returns :>> VRAI << (0x1)



today is for job copA02 08-01-97Planning returns :>> VRAI << (0x1)

today is for job supS20 08-01-97Planning returns :

> > FAUX << (0x0)Le job supS20 de l’application AP01 n’est pas planifié le 8 janvier 1997, les autres jobs decette application le sont.

� Exemple 3Vérification du planning du traitement J003 de l’application AP01 de l’environnementexploitation :

tform exploitation AP01 J003today is for job J003 08-01-97Planning returns :>> FAUX << (0x0)

Le job J003 de l’application AP01 n’est pas planifié le 8 janvier 1997.

7.5.4 Affichage de la planification d'une application ou d'un traitement pourune période donnée

tplan /nom=Env/App[/Job] [/debut=JJ-MM-AAAA] [/fin=JJ-MM-AAAA] [/table] outplan /nom=Env/App[/Job] /annee[=AAAA] [/table]

/nom : nom complet de l'objet vtom (App ou Job)/début : Date de début d'analyse/fin : Date de fin d'analyse/année : Analyse annuelle/table : visualisation en mode tableau annuel

7.5.5 Vérification des blocages de datePour UNIX : tchkdate /nom=date [/env=env]Pour NT : idem




8 Configuration du client Visual TOMLe client Visual TOM est chargé de :

- l'exécution des scripts associés aux traitements- l’édition des scripts- et la visualisation et la suppression des logs d’exécution des scripts

Lors de la réception d’une demande de soumission d’un traitement envoyée par un serveurVisual TOM, le client stocke les références du traitement (pid, nom du script, …) dans unefile d’attente appelée queue batch. Et selon le paramétrage de cette queue batch (nombre dejobs simultanés, …), le client décide ou non de lancer l’exécution du script associé autraitement.Le lancement de l’exécution d’un script d’un traitement est effectué par un script shell sousUnix ou un fichier de commandes sous Windows appelé Submitter ; à chaque queue batchest associé un Submitter. Un client peut gérer plusieurs queue batch.

La configuration d’un client Visual TOM se base sur les paramétrages de trois typesd’objets :

- le numéros de port de communication- les variables d’environnements de l’administrateur de Visual TOM pour un

client Unix et les variables d’environnement système pour un clientWindows

- les paramètres de configuration définis dans vtom.ini- les queue batch- les fichiers de commandes ou shells associés aux queue batch

(submiiters)- le fichier de commande ou script shell de gestion des fichiers logs

8.1 Les ports de communication utilisés par un client

En dehors du port bdaemon, un seul port de communication est utilisé par un client VisualTOM. C’est le port tomDBd du processus dserver du module serveur. La valeur par défautde ce port est 20001 et elle est définie dans le fichier /etc/services pour un système Unix oudans le fichier %windir%\systtem32\drivers\etc\services pour un système Windows NT. Cettevaleur est mise à jour automatiquement lors de l’installation d’un client Windows NT, parcontre, sur un système Unix, la mise à jour de la valeur du port tomDBd doit être faitemanuellement.

Pour tester l’état de la communication d’un client vers un serveur, il suffit de positionner lavaleur de la variable d’environnement TOM_REMOTE_SERVER avec le nom de la machinedu serveur Visual et de lire la valeur d’une ressource de Visual TOM avec la commande tval

Tval –name <nom_ressource>

8.2 Les variables d’environnement de l’administrateur du clientVisual TOM sous Unix

Comme pour un serveur Visual TOM Unix, les variables d’environnement de l’administrateurdu client de Visual TOM sont définies dans le fichier vtom_init.[$SHELL] ; la valeur de lavariable $SHELL donne le type de shell associé à l’administrateur du client de Visual TOM :ksh pour korn shell, …Les valeurs de ces variables d’environnement sont positionnées lors de l’ouverture d’unesession par l’administrateur de Visual TOM et elles sont utilisées par le processus bdaemon;par exemple la variable $ABM_LOGS qui contient le nom du répertoire des logs est utilisée àla fin de l’exécution des traitements.



Le fichier vtom_init.[$SHELL] est généré automatiquement dans le répertoire$TOM_ADMIN lors de l’installation du module client Visual TOM, et il est intégré au fichier.profile de l’administrateur de Visual TOM.Dans la cas d’une installation d’un module serveur et d’un module client sur la mêmemachine un seul fichier vtom_ini est généré et il contient les variables d’environnement pourles processus du serveur et du client.

Ci dessous un tableau qui donne la liste des variables d’environnement utilisées par lemodule client de Visual TOM


ClientABM Répertoire d’installation du client ABMABM_BIN Répertoire des exécutablesABM_LOGS Répertoire des logsABM_SPOOL Répertoire de la file d’attente des traitements

8.3 Les variables d’environnement système Windows d’un clientVisual TOM

Lors de l’installation d’un client, les variables d'environnement système suivantes sontcréées :

- ABM_BIN = répertoire des exécutables du client Visual TOM- ABM_LOG = Répertoire des logs

La visualisation des valeurs des variables d’environnement système de Windows se fait àl’aide de la fonction Demarrer\Panneau de configuration\Systeme\Environnement.

Pour modifier l’emplacement des logs, il suffit de modifier une clé de la registry ; pour cela ilfaut exécuter la procédure suivante :

4. lancer l'utilitaire de modification de la registry : \winnt\system32\regedt32.exe

5. Ouvrir la fenêtre HKEY_LOCAL_MACHINE. Aller dans : System, CurrentControlSet, Control, Session Manager, Environment

6. Aller dans le Menu Edit et sélectionner Add Value ou Ajouter une valeur. Value Name = ABM_LOG

String = <nom_répertoire>, faire OK

Pour que le système d’exploitation prenne en compte la modification de la registry , il estnécessaire de redémarrer la machine. Après le redémarrage, la variable positionnée doitapparaître dans la partie réservée aux variables système (Demarrer\Panneau deconfiguration\Systeme\Environnement).



� Sous Windows NT- Menu : Démarrer / Outils d'Administration / Gestion des Utilisateurs- Stratégies- Cocher "Afficher les droits avancés des utilisateurs"- Sélectionner les droits souhaités- Choisir Ajouter

� Sous Windows 2000- Menu : Démarrer / Paramètres / Panneau de configuration- Outils d’administration / Stratégie de sécurité locale- Stratégies Locales / Attribution des droits utilisateurs- Sélectionner les droits souhaités en double cliquant dessus- Choisir Ajouter et ajouter l’administrateur local pour chacun d’eux

Modification du démarrage du service AbsyssBatchManager

A partir de la liste des services sous Windows, sélectionner le service« AbsyssBatchManager », arrêter le service et cliquer avec le bouton droit pour afficher ses« propriétés ». Dans l’onglet « connexion » choisir « Ouvrir une session en tant que » « cecompte » et sélectionner le compte utilisateur défini précédemment.

8.6.2 Gestion des utilisateurs par le client Visual TOML’installation par défaut du client Visual TOM ne gère pas les utilisateurs ; c’est à dire que lavaleur du paramètre utilisateur d’un traitement n’est pas pris en compte par le client VisualTOM. Pour que le client Visual TOM puisse gérer des utilisateurs, il faut déclarer ceux-cidans le fichier vtom.ini.

[bdaemon]users=1 la valeur 0 pour ne pas prendre en compte cette gestion des

utilisateurs[users]user1=<domaine>,<utilisateur>,<mot de passe>user2=<domaine>,<utilisateur>,<mot de passe>...usern=<domaine>,<utilisateur>,<mot de passe>

Remarques:<Domaine> : pour le champ domaine, il est possible d'indiquer le nom du domaine ou lenom d'une machine. Pour indiquer un utilisateur local, mettre un point à la place du champ« domaine ».<Mot de passe> : Les mots de passe devant être affichés en clair, il est préférable deprotéger le fichier vtom.ini (le rendre accessible en lecture uniquement par l'administrateur).

Exemple :

[bdaemon]users=1 0 pour ne pas prendre en compte cette gestion des utilisateurs[users]user1=AbsyssDomain,Lambda,TOM ‘utilisateur du domaine « AbsyssDomain »user2=.,admin,TOM ‘utilisateur local à la machine cliente




8.7 les queue batch

Une queue batch est un objet de Visual TOM qui permet à un client de gérer des filesd’attente de traitements à soumettre. A chaque queue batch est associé un script shell sousUnix ou un fichier de commandes sous Windows qui « en capsule » l’exécution du script d’untraitement. Ce script shell ou fichier de commandes est appelé submitter; par exemple :

- Sous un client Unix, un traitement défini avec la queue batch queue_kshsera soumis par le script shell tom_submit.ksh

- Sous un client Windows NT, un traitement défini avec la queue batchqueue_wnt sera soumis par le fichier de commandesSubmit_queue_wnt.bat

8.7.1 Configuration d’une queue batch sous un client UnixA chaque queue batch correspond un sous-répertoire sous le chemin $ABM/config/queues.Ce sous-répertoire contient les fichiers suivants :

o fichier de configuration de la queue: queue.confo définition des utilisateurs: users

La description du fichier queue.conf est la suivante :N : Nombre maximum de jobs en exécution simultanéeM : Nombre Maximum de jobs en attenteShell : Chemin et nom du shellP : priorité des jobs dans la queue (non utilise sous UNIX)

Exemple :Fichier $ABM/config/queues/prod/queue_config de la queue prod155/user/bin/tcsh4Le queue prod a droit a 15 jobs en exécution simultanée et a 5 jobs enattente.Elle utilisera le shell /user/bin/tcshLa priorité des jobs dans la queue est de 4 (non utilise sous UNIX).

8.7.1.1 Configuration des administrateursUn administrateur est un utilisateur du système d’exploitation qui peut gérer toutes lesqueues et tous les jobs. Il est le seul habilité à arrêt et à démarrer le client. La liste desadministrateurs est définie dans le fichier $ABM_CONFIG/managers

8.7.1.2 Configuration des utilisateursUn utilisateur peut être associé a une ou plusieurs queues batch qu'il peut utiliser. Pourchaque user, on indique :

o le nombre de jobs batch qui peuvent être exécutés en même temps.o le nombre de jobs batch en attente.

La syntaxe de saisie est la suivante : "Nom_Login:Max_Exe:Max_Wait". Cette liste desutilisateurs est définie dans le fichier users.NB : La déclaration du user "any" dans une queue rend accessible cette queue à tout lesusers non déclarés.

Exemple : le fichier $ABM/config/queues/prod/users de la queue prodoracle:1:1L’utilisateur oracle a droit a un seul job en exécution et un seul job en attente dans la queueprod



8.7.2 Configuration d’une queue batch sous un client WindowsLa liste des queue batch est déclarée dans le paramètre ABM_QUEUE de la section[bdaemon] du fichier vtom.ini.A l’installation, il n y a qu’une seule queue qui est déclarée, c’est la queue queue_wnt. Dansle fichier vtom.ini généré à l’installation on trouve :

[bdaemon]ABM_QUEUES :/queue_wnt:1

Si voulez rajouter la queue queue_test, il suffit de rajouter le nom de la queue et le nombrede jobs simultanés autorisés (par exemple 10) sur la ligne ABM_QUEUE.

ABM_QUEUE : /queue_wnt :1 /queue_test :10

Il faut aussi créer un submiiter associé à toute nouvelle queue_batch et arrêter et redémarrerle service AbsyssBatchManager.

8.8 Les Submitter

On rappelle qu’un Submiitter est un script shell ou un fichier de commandes associé à unequueue batch. Le submiiter est exécuté avant la soumission de tout traitement.Sous Unix, les submiiter se trouvent dans le répertoire pointé par la variable $TOM_ADMINsous Ubix, et sous Windows ces submitter se trouvent dans le répertoire pointé par lavariable %ABM_BIN%

Exemple d’exécution d’un traitement ayant pour script job_test et pour queue batchqueue_test :

- le Client Visual TOM Unix déclenchera alors le script tom_submit avecl’extension test soit $TOM_ADMIN/tom_submit.test, en lui transmettant lenom du script à exécuter et une liste de valeurs de variablesd’environnement

- Le client Visual TOM Windows déclenchera alors le fichier de commandes%ABM_BIN%/Submit_queue_test.bat en lui transmettant le nom du scriptà exécuter et une liste de valeurs de variables d’environnementparamètres




Le tableau ci-après liste les variables d'environnement qui sont transmises par le clientVisual TOM au Submiiter :

TOM_REMOTE_SERVER Nom de la machine serveur Visual TOM qui a lancéle traitement.

TOM_JOB_ID Identifiant du traitement dans la base de donnéesTOM_JOB Nom du traitementTOM_APPLICATION Nom de l’applicationTOM_ENVIRONMENT Nom de l’environnementTOM_DATE Nom de la date d’exploitationTOM_DATE_VALUE Valeur de la date d’exploitationTOM_USER Utilisateur exécution du traitementTOM_SCRIPT Nom du script a exécuterTOM_SCRIPT_ARGS Liste des paramètres du script ou jobTOM_QUEUE_PRIORITY Priorité du jobTOM_JOB_RETRY Nombre de reprises effectuéesTOM_JOB_POINT Point de reprise. La valeur de la variable

d’environnement TOM_JOB_POINT est égale à 0par défaut. La modification de la valeur de cettevariable d’environnement s’effectue à l’aide de lacommande tstep (tstep –l <valeur), ce qui permet larelance du script à un step donné

TOM_JOB_EXEC Mode exécutionTOM_FAMILY Nom de la famille statistiqueTOM_QUEUE Nom de la queue batch associéeTOM_LOG_ACTION Action à effectuer sur les fichiers logTOM_HOST Nom de la machine d’exécution

Ces variables d’environnement peuvent être utilisées pour personnaliser le submitter ;Par exemple l’envoi d’un message sur une console lorsqu’un traitement se termine en erreur.

L’exécution d’un Submitter standard se déroule de la manière suivante ::- L’affichage dans la log des valeurs des variables d’environnement- L’exécution du script- La gestion du code retour du traitement, acquittement ou remontée d'erreur à Visual

TOM par la commande tsend- La gestion des fichiers logs en fin de traitement

8.9 Gestion des logs

Tout traitement soumis par le client Visual TOM génère deux fichiers de traces d'exécutionappelée fichiers log. Ces fichiers sont générés sur le sous-répertoire pointé par la variabled’environnement ABM_LOGS pour Unix et ABM_LOG pour Windows et portent l’identifiantsuivant :

- nom_env_nom_appli_nom_ job_ AAMMJJ-HHMMSS.o sortiestandard

- nom_env_nom_appli_nom_ job_ AAMMJJ-HHMMSS.e sortie erreur

Par défaut Visual TOM génère deux fichiers log pour chaque exécution d’un traitement. Il estpossible de modifier ce comportement par l'intermédiaire du menu fin de traitement (voir



définition d’un u traitement). Les options de ce menu sont : impression de la log, suppressionde la log et copie de la log.Les valeurs des actions choisies dans la définition d’un traitement sont transmises parl’intermédiaire de la variable d’environnement TOM_LOG_ACTION, et sont traitées par lescript ou fichier de commandes gestlog situé dans le répertoire $TOM_ADMIN pour Unix ou%ABM_BIN % pour Windows.

Pour modifier le comportement par défaut de la gestion des logs, il suffit de personnaliser lescript ou fichier de commandes gestlog en tenant compte des variables d’environnementsuivantes :

TOM_SCRIPT : nom du scriptTOM_LOG : nom de la logTOM_LOG_ACTION : action à accomplir sur la log

8.10 Gestion des priorités d’exécution dans les queue batch

Cette fonctionnalité est opérationnelle à partir de la version 4.0.

Lors de la soumission d’un traitement à un client Visual TOM, la variable d’environnementTOM_QUEUE_PRIORITY du contexte du traitement contient la valeur de la priorité dutraitement. Cette valeur est comprise entre 0 et 10, et la valeur par défaut de la priorité d’untraitement est de 5.

Paramétrage de la priorité d’un traitement ou définition de la priorité lescaractéristiques d’un traitement :

Les caractéristiques d’un traitement ne possèdent pas de champ priorité.Pour paramétrer la priorité d’un traitement, on utilise le nom de la queue batch du traitementet on procède de la manière suivante en prenant comme exemple un traitement qui a pourqueue batch queue_wnt :

1. Créez la queue batch avec queue_wnt.x ; x est la valeur de la priorité du traitementdans la queue batch queue_wnt

2. Modifiez la définition du traitement en mettant dans le champ queue batch :queue_wnt.x

Paramétrage du fichier vtom.ini du client Visual TOM :

Sous Windows, ajouter le paramètre ABM_QUEUES_PRIORITY_INCREMENT=BY_ONEdans la section [BDAEMON]

[BDAEMON]ABM_QUEUES=/queue_wnt:1ABM_QUEUES_PRIORITY_INCREMENT=BY_ONE

Sous Unix, ajouter le paramètre ABM_QUEUES_PRIORITY_INCREMENT=BY_ONE dans lasection [BDAEMON]

[BDAEMON]ABM_QUEUES_PRIORITY_INCREMENT:BY_ONE

Dans $ABM/config/queues/queue_test/queue.conf mettre à jour le nombre de priorité par

queue_test /* Nom de la queue */3 /* Nombre maximum de job s’exécutant en parallèle */




-1 /* Nombre maximum de job en attente de soumission *//bin/ksh /* Shell utilisé */20 /* Priorité (non utilisé) */

Paramétrage :

ABM_QUEUES_PRIORITY_INCREMENT peut prendre les valeurs :DISABLED � La gestion des priorités est désactiveBY_ONE � Après chaque fin de job, la queue est mise a jour en incrémentant la prioritécourante de 1BY_PRIORITY � Après chaque fin de job, la queue est mise a jour en incrémentant lapriorité courante par la priorité initialeCe paramètre implique qu’un job se trouvant dans la queue depuis longtemps prend unepriorité de plus en plus grande et fini par être soumis.La priorité initiale varie de 0 à 10. Les jobs de priorité 10 passeront en priorité (même devantdes jobs ayant une priorité courante de plus de 10) et leur priorité courante n’est pasincrémentée. Les jobs de priorité 0 passent en dernier et leur priorité courante n’est pasincrémenté.

Une variable TOM_QUEUE_PRIORITY est exportée dans l’environnement d’exécution dujob. Cette variable contient la valeur de la priorité initiale du job dans la queue.

Par défaut, si la queue ne comporte pas l’extension.x, les jobs ont une priorité 5.

Sous Unix :ABM_QUEUES_PRIORITY_TRACE:oui/nonCe paramètre sert de générateur de Traces dans le bdaemon.



9 Les commandes du client Visual TOMLe client Unix Visual TOM se gère par le menu adminc. Les démarrages et arrêts du démonclient sont archivés dans le fichier client.log du répertoire d'installation de Visual TOM. Vouspouvez aussi utiliser les scripts start_client et stop_client.

9.1 Démarrage et arrêt du démon client

Il existe un fichier de configuration des administrateurs du client Unix Visual TOM : le fichier$ABM/config/managers. Seuls les administrateurs définis dans ce fichier peuvent arrêter etlancer le client Unix Visual TOM.

9.1.1 Démarrage du démon clientPour UNIX : $ABM_BIN/bdaemonPour NT : voir tom-go.batPour VMS : call SYS$startup : vtomstartup.com ABM_STOPPour AS400 : Call SYS_AUTO/VPRDO60C

Démarre le démon Visual TOM Absyss Batch Manager utilisant le port TCP/IP bdaemon définidans le fichier /etc/services.Retourne la valeur des variables $ABM_LOGS et $ABM

9.1.2 Arrêt du démon clientPour UNIX : bdown [-a]Pour NT : voir tom-stop.batPour VMS : ABM_STARTPour AS400 : call SYS_AUTO/BDOWN

Stoppe le démon Visual TOM Absyss Batch Manager. L’emploi de l'option -a provoque unarrêt immédiat sans tenir compte des éventuels jobs actifs.Seuls les utilisateurs définis dans le fichier de configuration manager ont la possibilitéd'utiliser cette commande.

9.2 statistiques d’utilisation des files d’attente du client

Pour UNIX : bstatPour NT : commande inexistanteAffiche pour chaque queue batch le nombre de jobs EN ATTENTE, en cours d’exécution...

ExempleQueue User Run MRun Wait Mwait

queue_tcsh 0 10 0 -1Visual TOM 3 -1 0 -1prod 1 5 1 5

L’utilisateur Visual TOM a trois jobs en cours d’exécution (pour un maximum infini), et aucunjob EN ATTENTE.L’utilisateur prod a un jobs en exécution (pour un maximum de trois en exécutionsimultanée), et un job EN ATTENTE (pour un maximum de cinq).




Seuls les utilisateurs définis dans le fichier de configuration manager ont la possibilitéd'utiliser cette commande.

9.3 statistiques d’utilisation des files d’attente par un utilisateur

Pour UNIX : buserPour NT : commande inexistante

Affiche pour l’utilisateur courant le nombre de jobs EN ATTENTE, en cours d’exécution pourl'utilisateur qui lance cette commande.

9.4 La gestion de l’ordonnancement

9.4.1 Valorisation ou consultation d’une ressourceTout traitement soumis par Visual TOM peut consulter ou valoriser une Ressource Globale(définie au niveau du Domaine d’exploitation) ou une Ressource Locale.Pour UNIX et NT :tval -name nom_ressource –info :

Renvoie la valeur de la ressource globale nom_ressourcetval -name nom_ressource -value valeur:

Valorise la ressource globale nom_ressource à la valeur valeurtval [-env nom_environnement ] -name nom_ressource -info

Renvoie la valeur de la ressource nom_ressource locale ànom_environnementtval [-env nom_environnement ] -name nom_ressource -value

Valorise la ressource nom_ressource locale à nom_environnement à lavaleur valeurPour la gestion des ressources de type pile, vous devez utiliser les commandes tpush,tpop et tempty.

9.4.2 Ajout d'un élément dans une pileLa commande tpush permet d'ajouter un élément à la fin d'une ressource de type pile.Syntaxe de la commande :Pour UNIX : tpush -name <nom de la pile> -value <valeur>] [-info]Pour NT : idemValeurs de retour :Si l'argument -value n'est pas transmis, valeur du premier élément de la pile ;Valeur de l’élément inséré si le tpush a réussi (code retour 0) ;Message ‘ressource inconnue‘ si la ressource n’existe pas dans la base (code retour 1) ;Contenu de la pile avec l'option -info.

9.4.3 Suppression du 1er élément d'une pileLa commande tpop permet de supprimer le premier élément d'une ressource de type pile.Syntaxe de la commande :Pour UNIX : tpop -name <nom de la pile>Pour NT : idemValeurs de retour :Message ‘ressource inconnue‘ si la ressource n’existe pas dans la base (code retour 1) ;Code de retour 0 si la mise à jour a réussi.



9.4.4 Suppression de tous les éléments d'une pileLa commande tempty permet de vider le contenu d'une ressource de type pile.Syntaxe de la commande :Pour UNIX : tempty -name <nom de la pile>Pour NT : idemValeurs de retour :Message ‘ressource inconnue‘ si la ressource n’existe pas dans la base (code retour 1) ;Code de retour 0 si la mise à jour a réussi.

9.5 La gestion du code retour et des reprises des traitements

9.5.1 Envoi du statut de fin d’un traitement au serveurTout traitement soumis par Visual TOM doit signaler sa bonne fin. Cette fonction est assuréepar la commande tsend. Tout traitement terminé sans effectuer cette commande seraconsidéré comme EN ERREUR.Cette commande doit donc terminer tous les Traitements soumis par Visual TOM.C’est le script d’en capsulage qui prend en charge cette fonction.

Pour UNIX : tsend [-sY] [-m"Message"]Pour NT : idem

Utilisé sans options, tsend renvoie pour le job courant le statut de fin normale TERMINE (iln'est pas possible d'utiliser tsend pour un traitement autre que le traitement courant).

Option -s (nouveau statut du traitement) :Il est possible d'altérer le comportement par défaut de la commande tsend en utilisant

L'option –sY, où Y est le nouveau statut du job. Les valeurs possibles de Y sont :A A VENIR (Le job est à nouveau éligible pour soumission par Visual TOM)T TERMINEE EN ERREURN NON PLANIFIE

- ��Attention, dans ce cas il ne faut pas que le tsend du submitter soit exécutécar il forcerait à nouveau le statut du job

Option -m (message à remonter dans la colonne info du suivi d'exploitation).

9.5.2 Notification du label de repriseLors de son exécution, un Traitement a la possibilité de signaler l'état interne de sonavancement à Visual TOM, et ainsi de signaler à quel label il doit être redémarré en casd’erreur.

tstep -l valeur_label [-e nom_environnement -a nom_application - j nom_job

Positionne la variable d’environnement du traitement de label de reprise du traitementTOM_JOB_POINT courant (ou du traitement nom_environnement nom_applicationnom_traitement) à la valeur numérique valeur_label.

Pour avoir la possibilité de gérer des labels de reprise alphanumérique (maximum 16caractères), il faut ajouter dans le fichier vtom.ini du serveur,

Pour NT :




[globales]AcceptAlphaStep=1

Pour UNIX[general]AcceptAlphaStep:1



10 Configuration d’une IHM Visual TOML’interface graphique de Visual TOM permet :

- de définir et de modifier les objets de la base de données du serveur- piloter l’exploitation- d’éditer les scripts associés aux traitements- et de visualiser les logs d’exécution des scripts

L’interface graphique communique - avec le serveur en utilisant les ports de communications tomDBd, gwd et ntfy- avec les clients (pour l’édition des scripts et la consultation des logs) en

utilisant le port de communication bdaemon

L’exécutable qui permet de lancer l’interface graphique est vtom ; il est situé dans lerépertoire d’installation de l’interface graphique « visual »

La configuration d’une IHM Visual TOM se base sur les paramétrages de trois typesd’objets :

- les numéro de port des communication du tomDBd, gwd, ntfy et bdaemon

- les variables d’environnements de l’administrateur de Visual TOM pourune IHM Unix et les variables d’environnement système pour une IHMWindows

- les paramètres de configuration définis dans vtom.ini

10.1 Les ports de communication utilisés par une IHM

Les ports de communication utilisés par l’interface graphique sont- tomDB pour communiquer le processus dserver du module serveur ; la

valeur par défaut de ce port est 20001- gwd pour communiquer le processus gwd du module serveur ; la valeur

par défaut de ce port est 20002- ntfy pour communiquer le processus pserver du module serveur ; la valeur

par défaut de ce port est 20003- bdaemon pour communiquer les processus des clients Visual TOM ; la

valeur par défaut de ce port est 20004Ces ports de communication sont déclarés dans le fichier /etc/services pour un système Unixou dans le fichier %windir%\systtem32\drivers\etc\services pour un système Windows. Ladéclaration des ports de communication est faite automatiquement lors de l’installation del’iHM Windows, par contre, sur un système Unix, cette déclaration doit être faitemanuellement.

10.2 Les variables d’environnement de l’administrateur de l’IHMsous Unix

L’administrateur d’une IHM Visual TOM est le même que l’administrateur du serveur Visualcar l’installation d’une IHM sous Unix n’est possible qu’avec une installation d’un moduleserveur.




Les variables d’environnement de l’administrateur de l’IHM de Visual TOM sont définies dansle fichier vtom_init.[$SHELL] ; la valeur de la variable $SHELL donne le type de shell associéà l’administrateur de l’IHMVisual TOM : ksh pour korn shell, …Les valeurs de ces variables d’environnement sont positionnées lors de l’ouverture d’unesession par l’administrateur de Visual TOM

Le fichier vtom_init.[$SHELL] est généré automatiquement dans le sous-répertoire$TOM_ADMIN lors de l’installation du module client Visual TOM, et il est intégré au fichier.profile de l’administrateur de Visual TOM.

Ci dessous un tableau synthétise les variables d’environnement utilisées par le module IHMde Visual TOM


IHM (Interface graphique)TOM_VISUAL Répertoire d’installation de l’interface graphiqueTOM_LP Script associé à l'impression dans l'interface

graphiqueND_PATH Chemin pour les fichiers de configuration Neuron

Data ($TOM_VISUAL)

10.3 Les variables d’environnement système Windows d’une IHM

Une seule variable d'environnement système est créée lors de l’installation d’une IHM VisualTOM Windows, ND_PATH qui contient le nom du répertoire des fichiers de configurationNeuron Data.

10.4 Le fichier de configuration vtom.ini

Sous Unix, ce fichier est généré dans répertoire $TOM_ADMIN lors de l’installation duserveur et de l’IHM; c’est un fichier caché .vtom.ini.Sous Windows, Ce fichier est généré lors de l’installation dans le répertoire %windir%.Dans le cas d’une installation d’un serveur (avec IHM) et d’un client sur la même machine,un seul fichier vtom.ini est généré avec les paramètres du serveur, de l’IHM et du client.

Nota : Toute modification de ce fichier nécessite un arrêt et une relance de l’IHM VisualTOM pour être prise en compte.

Fichier vtom.ini pour Unix

[vtom]documentation:/…/documentation/nom_serveur ou http://webdoc/documentation

[aide] (Aide en ligne au format html)browser:/appli/netscape/netscape

Fichier vtom.ini pour Winows

http://webdoc/documentation



[GLOBALES]pourcent=0 faire apparaitre % dans pilote graphique pour Supra Manager[VTOM]ND_PATH=e:\vtom\visual\documentation=e:\vtom\visual\[aide]browser=c:\Program Files\Microsoft Internet\IEXPLORER.exe

L’utilisation des paramètres documentation et browser sera abordée dans le chapitre « miseen place de la fonctionnalité documentation et consignes.

10.5 Mise en place des fonctionnalités documentation et consignes

Cette fonctionnalité permet l'accès depuis l'IHM Visual TOM à des pages au format HTMLVous pouvez créez pour chaque entité (application et traitement)

- un dossier d’exploitation qui contient tout le descriptif de l'entité à laquelle il est associé

- un dossier qui contient les consignes d'exploitation destinées aux exploitants danslesquelles on trouve les informations relatives au contexte de production telles que lavaleur des paramètres, les consignes de reprise.

L'accès à ces document dossiers se fait par l'intermédiaire d’items dans les menuscontextuels des applications et des traitements :

- En mode définition on accède aux deux types de documents liés à l'entité sélectionnée

- En suivi ou pilotage on accède aux consignes liées à l'entité sélectionnée.

Les documents identifiés par le nom de l'entité associée doivent être générés dans desrépertoire référencé dans le fichier vtom.ini par le paramètre « documentation » de lasection [vtom]:

Nommage d’un document de type documentation pour une application :

env_app_doc.htm; env = nom de l’environnement ; app = nom de l’application

Nommage d’un document de type consignes pour une application :

env_app_recovery.htm ; env = nom de l’environnement ; app = nom de l’application

Nommage d’un document de type documentation pour un traitement :

env_app_job_doc.htm; env = nom de l’environnement ; app = nom de l’application ; job = nom du traitement

Nommage d’un document de type consignes pour un traitement :

env_app_job_recovery.htm; env = nom de l’environnement ; app = nom de l’application ; job = nom du traitement

L’accès à ces dossiers d’exploitation et de consignes se fait à l’aide d’un browser que vousaurez référencé dans le paramètre « browser » de la section [aide] du fichier vtom.ini.




10.6 Mise en place de la fonction impression des logs et des scripts

Sous Unix, il suffit de positionner la variable d’environnement $TOM_LP dansvtom_init.[$Shell] par le chemin absolu d’un script qui permet d’imprimer un fichier aveccomme argument le nom du fichier.

Sous Windows, il faut procéder de la manière suivante :

1. Créez un fichier de commandes TOM_LP.bat Contenant la commande d’impression :print[/d:périphérique] [lecteur:][chemin] "%1" - pour une imprimante localeprint /d:\\nom_serveur\imprimante_partag "%1" - pour une imprimante réseau

2. Créez une variable d'environnement [Panneau de configuration/système/ongletenvironnement]Variable : TOM_LPValeur : [chemin du répertoire]\TOM_LP.bat



11 Conception et Pilotage de la production enmode commande

Ces commandes ne sont disponibles que sur machine serveur Visual TOM.

11.1 Ajout ou modification d’objets dans le domaine d’exploitation

11.1.1 liste des objets définis dans le domaine d'exploitation

tlist - liste les objets du domaine d'exploitation

La commande tlist permet de récupérer en ligne de commande les noms des objets dudomaine d'exploitation.Pour les applications, tlist renvoie aussi le nombre de traitements qu'elle contient, et lenombre de traitements qui sont statués (etats autres que A VENIR ou EN COURS).Utilise sans arguments, tlist renvoie son usage.

Usage : tlist [-v | -h | -d] <nom de l'objet>ou tlist <nom de l'objet> [-v | -h | -d]avec -v : mode 'verbose' -d : mode 'debug' -h : aide

et avec <nom de l'objet> :- jobs : liste des jobs- dates : liste des dates- calendriers : liste des calendriers- utilisateurs : liste des utilisateurs- resources : liste des ressources- machines : liste des machines- tokens : liste des tokens- bloquage : liste des blocages- nodes : liste des nodes- notify 1 : liste des notifications- retenus : liste des jobs retenus- ENERREUR : liste des jobs en erreur- ENCOURS : liste des jobs en cours- AVENIR : liste des jobs a venir- DEPLANIFIE : liste des jobs deplanifies- NONPLANIFIE : liste des jobs non planifies- TERMINE : liste des jobs termines

Exemples :>tlist -v dates>tlist -v jobs>tlist -v app>tlist -v AVENIR>tlist ENCOURS –v




11.1.2 Ajout ou modification d'une date d'exploitation

Pour UNIX : taddate /nom=nom_date_exploitation [ /val=<valeur_date> ] [/typ=<type_date> ]Pour NT : idem

La commande tadddate permet la modification de la valeur d’une date d’exploitation globaleà l’environnement.

Options valeur par défaut arguments/valeur= date système date au format JJ-Mmm-AA[AA] ou JJ-MM-AA[AA]

(ex. : 12-Fev-1997 ou 12-02-97 ou 12-Fev-97 ou 12-02-1997)/type= automatique automatique, constante ou système

11.1.3 Suppression d'une date d'exploitationPour UNIX : tdatedel <id date> KO sur UNIX et NT)

La commande tdatedel permet de supprimer une date d'exploitation par la ligne decommande. L'id de la date à supprimer peut être récupéré par la commande tlist -vdates.

� Attention, la date et toutes ses références seront supprimées. (Vérifiez lesdépendances de la date à l'aide des références croisées). Il est donc préférable desupprimer les dates par l'interface graphique et de n'utiliser tdatedel qu'en cas de nécessité.

11.1.4 Ajout ou modification d'une ressourcePour UNIX : taddres /nom=<nom_ressource> /type=<type_ressource> [ /valeur=<valeurressource> ]Pour NT : idem

La commande taddres permet la création d’une ressource globale de l’environnement.Le nom et le type de la ressource sont obligatoires.Si le nom de la ressource est existant, alors la ressource est modifiée ; sinon elle est créée.�� RemarquesLa ressource de type Date est non opérationnelle pour UNIX et NT.L’option /valeur n’est pas supportée sur UNIX et NT.

11.1.5 Ajout ou modification d'un utilisateurLa commande tadduser permet l’ajout ou la modification d’un utilisateur du domained’exploitation

Pour UNIX : tadduser /nom=<utilisateur> /password=<mot de passe> [options]Pour NT : idem

Liste des options:

/droits=<XXXXXXXXXXXXXXXX>X=0: LectureX=1: Lecture et ecriture (defaut)X=4: Aucunbyte 01 - Date d'exploitationbyte 02 - Calendriersbyte 03 - Periodesbyte 04 - Ressourcesbyte 05 - Utilisateurs



byte 06 - Machinesbyte 07 - Queue batchbyte 08 - Environnementbyte 09 - Jetonbyte 10 - Pilote (Visualiser)byte 11 - Pilote (Agir)byte 12 - Moteur (Demarrer)byte 13 - Moteur (Arreter)byte 14 - Statistique (Lancer)byte 15 - Statistiques Graphiques (Lancer)byte 16 - Simulation (Lancer)Exemple: /droits=1110044111111111

/droits_env=<<nom_env>[XY],...>X= L ou - : Lecture ou inactifY= E ou - : Ecriture ou inactif

/nom_usuel=<Nom usuel>

/comment=<Commentaire>

/print=<Commande d'impression>

11.1.6 Suppression d'un utilisateurPour UNIX : tdeluser /nom=<nom utilisateur>Pour Windows : non supporté

11.1.7 Modification du nom d'une machine

Pour UNIX : tmodmach /nom=<ancien nom> /nouveau=<nouveau nom>

11.1.8 Ajout d’une queuePour Unix : taddqueue <nom_queue>




11.2 Ajout et modification d’une application

Pour UNIX : taddapp /nom=env/app [options]Pour NT : idem

La commande taddapp permet la création d’une application dans un environnement et une application avec toutes ses caractéristiques définies enoptions (voir le tableau des options de la commande taddapp ci-après).Si l'application existe déjà, elle est mise à jour avec les nouvelles valeurs transmises en argument à la commande taddapp. Si des options ne sontpas précisées, l'application conserve ses anciennes valeurs pour ces champs.En mode création, seul le nom de l'application est obligatoire. Pour les champs qui ne sont pas précisés, l’application hérite alors des caractéristiquespar défaut de l’environnement.

Les options de la commande taddapp pour UNIX et NT

Caractéristique Mode commande Mode export valeurs / format défautNom /Nom [job:<env>/<app >] <nom de l’application> obligatoireCommentaire /Comm commentaire <"commentaire"> aucunFamille /Family famille <« famille »> aucuneDate d’exploitation /date Date <nom date d’exploitation> obligatoireType de périodicité /TypePer Type_periodicite periodique | demande periodiqueCyclique /Cyclique cyclique oui | non nonpériode du cycle /Cycle Cycle <heure> 00:00:00Periodicité /Per periodicite journaliere | hebdomadaire | mensuel | annuel journalièreHeure de départ minimum /Hdeb heure_debut <heure> 00:00:00Heure de départ maximum /Hfin heure_fin <heure> illimiteMode d'exécution /Mode mode job | stop | exec | test | simu jobMachine /Machine machine <"machine"> defaut de l'applicationQueue batch /Queue queue <"queue"> defaut de l'applicationUtilisateur /User User <"utilisateur"> defaut de l'applicationne pas déplanifier les successeurs /NonDepl ne_pas_deplanifier oui | non nonHeure de déplanification /Hdepl heure_deplanification <heure> 23:59:59Liste des paramètres /Par parametres < par1 >[,< par2 >,...,< parn >] aucunLien de ... /LienDe Liens_de < env >/< appli >/< job >[< type de lien >]

type de lien : obli | facu | excl | cond | erreaucun



Lien vers ... /LienVers Liens_vers < env >/< appli >/< job >[< type de lien >]type de lien : obli | facu | excl | cond | erre

aucun

Calendrier /Cal calendrier <calendrier> defaut de l’applicationJours de la semaine /Jsem jour_semaine O,C,R,F c * 7 OOOOOOO (O * 7)Jours du mois /Jmois jour_mois O,C,R,F c * 31 C * 31Semaines du mois /Smois semaine_mois O,C,R,F OOOOOMois de l'année /Mannee mois_annee O,C,R,F c * 12 OOOOOOOOOOOOFormule /Formule aucuneRessources /Res ressource aucuneStatut /status status NO (non planfié) | AV (a venir) | EN (en cours) | ER (en

erreur) | TE (terminé) | DE (deplanifié)AV (a venir)

Géométrie /Geom geometrie hxl+y+x h:hauteur, l: largeur, y: ordonnée,x:abscisse

90*16+0+0

couleur bordure /Cbord sfrmclr defaut IHMcouleur fond /Cfond sbgclr defaut IHMcouleur titre /Ctitre sfrblclr defaut IHMCopie de ... /De NON DISPONIBLE < env >/< appli > aucunMise en exploitation /exploit 1 pour la mise en exploitation




11.3 Ajout ou modification d'un traitement

Pour UNIX : taddjob /nom=env/app/job /script=<nom_script> [ options ]Pour NT : idem

La commande taddjob permet la création ou la modification d’un job dans un environnement et une application avec toutes ses caractéristiquesdéfinies en options (voir le tableau des options de la commande taddjob ci-après).En mode création, seuls le nom et le script du traitement sont obligatoires. Le traitement hérite alors de toutes les caractéristiques par défaut del’application.Si le nom du traitement n'existe pas dans l'application et l'environnement références, le traitement est créé, sinon il est mis à jour.

Les options de la commande taddjob pour UNIX et NT

Caractéristique Mode commande Mode export valeurs / format défautNom /Nom [job:<env>/<app>/<job>] <nom du job> obligatoireScript /Script Script <script> obligatoireCommentaire /Comm commentaire <"commentaire"> aucunFamille /Family Famille <« famille »> aucuneType de périodicité /TypePer type_periodicite periodique | demande periodiqueCyclique /Cyclique cyclique oui | non nonpériode du cycle /Cycle cycle <heure> 00:00:00Periodicité /Per periodicite journaliere | hebdomadaire | mensuel | annuel journalièreHeure de départ minimum /Hdeb heure_debut <heure> 00:00:00Heure de départ maximum /Hfin heure_fin <heure> illimiteMode d'exécution /Mode mode stop | exec | test | simu execMachine /Machine machine <"machine"> defaut de l'applicationQueue batch /Queue queue <"queue"> defaut de l'applicationUtilisateur /User user <"utilisateur"> defaut de l'applicationne pas déplanifier les successeurs /NonDepl ne_pas_deplanifier oui | non nonHeure de déplanification /Hdepl heure_deplanification <heure> 23:59:59Blocage de la date d'exploitation /Bloquant bloquer_la_date oui | non ouimettre l'application en erreur /ApplErr mettre_application_en_err

euroui | non oui

Liste des paramètres /Par parametres < par1 >[,< par2 >,...,< parn >] aucun




11.4 Suppression d'un traitement

Pour UNIX : tdeljob -a app –e env -j jobPour NT : idem

La commande tdeljob permet de supprimer un job donné d'une application donnée d'unenvironnement donné.

11.5 Suppression d’un lien

Pour UNIX : tdellink env/app/job (de)env/app/job(vers)Pour NT : idem

La commande tdellink permet de supprimer un lien entre traitements ou applications.L'option "-f" permet de supprimer des liens n'ayant pas d'existence graphique. Attention !!!Ce mode est à utiliser avec précautions, sauvegarde de base et arrêt du moteur.�� RemarqueX-Lien ET et Lien OU non supportés



12 Serveur de backupVisual TOM permet d’avoir un niveau de sécurité supplémentaire grâce au module Back-upServeur. La mise en place d’un serveur de back up Visual TOM permet d’avoir unesauvegarde en temps réel du référentiel (base) grâce la synchronisation des base entre leserveur primaire et le serveur de back up.Deux variables d’environnement doivent être positionnées lors de la mise en place de lasolution du serveur de back up :

� La variable d’environnement TOM_BACKUP_SERVER (nom du serveur de back up)sur le serveur primaire

� La variable d’environnement TOM_PRIMARY_SERVER (nom du serveur primaire)sur le serveur de back up

En cas d'absence de ces deux variables, le fonctionnement de Visual TOM est celui d'unserveur standard.

12.1 Synchronisation des bases

Après le démarrage du serveur primaire, une synchronisation des bases de données doitêtre effectuée avant le démarrage des moteurs et le démarrage du serveur de back up.

Cette synchronisation des bases de données est automatique sous Unix à la condition queles commandes rcp et rlogin soient actives. La fin de la synchronisation des bases estsignalée sous Unix.

Sous NT, la synchronisation des bases se fait manuellement en copiant le contenu durépertoire base du serveur primaire dans le répertoire base du serveur de back up .

En cours de production, le serveur primaire dédouble ses requêtes de mise a jour de labase : à chaque mise a jour de la base de données du serveur primaire, une requête demise a jour est envoyée sur le serveur de back up. Ce mécanisme permet d'obtenir en tempsréel la réplication de la base du serveur primaire sur le serveur de back up.

12.2 Mécanisme de basculement automatique

Le mécanisme de basculement est piloté par le serveur de back up.

Deux cas de basculement :

- Premier cas : le serveur primaire ne répond pas à la requête de test d’activitéenvoyée par le serveur de back up

- Deuxième cas : un client n’arrive pas à envoyer une commande au serveurprimaire

Le serveur primaire ne répond pas à la requête de test d’activité envoyée par leserveur de back upRégulièrement le serveur de back up envoi une requête de test d’activité vers le serveurprimaire. Dans le cas où le serveur primaire ne répond pas à une requête du serveur de




back up, le serveur de back up envoi à chaque client une requête leur demandant de testerla présence du serveur primaire.Si, au moins un client, réussit dans ce test de présence du serveur primaire, le basculementne s’effectue pas. Sinon, la procédure de basculement est déclenchée.

Un client n’arrive pas à envoyer une commande au serveur primaire

Dans ce cas, le client renvoi sa commande vers le serveur de back up. Dès la réception decette commande, le serveur de back up envoi une requête de test d’activité vers le serveurprimaire.

Si le serveur primaire répond au serveur de back up, alors celui-ci renvoi une requêtedemandant au serveur primaire de vérifier sa connexion avec chacun des clients. Si aucundes clients ne répond au serveur primaire, la procédure de basculement est déclenchée.Sinon le basculement ne s’effectue pas.

Si le serveur primaire ne répond pas au serveur de back up, on se retrouve dans ledeuxième cas : voir ci-dessus.

12.3 Procédure de basculement

Le serveur de back up devient actif et les moteurs qui étaient actifs sur le serveur primairedémarrent sur le serveur de back up (attention, selon la configuration de votre machine, ledémarrage des moteurs sur le serveur de back up peut prendre quelques minutes).

Si le serveur de back up reçoit une demande de mise a jour de la part du serveur primaireaprès son basculement, il refuse alors la mise a jour et envoie une requête au serveurprincipal lui demandant de s'arrêter.

12.4 Retour au mode normal

� Arrêt des processus sur le serveur de back up (moteurs, interfaces graphiques etclients).

� Arrêt des processus sur le serveur primaire (moteurs, interfaces graphiques etclients).

� Copie manuelle de la base du serveur de back up sur le serveur primaire.

� Relance du serveur primaire.

� Destruction des fichiers traces sur les clients avec la commande tdelbackup.

� Démarrage des processus des serveurs



13 Configuration des modules I-Superviser etWebdoc

Les modules I-Superviser et webdoc utilisent une passerelle applicative appelée I-Serverafin de communiquer avec les domaines d’exploitation de Visual TOM.

13.1 Configuration de la passerelle I-Server

Le fonctionnement de la passerelle i-server est assuré par un exécutable isever et deuxfichiers de configuration iserver.ini et security.ini.La localisation du processus iserver est définie lors de la phase d’installation (cf guided’installation vt-ins-guide).La localisation du fichier de configuration iserver.ini est indiquée par la variabled’environnement ISERVER_INI (elle est de type système sous Windows).La localisation du fichier security.inii est indiquée par le paramètre file de la section [security]du fichier iserver.ini.

13.1.1 Fonctionnement de la passerelle I-serverLe processus i-server fonctionne en mode :

- Serveur avec les modules i-superviser et weddoc; c’est à dire que lorsque ce processusest démarré, il se met en état d’écoute sur le port de communication TCP listenPort. Lavaleur du port listenPort est renseignée dans le fichier de configuration iserver.ini

- Client avec le module serveur de Visual TOM ;c’est à dire que lorsque ce processus estactif, il utilise l’adresse IP de la machine du serveur Visual TOM et les numéros de portdes processus du module serveur pour adresser une requête vers le serveur VisualTOM. Les valeurs des paramètres qui permettent de communiquer avec un serveurVisual TOM sont renseignées dans la section [domain] du fichier de configurationiserver.ini

La passerelle dispose d'un système d'authentification par un échange de clefs indépendantde celui de Visual TOM. Ce système d’authentification utilise le fichier security.ini

13.1.2 Démarrage et arrêt de la passerelle I-ServerSous Unix :

L’ activation de la passerelle I-server s’effectue en tapant la commande suivante : nohup iserver &

L’arrêt de la passerelle I-server s’effectue en arrêtant le processus i-server par lacommande kill.

Sous Windows :Le processus iserver fonctionne sous le service Windows Absyss iServer. Lacommande d’installation du processus iserver en tant que service Windows est lasuivante :

IServer –install

La commande de désinstallation du processus iserver en tans que service Windowsest la suivante :

IServer –remove



13.2 Configuration du I-Superviser

Le module I-Superviser est écrit en langage Java et s’exécute sous l’environnement JRE 1.3(voir java.sun.com).Le fonctionnement de ce module est assuré par les éléments suivants : isuperviser.jar,isuperviser..ini et isuperviser.exe. La localisation de ces fichiers est lors de la phased’installation (cf Guide d’installation vt-ins-guide).Le module I-superviser dialogue en mode client avec la passerelle iserver. Pour cela, Ilutilise les paramètres host, port et user définis dans le fichier de configuration isuperviser.ini.

Sous Unix, le lancement du module isuperviser s’effectue de la manière suivante : java –jar isuperviser.jar isuperviser.ini

Sous Windows, il suffit de lancer en mode commandes le fichier isuperviser.exe.

Le fichier isuperviser.ini contient les paramètres suivants : [iserver]host = nom de la machine où est installé le module I-Serverport = numéro de port d’écoute du I-server (listenPort dans le fichier

iserver.ini)user = utilisateur par défaut

[interface]fullscreen = 1 si plein écran ou 0 taille normale (la valeur par défaut est 0)

[options]sortByLastExec 1 pour le tri par dernière exécution, 0 sinon. La valeur par défaut est 0

13.3 Configuration du webdoc

Le module WebDoc est un cgi, il faut donc, au préalable installer un serveur http etconfigurer ce serveur http pour qu’il fonctionne avec le cgi webdoc.Le module webdoc possède une fichier de configuration webdoc.ini pointé par la variabled’environnement WEBDOC_INI.Le fichier webdoc.ini possède la structure suivante :

[Iserver] host = nom de la machine où est installé le module I-Server port= numéro de port d’écoute du I-server (listenPort dans le fichier

iserver.ini)

[Parameters] templatePath= Répertoire des fichiers template ; par défaut .\\Template\\ language =langue utilisée : Fr_FR ou En_US wwwBase=base de l’adresse web du webdoc, exemple : http://localhost/webdoc cgiBase=base de l’adresse web du cgi, exemple : http://localhost/cgi-bin/webdoc pageSize=nombre d’éléments affichés dans les requêtes de type liste

Exemple de configuration du serveur http Apache :

Il faut tout d’abord indiquer l’adresse dans le domaine ou juste le nom du serveur Apachedans le fichier index.html situé dans le sous-répertoire www du répertoire d’installation du




module webdoc. Pour cela, il faut mettre à jour des lignes suivantes :

<base href= http://……/><a href=http://……/cgi-bin/webdoc...

Puis il faut déclarer le cgi webdoc dans le fichier de configuration du serveur Apache

# Section Apache VTOM

Alias /WebDoc/ "C:/vtom/WebDoc/www/" Alias /img/ "C:/vtom/WebDoc/www/img/" Alias /css/ "C:/vtom/WebDoc/www/css/"

# Droits du répertoire www de WebDoc <Directory "C:/vtom/WebDoc/www"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all </Directory>

# Droits du répertoire images du WebDoc <Directory "C:/vtom/WebDoc/www/img"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all </Directory>

# Droits du répertoire feuilles de styles du WebDoc <Directory "C:/vtom/WebDoc/www/css"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all</Directory>

et ajouter

ScriptAlias /cgi-bin/ "C:/vtom/WebDoc/cgi-bin/"

Pour lancer le module webdoc, il faut ouvrir un navigateur Web puis ouvrir l'URL du serveurou est installé le WebDoc (ex: http://localhost/), et cliquer sur "Lancer l'outil dedocumentation".

http://localhost/



14 Guide de l’utilisateur du support standard

14.1 ASSISTANCE TELEPHONIQUE

14.1.1 Comment nous contacterAppeler au 01.40.84.89.01 ou [email protected] 8 heures à 19 heuresDu lundi au Vendredi

14.1.2 Avant d’appeler le supportSources d’informations à consulter.

Une abondante documentation technique est mise à votre disposition :- Guides d’utilisation et d’installation en format word et HTML .- Releases notes en word.- FAQS en word et HTML.

Cette documentation est disponible sur :- chaque CD d’installation du produit Visual Tom .- le site internet pour les FAQS sur ‘’ www.absyss.com ‘’ en cliquant sur support,l’utilisateur = nom de votre société et le password = abs ! suivi des 3 premièreslettres de votre société .

14.1.3 Informations à fournir pour toute demande d’assistance technique-Votre nom.-Votre adresse-Votre numéro de téléphone-Votre numéro de fax, le cas échéant-Votre mail-Votre N° d’appel hotline si celui-ci est déjà ouvert-La machine et le système d’exploitation (OS)-La version actuelle de Visual Tom-Une description précise de l’incident

Peut être demandé par le support :

- Envoi de fichiers (fichiers traces, dumps, test cases : un ’ test case’ est un ensembleprogrammes-jeu de données, permettant de reproduire l’incident de façonsystématique ).- Connexion sur le site client via le modem pour une télé-maintenance.

14.1.4 Dans quels cas appeler le supportUne assistance technique peut être sollicitée dans les cas suivants :

- Questions sur l’installation- Identification, résolution ou contournement d’erreurs logicielles (bogues)- Demande d’amélioration de produit .

mailto:[email protected]




Toute question ou tout problème soumis au support donne lieu à la création d’une‘Demande d’Assistance Technique ‘ ( DAT ).

Chaque DAT permet ainsi d’identifier un problème unique et de le suivre jusqu’à sarésolution : un N° d’appel (de référence) est communiqué à la création de la demanded’assistance

Ce numéro est à rappeler lors de toute communication avec le support.

Fermeture d’une DAT :

Un appel est considéré comme clos lorsqu’une réponse, une solution ou uncontournement mutuellement acceptable a été fourni .Un appel fermé peut être réouvert si nécessaire à condition que le problème soit lemême.

Il peut être convenu de fermer un appel après un certain délai, si aucune nouvelle n’aété donnée.

Suivi du DAT :

Une synthèse mensuelle de tous vos appels ouverts est envoyée par courrierélectronique.

14.1.5 Conditions d’accès au supportTout client ayant un contrat de maintenance peut demander une assistancetechnique auprès du support .

Il est souhaitable que les personnes qui appellent le support connaissent le produit etleur environnement opérationnel.

14.2 MAINTENANCE DES SYSTEMES VISUAL TOM

14.2.1 Sauvegarde et restauration Tout client doit impérativement mettre en place des procédures de sauvegarde et derestauration afin d’éviter la perte de données.Nous vous conseillons de faire régulièrement vos sauvegardes et de pratiquer dessimulations de restauration afin de vous assurer des résultats.En supplément des utilitaires de vos OS, vous disposez dans la documentation VisualTom de tous les outils de sauvegarde et de restauration.

Remarque : nous pouvons vous offrir des services, conseils pour le choix etl’élaboration d’une stratégie de sauvegarde adéquate . Ces services fontl’objet d’une tarification.

14.2.2 Environnement de test L’environnement de test constitue un élément essentiel de votre système, il permet :de tester toute modification locale proposée.d’aider à isoler des anomalies par rapport à l’environnement réel.de fournir un cadre pour l’élaboration de scénarii des testsreproductibles.



de tester de nouvelles versions.de tester vos stratégies de sauvegardes et de restauration.

Bien qu’il ne soit évidemment pas toujours possible de reproduire ,dans votreenvironnement de test, les volumes de données ou les transactions de votreenvironnement réel, il n’en demeure pas moins qu’un environnement de test permetde minimiser l’impact des changements sur votre environnement réel.

14.2.3 Gestion de vos espaces

Vous devez vous assurer en permanence que les machines ‘ client ‘ et ‘ serveur‘disposent d’un espace suffisant pour le système de fichiers, notamment pour lesrépertoires de trace.

14.2.4 Installation de version

Avant de réaliser votre installation, nous vous conseillons :- d’obtenir la dernière version- de lire toute la documentation ,nous rappelons qu’elle est disponible sur le CD etinternet.- de vérifier tous les pré-requis logiciels et matériels.- de la valider sur votre environnement de test avant l’installation réelle deproduction.




HOTLINE 01 40 84 89 01

[email protected]

ABSYSS15/17, boulevard du Général de Gaulle

92120 - MONTROUGE - FRANCE33 (0) 1 40 84 89 01

33 (0) 1 40 84 88 40 [email protected]

vt admin guide

Documents

serveur visual tom

visual tom pour

traces sous visual tom

administration des processus

fonctionnement des processus

visual tom xvision vt

visual tom serveurs

visual tom modules optionnels