Vt Admin Guide

Net job scheduler

Visual TOM Guide d’administration

The job scheduling company

Visual TOM-Guide d’ administration

SOMMAIRE

1

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

2

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

3

ARCHITECTURE DE VISUAL TOM ............................................................................. ............................................................................................ ............... 6

3.1 VISUAL TOM SERVEURS (RÉFÉRENTIEL, ORDONNANCEUR). ).............................................................. ............................................................. 6 3.2 VISUAL TOM XVISION (VT-XVI = CONCEPTION, PILOTAGE) ............................................................. 6 3.3 VISUAL TOM CLIENTS (EXÉCUTION DES TÂCHES SUR UNE MACHINE) ................................................. 7 3.4 VISUAL TOM MODULES OPTIONNELS ................................................................................. ............................................................................................... .............. 7 3.5 EXEMPLES D’ARCHITECTURE.................................................................................. ............................................................................................................ .......................... 8 3.5. 3. 5.11 Arc rchi hite tect ctur uree ce cent ntra rallis isée ée .............................................................................. ......................................................................................................... ........................... 8 3.5. 3. 5.22 Arch Ar chititec ectu ture re rép répar artitiee ou dis distr tric icbu buée ée....................................................................................... ....................................................................................... 9 4 PRIN PR INCI CIPE PES S DE FO FONC NCTI TION ONNE NEME MENT NT DES DES PRO PROCE CESS SSUS US DE VIS VISUA UAL L TOM TOM .......................... 10 4.1 PROCESSUS DU MODULE SERVEUR...................................................................................... ................................................................................................. ........... 10 4.1. 4. 1.11 Less proc Le proces essu suss de ge gest stio ionn de la la prod produc uctition on......................................................................... ......................................................................... 10 4.1. 4. 1.22 Less pr Le proc oces essu suss d’ d’or ordo donn nnan ance ceme ment nt....................................................................................... ....................................................................................... 11 4.2 PROCESSUS DU MODULE CLIENT .......................................................................................... .................................................................................................... .......... 12 4.3 PROCESSUS DU MODULE INTERFACE GRAPHIQUE ............................................................................ 12 4.4 ARCHITECTURE TECHNIQUE ................................................................................... ........................................................................................................... ........................ 13 5 ADM DMIN INIS ISTR TRA ATI TION ON DES PRO ROC CES ESSU SUS S DE DE VIS VISUA UAL L TOM TOM ....................................................... 14 5.1 ADMINISTRATION SOUS UN SYSTÈME UNIX ...................................................................................... 14 5.1.1 Appe pell du me mennu : ad admi minns ............................................................................................ ...................................................................................................... .......... 14 5.1.2 Appe pell du me mennu : ad admi minnc ............................................................................................ ...................................................................................................... .......... 15 5.2 ADMINISTRATION SOUS UN SYSTÈME W INDOWS NT NT......................................................................... ......................................................................... 16 5.2.1 Processus du Serveur ................................................................................ ......................................................................................................... ......................... 16 5.2.2 Processus du Client ..................................................................................... ............................................................................................................. ........................ 16 5.2.3 Processus de de l’l’IHM ....................................................................................... .............................................................................................................. ....................... 16 6

CONFIGURA RATI TIO ON DU DU SE SERVEUR VI VISUA UAL L TO TOM...................................................................... 17

6.1 LES PORTS DE COMMUNICATION DU SERVEUR VISUAL TOM TOM............................................................. ............................................................. 17 6.2 LES VARIABLES D’ENVIRONNEMENT DE L’ADMINISTRATEUR DE VISUAL TOM POUR UN SERVEUR UNIX 17 6.3 LES VARIABLES D’ENVIRONNEMENT SYSTÈME POUR UN SERVEUR W INDOWS.................................... 18 6.4 LE FICHIER DE CONFIGURATION VTOM.INI ........................................................................................ 19 6.5 PARAMÉTRAGE DE LA PROCÉDURE DE COMMUNICATION DES MOTEURS AVEC LES CLIENTS. ........... ............... .... 19 6.6 PRODUCTION DE TABLEAUX DE BORDS DES JOURNÉES D’EXPLOITATION PRÉCÉDENTES ........... ................. .......... .... 19 6.7 PRODUCTION DE TABLEAUX TABLEAUX DE BORD DE L’EXPLOITATION DES JOURNÉES D’EXPLOITATION FUTURES : PLANNING PRÉVISIONNEL ...................................................................................... .......................................................................................................................... .................................... 20 6.8 LA MISE EN PLACE DES TRACES DES MOTEURS ................................................................................ 21 6.8. 6. 8.11 Fonct Fon ctio ionn nneme ement nt de dess Tra Trace cess so sous us Vi Visua suall TOM TOM.................................................................... .................................................................... 21 6.8. 6. 8.22 Optition Op onss des des tr trac aces es da dans ns vt vtom om.i.ini ni......................................................................................... ......................................................................................... 22 6.8. 6. 8.33 Visu Vi sual alis isat atio ionn d'u d'unn fich fichie ierr de tr trac aces es ...................................................................................... 22 6.8. 6. 8.44 Modi Mo dific ficat ation ion de dess opti option onss d'un d'un fifichi chier er de tra trace ces. s.................................................................... ................................................................... 23 7

LES COMM MMA ANDES DU SE SERVEUR VIS VISUA UAL L TO TOM .................................................................... 24

7.1 DÉMARRAGE ET ARRÊT DES PROCESSUS DU SERVEUR .................................................................... 24 7.1. 7. 1.11 Déma Dé marr rrag agee du du dém démon on se serv rveu eurr de de don donné nées es......................................................................... ......................................................................... 24 7.1. 7. 1.22 Démar Dé marra rage ge du dém démon on se serv rveu eurr de de noti notififica catition onss.................................................................... 24 2/ 65

vt-admin-guide.doc

Copyright © ABSYSS. All rights reserved reserved

13/09/02

Visual TOM – Guide d’administration 7.1.33 7.1. Déma Dé marr rrag agee du dé démo monn serv serveu eurr de gr grap aphi hism smee...................................................................... 24 7.1. 7. 1.44 Arrê Ar rêtt d’un d’un pro proce cess ssus us dé démo monn Vis Visua uall TOM TOM............................................................................ 24 7.2 SAUVEGARDE ET RESTAURATION D’UNE BASE ................................................................................. 25 7.2. 7. 2.11 Sauve Sa uvega gard rdee du du rép répert ertoi oire re de la ba base se de do donné nnées es.............................................................. .............................................................. 25 7.2. 7. 2.22 List Li stee le le cont conten enuu de la bas basee dan danss un un fichi fichier er te texte xte................................................................. ................................................................. 25 7.2. 7. 2.33 Impor Imp ortt des des ob obje jets ts dé défifinis nis da dans ns un fifich chie ierr texte texte.................................................................... .................................................................... 25 7.3 LA GESTION DES MOTEURS .................................................................................... ............................................................................................................ ........................ 26 7.3. 7. 3.11 Démar Dé marra rage ge d’ d’un un mot moteu eurr sur sur un En Envi viron ronne nemen mentt .................................................................. 26 7.3. 7. 3.22 Arrê Ar rêtt d’un d’un mo mote teur ur su surr un En Envi viro ronn nnem emen entt............................................................................. 26 7.3.3 7.3 .3 Remise Remi se à OFF du du flag flag moteu moteurr de l’in l’inter terfac facee graphiq graphique ue pour pour un un environ environneme nement nt..... ........... ........... ..... 26 7.3. 7. 3.44 Testt de pré Tes prése senc ncee d’un d’un mote moteur ur act actifif pou pourr un envi enviro ronne nnemen mentt............................................... 26 7.4 GESTION DE LA PRODUCTION ................................................................................ ......................................................................................................... ......................... 27 7.4.1 7.4 .1 Produc Pro ductio tionn d’un d’un fich fichier ier d’a d’analy nalyse se des exé exécuti cution on des des trai traiteme tements nts........................................ ........................................ 27 7.4.2 Purg rgee de des st statitisstiques ................................................................................ ......................................................................................................... ......................... 28 ESTION DE LA PLANIFICATION 7 .5 G ....................................................................................................... .............................................................................. ......................... 29 7.5. 7. 5.11 Deman De mande de de de plan planifific icati ation on d’u d’unn trav travai aill « à la dema demand ndee »..................................................... »..................................................... 29 7.5. 7. 5.22 Força For çage ge à A VE VENI NIR R des des trai traite temen ments ts d’u d’unn envi environ ronnem nemen entt................................................... 29 7.5.3 7.5 .3 Evalua Eva luatio tionn de pla planif nifica icatio tionn pour pour un un Trait Traitemen ementt ou ou une une Appl Applica ication tion..................................... ..................................... 29 7.5.4 7.5 .4 Afficha Affi chage ge de la la planifi planificat cation ion d'une d'une appl applicat ication ion ou d'un trai traiteme tement nt pour pour une pério période de donnée donnée30 30 7.5. 7. 5.55 Véri Vé rififica catition on de dess blo bloca cage gess de de dat datee........................................................................................ 30 8 CONFIGURA RATI TIO ON DU CL CLIENT VIS VISUA UAL L TO TOM M .......................................................................... 31 8.1 LES PORTS DE COMMUNICATION UTILISÉS PAR UN CLIENT ................................................................ 31 8.2 LES VARIABLES D’ENVIRONNEMENT DE L’ADMINISTRATEUR DU CLIENT VISUAL TOM SOUS UNIX......... ......... 31 8.3 LES VARIABLES D’ENVIRONNEMENT SYSTÈME W INDOWS D’UN CLIENT VISUAL TOM .......................... 32 8.4 LE FICHIER DE CONFIGURATION VTOM.INI ........................................................................................ 33 8.5 GESTION DES RESSOURCES DE TYPE FICHIER ................................................................................. 33 8.6 PROCÉDURE DE MISE EN PLACE DE LA GESTION DES UTILISATEURS PAR UN CLIENT VISUAL TOM SOUS WINDOWS NT OU WINDOWS 2000 2000.................................................................................... ............................................................................................................ ........................ 33 8.6. 8. 6.11 Démar Dé marra rage ge du se servi rvice ce Ab Absy syssB ssBat atch chMa Manag nager er..................................................................... ..................................................................... 33 8.6. 8. 6.22 Gest Ge stio ionn des des uti utililisa sateu teurs rs pa parr le cli client ent Vi Visu sual al TOM TOM................................................................ ................................................................ 34 8.7 LES QUEUE BATCH ..................................................................................... ......................................................................................................................... .................................... 35 8.7. 8. 7.11 Conf Co nfig igur urati ation on d’u d’une ne que queue ue bat batch ch sou souss un cl clie ient nt Uni Unixx ......................................................... 35 8.7. 8. 7.22 Conf Co nfig igur urati ation on d’une d’une que queue ue batc batchh sous sous un un clie client nt Wind Window owss.................................................. 36 8.8 LES SUBMITTER ........................................................................................ ............................................................................................................................ .................................... 36 8.9 GESTION DES LOGS .................................................................................. ....................................................................................................................... ..................................... 37 8 .1 0 GESTION DES PRIORITÉS D’EXÉCUTION DANS LES QUEUE BATCH .................................................. 38 9

LES COMMA MAN NDES DU CLIENT VI VISUA UAL L TO TOM M ........................................................................ 40

9.1 DÉMARRAGE ET ARRÊT DU DÉMON CLIENT ...................................................................................... 40 9.11.1 Dé 9. Déma marr rrag agee du dé démo monn cl cliien entt ..................................................................................... ................................................................................................ ........... 40 9.1.2 Arrê rêtt du démo monn client................................................................................... ........................................................................................................... ........................ 40 9.2 STATISTIQUES D’UTILISATION DES FILES D’ATTENTE DU CLIENT ......................................................... 40 9.3 STATISTIQUES D’UTILISATION DES FILES D’ATTENTE PAR UN UTILISATEUR .......................................... 41 9.4 LA GESTION DE L ’ORDONNANCEMENT ................................................................................. ............................................................................................. ............ 41 9.4. 9. 4.11 Valo Va lori risa satio tionn ou ou cons consul ulta tatition on d’ d’un unee res resso sour urce ce...................................................................... ...................................................................... 41 9.4. 9. 4.22 Ajou Aj outt d' d'un un él élém émen entt da dans ns un unee pil pilee......................................................................................... 41 9.4. 9. 4.33 Supp Su ppre ress ssio ionn du 1e 1err élém élémen entt d'u d'une ne pi pile le ............................................................................... 41 9.4. 9. 4.44 Suppr Su ppres essi sion on de tou touss les les él éléme ément ntss d'u d'une ne pi pile le...................................................................... ...................................................................... 42 9.5 LA GESTION DU CODE RETOUR ET DES REPRISES DES TRAITEMENTS ................................................ 42 9.5. 9. 5.11 Envo En voii du du sta statu tutt de fin d’ d’un un tr trait aiteme ement nt au ser serve veur ur................................................................ ................................................................ 42 9.5. 9. 5.22 Notitififica No catition on du la labe bell de de re repr pris isee ................................................................................ ............................................................................................ ............ 42 10 CON ONFI FIG GUR URA ATI TION ON D’U ’UNE NE IH IHM M VIS VISUA UAL L TOM TOM .......................................................................... 44 1 0 .1 LES PORTS DE COMMUNICATION UTILISÉS PAR UNE IHM .............................................................. 44 1 0 .2 LES VARIABLES D’ENVIRONNEMENT DE L’ADMINISTRATEUR DE L’IHM SOUS UNIX.......................... 44 1 0 .3 LES VARIABLES D’ENVIRONNEMENT SYSTÈME W INDOWS D’UNE IHM IHM............................................. ............................................. 45 1 0 .4 LE FICHIER DE CONFIGURATION VTOM.INI .................................................................................... 45 1 0 .5 MISE EN PLACE DES FONCTIONNALITÉS DOCUMENTATION ET CONSIGNES ...................................... 46 1 0 .6 MISE EN PLACE DE LA FONCTION IMPRESSION DES LOGS ET DES SCRIPTS ..................................... 47 11 CONCEP CONC EPTIO TION N ET ET PILO PILOTA TAGE GE DE DE LA PRO PRODU DUCTI CTION ON EN EN MODE MODE COM COMMA MAND NDE E ........... ................. .......... .... 48 1 1 .1

AJOUT OU MODIFICATION D’OBJETS DANS LE DOMAINE D ’EXPLOITATION ........................................ 48

reserved Copyright © ABSYSS. All rights reserved 13/09/02

vt-admin-guide.doc

65 3/ 65

Visual TOM-Guide d’ administration 11.1.1 lis 11.1.1 liste te des des objets objets défini définiss dans dans le domain domainee d'explo d'exploita itatio tionn ........................................................ 48 11.1.2 11. 1.2 Ajo Ajout ut ou ou modifi modificat cation ion d'un d'unee date date d'expl d'exploit oitati ation on.................................................................... .................................................................... 49 11.1.3 11. 1.3 Sup Suppre pressi ssion on d'u d'une ne date d'e d'explo xploita itatio tionn ................................................................................. 49 11.1 11 .1.4 .4 Aj Ajou outt ou modifi modifica catition on d'une d'une res resso sour urce ce................................................................................. ................................................................................. 49 11.1.5 11. 1.5 Ajo Ajout ut ou modi modifica ficatio tionn d'u d'unn uti utilis lisateu ateurr ................................................................................... 49 11.1 11 .1.6 .6 Su Suppr ppres essi sion on d' d'un un uti utililisa sate teur ur...................................................................................... ................................................................................................. ........... 50 11.1 11 .1.7 .7 Mo Modi dific ficat ation ion du nom nom d'u d'une ne mac machi hine ne.................................................................................... .................................................................................... 50 11..1. 11 1.88 Ajo jout ut d’ d’un unee qu queu euee ......................................................................................... ................................................................................................................ ....................... 50 1 1 .2 AJOUT ET MODIFICATION D’UNE APPLICATION .............................................................................. 51 1 1 .3 AJOUT OU MODIFICATION D'UN TRAITEMENT................................................................................. 53 1 1 .4 SUPPRESSION D'UN TRAITEMENT ..................................................................................... ................................................................................................ ........... 55 1 1 .5 SUPPRESSION D’UN LIEN .................................................................................... ............................................................................................................ ........................ 55 12 SERVEUR DE BACKUP .................................................................................... ............................................................................................................ ........................ 56 1 2 .1 1 2 .2 1 2 .3 1 2 .4 13

SYNCHRONISATION DES BASES ........................................................................................ ................................................................................................... ........... 56 MÉCANISME DE BASCULEMENT AUTOMATIQUE ............................................................................. 56 PROCÉDURE DE BASCULEMENT ................................................................................................. ........... 57 BASCULEMENT ...................................................................................... RETOUR AU MODE NORMAL ............................................................................... ........................................................................................................ ......................... 57 CONF CO NFIG IGURA URATIO TION N DE DES S MOD MODUL ULES ES I-SUPE I-SUPERV RVIS ISER ER ET WE WEBD BDOC OC ...................................... 58

1 3 .1 CONFIGURATION DE LA PASSERELLE I-SERVER............................................................................ 58 13.1.1 13. 1.1 Fonc Fonctio tionne nnement ment de la pas passer serelle elle I-s I-serv erver er ........................................................................... 58 13.1.2 13. 1.2 Déma Démarrag rragee et arrê arrêtt de la passe passerel relle le I-Se I-Server rver...................................................................... ...................................................................... 58 13.1 13 .1.3 .3 Fi Fich chie ierr de con confifigu gura ratio tionn ise iserv rver. er.in inii ...................................................................................... 59 13.1 13 .1.4 .4 Fi Fich chie ierr se secu curt rty. y.in inii .......................................................................................... ................................................................................................................. ....................... 59 1 3 .2 CONFIGURATION DU I-SUPERVISER................................................................................. ............................................................................................. ............ 60 1 3 .3 CONFIGURATION DU WEBDOC ........................................................................................... ..................................................................................................... .......... 60 14 GUID GU IDE E DE L’ L’UT UTIL ILIS ISA ATE TEUR UR DU SUP SUPPO PORT RT STA STAND NDA ARD RD......................................................... ......................................................... 62 1 4 .1 ASSIS ISTA TAN NCE TE TELE LEP PHONIQUE ................................................................................ ............................................................................................ ............ 62 14.1 14 .1.1 .1 Co Comm mmen entt nous nous con conta tact cter er........................................................................................... ..................................................................................................... .......... 62 14.1 14 .1.2 .2 Av Avan antt d’a d’appe ppele lerr le le sup suppo port rt........................................................................................ ................................................................................................... ........... 62 14.1.3 14. 1.3 Inf Informa ormatio tions ns à fournir fournir pour pour toute demand demandee d’assis d’assistan tance ce techniqu techniquee.................................... 62 14.1 14 .1.4 .4 Da Dans ns que quels ls cas cas app appele elerr le sup suppo port rt ...................................................................................... 62 14.1 14 .1.5 .5 Co Condi nditition onss d’ac d’accè cèss au au supp support ort................................................................................. ............................................................................................. ............ 63 14.2 14 .2 MAIN MA INTE TENA NANC NCE E DE DES S SY SYST STEM EMES ES VI VISU SUAL AL TO TOM M .................................................................. 63 14.2 14 .2.1 .1 Sa Sauve uvega gard rdee et res restau taurat ratio ionn ...................................................................................... ................................................................................................. ........... 63 14.2 14 .2.2 .2 En Envi viro ronn nnem emen entt de de tes testt ................................................................................ ......................................................................................................... ......................... 63 14.2 14 .2.3 .3 Ge Gest stio ionn de de vos vos es espa pace cess ............................................................................................ ...................................................................................................... .......... 64 14.2 14 .2.4 .4 In Inst stal alla latition on de de vers versio ionn .................................................................................. .......................................................................................................... ........................ 64

4/ 65

vt-admin-guide.doc


13/09/02

Visual TOM – Guide d’administration

1 Avant-Propos Ce document décrit principalement principalement le fonctionnement, fonctionnement, l’administration et l’utilisation en mode administrateur 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 TOM Visual TOM, acronyme de Visual Time Operation Manager , est un automate qui libère les services d’exploitation des contraintes liées aux systèmes hétérogènes. Visual TOM a pour but de libérer le service exploitation exploitation des tâches répétitives et des contraintes de manipulations existant entre tous les travaux qui doivent être effectués sur un site informatique. informatique. Visual TOM permet : 

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



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énements utilisateurs, événements extérieurs…).



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



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



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



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



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



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


vt-admin-guide.doc

65 5/ 65


3 Architecture Architectu re de Visual TOM L’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 le référentiel de production, le système de planification et d’ordonnancement, les APIs. I l peut être installé indifféremment sur des machines UNIX ou Windows NT.

•

Visual TOM Departmental Departmental Server (VT-SDS) Serveur secondaire pour gérer l'autonomie des sites répartis ou répartir la charge dans une architecture distribuée. Il nécessite la présence d’un module Enterprise Server. 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 systématiquement mis en place dans les productions nécessitant un niveau de sécurité optimal. Il peut être installé indifféremment sur des machines UNIX ou NT. •

3.2 Visual TOM XVision (VT-XVI = Conception, Pilotage) Visual TOM IHM Interface graphique locale locale ou déportée sur un LAN ou un Wan connecté à tout type de serveur Visual TOM (y compris les NetClients). Elle permet la modélisation, la gestion et le pilotage de la production. Elle peut être installée sur des plates-formes UNIX et Windows NT/95. •

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

•

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

6/ 65

vt-admin-guide.doc


13/09/02


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 ordres de 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 des machines UNIX ou NT, VAX/VMS, Open VMS, AS400, GCOS7 GCO S7 et GCOS8. Visual TOM Net Client (VT-CN) Client Visual TOM possédant en local son propre référentiel de production lui garantissant l’autonomie de fonctionneme f onctionnement. nt. Il peut être installé indifféremment indifféremment sur UNIX 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/ou applicative. applicative. Dans le cas d’OpenMaster et de PATROL, les modules sont livrés sous forme 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, …). •


vt-admin-guide.doc

65 7/ 65


3.5 Exemples d’architecture 3.5.1 Architecture centralisée Un Serveur est responsable de un ou plusieurs clients dépourvus d’intelligence locale. La base de données est centralisée sur le serveur. Visual TOM XVision est installé sur une des machines 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 applications sur le réseau local (LAN).

Architecture Centralisée Mono-site Multi-systèmes

VT Enterprise server VT Backup server

VT Client

VT Net client

VT Xvision

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

8/ 65

vt-admin-guide.doc


13/09/02


3.5.2 Architecture répartie ou districbuée La 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’un ou 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 Departmental Serveur

Multi-sites Multi-systèmes

Client simple

Client simple Net Client Enterprise Server

WAN

Departmental Serveur

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


Xvision Administration Locale

Net client

Client Mainframe

vt-admin-guide.doc

65 9/ 65


4 Principes de fonctionnement des processus de Visual TOM Les processus de Visual TOM fonctionnent en mode Client/Serveur basé sur le protocole de communication TCP/IP. Le principe de fonctionnement d’un processus en mode Serveur basé sur le protocole TCP/IP TCP/I P est que lorsque ce type de processus démarre, il établit établit une liaison interne à un socket (une ressource TCP), permanente, permanente, de la machine locale et se met met à l’écoute des requêtes arrivant sur un port TCP. Cette liaison permanente permanente permet aux clients de ce processus de lui envoyer des requêtes. Ce principe de fonctionnement fonctionnement est le même que celui 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 machines utilisant des modules de Visual Visual TOM est de tester une ouverture de session session telnet, rlogin, ftp, … . Le principe de fonctionnement d’un processus en mode Client basé sur le protocole TCP/IP est que lorsque ce type de processus est activé, activé, il établit une liaison TCP/IP avec le processus Serveur en utilisant l’adresse IP de la machine et le numéro de port du processus Serveur.

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, les connections avec avec les IHM et les mises à jour jour des ces IHM. Ces processus processus communiquent en mode serveur avec les processus des modules Clients et IHM de Visual TOM

-

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

4.1.1 Les processus de gestion de la production Dans 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épertoire référencé par la variable $TOM_BIN. Sous Windows, les exécutables exécutables associés à ces processus sont sont installés dans le répertoire \vtom\services. 4.1.1.1 Le processus de de gestion de la base base de données :dserver :dserver

Le processus dserver gère la base de données de la production. Lorsqu’il est démarré il est en écoute sur le port tomDB. Pour vérifier que le processus est bien en état d’écoute sur le port tomDBD, il suffit de lancer la commande d’affichage des connexions 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, .. f in de traitement, demande de valorisation d’une ressource, … - Clients : indication de fin - Moteurs : demande des caractéristiques des objets d’un environnement, … 10/ 65

vt-admin-guide.doc


13/09/02


4.1.1.2 Le processus des des gestion des connections connections avec les IHM : pserver

Ce processus utilise le port ntfy, et il reçoit de la part du dserver les notifications notifications de modifications 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, le processus pserver maintient 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 IHM connectés au serveur pour prendre connaissance des modifications des contenus des fenêtres graphiques. Les contenus de ces modifications sont fournies par le processus gserver. 4.1.1.3 Le processus de gestion gestion des mises à jour des IHM : gserver gserver

Ce processus utilise le port gwd ; il reçoit des requêtes de la part des IHM connectées au serveur pour qu’il leur fournisse f ournisse les modifications des contenus des fenêtres graphiques ouvertes.

4.1.2 Les processus d’ordonnancement A 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 variable d’environnement d’environnement TOM_BIN. Pour chaque environnement environnement actif, le moteur ou tengine tengine effectue cycliquement cycliquement des tâches d’ordonnancement d’ordonnan cement et de surveillance de l’activité l’activit é des clients de Visual TOM. Pour chaque entité d’un environnement (application et traitement) les tâches d’ordonnancement d’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é responsabilit é de soumettre soumettr e le traitement. traitemen t. Un moteur dialogue - d’une part, avec le processus dserver pour lire les caractéristiques de chaque application et chaque traitement d’un ’environnement ’environnement - et d’autre part, avec les clients pour soumettre les traitements et surveiller le déroulement déroulement de l’exécution des traitements Le Moteur utilise utilise le fichier de configuration configuration du serveur serveur pour déterminer déterminer la procédure 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 de test d’activité d’un traitement en cours de soumission. Cette procédure est déterminée par les 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 reserved Copyright © ABSYSS. All rights reserved 13/09/02

vt-admin-guide.doc

65 11/ 65

Visual TOM-Guide d’ administration -

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

4.2 Processus du module client La communication avec le module client Visual TOM s’effectue à l’aide du processus processus bdaemon qui fonctionne en mode Serveur sur le port bdaemon. Sous Unix, l’exécutable associé au processus bdeamon se trouve dans le répertoire référencé par la variable $ABM_BIN. Sous Windows, l’exécutable associé au processus bdeamon se trouve dans le répertoire \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 I HM - 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 l‘indication de fin d’un traitement (tsend), la valorisation valorisation d’une ressource (tval), (tval), sont envoyées par d’autres processus processus que le processus processus bdaemon. bdaemon. Ces processus sont localisées sur la machine cliente et utilisent le port de communication communication tomDBd ; d’où la nécessité de déclarer le port tomDBd sur chaque machine cliente Visual TOM. Sous Unix, le processus bdaemon utilise les droits de root à travers un setuid afin de pouvoir soumettre les traitement de tous les utilisateurs habilités. Sous Windows NT, le processus processus bdaemon bdaemon est représenté par par le service AbsyssBatchManager. AbsyssBatchManager. Ce service est démarré par défaut sous le compte système local; local; il peut être démarré sous le compte compte d’un utilisateur en paramétrant paramétrant le fichier de configuration du 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 en mode client avec les processus dserver, pserver, gserver et bdaemon ; d’où la nécessité de déclarer les ports tomDBd, ntfy, gwd et bdaemon sur chaque machine machine qui possède un module IHM de Visual TOM. Sous Unix, l’exécutable associé au processus vtom se trouve dans le répertoire associé à la variable $TOM_VISUAL Sous Windows, l’exécutable associé au processus vtom se trouve tr ouve dans le répertoire \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

12/ 65

vt-admin-guide.doc


13/09/02


4.4 Architecture technique

Architecture technique Gestion référentiel de production

Tcp/ip

Tengine l e é r s p m e t n e n o i t a c i l p é R

vtom

Vtom serveur VT-SDS VT-SES Vtom backup serveur VT-SBU Vtom client VT-CS

tomDBd gwd ntfy

dserver gserver pserver

Gestion des événements tomDBd gwd ntfy

dserver gserver pserver

tomDBd bdaemon

bdaemon Soumission des batchs Queues batchs

tomDBd

Vtom VT-XVISION

Queue ksh Queue SAP Affichage Script batch et log

gwd ntfy

Mr TOM


Gestion graphique

vt-admin-guide.doc

65 13/ 65


5 Administration des processus processus de Visual Visual TOM TOM 5.1 Administration sous un système Unix Deux menus d’administration des processus de Visual TOM sont disponibles disponibles dans le répertoire $TOM_ADMIN : admins et adminc. Ces menus sont accessibles à l’administrateur de Visual TOM.

5.1.1 Appel du menu : admins

Administration de Visual TOM - serveur ${HOST} 1

Etat

de Visual TOM - Serveur

2

Dema Demarr rrag agee

des des Ser Serve veur urss Vis Visua uall TO TOM

3

Arret

des Serveurs Visual TOM

4

Gestion

des Moteurs Visual TOM

5

Gestion

du client Visual TOM

6

Visual TOM

7

Sauv Sauveg egar arde de

q

Quitter

de la base base de don donne nees es

commande :

Option 1 - Etat de Visual TOM

Cette 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: suivantes: nom du process : utilisateur pid date ou heure base Si le serveur Visual TOM est actif sur la machine, on trouve l'état des moteurs sur les différents environnements : nom de l’environnement : ON/OFF

Options 2 et 3 - Démarrage et arrêt des serveurs serveurs Visual TOM

Ces 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 serveurs de Visual TOM durent plusieurs minutes. Dans ce cas il faut purger le fichier des statistiques

14/ 65

vt-admin-guide.doc


13/09/02


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

Option 4 - Gestion des moteurs Visual TOM

Cette option appelle le sous menu de Gestion des moteurs. Ce sous-menu n'est accessible que si les serveurs Visual TOM ont été activés. La liste des environnements environnements est affichée, avec pour chacun l’état du processus tengine associé (ON ou OFF). Il est possible de gérer tous les moteurs simultanément (entrez start pour les démarrer, stop pour les arrêter) ou individuellement individuellement (entrez le nom de l'environnement). l'environnement). Dans ce dernier cas, si le moteur est actif sur l'environnement l'environnement alors il est arrêté, s'il est inactif alors il est dé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 t ouche Entrée. Le cycle du moteur est fixé par défaut à 10 secondes, mais il est possible d'indiquer un autre cycle en suivant le nom de l'environnement d'une virgule et de la valeur du cycle (ex: start,30 ; production,60 ...).

Option 5 - Gestion du client

Il s’agit d’un appel au menu adminc (cf. paragraphe suivant) .

Option 6 - Visual TOM

Lancement de l’interface graphique. Pour être opérationnelle cette option nécessite que les serveurs Visual TOM (dserver, gserver et pserver) soient lancés.

Option 7 - Sauvegarde de la base de données

Cette option permet de sauvegarder la base de données , même si un ou plusieurs moteurs sont actifs sur la base. Le répertoire base est copié dans le répertoire $TOM_BACKUP, référence par le jour et l'heure.

5.1.2 Appel du menu : adminc

Administration de Visual TOM - client ${HOST} ${HOST} 1 Etat

de Visual TOM - Client

Démarr rrag agee 2 Déma

du Clie Client nt Visu Visual al TOM

3 A r rê t

du Client Visual TOM

q Quitter commande :

Option 1 - Etat du client Visual TOM

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

Ces fonctions permettent de lancer ou d'arrêter le client Visual TOM.

Copyright © ABSYSS. All rights reserved reserved 13/09/02

vt-admin-guide.doc

65 15/ 65


Les lancements et arrêts du client sont tracés dans le ffichier ichier $TOM_TRACES/client. $TOM_TRACES/client. 5.1.2.1 5.1.2. 1 Démarrag Démarr ag es proceseboot proceseboot

Deux scripts boot_start_client boot_start_client et boot_start_server boot_start_server sont disponibles disponibles dans le répertoire $TOM_ADMIN . Ces deux scripts peuvent peuvent intégrés à la procédure de boot système pour démarrerf1tomatiquement 1tomatiquement les processus du serveur et du client Visual TOM lors d’un redémarrage de la machine.

5.2 Administration sous un système Windows NT 5.2.1 Processus du Serveur Les exécutables associés aux processus dserver, pserver et gserver sont lancés 1tomatiquement 1tomatiquement lors du boot de la machine et ils apparaissent en tant que q ue services sous Windows NT. On peut 1tiliser l’o1til Windows Démarrer\programmes\Parmaètres\Panneau Démarrer\programmes\Parmaètres\Panneau de conf guration\Services guration\Services pour arrêter et démarrer ces processus. processus. Sinon deux f chiers de commandes tom-start.bat et tom-stop.bat tom-stop.bat installés dans le répertoire \vtom\tool \vtom\toolss permettent respectivement respectivement de démarrer et d’arrêter les processus du serveur Visual TOM.

5.2.2 Processus du Client L’exécutable associé au processus bdeamon se trouve dans le répertoire \abm\se \abm\services. rvices. On peut utiliser l’o1til Windows Démarrer\programmes\Parmaètres\Pan Démarrer\programmes\Parmaètres\Panneau neau de configuration\Services configuration\Services pour arrêter et démarrer ce processus.

5.2.3 Processus de l’IHM L’exécutable associé au processus vtom se trouve dans le répertoire \visual. Pour accéder à l’interface graphique de Visual TOM, il suffit de lancer l’exéc1table de lancement de l’interface graphique vtom.exe situé dans le sous-répertoire visual. Vous pouvez aussi démarrer l’interface l’interface graphique graphique par le menu Démarrer\programmes\Visual Démarrer\programmes\Visual TOM\vtom.

16/ 65

vt-admin-guide.doc


13/09/02


6 Configuration Configuration du serveur Visual TOM La configuration d’un serveur Visual TOM se base sur les définitions de trois types de paramètres : - les numéros de port des communication des processus dserver, pserver et gserver et bdaemon qui ont pour noms respectifs tomDBd, ntfy, gwd et bdaemon d’environnements de l’administrateur l’administrateur de Visual TOM pour un - les variables d’environnements serveur Unix et les variables d’environnement système pour un serveur Windows NT - les paramètres de configuration définis dans vtom.ini

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

6.2 Les variables d’environnement d’environnement de l’administrateur de Visual TOM pour un serveur Unix Les variables d’environnement de l’administrateur du serveur de Visual TOM sont définies dans le fichier vtom_init.[$SHELL] ; la valeur de la variable $SHELL indique le type de shell associé à l’administrateur du serveur de Visual TOM : ksh pour korn shell, … Les valeurs de ces variables d’environnement d’environnement sont positionnées lors de l’ouverture d’une session par l’administrateur de Visual TOM et elles sont utilisées par les différents processus de Visual TOM ; par exemple la variable $TOM_BASES qui contient le nom du répertoire de la base de données de Visual TOM est utilisée comme argument lors du lancement des processus 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é au fichier .profile de l’administrateur de Visual TOM.


vt-admin-guide.doc

65 17/ 65


Ci dessous un tableau qui donne la liste des variables d’environnement utilisées par le module serveur de Visual TOM HOST TOM_HOME TOM_ADMIN TOM_USER_ADMIN VTOM TOM_BACKUP TOM_BASES TOM_BIN TOM_STATS TOM_TRACES PATH

Générales Nom de la machine Répertoire d’installation de Visual TOM Répertoire des scripts d’administration Administrateur Visual TOM Serveur Répertoire de la partie serveur Répertoire de backup des bases Répertoire de la base de données Visual TOM Répertoire des exécutables serveur Répertoire des statiques Répertoire des traces moteur et serveurs Le path comprend le répertoire vtom/bin

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

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

Le répertoire contenant la base de données du serveur Visual TOM est défini dans le fichier vtom.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 Demarrer\Panneau de configuration\Systeme\Environne configuration\Systeme\Environnement ment . Le paramétrage d’une variable d’environnement système sous Windows se fait en modifiant la 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 = , faire OK

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

vt-admin-guide.doc


13/09/02


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 du serveur; c’est un fichier caché .vtom.ini. Sous Windows, ce fichier est généré au cours cours de la phase d’installation d’installation du serveur dans le répertoire %windir%V. Le fichier vtom.ini ne contient pas toutes les options, options, et toute modification de ce fichier né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 qui dé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 moteurs avec les clients. Les paramètres à mettre en place doivent être intégrées dans la section [general] pour Unix et dans section [GLOBALES] pour Windows. [GLOBALES] delaiWait delaiWait:30 :30 Délai Délai d'attente d'attente "en secondes secondes"" d'une répons réponsee d’un client client suite à une demand demandee de 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 avant une nouvelle tentative tentative de contact avec un client qui n’a pas répondu à une demande nbWai nbWaitRe tRetry try:1 :100 Nomb Nombre re de de tent tentat ativ ives es de de cont contac actt avec avec un un clie client nt ava avant nt la la modi modific ficat atio ionn du du statut d’un traitement StatusFailSubmit:ENCOURSNouveau statut d'un traitement traitement qui n'a pas pu être être soumis à un client StatusFailExist:ENCOURS Nouveau statut d'un traitement dont dont on a perdu 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’exploitation précédentes Au cours de son activité quotidienne, les moteurs de Visual TOM alimentent la table de la base de données stats.dbf, appelée fichier des statistiques. Les fonctions d’analyse de traitements permettent de produire les tableaux de bord de l’exploitation réalisée (cf Guide utilisateur Analyse des traitements). Ces tableaux de bord sont générés à partir du fichier des statistiques statistiques stats.dbf. automatiquement par Visual TOM ; ce qui Attention : le fichier stats.dbf n’est pas purgé automatiquement peut provoquer un ralentissement de l’activité des processus du serveur. La commande tpurge permet de purger le fichier des statistiques. Sous Unix, la fonction f onction d’alimentation du fichier des statistiques est active par défaut, par contre sous Windows, il faut mettre la valeur du paramètre stats à 1 pour que cette fonction soit active ou mettre la valeur 0 pour inhiber inhiber cette fonction. Le paramètre stats se trouve dans le fichier vtom.ini. [ GLOBALES GLOBALES ] Copyright © ABSYSS. All rights reserved reserved 13/09/02

vt-admin-guide.doc

65 19/ 65


bases=e:\vtom\bases bases=e:\vtom\bases stats=1

Répertoire de la base de données de Visual TOM Activation de la fonction analyse des traitements

Il est bien sûr possible d’automatiser la production de ces tableaux de bord dans un traitement 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 une application de votre production.

6.7 Production de tableaux de bord de l’exploitation des journées d’exploitation futures : Planning prévisionnel Cette fonction permet de produire les tableaux de bord relatifs à l’exploitation l’exploitation qui devrait se dé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 être déclarés dans le fichier /etc/services : PLANPREV_tomDBd 20006/tcp 01_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 Guide Utilisateur). Il est possible d’automatiser d’automatiser la production de ces tableaux de bord, dans un traitement soumis par Visual TOM. Sous UNIX, un traitement générant générant le planning prévisionnel prévisionnel est disponib disp onible le dans $TOM TOM_AD ADM MIN/p IN/pllanprev rev et peut p eut devenir deven ir votre votr e modèle mo dèle de générati génér ation on de d e planni p lanning ng prévisionnel. Celui-ci pourra être exécuté dans une application de votre production.

20/ 65

vt-admin-guide.doc


13/09/02


6.8 La mise en place place des traces des moteurs 6.8.1 Fonctionnement des Traces sous Visual TOM


vt-admin-guide.doc

65 21/ 65


6.8.2 Options des traces dans vtom.ini Toutes les options de traces t races sont regroupées dans la section [TRACES]. mode = [none, local local , remote, both] ( Mode de fonctionnement fonctionnement des traces) - none : pas de traces - local : traces sur fichier f ichier 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 sélectionnées (exemple NS pour Network et System) level=[C, E , I , D] (Définit (Déf init les niveau de traces pris en compte) - (C)ritic : Problèmes critiques. critiques. - (E)rror : Problèmes corrigibles. corrigibles. - (I)nfo : Informations I nformations - (D)ebug : Informations détaillées. 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 f ichier 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 Taille du fichier de traces en Mo. La valeur par défaut est 10. 0 définie un fichier f ichier continu. Note: Sous UNIX le séparateur = est remplacé par le symbole :

6.8.3 Visualisation d'un fichier de traces Cette 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] [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 t races (HHMMSS) -L niveau des traces (C)ritic (E)rror nfo (D)ebug -F famille des traces (N)etwork (S)ystem (L)ogical (O)ther ll 22/ 65

vt-admin-guide.doc


13/09/02


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

6.8.4 Modification des options d'un d'un fichier de traces. traces. Cette fonction s’applique s’applique à un fichier de de traces donné. donné. Elle permet de : - Modifier la taille t aille 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 nfo (D)ebug -F Fixe les Familles des traces enregistrées : (N)etwork (S)ystem (L)ogical (O)ther 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 -E Cette commande efface le fichier vtom.trc et lui dit d'enregistrer toutes les traces (mode debug).


vt-admin-guide.doc

65 23/ 65


7 Les commandes du serveur Visual Visual TOM TOM Sous Unix : La gestion courante des serveurs Visual TOM sur UNIX par le menu d'administration Visual TOM. Les traces d'arrêt et de relance r elance des serveurs sont tracées dans le fichier f ichier servers.log que vous trouverez dans le répertoire de base d'installation $TOM_HOME, vous pouvez aussi 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 menu fait appel aux scripts start_moteurs et stop_moteurs . Sous Windows : La gestion courante des serveurs Visual TOM se fait par les fichiers « .bat » du sousré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 démon serveur serveur de données données Pour UNIX : dserver $TOM_BASES Pour NT : voir tom-go.bat Démarre le démon Visual TOM dserver sur le port de communication TCP/IP tomDBd avec la base de données définie par la variable $TOM_BASES.

7.1.2 Démarrage du démon serveur de notifications Pour UNIX : pserver $TOM_BASES Pour NT : voir tom-go.bat Démarre le démon Visual TOM pserver sur le port de communication TCP/IP ntfy avec la base de données définie par la variable $TOM_BASES .

7.1.3 Démarrage du démon démon serveur serveur de graphisme graphisme Pour UNIX : gserver $TOM_BASES Pour NT : voir tom-go.bat Démarre le démon Visual TOM gserver sur le port de communication TCP/IP gwd avec la base de données définie par la variable $TOM_BASES .

7.1.4 Arrêt d’un processus processus démon Visual TOM Pour UNIX : dcs tomDBd dcs ntfy dcs gwd Pour NT : voir stop.bat Arrête respectivement les démons Visual TOM dserver, pserver, et gserver .

24/ 65

vt-admin-guide.doc


13/09/02


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 répertoire de la base base de données tbackup /target= /target= Cet outil de sauvegarde de la base de données fonctionne fonctionne en client/serveur, c'est-à-dire que l'on peut réaliser une sauvegarde de la base depuis une autre machine en positionnant la variable TOM_REMOTE_SERVER avec le nom de la machine sur laquelle on veut faire la sauvegarde 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 à la JJMMAA-HHMMSS sous lequel l'ensemble des fichiers de la base de données est sauvegardé. Pour restaurer une base, Il faut dans un premier temps arrêter tous les process Vtom puis copier la base sauvegardée puis relancer les services Vtom et l’IHM.

7.2.2 Liste le contenu de la base dans un fichier texte texport > nom_fichier (base) Options :

tex texport ort en env/ap /app/job /job > nom nom__fich fichie ierr

Liste le contenu de la base de données dans un fichier ASCII (cf. Les tableaux comparatifs des 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 de sélectionner un environnement, une application ou un traitement. Le fichier généré peut être modifié (en tenant compte des règles r ègles syntaxiques) syntaxiques) avant d'être importé 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 fichier texte texte timport nom_fichier nom_fichier La commande timport permet de récupérer des objets exportés d'une autre base de données par la commande comm ande texp texpor ortt (cf. Les tableaux tab leaux comparatifs compa ratifs des options optio ns des commandes tad taddjob et tad taddapp et leurs formats au mode import/export). import/ex port).

Les objets définis dans le fichier d'export sont créés dans la base de données courante, ou s'ils existent déjà, sont mis à jour. Si les applications ou les traitements exportés exportés utilisent des objets qui n'existent pas dans la base de données courante, ceux-ci sont créés tels que définis dans le fichier d'export.  Attention, pour les valeurs par défaut, on récupère les valeurs par défaut de la nouvelle base de données (environnement ou applications).


vt-admin-guide.doc

65 25/ 65


7.3 La gestion des moteurs 7.3.1 Démarrage d’un moteur moteur sur sur un Environnement Environnement tengine nom_environnement nom_environnement [cycle_du_moteur] [cycle_du_moteur] Démarre le moteur de Visual TOM pour l’environnement nom_environnement avec un cycle de scrutation de la base d’une valeur fixée par [cycle_du_moteur] en secondes. Le cycle est sur 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 vers un 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 moteur sur sur un Environnement estop nom_environnement Demande l’arrêt du moteur Visual TOM pour l’environnement [nom_environnement]. [nom_environnement]. L’arrêt effectif du moteur n’aura lieu qu’à la fin f in du cycle courant. Messages de retour : environnement non trouve l’environnement l’environnement a été trouvé, mais le moteur n’est pas actif arret du moteur demande l’environnement l’environnement a été trouvé, mais le moteur n’est pas actif

7.3.3 Remise à OFF du flag moteur de l’interface graphique pour un environnement eclear nom_environnement nom_environnement Force à OFF le flag signalant un Moteur actif pour l’environnement l’environnement [nom_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 environnement l’environnement l’environnement a été trouvé, t rouvé, mais le moteur n’est pas actif Environnement trouve , absence d’un ;moteur signalée dans la base l’environnement l’environnement a été trouvé, t rouvé, mais le moteur n’est pas actif arrêt du moteur demande l’environnement l’environnement a été trouvé, t rouvé, mais le moteur n’est pas actif

7.3.4 Test de présence d’un moteur actif pour un environnement environnement epresent nom_environnement Signale si un Moteur est actif pour l’environnement l’environnement [nom_envi [ nom_environnement] ronnement]

26/ 65

vt-admin-guide.doc


13/09/02


7.4 Gestion de la production 7.4.1 Production d’un fichier d’analyse d’analyse des exécution exécution des des traitements Pour Unix : tstat -B date_debut date_debut -E date_fin -e environnement [options] -

date_debut ,date_fin :

-

environnement environnement :

format JJ-MM-AAAA (sous Unix, résultat de la commande `date +%d-%m-%Y`) 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_fin Les 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 Analyse Dans l’invite de commande dos, taper tstat ana.cfg Liste des Options de la fonction tstat pour UNIX: -o -p -f

-l

-x

-v

Ordre

Définit les champs à afficher et leur ordre d'affichage. Voir plus bas la liste des mots-clés pour l'option -o séparateur de Par défaut, deux pages sont séparées par deux pages lignes vides. Cette option permet de positionner positionner à la place un saut de page. fichier de sortie La sortie par défaut des résultats de tstat se fait dans deux fichiers dans le répertoire $TOM_STATS. Les noms des fichiers sont générés avec comme base le type de report (ex.: ( ex.: anatrait) anatrait) plus une chaîne dé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 nom des fichiers de sortie. Si l'option '-f' est utilisée avec l'argument '-' , la sortie se fait sur la sortie standard Format du rapport : Par défaut, le rapport est produit sous forme de listing/tableau tableau sans mise en page, les colonnes étant sé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) séparateur de Par défaut, le séparateur de champ en mode tableau champ (mode est le ';'. tableau) Cette option permet de définir l'argument comme séparateur. Ventilation Ajoute au tableau produit par défaut trois tableaux: job volume (nombre (nombre de jobs exécutés) exécutés) incidents volume (nombre d'incidents) temps en minutes (d'exécution) (d'exécution) Les lignes représentent les dates (de la date de début à la date de fin du tstat), les colonnes


vt-admin-guide.doc

65 27/ 65


représentent les différents champs des arguments définis pour la ventilation Les deux champs possibles sont machines et applications. NON PLANIFIES inclut les jobs non planifiés Simulation Cette option permet l'analyse des traitements de la simulation (n°du filtre de simulation)  Attention, cette option doit être le premier argument de la commande tstat type de statistiques Cette option est utilisée par les scripts appelés depuis l'interface graphique (anatrait, planprev et anasimu). Les trois valeurs possibles sont : prévisionnel : planning prévisionnel analyse : analyse des traitements effectués analyse_simulation

-Z -s

-T

Liste des filtres possibles -m -a -F

Machines Application Famille

-u -c -q

user calendrier queue



Attention : Si une option a plusieurs arguments, ils doivent être séparés par des virgules. (ex. : -m Jupi Jupite ter, Uran Uranus) Liste complète des mots-clés associés à l’option ix_id machine Duree Mode relances situation

Env status CP Sysdate Queue Rattrapage

-o

appl daytype IO systime user message

pour la fonction

tstat:

jobname date_debut jobtype nom_dp periodicite ressource

Famille date_fin Cal valeur_dp Cycle

7.4.2 Purge des statistiques nom_environnement date_limite $TOM_BASES Pour UNIX : tpurge nom_environnement Pour NT : idem Ou (UNI (UNIX X et et N NT) T) : tpur tpurge ge ‘*’ ‘*’ dat datee lim limititee $TO $TOM_ M_BA BASE SES S (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 avant la date [date_limite] incluse. Utilisé sans arguments, tpu tpurge rge retourne son usage us age : tpurge [environnement] [environnement] [date] Usage : 'environnement' 'environnement' is thé environnement to clean 'date' is DD-MM-YY[YY] or or DD-month-YY[YY] DD-month-YY[YY] 28/ 65

vt-admin-guide.doc


13/09/02

Visual TOM – Guide d’administration 

Exemple Exemple

tpu tpurge rge Explo xploiitati tatioon 12-j 12-jan-00 n-00 $TOM TOM_BA BASE SES S

7.5 Gestion de la planification 7.5.1 Demande de planification d’un travail « à la demande » Pour UNIX UNIX : tstart environne environnement ment applicati application on [job] [job] [par=x [par=xxx,yy xx,yyy,…,z y,…,zzz] zz] Pour NT : idem Demande l'exécution immédiate (passage au statut EN COURS ) d'une application ou d'un traitement (équivalent à l'option Demander dans le pilote graphique) graphique) Tout job soumis par Visual TOM peut « demander » (planifier) un Traitement ou une Application « à la demande ».

7.5.2 Forçage à A VENIR des traitements d’un environnement Pour UNIX : treset treset nom_e nom_envir nvironne onnement ment nom_date nom_date_exp _exploita loitation tion Pour NT : idem Force A VENIR tous les jobs de l’Environnement la date [nom_date_e [nom_date_exploit xploitation] ation] :

[nom_environnement] qui sont rattachés à

Résultat STATUS :OK Environnement Environnement inexistant Date inexistante Un moteur tourne dans cet environnement - Arretez le avant treset FAILED (une erreur s’est produite)   Remarque : treset ne fonctionne que si aucun moteur ne tourne sur cet environnement.

7.5.3 Evaluation de planification pour un Traitement ou une une Application Application Pour UNIX UNIX : tform nom_envi nom_environn ronnemen ementt nom_appl nom_applicati ication on [nom_Tra [nom_Traitem itement ent / all] all] Pour Pour NT : tform tform nom_e nom_env nviro ironn nneme ement nt nom_a nom_appl pplica icatio tionn [nom_T [nom_Trai raitem tement ent]] / all Evalue la planification du Traitement ou de l’Application pour la valeur courante de sa date d’exploitation. Retourne la date rattachée au job ou à l’application, suivi de VRAI si le planning est vérifié ce jour ou FAUX si l’application ou le traitement n’est pas planifié. Exemple 1  Vérification du planning de l’application AP01 de l’environnement exploitation : tform exploitation AP01 today is 08-01-97 Planning returns : >> VRAI <<(0x1) L’application AP01 de l’environnement exploitation est planifiée le 8 janvier 1997. Exemple 2  Vérification du planning de tous les traitements de l’application AP01 de l’environnement exploitation : tform exploitation AP01 all today is for job imp012 08-01-97 Planning returns : >> VRAI << (0x1) Copyright © ABSYSS. All rights reserved reserved 13/09/02

vt-admin-guide.doc

65 29/ 65


today is for job copA02 08-01-97 Planning returns : >> VRAI << (0x1) today is for job supS20 08-01-97 Planning returns : > > FAUX << (0x0) Le job supS20 de l’application AP01 n’est pas planifié le 8 janvier 1997, les autres jobs de cette application le sont.  Exemple 3 Vérification du planning du traitement J003 de l’application AP01 de l’environnement exploitation : tform exploitation AP01 J003 today is for job J003 08-01-97 Planning 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 d'une application ou d'un traitement traitement pour une période donnée tplan /nom=Env/App[/Job] [/debut=JJ-MM-AAAA] [/fin=JJ-MM-AAAA] [/table] ou tplan /nom=Env/App[/Job] /annee[=AAAA] [/table] /nom : nom complet de l'objet l'objet vtom (App ou Job) Job) /début : Date de début d'analyse d'analyse /fin : Date de fin d'analyse d'analyse /année : Analyse annuelle annuelle /table : visualisation visualisation en mode tableau tableau annuel

7.5.5 Vérification des blocages de date Pour Pour UN UNIX IX : tchkda tchkdate te /nom=d /nom=date ate [/env [/env=en =env] v] Pour NT : idem

30/ 65

vt-admin-guide.doc


13/09/02


8 Configuration du client client Visual Visual TOM TOM Le 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 serveur Visual TOM, le client stocke les références références du traitement (pid, nom du script, …) dans une file d’attente appelée queue batch. Et selon le paramétrage de cette queue batch (nombre de jobs simultanés, simultanés, …), le client décide ou ou non de lancer lancer l’exécution du script script associé au traitement. Le lancement de l’exécution d’un script d’un traitement est effectué par un script shell sous Unix ou un fichier de commandes sous Windows appelé Submitter ; à chaque queue batch est 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 types d’objets : - le numéros de port de communication d’environnements de l’administrateur l’administrateur de Visual TOM pour un - les variables d’environnements client Unix et les variables d’environnement d’environnement système pour un client Windows - 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 f ichiers 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 Visual TOM. C’est le port tomDBd du processus dserver du module serveur. serveur. La valeur par défaut de ce port est 20001 et elle est définie dans le fichier /etc/services pour un système Unix ou dans le fichier %windir%\systtem32\drivers\etc\services %windir%\systtem32\drivers\etc\services pour un système Windows W indows NT. Cette valeur est mise à jour automatiquement automatiquement lors de l’installation d’un client Windows NT, par contre, sur un système système Unix, la mise à jour jour de la valeur du port tomDBd doit être faite faite manuellement. Pour tester l’état de la communication communication d’un client vers un serveur, il suffit de positionner positionner la valeur de la variable d’environnement TOM_REMOTE_SERVER avec le nom de la machine du serveur Visual et de lire la valeur d’une ressource de Visual TOM avec la commande tval Tval –name

8.2 Les variables d’environnement d’environnement de l’administrateur du client Visual TOM sous Unix Comme pour un serveur Visual TOM Unix, les variables d’environnement de l’administrateur du client de Visual TOM sont définies dans le fichier vtom_init.[$SHELL] ; la valeur de la variable $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 d’environnement sont positionnées lors de l’ouverture d’une session par l’administrateur de Visual TOM et elles sont utilisées par le processus bdaemon; 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. Copyright © ABSYSS. All rights reserved reserved 13/09/02

vt-admin-guide.doc

65 31/ 65


Le fichier vtom_init.[$SHELL] est généré automatiquement automatiquement dans le répertoire $TOM_ADMIN lors de l’installation 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ême machine un seul fichier vtom_ini est généré g énéré et il contient les variables d’environnement d’environnement pour les processus du serveur et du client. Ci dessous un tableau qui donne la liste des variables d’environnement utilisées par le module client de Visual Visual TOM HOST TOM_HOME TOM_ADMIN TOM_USER_ADMIN

Générales Nom de la machine Répertoire d’installation de Visual TOM Répertoire des scripts d’administration Administrateur Visual TOM

ABM ABM_BIN ABM_LOGS ABM_SPOOL

Client Répertoire d’installation du client ABM Répertoire des exécutables Répertoire des logs Répertoire de la file d’attente des traitements

8.3 Les variables d’environnement d’environnement système système Windows d’un client Visual TOM Lors de l’installation d’un client, les variables d'environnement d'environnement système suivantes sont créé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 Demarrer\Panneau de configuration\Systeme\Environne configuration\Systeme\Environnement ment . Pour modifier l’emplacement des logs, il suffit de modifier une clé de la registry ; pour cela il faut 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 = , faire OK

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

vt-admin-guide.doc


13/09/02


8.4 Le fichier de configuration vtom.ini Sous Unix, ce fichier est généré dans répertoire $TOM_ADMIN lors de l’installation du


vt-admin-guide.doc

65 33/ 65

Visual TOM-Guide d’ administration 

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 l’administrateur local pour chacun d’eux - Choisir Ajouter et ajouter l’administrateur

Modification du démarrage du service AbsyssBatchManager A partir de la liste des services services sous Windows, sélectionner 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 » « ce compte » et sélectionner sélectionner le compte utilisateur défini précédemment. précédemment.

8.6.2 Gestion des des utilisateurs utilisateurs par par le le client Visual TOM TOM L’installation par défaut du client Visual TOM ne gère pas les utilisateurs ; c’est à dire que la valeur du paramètre utilisateur d’un traitement n’est pas pris en compte par le client Visual TOM. Pour que le client Visual TOM puisse gérer des utilisateurs, il faut déclarer ceux-ci dans le fichier vtom.ini. [bdaemon] users=1

la valeur 0 pour ne pas prendre en compte cette gestion des utilisateurs

[users] user1=,,,, user2=,,,, ... usern =,,,, Remarques:

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

[bdaemon] users=1 0 pour ne pas prendre en compte cette gestion des utilisateurs [users] user user1= 1=Ab Absy syss ssDo Doma main in,L ,Lam ambd bda, a,TO TOM M ‘uti ‘utililisa sate teur ur du du do domain mainee « Abs Absys yssD sDom omai ainn » user2=.,admin,TOM ‘utilisateur local à la machine cliente

34/ 65

vt-admin-guide.doc


13/09/02


8.7 les queue batch Une queue batch est un objet de Visual TOM qui permet à un client de gérer des files d’attente de traitements à soumettre. A chaque queue batch est associé un script shell sous Unix ou un fichier de commandes sous Windows qui « en capsule » l’exécution du script d’un traitement. Ce script shell ou fichier de commandes est appelé submitter; par exemple : Unix, un traitement défini défini avec la queue queue batch queue_ksh queue_ksh - Sous un client Unix, sera soumis par le le script shell shell tom_submit.ksh - Sous un client Windows NT, un traitement défini avec la queue batch queue_wnt sera soumis par le fichier de commandes Submit_queue_wnt.bat

8.7.1 Configuration d’une d’une queue queue batch sous un client Unix A chaque queue batch correspond un sous-répertoire sous le chemin $ABM/config/queues. Ce sous-répertoire contient les fichiers suivants : configurat ion de la queue: queue.conf o fichier de configuration users o définition des utilisateurs: La description du fichier queue.conf est la suivante : N: Nomb Nombre re maxi maximu mum m de jobs jobs en exéc exécut utio ionn simu simultltan anée ée M: Nomb Nombre re Maximum mum de de job jobss en en att atteente Shell Shell : Chemin Chemin et nom nom du shell shell P: prio priori rité té des des job jobss dan danss la la que queue ue (non (non util utilis isee sou souss UNIX UNIX)) Exemple : Fichier $ABM/config/queues/prod/queue_con $ABM/config/queues/prod/queue_config fig de la queue prod 15 5 /user/bin/tcsh 4 Le queue prod a droit a 15 jobs en exécution simultanée et a 5 jobs en attente. Elle utilisera le shell /user/bin/tcsh La priorité des jobs dans la queue est de 4 (non utilise sous UNIX).

8.7.1.1 Configuration des administrateurs

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

Un utilisateur peut être associé a une ou plusieurs queues batch qu'il peut utiliser. Pour chaque 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". "Nom_Login:Max_Exe:Max_Wait". Cette liste des utilisateurs est définie dans le fichier f ichier users. déclaration du user user "any" dans une une queue queue rend accessible cette queue queue à tout les NB : La déclaration users non déclarés. Exemple : oracle:1:1

le fichier $ABM/config/queues/prod/user $ABM/config/queues/prod/users s de la queue prod

L’utilisateur oracle a droit a un seul job en exécution et un seul job en attente dans la queue prod


vt-admin-guide.doc

65 35/ 65


8.7.2 Configuration d’une d’une queue queue batch sous un client Windows Windows La 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. queue_wnt. Dans le 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 nombre de 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émarrer le service AbsyssBatchManager.

8.8 Les Submitter On rappelle qu’un Submiitter est un script shell ou un fichier de commandes associé à une quueue 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_ADMIN sous Ubix, et sous Windows ces submitter se trouvent dans le répertoire pointé par la variable %ABM_BIN% Exemple d’exécution d’un traitement ayant pour script job_test j ob_test et pour queue batch queue_test : -

-

36/ 65

le Client Visual TOM Unix déclenchera alors le script tom_submit avec l’extension test soit $TOM_ADMIN/tom_submit.test, en lui transmettant le nom du script à exécuter et une liste de valeurs de variables d’environnement Le client Visual TOM Windows déclenchera alors le fichier de commandes %ABM_BIN%/Submit_queue_test.bat %ABM_BIN%/Submit_que ue_test.bat en lui transmettant le nom du script à exécuter et une liste de valeurs de variables d’environnementparamètres

vt-admin-guide.doc


13/09/02


Le tableau ci-après liste les variables d'environnement qui sont transmises par le client Visual TOM au Submiiter : TOM_REMOTE TOM_REMOTE_SER _SERVER VER Nom de de la machine machine serveur serveur Visual Visual TOM TOM qui qui a lancé lancé le traitement. TOM_JOB_ID Identifiant du traitement dans la base de données TOM_JOB Nom du traitement TOM_APPLICATION Nom de de l’application TOM_ENV NVIR IRON ONM MENT Nom de l’environnement TOM_DATE Nom de la date d’exploitation TOM_DATE_VALUE Valeur de de la date d’exploitation TOM_USER Utilisateur exécution du traitement TOM_SCRIPT Nom du script a exécuter TOM TOM_SC SCRI RIP PT_AR T_ARGS GS Liste iste des para aramètr mètrees du scri scrippt ou job job TOM_ TOM_QU QUEU EUE_ E_PR PRIOR IORITY ITY Prio Priori rité té du job job TOM_JOB_RETRY Nombre de reprises effectuées TOM_JOB_POINT Point de de reprise. La La valeur de de la variable d’environnement d’environnement TOM_JOB_POINT est égale à 0 par défaut. La modification de la valeur de cette variable d’environnement s’effectue à l’aide de la commande tstep (tstep –l
8.9 Gestion des logs Tout traitement soumis par le client Visual TOM génère deux fichiers de traces d'exécution appelée fichiers log. Ces fichiers sont générés sur le sous-répertoire pointé par la variable d’environnement ABM_LOGS pour Unix et ABM_LOG pour Windows et portent l’identifiant suivant : -

-

nom_env_nom_appli_nom_ job _ AAMMJJ-HHMMSS .o

sortie

nom_env_nom_appli_nom_ job _ AAMMJJ-HHMMSS .e

sortie erreur

standard

Par défaut Visual TOM génère deux fichiers log pour chaque exécution d’un traitement. Il est possible de modifier ce comportement par l'intermédiaire du menu fin de traitement (voir Copyright © ABSYSS. All rights reserved reserved 13/09/02

vt-admin-guide.doc

65 37/ 65


définition d’un u traitement). Les options de ce menu sont : impression de la log, suppression de la log et copie de la log. Les valeurs des actions choisies dans la définition d’un traitement sont transmises par l’intermédiaire de la variable d’environnement d’environnement TOM_LOG_ACTION, et sont traitées par le script 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 le script ou fichier de commandes gestlog en tenant compte des variables d’environnement d’environnement suivantes : TOM_SCRIPT : TOM_LOG : TOM_ OM_LOG_A G_ACTION :

nom du script nom de la log action à accom complir 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, TO M, la variable d’environnement TOM_QUEUE_PRIORITY du contexte du traitement contient la valeur de la priorité du traitement. Cette valeur est comprise entre 0 et 10, et la valeur par défaut de la priorité d’un traitement est de 5.

Paramétrage de la priorité d’un traitement ou définition de la priorité les caracté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 traitement et on procède de la manière suivante en prenant comme exemple un traitement qui a pour queue batch queue_wnt : 1. Créez la queue batch avec queue_wnt.x queue_wnt. x ; x est la valeur de la priorité du traitement traiteme nt dans la queue batch queue_wnt 2. Modifiez la définition du traitement en mettant dans le champ queue 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_ONE ABM_QUEUES_PRIORITY_INCREMENT=BY_ONE dans la section [BDAEMON] [BDAEMON] ABM_QUEUES=/queue_wnt:1 ABM_QUEUES_PRIORITY_INCREMENT=BY_ONE Sous Unix, ajouter le paramètre ABM_QUEUES_PRIORITY_INCREMENT=BY_ONE ABM_QUEUES_PRIORITY_INCREMENT=BY_ONE dans la section [BDAEMON] [BDAEMON] ABM_QUEUES_PRIORITY_INCREMENT:BY_ONE Dans $ABM/config/queues/queue_tes $ABM/config/queues/queue_test/queue.conf t/queue.conf mettre à jour le nombre nombre de priorité par queu queue_ e_te test st 3 38/ 65

/* Nom Nom de la queu queuee */ /* Nombre maximum de job s’exécutant en parallèle */ vt-admin-guide.doc


13/09/02


-1 /bin/ksh 20

/* Nombre maximum de job en attente de soumission */ /* Shell utilisé */ /* Priorité (non utilisé) */

Paramétrage :

ABM_QUEUES_PRIORITY_INCREMENT peut prendre les valeurs : DISABLED  La gestion des priorités est désactive BY_ONE  Après chaque fin de job, la queue est mise a jour en incrémentant la priorité courante de 1 BY_PRIORITY  Après chaque fin de job, la queue est mise a jour en incrémentant la priorité courante par la priorité initiale Ce paramètre implique qu’un job se trouvant dans la queue depuis longtemps prend une priorité 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 devant des jobs ayant une priorité courante de plus de 10) et leur priorité courante n’est pas incrémentée. Les jobs de priorité 0 passent en dernier et leur priorité courante n’est pas incrémenté. Une variable TOM_QUEUE_PRIORITY est exportée dans l’environnement l’environnement d’exécution du job. Cette variable contient contient la valeur de la priorité priorité initiale 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/non Ce paramètre sert de générateur de Traces dans le bdaemon.


vt-admin-guide.doc

65 39/ 65


9 Les commandes du client Visual TOM Le client Unix Visual TOM se gère par le menu adm adminc. nc. Les démarrages et arrêts a rrêts du démon client sont archivés dans le fichier client.log du répertoire d'installation de Visual TOM. Vous pouvez pou vez aussi aus si utilis uti liser er les script scr iptss star start_ t_cl clie ient nt et stop_ stop_cl clie ient nt..

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. $ABM/config/managers. Seuls les administrateurs administrateurs définis dans ce fichier peuvent arrêter et lancer le client Unix Visual TOM.

9.1.1 Démarrage du démon client Pour UNIX : Pour NT : Pour Pour VMS VMS : Pour AS400 AS400 :

$ABM_BIN/bdaemon $ABM_BIN/bdaemon voir tom-go.bat call call SYS SYS$s $sta tart rtup up : vtom vtomsta start rtup up.c .com om AB ABM_ M_STO STOP P Call SYS_AUTO/VP SYS_AUTO/VPRDO60 RDO60C C

Démarre le démon Visual TOM Absyss Batch Manager utilisant le port TCP/IP bdaemon défini dans dan s le fichi fi chier er /etc /etc/s /ser ervi vices. ces. Retourn Ret ournee la l a valeur va leur des variables varia bles $ABM $ABM_L _LOG OGS S et $ABM $ABM

9.1.2 Arrêt du démon client Pour UNIX : Pour NT : Pour VM VMS : Pour AS400 AS400 :

bdown [-a] voir tom-stop.bat ABM_START call SYS_AUTO/BD SYS_AUTO/BDOWN OWN

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

9.2 statistiques d’utilisation des files d’attente du client Pour UNIX : bstat Pour NT NT : commande inexistante Affiche pour chaque queue batch le nombre de jobs EN ATTENTE , en cours d’exécution... Exemple Queue queue_tcsh

User

Run

MRun

Wait

Mwait

Visual TOM prod

0 3 1

10 10 -1 5

0 0 1

-1 -1 5

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

40/ 65

vt-admin-guide.doc


13/09/02


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

9.3 statistiques d’utilisation des files d’attente par un utilisateur Pour UNIX : buser Pour NT NT : commande inexistante Affiche pour l’utilisateur courant le nombre de jobs EN ATTENTE , en cours d’exécution pour l'utilisateur qui lance cette commande.

9.4 La gestion de l’ordonnancement 9.4.1 Valorisation ou consultation d’une ressource Tout traitement soumis par Visual TOM peut consulter consulter ou valoriser 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_ressource tval -name nom_ressource -value valeur: Valorise la ressource globale nom_ressource à la valeur valeur tval [-env nom_environnement nom_environnement ] -name nom_ressource nom_ressource -info Renvoie la valeur de la ressource nom_ressource locale à nom_environnement

tval [-env nom_environnement nom_environnement ] -name nom_ressource -value Valorise la ressource nom_ressource locale à nom_environnement à la valeur valeur Pour 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 pile La commande tpush permet d'ajouter un élément à la fin d'une ressource de type pile. Syntaxe de la commande : Pour UNIX : tpush -name pile> -value -value ] eur>] [-info] [-info] Pour NT : idem Valeurs 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 pile La commande tpop permet de supprimer le premier élément d'une ressource de type pile. Syntaxe de la commande : Pour Pour UNI UNIX X : tpop tpop -nam -namee > Pour NT : idem Valeurs 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.


vt-admin-guide.doc

65 41/ 65


9.4.4 Suppression de tous les éléments d'une d'une pile pile La commande tempty permet de vider le contenu d'une ressource de type pile. Syntaxe de la commande : Pour Pour UN UNIX IX : tempty tempty -name -name pile> Pour NT : idem Valeurs 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 serveur serveur Tout traitement soumis par Visual TOM doit signaler sa bonne fin. Cette fonction est assurée par la commande tsend . Tout traitement t raitement terminé sans effectuer cette commande sera considé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. fonction. Pour Pour UNI UNIX X : tsen tsendd [-sY [-sY]] [-m" [-m"Me Mess ssag age" e"]] Pour NT : idem Utilisé sans options, tsend renvoie pour le job courant le statut de fin normale TERMINE (il n'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 TERMINE E EN ERREUR N NON PLANIFIE -

 Attention, dans ce cas il ne faut pas que le tsend du submitter soit exécuté  Attention,

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 reprise Lors de son exécution, exécution, un Traitement T raitement a la possibilité de signaler l'état interne de son avancement à Visual TOM, et ainsi de signaler à quel label il doit être redémarré en cas d’erreur. tstep -l valeur_label valeur_label [-e nom_environnement nom_environnement -a nom_application - j nom_job Positionne la variable d’environnement d’environnement du traitement tr aitement de label de reprise du traitement tr aitement TOM_JOB_POINT courant (ou du traitement nom_enviro nom_environnemen nnement t nom_applicat nom_application ion nom_traitement) à la valeur numérique valeur_label. Pour avoir la possibilité de gérer des labels de reprise alphanumérique (maximum 16 caractères), il faut ajouter dans le fichier vtom.ini du serveur, Pour NT : 42/ 65

vt-admin-guide.doc


13/09/02


[globales] AcceptAlphaStep=1 Pour UNIX [general] AcceptAlphaStep:1


vt-admin-guide.doc

65 43/ 65


10 Configuration d’une IHM Visual TOM L’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 graphique est vtom ; il est situé dans le répertoire d’installation de l’interface graphique « visual » La configuration d’une IHM Visual TOM se base sur les paramétrages de trois types d’objets : port des communication communication du tomDBd, gwd, ntfy et bdaemon - les numéro de port -

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

-

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 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 20004 Ces ports de communication sont déclarés dans le fichier /etc/services pour un système Unix ou dans le fichier %windir%\systtem32\drivers\etc\services %windir%\systtem32\drivers\etc\services pour un système Windows. La déclaration des ports de communication est faite automatiquement lors de l’installation de l’iHM Windows, par contre, sur un système Unix, cette déclaration doit être faite manuellement.

10.2 Les variables d’environnement de l’administrateur de l’IHM sous Unix L’administrateur d’une IHM Visual TOM est le même que l’administrateur du serveur Visual car l’installation d’une IHM sous Unix n’est possible qu’avec une installation d’un module serveur. 44/ 65

vt-admin-guide.doc


13/09/02


Les variables d’environnement d’environnement de l’administrateur de l’IHM l’I HM de Visual TOM sont définies dans le 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 d’environnement sont positionnées lors de l’ouverture d’une session 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 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 t ableau synthétise les variables d’environnement d’environnement utilisées par le module IHM de Visual TOM Générales Nom de la machine Répertoire d’installation de Visual TOM Répertoire des scripts d’administration Administrateur Visual TOM

HOST TOM_HOME TOM_ADMIN TOM_USER_ADMIN

IHM (Interface graphique) TOM_VISUAL TOM_LP ND_PATH

Répertoire d’ d’installation de de l’l’interface gr graphique Script associé à l'impression dans l'interface graphique 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 Visual TOM Windows, ND_PATH qui contient le nom du répertoire des fichiers de configuration Neuron 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 du serveur et de l’IHM; c’est un fichier fichier caché .vtom.ini. Sous Windows, Ce fichier f ichier est généré lors de l’installation dans le répertoire 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 fichier nécessite un arrêt et une relance relance de l’IHM Visual TOM pour être prise en compte.

Fichier vtom.ini pour Unix [vtom] documentation:/…/documentation documentation:/…/documentation/nom_serveur /nom_serveur ou http://webdoc/documentation [aide] (Aide en ligne au format html) browser:/appli/netscape/netscape

Fichier vtom.ini pour Winows Copyright © ABSYSS. All rights reserved reserved 13/09/02

vt-admin-guide.doc

65 45/ 65


[GLOBALES] pourcent=0

faire apparaitre % dans pilote graphique pour Supra Manager

[VTOM] [VTOM] ND_PATH=e:\vtom\visual\ documentation=e:\vtom\visual\ [aide] browser=c:\Program Files\Microsoft Internet\IEXPLORER.ex I nternet\IEXPLORER.exee

L’utilisation des paramètres documentation et browser sera abordée dans le chapitre « mise en 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 HTML Vous pouvez créez pour chaque entité (application et traitement) -

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

-

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

L'accès à ces document dossiers se fait f ait par l'intermédiaire d’items dans les menus contextuels 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 des répertoire référencé référencé dans le fichier vtom.ini par le paramètre « documentation » de la section [vtom]: Nommage d’un document de type documentation pour une application : env_app_ doc.htm; 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 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_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_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 vous aurez référencé dans le paramètre « browser » de la section [aide] du fichier vtom.ini. 46/ 65

vt-admin-guide.doc


13/09/02


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 dans vtom_init.[$Shell] vtom_init.[$Shell] par le chemin absolu d’un script qui permet d’imprimer un fichier avec comme argument le nom du fichier. Sous Windows, il faut procéder de la manière suivante suivante : 1. Créez un fichier fichier de commandes commandes TOM_LP.bat TOM_LP.bat Contenant la la commande d’impression : print[/d:périphérique] print[/d:périphérique] [lecteur:][chemin] [lecteur:][chemin] "%1" - pour une imprimante locale locale print /d:\\nom_serveur\imprimante_partag /d:\\nom_serveur\imprimante_partag "%1" - pour une imprimante réseau 2. Créez une variable d'environnement d'environnement [Panneau de configuration/système configuration/système/onglet /onglet environnement] Variable : TOM_LP Valeur : [chemin du répertoire]\TOM_LP.bat


vt-admin-guide.doc

65 47/ 65


11 Conception et Pilotage de la production production en mode 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 objets du domaine d'exploitation d'exploitation La commande tlist permet de récupérer en ligne de commande les noms des objets du domaine d'exploitation. d'exploitation. Pour les applications, tlist renvoie aussi le nombre de traitements qu'elle contient, et le nombre 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] ou tlist [-v | -h | -d] avec -v : mode 'verbose' -d : mode 'debug' -h : aide et avec : : liste des jobs - jobs : liste des dates - dates - calendriers : liste des calendriers - utilisateurs : liste des utilisateurs - resources : liste des ressources : liste des machines - machines : liste des tokens - tokens : liste des blocages - bloquage : liste des nodes - nodes : liste des notifications - notify 1 : liste des jobs retenus - retenus : liste des jobs en erreur - ENERREUR : liste des jobs en cours - ENCOURS : liste des jobs a venir - AVENIR deplanifies - DEPLANIFIE : liste des jobs deplanifies des jobs non planifies planifies - NONPLANIFIE : liste des : liste des jobs termines - TERMINE Exemples : >tlist -v dates >tlist -v jobs >tlist -v app >tlist -v AVENIR >tlist ENCOURS –v

48/ 65

vt-admin-guide.doc


13/09/02


11.1.2 Ajout ou modification d'une date date d'exploitation Pour UNIX UNIX : taddate taddate /nom=no /nom=nom_da m_date_ex te_exploi ploitatio tationn [ /val=< /val= ate> ] [ /typ= ] Pour NT : idem La commande tadddate permet la modification de la valeur d’une date d’exploitation globale à l’environnement. l’environnement. Options /valeur=

valeur par défaut date système

/type=

automatique

arguments date au format JJ-Mmm-AA[AA] ou JJ-MM-AA[AA] (ex. : 12-Fev-1997 ou 12-02-97ou 12-Fev-97 ou 12-02-1997) automatique, constante ou système

11.1.3 Suppression Suppression d'une date d'exploitation Pour UNIX : tdatedel

KO sur UNIX et NT)

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



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

11.1.4 Ajout Ajout ou modification d'une ressource Pour UNIX : taddres /nom= /nom= /type= /type= [ /valeur= ] Pour NT : idem La commande taddres permet la création d’une ressource globale de l’environnement. 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.   Remarques La 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 Ajout ou modification d'un utilisateur La commande tadduser permet l’ajout ou la modification d’un utilisateur du domaine d’exploitation Pour UNIX : tadduser /nom= /password= [options] Pour NT : idem Liste des options: /droits= /droits= X=0: Lecture X=1: Lecture et ecriture (defaut) X=4: Aucun byte 01 - Date d'exploitation byte 02 - Calendriers byte 03 - Periodes byte 04 - Ressources byte 05 - Utilisateurs Ut ilisateurs Copyright © ABSYSS. All rights reserved reserved 13/09/02

vt-admin-guide.doc

65 49/ 65


byte 06 - Machines byte 07 - Queue batch byte 08 - Environnement byte 09 - Jeton byte 10 - Pilote (Visualiser) byte 11 - Pilote (Agir) byte 12 - Moteur (Demarrer) byte 13 - Moteur (Arreter) byte 14 - Statistique (Lancer) byte 15 - Statistiques Graphiques Graphiques (Lancer) byte 16 - Simulation (Lancer) Exemple: /droits=111004411111111 /droits=11100441111111111 /droits_env=<[XY],...> /droits_env=<[XY],...> X= L ou - : Lecture ou inactif Y= E ou - : Ecriture ou inactif /nom_usuel= usuel> /comment= /comment= /print= d'impression>

11.1.6 Suppression d'un utilisateur Pour Pour UNIX UNIX : tdelus tdeluser er /nom=< /nom= r> Pour W indows : non supporté

11.1.7 Modification Modification du nom d'une machine Pour UNIX : tmodmach tmodmach /nom= /nouveau /nouveau=

11.1.8 Ajout d’une queue Pour Unix : taddqueue

50/ 65

vt-admin-guide.doc


13/09/02


11.2 Ajout et modification d’une application Pour Pour UNI UNIX X: Pour NT :

tadda taddapp pp /nom=e /nom=env/ nv/app app [optio [options] ns] idem

La commande taddapp permet la création d’une application dans un environnement et une application avec toutes ses caractéristiques définies en options (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 sont pas 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éristiques par défaut de l’environnement. l’environnement. Les options de la commande taddapp pour UNIX et NT Caractéristique Nom Commentaire Famille Date d’exploitation Type de périodicité Cyclique période du cycle Periodicité Heure de départ minimum Heure de départ maximum Mode d'exécution Machine Queue batch Utilisateur ne pas déplanifier les successeurs Heure de déplanification Liste des paramètres Lien de ...

Copyright © ABSYSS. All rights reserved 13/09/02

Mode commande /Nom /Comm /Family /date /TypePer /Cyclique /Cycle /Per /Hdeb /Hfin /Mode /Machine /Queue /User /NonDepl /Hdepl /Par /LienDe

Mode export [job:/] commentaire famille Date Type_periodicite cyclique Cycle periodicite heure_debut heure_fin m ode machine queue User ne_pas_deplanifier heure_deplanification parametres Liens_de

valeurs / format <"commentaire"> <« famille »> periodique | demande oui | non journaliere | hebdomadaire | mensuel | annuel job | stop | exec | test | simu <"machine"> <"queue"> <"utilisateur"> oui | non < par1 >[,< par2 >,...,< parn >] < env >/< appli >/< job >[< type de lien >] type de lien : obli | facu | excl | cond | erre vt-admin-guide.doc

défaut obligatoire aucun aucune obligatoire periodique non 00:00:00 journalière 00:00:00 illimite job defaut de l'application defaut de l'application defaut de l'application non 23:59:59 aucun aucun

51/ 65 65


Lien vers ...

/LienVers

Liens_vers

Calendrier Jours de la semaine Jours du mois Semaines du mois Mois de l'année Formule Ressources Statut

/Cal /Jsem /Jmois /Smois /Mannee /Formule /Res /status

calendrier jour_semaine jour_mois semaine_mois mois_annee ressource status

Géométrie

/Geom

geometrie

couleur bordure couleur fond couleur titre Copie de ... Mise en exploitation

/Cbord /Cfond /Ctitre /De /exploit

sfrmclr sbgclr sfrblclr NON DISPONIBLE

52/ 65

vt-admin-guide.doc

< env >/< appli >/< job >[< type de lien >] type de lien : obli | facu | excl | cond | erre O,C,R,F c * 7 O,C,R,F c * 31 O,C,R,F O,C,R,F c * 12

aucun defaut de l’application OOOOOOO (O * 7) C * 31 OOOOO OOOOOOOOOOOO aucune aucune

NO (non planfié) | AV (a venir) | EN (en cours) | ER (en erreur) | TE (terminé) (terminé) | DE DE (deplanifié)

AV (a venir)

hxl+y+x h:hauteur, l: largeur, y: ordonnée, x:abscisse

90*16+0+0

< env >/< appli > 1 pour la mise en exploitation

defaut IHM defaut IHM defaut IHM aucun



11.3 Ajout ou modification d'un traitement Pour UNIX : Pour NT :

taddjob taddjob /n /nom=e om=env/ap nv/app/jo p/job b /script= /script= ript> [ options options ] idem

La commande taddjob permet la création ou la modification d’un job dans un environnement et une application avec toutes ses caractéristiques définies en options (voir le tableau tab leau des de s options de la commande tad taddjob ci-après) b ci-après).. En mode création, seuls le nom et le script du traitement sont obligatoires. obligatoires. Le traitement hérite alors de toutes les caractéristiques par défaut de l’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 Nom Script Commentaire Famille Type de périodicité Cyclique période du cycle Periodicité Heure de départ minimum Heure de départ maximum Mode d'exécution Machine Queue batch Utilisateur ne pas déplanifier les successeurs Heure de déplanification Blocage de la date d'exploitation mettre l'application en erreur

Mode commande /Nom /Script /Comm /Family /TypePer /Cyclique /Cycle /Per /Hdeb /Hfin /Mode /Machine /Queue /User /NonDepl /Hdepl /Bloquant /ApplErr

Liste des paramètres

/Par


Mode export [job://] Script commentaire Famille type_periodicite cyclique cycle periodicite heure_debut heure_fin m ode machine queue user ne_pas_deplanifier heure_deplanification bloquer_la_date mettre_application_en_err eur parametres

valeurs / format <script> <"commentaire"> <« famille »> periodique | demande oui | non journaliere | hebdomadaire | mensuel | annuel stop | exec | test | simu <"machine"> <"queue"> <"utilisateur"> oui | non oui | non oui | non

défaut obligatoire obligatoire aucun aucune periodique non 00:00:00 journalière 00:00:00 illimite exec defaut de l'application defaut de l'application defaut de l'application non 23:59:59 oui oui

< par1 >[,< par2 >,...,< parn >]

aucun

vt-admin-guide.doc

53/ 65 65


11.4 Suppression d'un traitement tr aitement Pour Pour UNI UNIX X : tdel tdeljo jobb -a -a app app –e env env -j-j job job Pour NT : idem La commande comm ande tde tdeljob job permet de supprimer suppr imer un job donné d'une application app lication donnée d'un environnement donné.

11.5 Suppression d’un lien Pour Pour UNIX : tdell tdellink ink env/a env/app/ pp/job job (de) (de)env env/ap /app/j p/job ob(ve (vers) rs) Pour NT : idem La commande comm ande tde tdellink permet de supprimer suppr imer un lien entre entr e traitements trait ements ou applications. applica tions. 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. Remarque   X-Lien ET et Lien OU non supportés


vt-admin-guide.doc

65 55/ 65


12 Serveur de backup Visual TOM permet d’avoir un niveau de sécurité supplémentaire grâce au module Back-up Serveur. La mise en place d’un serveur de back up Visual TOM permet d’avoir une sauvegarde en temps réel du référentiel (base) grâce la synchronisation des base entre le serveur primaire et le serveur de back up. Deux variables d’environnement doivent être positionnées lors de la mise en place de la solution 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'un serveur 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 que les commandes rcp et rlogin soient actives. La fin de la synchronisation des bases est signalée sous Unix. Sous NT, la synchronisation des bases se fait manuellement en copiant le contenu du ré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 la base : à chaque mise a jour de la base de données du serveur primaire, une requête de mise a jour est envoyée sur le serveur de back up. Ce mécanisme permet d'obtenir en temps ré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 serveur primaire

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

56/ 65

vt-admin-guide.doc


13/09/02


back up, le serveur de back up envoi à chaque client une requête leur demandant de tester la présence du serveur primaire. Si, au moins un client, réussit dans ce test de présence du serveur primaire, le basculement ne 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 de cette commande, le serveur de back up envoi une requête de test d’activité vers le serveur primaire. Si le serveur primaire répond au serveur de back up, alors celui-ci renvoi une requête demandant au serveur primaire de vérifier sa connexion avec chacun des clients. Si aucun des 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 le deuxiè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 primaire démarrent sur le serveur de back up (attention, selon la configuration de votre machine, le dé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 primaire après son basculement, il refuse alors la mise a jour et envoie une requête au serveur principal 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 et clients). Arrêt des processus sur le serveur primaire (moteurs, interfaces graphiques et clients).



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



Démarrage des processus des serveurs


vt-admin-guide.doc

65 57/ 65


13 Configuration des modules I-Superviser et Webdoc Les modules I-Superviser I-Supervise r et webdoc utilisent une passerelle applicative appelée I-Server afin de communiquer avec les domaines d’exploitation de Visual TOM.

13.1 Configuration de la passerelle passer elle I-Server Le fonctionnement de la passerelle i-server est assuré par un exécutable isever et deux fichiers de configuration iserver.ini et security.ini. security.ini. La localisation du processus iserver est définie lors de la phase d’installation (cf guide d’installation vt-ins-guide). La localisation du fichier de configuration iserver.ini est indiquée par la variable d’environnement d’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 f ile de la section [security] du fichier iserver.ini.

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

Serveur avec les modules i-superviser et weddoc; c’est à dire que lorsque ce processus est démarré, il se met en état d’écoute sur le port de communication TCP listenPort. La valeur 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 est actif, il utilise l’adresse IP de la machine du serveur Visual TOM et les numéros de port des processus du module serveur pour adresser une requête vers le serveur Visual TOM. Les valeurs des paramètres qui permettent de communiquer avec un serveur Visual TOM sont renseignées dans la section [domain] du fichier de configuration iserver.ini

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

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

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

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

Sous Windows :

Le processus iserver fonctionne sous le service Windows Absyss iServer. La commande d’installation d’installation du processus iserver en tant que service Windows est la suivante : IServer –install La commande de désinstallation du processus iserver en tans que service Windows est la suivante : IServer –remove

58/ 65

vt-admin-guide.doc


13/09/02


Le démarrage et l’arrêtET1 p.637erelle I-server s’efect en ut fonction Windows : Démarrer ->p.6r6mètres ->p.6r6mètres -> panneau.61 panneau.61 configur6tion configur6tion ->7ervices

13.1.3 Fichier 61 configuration iserver.ini Le nom complet du.chemin.(chemin absolu) est pointép.6r1 pointép.6r1 pvariable d’environnement Ie cont 61 c1 fichier estsuivant: estsuivant: [i7erver] name = nom 61 la machine d’installation d’install ation du I-server loc6tion = nom de la société contact = adresse E-mail du responsable technique listentPort = numéro 61 port d’écoute 6u service Iserver [domain] host dserverPort gserverPort gserverPor t pserverPort

= nom ou adresse IP 6u domaine d’exploitation d’exploita tion 61 Visual TOM = numéro 61 port du dserver = numéro 61 port du gserver = numéro 61 port du pserver

[7ecurity] file

= nom complet du fichier security.ini.(\curity.ini) security.ini.(\curity.ini)

[extras] ping Base BaseUrl Url

nom complet 6u scrip ript permettan tant 61 tes tester ter la présence d’un1 machine (unix seulement ) Url Url 61 61 bas basee 61 61 la la doc docum umen enta tatition on et 6es 6es con consi sign gnes es.L .Laa 6oc 6ocum umen enta tatition on et les les consignes 6oivent s1 trouver 6ans l1 répertoire aseUrl/NomDomaine/

[options] Famil Familyln ylnLis Lists ts 1 LastExecl LastExeclnLis nLists ts 0

1 pour pour qu1 la famill famill11 soit soit passé passéee 6ans 6ans les listes listes,, 0 sinon sinon 0 pour pour qu1 la date 61 la dernière dernière exécution exécution soit passée passée 6ans les listes, 0 sinon

13.1.4 Fichier securty.ini Ce fichier peut être installé 6ans un répertoire répertoire sécurisé. Ce fichier contient contient la liste 61s utilisateurs pouvant avoir accès aux fonctionnalités 61 la passerell1 I-server : [USER1] name password alias enabl1

= nom 61 l’utilisateur l’utilisat eur = mot 61 passe = alias Visual TOM = 1 actif, 0 inactif (cet utilisateur est actif par défaut)

[USER2] ……..


vt-admin-guide.doc

65 59/ 65


13.2 Configuration du I-Superviser I -Superviser Le module I-Superviser I-Superviser est écrit en langage Java et s’exécute sous sous l’environnement 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. isuperviser.exe. La localisation de ces fichiers est lors de la phase d’installation (cf Guide d’installation vt-ins-guide). Le module I-superviser dialogue en mode client avec la passerelle iserver. Pour cela, Il utilise les paramètres host, port et user définis dans le fichier de configuration configuration isuperviser.ini. isuperviser.ini. Sous Unix, le lancement du module isuperviser s’effectue de la manière suivante : java –jar isuperviser.jar i superviser.jar isuperviser.ini 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 host = nom nom de la la machi machine ne où où est est insta installlléé le mod module ule I-Serv I-Server er port port = numér numéroo de por portt d’écou d’écoute te du I-serve I-serverr (liste (listenPo nPort rt dans dans le le fichi fichier er 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] sortB sortByL yLas astE tExe xecc

1 pour pour le le tri tri par par dern derniè ière re exé exécu cutition on,, 0 sino sinon. n. La La vale valeur ur par par déf défau autt est est 0

13.3 Configuration du webdoc w ebdoc Le module WebDoc est un cgi, il faut donc, au préalable installer un serveur http et configurer 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 variable d’environnement d’environnement WEBDOC_INI. W EBDOC_INI. Le fichier webdoc.ini possède la structure suivante : [Iserver] host = nom de la machine où est installé installé le module I-Server port= 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\\ . \\Template\\ language =langue utilisée : Fr_FR ou En_US wwwBase=base de l’adresse web du webdoc, exemple : http://localhost/webdoc cgiBase=base cgiBase=base de l’adresse web du cgi, exemple : http://localhost/cgi-bin/webdoc http://localhost/cgi-bin/webdoc pageSize=nombre 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 Apache dans le fichier index.html situé dans dans le sous-répertoire sous-répertoire www du répertoire d’installation d’installation du 60/ 65

vt-admin-guide.doc


13/09/02


module webdoc. Pour cela, il faut mettre à jour des lignes suivantes : Options Indexes FollowSymLinks FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all # Droits du répertoire images du WebDoc mg"> Options Indexes FollowSymLinks FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all # Droits du répertoire feuilles de styles du WebDoc Options Indexes FollowSymLinks FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all et ajouter ScriptAlias /cgi-bin/ "C:/vtom/WebDoc/cgi-bin/" "C:/vtom/WebDoc/cgi-bin/" Pour lancer le module webdoc, il faut ouvrir un navigateur Web puis ouvrir l'URL du serveur ou est installé le WebDoc (ex: http://localhost/ ), et cliquer sur "Lancer l'outil de documentation".


vt-admin-guide.doc

65 61/ 65


14 Guide de l’utilisateur du support standard standard 14.1 ASSISTANCE TELEPHONIQUE 14.1.1 Comment nous contacter Appeler au 01.40.84.89.01 ou [email protected] De 8 heures à 19 heures Du lundi au Vendredi

14.1.2 Avant Avant d’appeler le support Sources d’informations à consulter. Une abondante documentation technique technique est mise à votre disposition : - Guides d’utilisation et d’installation 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 www.absyss.com ‘’ en cliquant cliquant sur support, support, l’utilisateur l’utilisat eur = nom de votre société et le password = abs ! suivi des 3 premières lettres 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 machine et le système d’exploitation d’exploitation (OS) (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 ensemble programmes-jeu programmes-jeu de données, permettant de reproduire l’incident de façon systématique ). - Connexion sur le site client via le modem pour une télé-maintenance.

14.1.4 Dans quels cas appeler le support Une assistance technique peut être sollicitée dans les cas suivants : - Questions sur l’installation - Identification, résolution ou contournement contournement d’erreurs logicielles (bogues) - Demande d’amélioration de produit . 62/ 65

vt-admin-guide.doc


13/09/02


Toute question ou tout problème soumis au support donne lieu à la création d’une ‘Demande d’Assistance Technique Technique ‘ ( DAT ). ). Chaque DAT permet ainsi d’identifier un problème unique et de le suivre jusqu’à sa résolution : un N° d’appel (de référence) est communiqué à la création de la demande d’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 un contournement contournement mutuellement acceptable a été fourni . Un appel fermé peut être réouvert si nécessaire à condition que le problème soit le mê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 support Tout client ayant un contrat de maintenance peut demander une assistance technique auprès du support . Il est souhaitable que les personnes qui appellent le support connaissent le produit et leur environnement opérationnel.

14.2 MAINTENANCE DES SYSTEMES VISUAL TOM 14.2.1 Sauvegarde Sauvegarde et restauration Tout client doit impérativement mettre en place des procédures de sauvegarde et de restauration afin d’éviter la perte de données. Nous vous conseillons conseillons de faire régulièrement régulièrement vos sauvegardes et de pratiquer des simulations de restauration afin de vous assurer des résultats. r ésultats. En supplément des utilitaires de vos OS, O S, vous disposez dans la documentation documentation Visual Tom de tous les outils de sauvegarde et de restauration.

Remarque : nous pouvons vous offrir des services, conseils pour le choix et l’élaboration d’une stratégie de sauvegarde adéquate . Ces services font l’objet d’une tarification. 14.2.2 Environnement Environnement de test L’environnement 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 tests reproductibles. Copyright © ABSYSS. All rights reserved reserved 13/09/02

vt-admin-guide.doc

65 63/ 65


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 votre environnement de test, les volumes de données ou les transactions de votre environnement réel, il n’en demeure pas moins qu’un environnement de test permet de 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 les ré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 documentation ,nous rappelons qu’elle est disponible disponible sur le CD et internet. - de vérifier tous les pré-requis logiciels et matériels. - de la valider sur votre environnement environnement de test avant l’installation réelle réelle de production.

64/ 65

vt-admin-guide.doc


13/09/02


HOTLINE 01 40 84 89 01 01 [email protected]

ABSYSS 15/17, boulevard du Général de Gaulle 92120 - MONTROUGE - FRANCE 33 (0) 1 40 84 89 01 33 (0) 1 40 84 88 40 Fax [email protected]

www.absyss.com


vt-admin-guide.doc

65 65/ 65

Vt Admin Guide

Recommend Documents