Visual TOM Guide Administrateur

Visual TOM Guide Administrateur
ss
SIMPLICITE, FIABILITE, AGILITE,

AU SERVICE DE LA PERFORMANCE INFORMATIQUE ET METIER
Version 6.5.1D
Absyss ©
Réf : Visual TOM Guide administrateur - 651D.doc 1/183
Absyss ©
SOMMAIRE
1 Objectifs ........................................................................................................................................................................................................... 9
1.1 Liste des modules. ............................................................................................................................................................................................ 9
1.1.1 Visual TOM Serveurs (Référentiel, Ordonnanceur). .......................................................................................................................................... 9
1.1.2 Visual TOM Agents (Exécution des tâches sur une machine) ........................................................................................................................... 9
1.1.3 Visual TOM XVision VT-XVI (Conception, Pilotage) ......................................................................................................................................... 10
1.1.4 Visual TOM Modules optionnels ..................................................................................................................................................................... 10
1.2 Terminologie de base. .................................................................................................................................................................................... 10

2 Module Serveur .............................................................................................................................................................................................. 11
2.1 Installation d’un serveur Unix ......................................................................................................................................................................... 11
2.1.1 Désinstallation ................................................................................................................................................................................................ 11
2.1.2 Préparatifs ...................................................................................................................................................................................................... 11
2.1.3 Transfert de l’archive ...................................................................................................................................................................................... 11
2.1.4 Le fichier de configuration de l'installation : install_vtom.ini ......................................................................................................................... 12
2.1.5 Lancement du script d’installation.................................................................................................................................................................. 12
2.1.6 Fichier de configuration du profil de l’administrateur du Serveur .................................................................................................................. 13
2.1.7 Validation de l’installation .............................................................................................................................................................................. 15
2.1.8 Repartir d’une base de données vide ............................................................................................................................................................. 19
2.2 Installation d’un serveur Windows ................................................................................................................................................................. 19

2.2.2 Préparatifs ...................................................................................................................................................................................................... 20
2.2.3 Lancement du programme d’installation........................................................................................................................................................ 20
2.3 Mise en œuvre de la solution de Backup Visual TOM ..................................................................................................................................... 25

2.3.1 Pré requis pour la mise en œuvre de la solution du backup ........................................................................................................................... 25
2.3.2 Installation et configuration du serveur primaire ........................................................................................................................................... 25
2.3.3 Installation et configuration du serveur de backup ........................................................................................................................................ 26
2.3.4 Procédure de démarrage des serveurs ........................................................................................................................................................... 26
2.3.5 Procédure d’arrêt des serveurs ...................................................................................................................................................................... 27
2.3.6 Mécanisme de basculement automatique ..................................................................................................................................................... 27
2.3.7 Test d’activité ................................................................................................................................................................................................. 27
2.3.8 :Installation et configuration du serveur de backup en mode réplication uniquement .................................................................................. 29
2.3.9 Mode commande sur le serveur de backup.................................................................................................................................................... 30
Absyss ©
3 Module Agent .................................................................................................................................................................................................31

3.1 Installation d’un agent Unix ............................................................................................................................................................................31
3.1.1 Désinstallation ................................................................................................................................................................................................31
3.1.2 Préparatifs ......................................................................................................................................................................................................31
3.1.3 Transfert de l’archive ......................................................................................................................................................................................31
3.1.4 Le fichier de configuration de l'installation : install_vtom.ini .........................................................................................................................32
3.1.5 Lancement du script d’installation ..................................................................................................................................................................32
3.1.6 Fichier de configuration du profil de l’administrateur du Serveur ..................................................................................................................32
3.1.7 Validation de l’installation ..............................................................................................................................................................................34
3.2 Installation d’un agent Windows ....................................................................................................................................................................37

3.2.2 Préparatifs ......................................................................................................................................................................................................38
3.2.3 Lancement du programme d’installation........................................................................................................................................................38
3.3 Installation d’un agent As400 .........................................................................................................................................................................40

3.3.1 Pré-requis .......................................................................................................................................................................................................40
3.3.2 Contrôle des ports de communication TCP ....................................................................................................................................................41
3.3.3 Sauvegarde d’une installation ........................................................................................................................................................................41
3.3.6 Installation ......................................................................................................................................................................................................43
3.3.8 Démarrage automatique de l’agent................................................................................................................................................................51
3.3.9 Module de réponse automatique ...................................................................................................................................................................52
3.4 Installation d’un agent GCOS7 ........................................................................................................................................................................55

3.4.1 Pré-requis .......................................................................................................................................................................................................55
3.4.2 Installation ......................................................................................................................................................................................................55
3.4.3 Validation de l’installation de l’agent .............................................................................................................................................................56
3.5 Installation d’un agent GCOS8 ........................................................................................................................................................................59

3.5.1 Pré-requis .......................................................................................................................................................................................................59
3.5.2 Installation ......................................................................................................................................................................................................59
3.5.4 Réinstallation ou mise à jour de l’agent..........................................................................................................................................................63
3.6 Installation d’un agent VMS ...........................................................................................................................................................................64

3.6.1 Pré-requis .......................................................................................................................................................................................................64
Absyss ©
3.6.3 Installation ...................................................................................................................................................................................................... 65
3.6.4 Arrêt et démarrage de l’agent ........................................................................................................................................................................ 67
3.7 Installation d’un agent Z/OS ........................................................................................................................................................................... 70

3.7.1 Pré-requis ....................................................................................................................................................................................................... 70
3.7.2 Contrôle des ports de communication TCP .................................................................................................................................................... 70
3.7.3 Sauvegarde d’une installation ........................................................................................................................................................................ 71
3.7.5 Transfert des archives..................................................................................................................................................................................... 71
3.7.6 Installation ...................................................................................................................................................................................................... 72
3.7.8 Fonctionnalités ............................................................................................................................................................................................... 75
3.7.9 Programme de synchronisation « tstartwait » ............................................................................................................................................... 76
3.8 Installation en mode Cluster........................................................................................................................................................................... 78

3.8.1 Principe........................................................................................................................................................................................................... 78
3.8.2 Serveur Visual TOM en mode actif / passif ..................................................................................................................................................... 78
3.8.3 Agent Visual TOM en mode actif / passif ........................................................................................................................................................ 79
3.8.4 Agent Visual TOM en mode actif / actif .......................................................................................................................................................... 79
4 Modules XVISION............................................................................................................................................................................................ 82
4.1 Module IHM ................................................................................................................................................................................................... 82
4.1.1 Pré-requis ....................................................................................................................................................................................................... 82
4.1.2 Installation sous Unix ...................................................................................................................................................................................... 82
4.1.3 Installation sous Windows .............................................................................................................................................................................. 84
4.1.4 Gestion de la langue ....................................................................................................................................................................................... 87
4.1.5 Composant Dossier d’exploitation .................................................................................................................................................................. 87
4.1.6 Modules additionnels ..................................................................................................................................................................................... 88
5 Mise en œuvre du portail Web ....................................................................................................................................................................... 89

5.1 Installation sous Unix...................................................................................................................................................................................... 89
5.1.2 Transfert de l’archive ...................................................................................................................................................................................... 89
5.1.3 Exécution de la procédure d’installation ........................................................................................................................................................ 90
5.2 Installation sous Windows .............................................................................................................................................................................. 91

5.2.2 Lancement du programme d’installation........................................................................................................................................................ 91
Absyss ©
5.3 Paramétrage ...................................................................................................................................................................................................93

5.4 Démarrage du processus ................................................................................................................................................................................96
5.5 Arrêt du processus..........................................................................................................................................................................................96
6 Mise en œuvre de la sécurisation des flux avec ssl .........................................................................................................................................97
6.1 Configuration du serveur ................................................................................................................................................................................97
6.2 Utilisation de l’interface .................................................................................................................................................................................97
6.3 Configuration pour les agents.........................................................................................................................................................................97
6.4 Configuration pour le mode commande.........................................................................................................................................................98
6.5 Configuration pour le serveur http .................................................................................................................................................................98
6.6 Configuration pour le serveur d’api rest .........................................................................................................................................................98
6.7 Configuration globale .....................................................................................................................................................................................98
7 Mise en œuvre de la sécurisation des soumissions ........................................................................................................................................99
8 Mise en œuvre de IgraphBuilder .................................................................................................................................................................. 100

8.1 Installation sous Unix .................................................................................................................................................................................... 100
8.1.1 Transfert de l’archive .................................................................................................................................................................................... 100
8.1.2 Validation de l’installation ............................................................................................................................................................................ 100
8.2 Installation sous Windows ............................................................................................................................................................................ 100

8.2.1 Validation de l’installation ............................................................................................................................................................................ 100
8.3 Paramétrage ................................................................................................................................................................................................. 101

9 Installation de l’agent SNMP ........................................................................................................................................................................ 103
9.1 Principes de fonctionnement ....................................................................................................................................................................... 103
9.2 Agent SNMP Unix ......................................................................................................................................................................................... 103
9.2.1 Installation .................................................................................................................................................................................................... 103
9.2.2 Paramétrage du fichier des services ............................................................................................................................................................. 104
9.2.3 Paramétrage de la configuration SNMP........................................................................................................................................................ 104
9.2.4 Gestion des processus Agent ........................................................................................................................................................................ 104
9.3 Agent SNMP Windows .................................................................................................................................................................................. 105

9.3.1 Installation .................................................................................................................................................................................................... 105
9.3.2 Paramétrage du fichier des services ............................................................................................................................................................. 105
9.3.3 Paramétrage de la configuration SNMP........................................................................................................................................................ 106
9.3.4 Gestion du processus Agent ......................................................................................................................................................................... 106
9.4 Intégration Framework SNMP ...................................................................................................................................................................... 106

9.4.1 Installation .................................................................................................................................................................................................... 106
9.4.2 Description de la MIB ................................................................................................................................................................................... 107
9.4.3 Exemples d’intégration de la MIB ................................................................................................................................................................. 108
10 Principes de fonctionnement des processus ................................................................................................................................................ 109

10.1 Processus serveur ......................................................................................................................................................................................... 109
10.1.1 Processus de gestion de la production ......................................................................................................................................................... 109
10.1.2 Processus de gestion de la base de données ................................................................................................................................................ 109
10.1.3 Processus d’ordonnancement ...................................................................................................................................................................... 110
Absyss ©
10.1.4 Processus serveur d’APIs REST...................................................................................................................................................................... 110
10.2 Processus agent ............................................................................................................................................................................................ 110

10.3 Processus de mise à jour de l’agent.............................................................................................................................................................. 111
10.4 Processus Interface graphique ..................................................................................................................................................................... 112
11 Administration des processus ....................................................................................................................................................................... 113
11.1 Administration sous Unix .............................................................................................................................................................................. 113
11.2 Administration sous Windows ...................................................................................................................................................................... 115
12 Configuration du serveur .............................................................................................................................................................................. 116
12.1 Ports de communication .............................................................................................................................................................................. 116
12.2 Variables d’environnement .......................................................................................................................................................................... 116
12.3 Fichier de configuration vtom.ini .................................................................................................................................................................. 118
12.4 Fichier de configuration vtomapiserver.ini ................................................................................................................................................... 118
12.5 Sécurisation de l’accès à la base de données ............................................................................................................................................... 119
12.5.1 Configuration sous Unix ................................................................................................................................................................................ 119
12.5.2 Configuration sous Windows ........................................................................................................................................................................ 120
12.5.3 Configuration en contexte primaire/backup ................................................................................................................................................ 122
13 Configuration de l’agent ............................................................................................................................................................................... 123

13.1 Ports de communication .............................................................................................................................................................................. 123
13.2 Variables d’environnement .......................................................................................................................................................................... 123
13.3 Fichier de configuration vtom.ini .................................................................................................................................................................. 125
13.4 Gestion des utilisateurs de soumission......................................................................................................................................................... 125
13.5 Gestion des Queues Batch ............................................................................................................................................................................ 127
13.6 Variables connues pour les travaux exécutés ............................................................................................................................................... 129
13.7 Gestion des traces d’exécution..................................................................................................................................................................... 130
13.8 Gestion des priorités d’exécution ................................................................................................................................................................. 131
13.9 Vision du code retour ................................................................................................................................................................................... 132
13.10 Visualisation des traces sur les connecteurs ................................................................................................................................................. 132
13.11 Mécanisme de sécurisation du moteur ........................................................................................................................................................ 133
14 Intégration LDAP........................................................................................................................................................................................... 134
14.1 Authentification............................................................................................................................................................................................ 135
14.2 Connexion sans déclaration des comptes ..................................................................................................................................................... 136
14.2.1 Connexion basée sur un attribut LDAP ......................................................................................................................................................... 136
14.2.2 Connexion basée sur les groupes LDAP ........................................................................................................................................................ 137
15 Configuration de l’interface .......................................................................................................................................................................... 140

15.1 Port de communication ................................................................................................................................................................................ 140
15.2 Fichier de configuration VTXVision.ini .......................................................................................................................................................... 141
16 Configuration du moteur .............................................................................................................................................................................. 144
16.1 Mise à jour du référentiel lors de la bascule de Date ................................................................................................................................... 144
16.2 Autres besoins .............................................................................................................................................................................................. 144
17 Mode commande sécurisé ........................................................................................................................................................................... 145
18 API REST sécurisées ...................................................................................................................................................................................... 146
19 Principales commandes Serveur ................................................................................................................................................................... 148

19.1 Processus Serveur......................................................................................................................................................................................... 148
19.1.1 Démarrage des processus ............................................................................................................................................................................. 148
19.1.2 Arrêt des processus ...................................................................................................................................................................................... 148
Absyss ©
19.2 Processus Moteur ......................................................................................................................................................................................... 149

19.2.1 Démarrage du moteur de l’environnement spécifié ..................................................................................................................................... 149
19.2.2 Arrêt du moteur de l’environnement spécifié .............................................................................................................................................. 149
19.2.3 Test de l’état d’un moteur sur un environnement........................................................................................................................................ 149
19.2.4 Remise à zéro de l’indicateur d’état d’un moteur dans la base .................................................................................................................... 149
19.3 Sauvegarde et restauration de la base ......................................................................................................................................................... 149

19.4 Purges ........................................................................................................................................................................................................... 150
19.4.1 Statistiques ................................................................................................................................................................................................... 150
19.4.2 Historique ..................................................................................................................................................................................................... 151
19.5 Suivi .............................................................................................................................................................................................................. 153

19.5.1 Journées d’exploitation ................................................................................................................................................................................ 153
19.5.2 Anomalies ..................................................................................................................................................................................................... 153
19.5.3 Risques ......................................................................................................................................................................................................... 153
19.5.4 Périmètre technique ..................................................................................................................................................................................... 153
20 Principales commandes Agent...................................................................................................................................................................... 154

20.1 Processus Agent ........................................................................................................................................................................................... 154
20.1.1 Démarrage du processus .............................................................................................................................................................................. 154
20.1.2 Arrêt du processus ........................................................................................................................................................................................ 154
20.2 Gestion des Ressources ................................................................................................................................................................................ 154

20.2.1 Gestion des piles ........................................................................................................................................................................................... 154
20.2.2 Gestion des ressources textes ...................................................................................................................................................................... 154
20.2.3 Gestion des ressources numériques ............................................................................................................................................................. 155
20.2.4 Utilitaire de vérification de fichier ................................................................................................................................................................ 155
ANNEXE A : Liste des commandes serveur ................................................................................................................................................................... 156
ANNEXE B : Liste des commandes agent....................................................................................................................................................................... 159
ANNEXE C : Paramètres de configuration du fichier vtom.ini ....................................................................................................................................... 162
ANNEXE D : VARIABLES d’ENVIRONNEMENT iMPACTANT LE FONCTIONNEMENT ....................................................................................................... 182
Absyss ©
1 OBJECTIFS
Ce document décrit les procédures d’installation des différents modules de la suite logicielle Visual TOM.
Pour faciliter la compréhension du lecteur, les modules de la suite logicielle Visual TOM sont décrits ci-dessous. Ces
modules sont regroupés en cinq familles :
• Visual TOM Serveurs

• Visual TOM Agents
• Visual TOM Xvision
• Visua TOM Xapplication
• Visual TOM XFR
Pour plus de précisions sur les pré-requis, reportez-vous au document général des pré-requis.
1.1 LISTE DES MODULES.
1.1.1 Visual TOM Serveurs (Référentiel, Ordonnanceur).

Visual TOM Enterprise Server (VT-SES)
Ce module est l’élément de base de toute architecture. Il inclut le référentiel de production, l’ordonnancement des
Jobs et les APIs. Il peut être installé indifféremment sur des machines UNIX ou Windows.
Visual TOM Departmental Server (VT-SDS)
Ce module gère l'autonomie des sites distants. Il répartit 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 Windows.
Visual TOM Backup Server (VT-SBU)
Ce module relaye automatiquement un serveur Visual TOM en cas d’incident. Il est 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 Windows.
1.1.2 Visual TOM Agents (Exécution des tâches sur une machine)
Visual TOM Agent (VT-CS)
Ce module fonctionne en architecture Client/Serveur. Il dépend d’un Visual TOM serveur; il reçoit les ordres de
soumission en provenance du serveur et exécute les traitements batch. (exemple. : Exécution d’une tâche sur une
machine). Il peut être installé indifféremment sur des machines UNIX ou Windows, VAX/VMS, Open VMS, AS400,
GCOS7 et GCOS8.
Visual TOM Net Agent (VT-CN)
Ce module possède en local son propre référentiel de production, lui garantissant l’autonomie de fonctionnement. Il
peut être installé indifféremment sur UNIX ou NT.
Absyss ©
1.1.3 Visual TOM XVision VT-XVI (Conception, Pilotage)

Visual TOM IHM
Ce module représente l’interface graphique. Elle se connecte à tout type de serveur Visual TOM. Elle permet la
modélisation, la gestion et le pilotage de la production multi plates-formes UNIX et Windows.
Visual TOM Portail
Ce module est une Interface internet permettant de visualiser les caractéristiques des objets du domaine
d’exploitation Visual TOM (ressources, calendriers, environnements, applications, traitements …), et d’assurer le suivi
des travaux.
1.1.4 Visual TOM Modules optionnels

Visual TOM Xframework (VT-XFR) :
Ce module est une intégration à un système d’information possédant une plate-forme de supervision de systèmes et
de réseaux et/ ou d’application.
Visual TOM Xapplication (VT-XAP) :
Ce module est une intégration entre l’application Visual TOM et un progiciel du marché (comme SAP R/3, BAAN, JDE, PEOPLE
SOFT, ORACLE APPLICATIONS, …).
1.2 TERMINOLOGIE DE BASE.
Traitement :
Le Traitement représente une tâche élémentaire exécutable (script, exécutable, commande).
Application :
L’Application est un ensemble cohérent de Traitements.
Environnement :
L’Environnement est un ensemble d’Applications.
Moteur :
Le Moteur est un processus qui gère la planification et l’ordonnancement de tous les travaux d’un Environnement.
Domaine :
Le Domaine est l’ensemble des objets constituant le référentiel (Environnements, Agents, Utilisateurs…).
Utilisateur :
L’Utilisateur est le compte sous lequel est soumis le Traitement.
Queue Batch :
La Queue Batch est l’encapsulation scriptée d’un Traitement ; elle correspond à un comportement d’exécution.
Absyss ©
2 MODULE SERVEUR
2.1 INSTALLATION D’UN SERVEUR UNIX
Il est recommandé d’utiliser un système Windows disposant d’un lecteur CD-ROM et de transférer par FTP l’archive
du CD-ROM vers le système Unix.
! La version de l’interface doit impérativement être la même que celle du serveur.
2.1.1 Désinstallation
Dans le cas d’une réinstallation ou mise à jour, il est recommandé d’effectuer une désinstallation de Visual TOM.
Pour désinstaller Visual TOM, il faut arrêter tous les processus de Visual TOM :
• Les Moteurs (processus tengine),

• Les interfaces graphiques,
• Les processus serveurs actifs et agents actifs.
Lorsque Visual TOM est inactif et après avoir effectué une sauvegarde (fichier vtom.ini et base au minimum pour le
serveur, queues batch/submitter pour l’agent), vous supprimez le répertoire d’installation de Visual TOM.
2.1.2 Préparatifs
Il est nécessaire de disposer d’un compte utilisateur qui administrera Visual TOM. Par défaut, le compte vtom, est
utilisé mais il est possible de prendre n’importe quel utilisateur du système.
Visual TOM est fourni avec des procédures d’administration en c-shell, tc-shell, bourne shell ou korn shell, ainsi
l’utilisateur qui administrera Visual TOM pourra fonctionner indifféremment avec l'un de ces shells.
Visual TOM étant installé à partir du compte administrateur du système, le mot de passe de root sera nécessaire
pour installer Visual TOM.
2.1.3 Transfert de l’archive

Sélectionnez dans le répertoire « Installation » le module correspondant à votre système d’exploitation :
• VT-SES pour la solution Entreprise Server,

• VT-SDS pour la solution Departemental Server,
• VT-SBU pour la solution Back-up Server.
Copiez les archives représentant le module à installer vers le répertoire temporaire d’installation. Les fichiers copiés
sont :
• install_vtom script d'installation

• install_vtom.ini fichier de configuration de l’installation
• <module.os.version> archive du module à installer
Absyss ©
Pour la copie de ces fichiers, il est recommandé d’utiliser un système Windows, disposant d’un lecteur CD-ROM, et
de transférer les fichiers par FTP. Les modes de transfert des fichiers sont les suivants :
• bin pour le fichier <module.os.version>

• ascii pour les fichiers install_vtom et install_vtom.ini
2.1.4 Le fichier de configuration de l'installation : install_vtom.ini

Vous définissez les paramètres d’installation en exécutant directement le script d'installation. Vous pouvez
paramétrer le fichier de configuration install_vtom.ini, qui contient les paramètres par défaut (ex: installation de
plusieurs agents Visual TOM avec les mêmes paramètres).
 Remarques :
❑ Si vous souhaitez effectuer une installation en mode silencieux (mode batch), modifiez le paramètre
« batch » à la valeur « oui » dans le fichier install_vtom.ini.
❑ Pour que le démarrage du serveur http soit automatique, modifiez le paramètre « autostart_vthttpd » à la
valeur « oui » dans le fichier install_vtom.ini.
❑ Pour que le démarrage de l’interface SNMP soit automatique, modifiez le paramètre « autostart_tsnmp » à la
2.1.5 Lancement du script d’installation

Positionnez-vous dans le répertoire d’installation temporaire où vous avez extrait les fichiers, sous l'utilisateur root,
vérifiez que le fichier install_vtom est en mode exécutable, puis exécutez la commande suivante :
./install_vtom [module]
 Exemples :
Installation d’un module Visual TOM Enterprise Server HP
./install_vtom VT-SES-HPUX.51.Z
Installation d’un module Visual TOM Enterprise Server HP avec un module Visual TOM Agent local
./INSTALL_VTOM VT-SES-HPUX.51.Z VT-CS-HPUX.51.Z
Absyss ©
Le script d’installation utilise le fichier de configuration de l’installation (install_vtom.ini) pour proposer des
paramètres d’installation par défaut. Pour chacune des propositions, validez pour l’accepter ou entrez la nouvelle
valeur suivie d'Entrée :
• Répertoire de base de l'installation,

• Administrateur du serveur (et agent) Visual TOM,
• Navigateur HTML,
• Répertoire de la base de données,
• Répertoire de backup de la base de données,
• Répertoire des fichiers statistiques,
• Répertoire des traces du moteur,
• Solution serveur de backup : nom du serveur primaire ou de backup.
A l’issue de l’installation, vous trouverez un compte-rendu synthétique dans le fichier install_vtom.log.
Une fois l’installation terminée copiez le fichier de licence dans le sous répertoire bin du répertoire d’installation du
! serveur ([rep_install]/vtom/bin).
Mettez à jour le fichier /etc/services comme indiqué par la procédure. Si les services de votre système Unix sont
administrés par un serveur NIS, il sera nécessaire de les mettre à jour sur la machine serveur NIS s'ils ne sont pas
présents.
Il est recommandé de ne pas réaliser l’installation dans le répertoire d’accueil de l’administrateur Visual TOM ; les
droits sur les fichiers sont gérés à partir du répertoire d’installation, cela peut avoir des impacts sur les fichiers
existants.
 Remarques :
• L’interface graphique est installée automatiquement avec le module serveur.
• Le nom du chemin d'installation doit être composé uniquement de caractères alpha-numériques, tiret et
souligné, en complément du séparateur de répertoires (ex : /produits/visual_tom). Cette remarque
s’applique à l’ensemble des modules à installer.
2.1.6 Fichier de configuration du profil de l’administrateur du Serveur

L’exécution du script d’installation :
• génère un fichier de configuration du profil de l’administrateur du Serveur (vtom_init.[shell]),

• met à jour le profil de l’administrateur du serveur (.profile).
A. Fichier de configuration de l’administrateur du Serveur
Le nom du fichier de configuration du profil de l’administrateur du Serveur est établi selon la syntaxe suivante :
vtom_init.[$SHELL]. La variable $SHELL contient le nom du shell par défaut de l’administrateur du Serveur : ksh pour
korn shell, sh pour bourne shell, ….
Absyss ©
#-----------------------------------------------------------------------
# Exemple de Fichier de configuration du profil de l’administrateur du serveur Visual TOM
# ----------------------------------------------------------------------
# vtom_init.ksh
#
#General
[ -z "${HOST}" ] && HOST=frodon ; export HOST
if [ -n "${LD_LIBRARY_PATH}" ] ; then
[ -z "ècho $LD_LIBRARY_PATH | grep /usr/lib/:/usr/openwin/lib:`" ] &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/home4/vtom/visu
al:/usr/lib/:/usr/openwin/lib: ; export LD_LIBRARY_PATH
else
LD_LIBRARY_PATH=/home4/vtom/visual:/usr/lib/:/usr/openwin/lib: ; export LD_LIBRARY_PATH
fi
TOM_HOME=/home4/vtom ; export TOM_HOME
TOM_ADMIN=/home4/vtom/admin ; export TOM_ADMIN
[ -z "ècho $PATH | grep $TOM_ADMIN`" ] && PATH=${PATH}:${TOM_ADMIN} ; export PATH
TOM_USER_ADMIN=vtom ; export TOM_USER_ADMIN
# Serveur
TOM_STILL_WAIT=yes ; export TOM_STILL_WAIT
TOM_ABORT_SIGNAL=9 ; export TOM_ABORT_SIGNAL
VTOM=/home4/vtom/vtom ; export VTOM
TOM_BACKUP=/home4/vtom/backup ; export TOM_BACKUP
TOM_BASES=/home4/vtom/bases ; export TOM_BASES
TOM_BIN=${VTOM}/bin ; export TOM_BIN
TOM_STATS=/home4/vtom/stats ; export TOM_STATS
TOM_TRACES=/home4/vtom/traces ; export TOM_TRACES
TOM_LP=${TOM_ADMIN}/tom_imprim ; export TOM_LP
[ -z "ècho $PATH | grep $TOM_BIN`" ] && PATH=${PATH}:${TOM_BIN} ; export PATH
Exemple de fichier de configuration de l’administrateur du Serveur
B. Modification du profil de l’administrateur du serveur
Les fichiers du profil .cshrc (ou .login) et .profile du profil de l’administrateur du module Serveur sont modifiés par
l’installation : une ligne contenant la commande d’exécution du fichier de configuration vtom_init[$HELL] est insérée
en fin des fichiers de profil.
#-----------------------------------------------------------------------
# Exemple de Fichier .profile de l’administrateur du serveur Visual TOM
# ----------------------------------------------------------------------
<Ligne 1>
<Ligne 2>
<Ligne 3>
…
. /home4/vtom/admin/vtom_init.ksh
Exemple d’un fichier .profile de l’administrateur du Serveur
A chaque ouverture de session par l’administrateur de Visual TOM, le script vtom_init.[$SHELL] est exécuté et les
variables d’environnement Visual TOM sont valorisées.
! A chaque nouvelle installation d’un module de Visual TOM, une ligne de commande de lancement du script
vtom_init.[$SHELL] est rajoutée à la fin du fichier .profile de l’administrateur de Visual TOM. Supprimez les lignes de
commande obsolètes.
Absyss ©
2.1.7 Validation de l’installation

La validation de l’installation est réalisée par un ensemble d’étapes.
Attention : Le paramétrage d’un émulateur X a des impacts sur le fonctionnement de l’interface graphique.
 Exemple:
Si on utilise exceed pour lancer xvision x11, le paramètre "use native WM for embedded client" doit être décoché
dans la configuration exceed au niveau de la définition de l'écran. Si ce paramètre est coché, cela peut engendrer des
erreurs sur l’interface graphique.
A. Démarrage des processus et connexion de l’IHM au serveur
Connectez-vous avec l’utilisateur d’administration du serveur et lancez la commande « admins » :
Menu « admins »
Choisissez l’option 2 pour démarrer les processus du serveur et connectez-vous au serveur à l’aide du module IHM.
Un utilisateur est défini par défaut dans la base du serveur :
• Utilisateur TOM
• Mot de passe TOM
• Domaine = <nom_de_la_machine_serveur_vtom>
 Remarque :
Les procédures d’administration sont génériques. Elles peuvent nécessiter un paramétrage de l’administrateur pour
s’adapter au contexte.
Absyss ©
B. Mise à jour de la base de données de test
Une base de données est générée lors de l’installation. Il est nécessaire de mettre à jour cette base de données pour
tenir compte des paramètres tels que le nom de la machine ou celui de l’utilisateur d’administration.
Utilisateur
Avec le menu « Domaine Exploitation / Utilisateurs », affichez la fenêtre de définition des Utilisateurs.
Cliquez sur « Nouveau » et saisissez le nom de votre administrateur du serveur, renseigné lors de l’installation.
Répertoires des scripts
Avec le menu « Domaine Exploitation / Environnements », affichez la fenêtre des Environnements.
Sélectionnez l’Environnement « exploitation » et Cliquez sur « Modifier ». La fenêtre de définition de

l’environnement apparaît.
Modifiez le champ « Répertoire des Scripts » en remplaçant « {Rep_local}/Visual_TOM » par le répertoire

d’installation du serveur.
C. Validation du bon fonctionnement de la partie serveur de Visual TOM
Ce paragraphe explique comment faire fonctionner la base de données de test en mode simulation. L’exécution des
scripts en mode simulation permet de valider le bon fonctionnement de la partie serveur (planification et
ordonnancement) de Visual TOM.
Appel du Supra manager
Sélectionnez la fonction Supra manager du menu Pilote. La fenêtre du Supra Manager apparaît.
Une barre graphique indique l’avancement de l’environnement « exploitation ».
Démarrage du moteur
Démarrez le moteur en cliquant sur l’icône de la colonne « Moteur », à droite de la barre d’avancement, et confirmez
en validant.
La barre d’avancement doit se colorer en vert à l’issue de l’exécution des travaux.
Pour obtenir une vision des Applications, double-cliquez sur le nom de l’Environnement dans le Supra manager.
Puis pour obtenir une vision des Traitements, double-cliquez sur le nom de l’Application dans le Supra manager.
Pour revenir à l’Environnement, cliquez sur le nom du Domaine, indiqué juste sous la barre du haut présentant les
différents états
Pour obtenir une vision graphique de l’Environnement, cliquez sur sa barre d’avancement.
Absyss ©
Accès au graphe
Nom du de
Domaine l’Environnement
Accès aux Bouton de

Applications démarrage du
de Moteur
l’Environneme
nt
Fenêtre Supramanager, pour le suivi des environnements
D. Validation du bon fonctionnement de l’agent
Si vous avez installé un agent sur la même machine que le serveur, ce paragraphe nous explique comment exécuter
les Traitements et consulter leur compte rendu d’exécution.
Association de l’Utilisateur de soumission à l’Environnement
Ouvrez la liste des Environnements à l’aide du menu principal « Domaine/Environnements… ». Accédez à la

définition de l’Environnement « exploitation ».
Associez l’Utilisateur maître de l’administration de Visual TOM, indiqué lors de l’installation, à l’aide du bouton de la
colonne « Valeurs possibles ». Positionnez cet Utilisateur comme étant celui par défaut sur l’Environnement.
Association d’un
Choix de Utilisateur à
l’Utilisateur l’Environnement
par défaut
Fenêtre de définition d’un Environnement
Absyss ©
Modification du mode d’exécution
Depuis le Supra manager, ouvrez le graphe de l’Environnement « exploitation ».
Basculez vers le mode conception en utilisant le bouton en bas à gauche de la fenêtre représentant le graphe de
l’Environnement.
Bascule
Conception
Pilotage
Fenêtre graphe d’un environnement, représentant les Applications
Cliquez sur l’Application « appli_test » avec le bouton droit de la souris pour obtenir son menu contextuel. Cliquez
sur « Définition », la fenêtre de définition de l’Application s’affiche.
Dans le champ « Mode d’Exécution », sélectionnez « Exécution » et validez.
Double cliquez sur l’Application pour obtenir la représentation graphique des Traitements. Cliquez sur le Traitement
« job1 » avec le bouton droit de la souris pour obtenir son menu contextuel. Cliquez sur « Définition », la fenêtre de
définition du Traitement s’affiche. Vérifiez que le script existe, en cliquant sur le bouton situé en fin de ligne du
champ « Script ». Sinon, saisissez dans le champ script la ligne suivante :
scripts/job_ ksh
Validez en cliquant sur le bouton situé en fin de ligne du champ « Script ».
Validez également l’Utilisateur par défaut.
Démarrage de l’agent
Ouvrez la console UNIX où vous avez lancé le menu pour démarrer les processus serveur. Dans le menu admins,
choisissez l’option 5- Gestion de l’agent : démarrage de l’agent.
Lancement de l’exécution
Ouvrez le graphe de l’environnement « exploitation » depuis la fenêtre Supra manager, comme vu précédemment,
pour obtenir la représentation graphique des Applications.
Cliquez sur l’Application « appli_test » avec le bouton droit de la souris, choisissez le menu « Actions », puis l’item
« Forcer à A VENIR ».
Absyss ©
Double cliquez sur l’Application pour obtenir la représentation graphique des Traitements. Ceux-ci sont passés au
statut « A VENIR » et vont s’exécuter les uns après les autres.
Visualisation du compte rendu d’exécution
Cliquez deux fois sur un des Traitements pour obtenir la liste des compte rendus d’exécution. Vous pouvez
également y accéder en utilisant le bouton droit de la souris et le menu contextuel du Traitement, puis l’item
« Logs ».
La Liste des comptes rendus d’exécution de ce Traitement s’affiche. Double cliquez sur le premier élément de la liste,
ou utilisez le menu contextuel de l’élément : le contenu du fichier compte-rendu s’affiche.
2.1.8 Repartir d’une base de données vide

Une fois validée votre installation, vous pouvez repartir d'une base de données vierge. Pour cela, arrêtez Visual TOM
(Moteur, IHM et processus serveurs). Ensuite, effacez le contenu du répertoire de la base de données :
cd $TOM_BASES
pwd
Au redémarrage des processus du serveur, la base de données est recréée, vide.
2.2 INSTALLATION D’UN SERVEUR WINDOWS
! La version de l’interface doit impérativement être la même que celle du serveur.
Dans le cas d’une réinstallation ou mise à jour, il est nécessaire d’effectuer une désinstallation de Visual TOM. Pour
désinstaller Visual TOM, il faut arrêter tous les processus de Visual TOM :
• Les Moteurs (processus tengine),

• Les interfaces graphiques,
• Les processus serveurs actifs et agents actifs.
 Remarques :
Certains répertoires ou fichiers ne seront pas supprimés après la désinstallation :
• Le fichier « vtom.ini » situé dans le répertoire %windir% contient des paramètres de configuration. Ce fichier
sera copié sous vtom.old lors d'une nouvelle installation et pourra donc être réutilisé.
• Les services TCP de Visual TOM, déclarés dans le fichier %windir%\system32\drivers\etc\services ; ils seront
les ports par défaut lors de la prochaine installation (mais pourront être modifiés).
• Les répertoires modifiés après l'installation (ex: la base de données) qui pourront être conservés, ou être
supprimés par le gestionnaire de fichiers.
• Les variables d’environnement système préfixées par TOM ou ABM (exemple « TOM_BIN ») ne sont pas
supprimées. La variable PATH n’est pas mise à jour.
Lorsque Visual TOM est inactif et après avoir effectué une sauvegarde (fichier vtom.ini et base au minimum pour le
serveur, queues batch/submitter pour l’agent), vous désinstallez à partir du setup.
Pour une désinstallation permanente, supprimez le compte « vtomsgbd » avec l’aide de votre administrateur.
Absyss ©
2.2.2 Préparatifs
Visual TOM étant installé à partir du compte administrateur du système, le mot de passe administrateur sera
nécessaire pour installer Visual TOM.
Une installation en mode RODC nécessite au préalable la création d’un utilisateur pour la gestion du compte du
! service « AbsyssSgbd ». Ce compte doit être disponible pour démarrer l’installation.
2.2.3 Lancement du programme d’installation

Sélectionnez dans le répertoire « Installation » le module correspondant à votre système d’exploitation.
Lancez l’exécutable.
La fenêtre de choix du répertoire d’installation est affichée.
Choix du répertoire d’installation
Choisissez un répertoire d’installation. Si le répertoire n’existe pas, il est créé.
Il est recommandé de ne pas utiliser un nom de répertoire comprenant des espaces, caractères accentués et
! caractères spéciaux.
Cliquez sur le bouton « Suivant » ; la fenêtre du choix des modules à installer est affichée.
Absyss ©
Choix des modules à installer
Cliquez sur le bouton « Suivant » ; choisissez les numéros de ports de communication.
Choix des numéros de ports de communication des processus
Le fichier %windir%\system32\drivers\etc\services est mis à jour par le programme d’installation.
Cliquez sur le bouton « Suivant » ; choisissez les répertoires de travail.
Absyss ©
Choix des répertoires de travail
Si ces répertoires n’existent pas, le programme d’installation les créé.
Indication de la découverte d’une ancienne installation, ou messages de création des répertoires
Cliquez sur suivant. L’installation démarre. En fin d’installation, la fenêtre suivante s’affiche :
Absyss ©
Affichage du fichier Readme.txt
Cliquez sur suivant pour finaliser l’installation.
Finalisation de l’installation
Copiez le fichier licence dans le répertoire %TOM_BIN% avant redémarrage.
! Il est impératif de redémarrer le serveur pour finaliser l’installation. Au redémarrage, les services démarrent
automatiquement.
Absyss ©
 Remarques :
❑ Deux commandes sont fournies avec le groupe de programme de Visual TOM pour une gestion plus rapide
des services.
❑ Le nom du chemin d'installation doit être composé uniquement de caractères alpha-numériques, tiret et
souligné, en complément du lecteur et du séparateur de répertoires (ex : d:\produits\visual_tom). Cette
remarque s’applique à l’ensemble des modules à installer.

Mis à part le démarrage et l’arrêt des processus, gérés en tant que services, la procédure de validation de
l’installation est identique à la validation sous Unix ; mettez à jour le champ « Répertoire des scripts » dans la
définition de l’Environnement, en remplaçant « {Rep_local}/Visual_TOM » par le répertoire d’installation du serveur.
Le champ script des Traitements est valorisé. Validez en cliquant sur le bouton situé en fin de ligne du champ
« Script », dans la définition des Traitements.
Absyss ©
2.3 MISE EN ŒUVRE DE LA SOLUTION DE BACKUP VISUAL TOM
La mise en œuvre de la solution de Backup comporte trois fonctionnalités :
• la réplication automatique des données de la base entre le serveur primaire et le serveur de backup,
• la prise de responsabilité de la planification et de l’ordonnancement par le serveur de backup en cas de
défaillance du serveur primaire (réseau, processus, machine…).
• le pilotage depuis l’interface graphique de l’état des processus et de la synchronisation.
Par défaut, l’état des processus et de la synchronisation est mis à jour toutes les 10 secondes. La mise à jour de cette
valeur est effectuée dans le fichier vtom.ini du primaire, dans l’item « backup_monitor_loop » de la section
« GLOBALES ».
La mise en œuvre de la solution de Backup consiste à
• installer deux serveurs Visual TOM,

• configurer un premier serveur en tant que serveur primaire,
• configurer le second serveur en tant serveur de backup.
2.3.1 Pré requis pour la mise en œuvre de la solution du backup

Les prérequis sont les suivants :
• Le serveur de backup doit être sur le même réseau que le serveur primaire.
• Le serveur primaire et le serveur de backup doivent utiliser le même système d’exploitation (Unix ou
Windows).
• Les arborescences d’installation doivent être identiques sur les deux serveurs.
• Sous Unix, le nom de l’administrateur de Visual TOM doit être le même sur les deux serveurs.
• Les deux machines du serveur primaire et du serveur de backup doivent pouvoir communiquer entre elles.
• Les ports TCP utilisés par Visual TOM doivent être identiques sur les deux serveurs.
 Remarque :
Lorsqu’un Traitement se termine, le serveur Primaire et le serveur de Backup sont synchronisés.
2.3.2 Installation et configuration du serveur primaire

A. Installation
La procédure d’installation d’un serveur primaire est identique à celle d’un module Serveur comme c’est décrit ci-
dessous dans le chapitre d’installation d’un module Serveur.
 Remarque :
Lors de l’installation sous Unix, vous pouvez définir le serveur de backup.
B. Configuration
Sous Unix
Une variable d’environnement TOM_BACKUP_SERVER doit être définie dans le fichier vtom_init.[$SHELL] situé dans
le répertoire $TOM_ADMIN. La variable d’environnement TOM_BACKUP_SERVER doit contenir le nom ou l’adresse
IP du serveur de backup.
Absyss ©
Sous Windows
Une variable d’environnement de type système TOM_BACKUP_SERVER doit être définie dans le système Windows
et aura comme valeur le nom ou l’adresse IP du serveur de backup.
2.3.3 Installation et configuration du serveur de backup

A. Installation
La procédure d’installation d’un serveur de backup est identique à celle d’un module Serveur comme c’est décrit ci-
B. Configuration
Sous Unix
Une variable d’environnement TOM_PRIMARY_SERVER doit être définie dans le fichier vtom_init.[$SHELL] situé
dans le répertoire $TOM_ADMIN. La variable d’environnement TOM_PRIMARY_SERVER doit contenir le nom ou
l’adresse IP du serveur primaire.
 Remarque :
Lorsque le primaire est actif, la connexion d’une interface et l’usage du mode commande sur le backup sont
proscrits.
Sous Windows
Une variable d’environnement de type système TOM_PRIMARY_SERVER doit être définie dans le système Windows
et aura comme valeur le nom ou l’adresse IP du serveur primaire.
 Remarque :
Lorsque le primaire est actif, la connexion d’une interface et l’usage du mode commande sur le backup sont
proscrits.
2.3.4 Procédure de démarrage des serveurs

Le démarrage des deux serveurs doit se faire de la manière suivante :
• Lancement des processus serveur du primaire, y compris les Moteurs,

• Attente du démarrage effectif des processus serveurs (vérification par la commande vtlist env)
Démarrage des processus serveur du backup, sans les Moteurs
• Lancement des interfaces graphiques sur le serveur primaire uniquement,
• Lancement des Moteurs d'environnements sur le serveur primaire s’il y a lieu.
Pour synchroniser les bases au démarrage, supprimer le contenu du répertoire « BASES » sur le serveur de backup.
!
Absyss ©
2.3.5 Procédure d’arrêt des serveurs

L’arrêt des deux serveurs doit se faire de la manière suivante :
• Arrêt des moteurs sur le serveur primaire,

• Arrêt des interfaces graphiques,
• Arrêt des processus du serveur de backup,
• Arrêt des processus du serveur primaire.
 Remarque :
Si l’arrêt doit être long, il est conseillé de le faire quand aucun traitement n’est en cours d’exécution, pour ne pas
risquer la perte de l’acquittement de terminaison.
2.3.6 Mécanisme de basculement automatique

Le mécanisme de basculement est piloté par le serveur de backup, en fonction de 2 cas :
• Le serveur primaire ne répond pas à une requête de test d’activité,

• Un agent ne peut dialoguer avec le serveur primaire.
2.3.7 Test d’activité

A intervalle régulier, le serveur de backup exécute une requête pour tester l’activité du serveur primaire. Si le
serveur primaire ne répond pas, le serveur de backup envoie une requête vers chaque agent pour que ceux-ci
effectuent un test d’activité. Si au moins un agent réussi le test d’activité, la procédure de basculement n’est pas
enclenchée.
A. Communication agent vers serveur non opérationnelle
Si l’agent ne parvient pas à envoyer une commande au serveur primaire (acquittement sur terminaison d’un
traitement ou mode commande), il renvoie sa commande vers le serveur de backup.
• Si le serveur de backup a pris la main, la commande se termine.

• Si le serveur de backup n’a pris la main, la commande effectue une nouvelle tentative vers le serveur
primaire.
Ce mécanisme est répété jusqu’à concurrence du nombre maximum de tentatives, indiqué par l’item
« TOM_TSEND_MAX_RETRY » de la section « GLOBALES » du fichier de paramétrage « vtom.ini » de l’Agent
exécutant la commande. Le temps entre 2 tentatives est défini par l’item « TOM_TSEND_WAIT_RETRY » dans cette
même section.
B. Procédure de basculement
Les moteurs qui étaient actifs sur le serveur primaire sont démarrés sur le serveur de backup, l’état des moteurs
étant stocké dans la base de données.
Absyss ©
 Remarques :
• Le serveur de backup devient actif lorsque le fichier « bascule » est créé dans le répertoire contenant la base.
• Si le serveur primaire est redémarré ou reçoit une demande de mise à jour, alors que le serveur de backup a
pris la main, il s’arrête immédiatement.
• Le temps maximum de prise de décision pour la bascule peut être forcé depuis le fichier vtom.ini du serveur
de backup.
• L’indisponibilité du serveur primaire est visible à partir de l’interface graphique, dans le bandeau bas. Après 5
minutes, une connexion vers le backup est proposée.
C. Retour au mode normal
Lorsque le backup a pris la main, la procédure de retour au mode normal est la suivante :
• BACKUP : Arrêt des moteurs,

• BACKUP : Arrêt des interfaces graphiques (postes utilisateurs),
• BACKUP : Sauvegarde de la base avec « vtbackup »,
• BACKUP : Arrêt des processus serveur,
• BACKUP : Suppression du contenu du répertoire « BASES », (après sauvegarde de précaution)
• PRIMARY : Arrêt des processus serveur si besoin,
• PRIMARY : Suppression du contenu du répertoire « BASES »,
• PRIMARY : Stockage de la sauvegarde effectuée avec « vtbackup » dans le répertoire « BASES »,
• PRIMARY : Relance du processus « vtsgbd »,
• PRIMARY : Relance du processus « vtserver » (y compris les moteurs),
• BACKUP : Relance des processus « vtsgbd » et « vtserver ».
D. Incident sur synchronisation
Si le serveur de backup est arrêté (ou non joignable) pendant une période supérieure à la valeur indiquée par le
paramètre « backup_sync_timeout », il sera nécessaire de faire une synchronisation avant démarrage :
• BACKUP : Arrêt des processus s’ils sont actifs,

• BACKUP : Suppression du contenu du répertoire « BASES »
• BACKUP : Relance des processus.
Le Primaire doit être accessible par le Backup pour que la synchronisation soit faite.
!
Si le backup est arrêté pendant une durée inférieure à la valeur indiquée par le paramètre « backup_sync_timeout »,
la synchronisation sera effectuée automatiquement.
Absyss ©
2.3.8 :Installation et configuration du serveur de backup en mode réplication uniquement

A. Installation
La procédure d’installation d’un serveur de backup est identique à celle d’un module Serveur comme c’est décrit ci-
B. Configuration
Sous Unix
Une variable d’environnement TOM_PRIMARY_SERVER doit être définie dans le fichier vtom_init.[$SHELL] situé
dans le répertoire $TOM_ADMIN. La variable d’environnement TOM_PRIMARY_SERVER doit contenir le nom ou
l’adresse IP du serveur primaire.
Une variable d’environnement TOM_BACKUP_MODE doit être définie dans le fichier vtom_init.[$SHELL] situé dans
le répertoire $TOM_ADMIN. La variable d’environnement TOM_BACKUP_MODE doit contenir la valeur « R ».
Les valeurs disponibles pour cette variable sont :
• r : mode réplication uniquement,

• R: mode réplication uniquement,
• s : mode réplication et transfert de responsabilité du primaire vers le backup,
• S : mode réplication et transfert de responsabilité du primaire vers le backup.
 Remarques :
• Toute autre valeur provoque l’arrêt du processus.
• La valeur est paramétrable dans le fichier vtom.ini.
Sous Windows
Sous Windows
Une variable d’environnement de type système TOM_PRIMARY_SERVER doit être définie dans le système Windows
et aura comme valeur le nom ou l’adresse IP du serveur primaire.
Une variable d’environnement TOM_BACKUP_MODE doit être définie dans le système Windows et doit contenir la
valeur « r » ou « R ».
Les valeurs disponibles pour cette variable sont :
• r : mode réplication uniquement,

• R: mode réplication uniquement,
• s : mode réplication et transfert de responsabilité du primaire vers le backup,
• S : mode réplication et transfert de responsabilité du primaire vers le backup.
 Remarques :
• Toute autre valeur provoque l’arrêt du processus.
• La valeur est paramétrable dans le fichier vtom.ini.
Absyss ©
C. Test d’activité
A intervalle régulier, le serveur de backup exécute une requête pour tester l’activité du serveur primaire. Si le
serveur primaire ne répond pas, le serveur de backup envoie une requête vers chaque agent pour que ceux-ci
effectuent un test d’activité. Si aucun agent ne réussit le test d’activité, le serveur de backup s’arrête.
2.3.9 Mode commande sur le serveur de backup

L’utilisation des commandes suivantes est autorisée sur le serveur de Backup, même lorsque le serveur Primaire est
actif :
• vtbackup, pour effectuer une sauvegarde de la base,

• vtexport, pour exporter les données,
• vtdcs, pour arrêter le serveur,
• vtlist, pour afficher des listes d’objets.
Absyss ©
3 MODULE AGENT
3.1 INSTALLATION D’UN AGENT UNIX
Il est recommandé d’utiliser un système Windows disposant d’un lecteur CD-ROM et de transférer par FTP l’archive
du CD-ROM vers le système Unix.
! La version de l’agent doit impérativement être inférieure ou égale à celle du serveur.
L’option « nosuid » ne doit pas être activée sur le point de montage où se trouve le répertoire d’installation.
Pour utiliser un Modèle de Traitement, la version de l’agent doit être la même que celle du serveur.
Lorsque l’Agent est configuré en mode DMZ, il est nécessaire d’ajouter manuellement un droit d’écriture sur le
répertoire SPOOL pour que les commandes tsend puissent stocker le résultat des traitements soumis par différents
comptes de soumission.
Dans le cas d’une réinstallation ou mise à jour, il est recommandé d’effectuer une désinstallation de Visual TOM.
Pour désinstaller Visual TOM, il faut arrêter tous les processus de Visual TOM :
• Les processus agents actifs.
Lorsque Visual TOM est inactif et après avoir effectué une sauvegarde (fichier vtom.ini, queues batch/submitter pour
l’agent), vous supprimez le répertoire d’installation de Visual TOM.
3.1.2 Préparatifs
Il est nécessaire de disposer d’un compte utilisateur qui administrera Visual TOM. Par défaut, le compte vtom, est
utilisé mais il est possible de prendre n’importe quel utilisateur du système.
Visual TOM est fourni avec des procédures d’administration en c-shell, tc-shell, bourne shell ou korn shell, ainsi
l’utilisateur qui administrera Visual TOM pourra fonctionner indifféremment avec l'un de ces shells.
Visual TOM étant installé à partir du compte administrateur du système, le mot de passe de root sera nécessaire
pour installer Visual TOM.

Sélectionnez dans le répertoire « Installation » le module correspondant à votre système d’exploitation :
• VT-CS pour la solution Agent Normal

• VT-CSL pour la solution Agent Light
• VT-CSM pour la solution single Agent
• VT-CN pour la solution Net Agent
Copiez les archives représentant le module à installer vers le répertoire temporaire d’installation. Les fichiers copiés
sont :

• <module.os.version> archive du module à installer
Absyss ©
• bin pour le fichier <module.os.version>

• ascii pour les fichiers install_vtom et install_vtom.ini
3.1.4 Le fichier de configuration de l'installation : install_vtom.ini

Vous définissez les paramètres d’installation en exécutant directement le script d'installation. Vous pouvez
paramétrer le fichier de configuration install_vtom.ini, qui contient les paramètres par défaut (ex: installation de
plusieurs agents Visual TOM avec les mêmes paramètres).
 Remarque :
Si vous souhaitez effectuer une installation en mode silencieux (mode batch), modifiez le paramètre « batch » à la
3.1.5 Lancement du script d’installation

vérifiez que le fichier install_vtom est en mode exécutable, puis exécutez la commande suivante :
./install_vtom [module]
 Exemple :
Installation d’un module Visual TOM Agent local
./INSTALL_VTOM VT-CS-HPUX.51.Z
Le script d’installation utilise le fichier de configuration de l’installation (install_vtom.ini) pour proposer des
paramètres d’installation par défaut.. Pour chacune des propositions, validez pour l’accepter ou entrez la nouvelle
valeur :
• Répertoire de base de l'installation,

• Administrateur de l’agent de Visual TOM,
• Répertoire des comptes-rendus d’exécution.
A l’issue de l’installation, vous trouvez un compte-rendu synthétique dans le fichier install_vtom.log.
Mettez à jour le fichier /etc/services comme indiqué par la procédure. Si les services de votre système Unix sont
! administrés par un serveur NIS, il sera nécessaire de les mettre à jour sur la machine serveur NIS s'ils ne sont pas
présents.
Il est recommandé de ne pas réaliser l’installation dans le répertoire d’accueil de l’administrateur Visual TOM ; les
droits sur les fichiers sont gérés à partir du répertoire d’installation, cela peut avoir des impacts sur les fichiers
existants.
3.1.6 Fichier de configuration du profil de l’administrateur du Serveur

L’exécution du script d’installation :
• génère un fichier de configuration du profil de l’administrateur du Serveur (vtom_init.[shell]),

• met à jour le profil de l’administrateur du serveur (.profile).
Absyss ©
A. Fichier de configuration de l’administrateur du Serveur
Le nom du fichier de configuration du profil de l’administrateur du Serveur est établi selon la syntaxe suivante :
vtom_init.[$SHELL]. La variable $SHELL contient le nom du shell par défaut de l’administrateur du Serveur : ksh pour
korn shell, sh pour bourne shell, ….
#-----------------------------------------------------------------------
#Extrait du fichier vtom_init.ksh
# ----------------------------------------------------------------------
# Agent
ABM=/home4/abm ; export ABM
ABM_BIN=${ABM}/bin ; export ABM_BIN
ABM_LOGS=/home4/logs/ ; export ABM_LOGS
ABM_SPOOL=${ABM}/spool ; export ABM_SPOOL
Exemple de fichier de configuration de l’administrateur du Serveur
B. Modification du profil de l’administrateur de l’agent
Les fichiers du profil .cshrc (ou .login) et .profile du profil de l’administrateur du module Agent sont modifiés par
l’installation : une ligne contenant la commande d’exécution du fichier de configuration vtom_init[$HELL] est insérée
en fin des fichiers de profil.
#-----------------------------------------------------------------------
# Exemple de Fichier .profile de l’administrateur du serveur Visual TOM
# ----------------------------------------------------------------------
<Ligne 1>
<Ligne 2>
<Ligne 3>
…
. /home4/vtom/admin/vtom_init.ksh
Exemple d’un fichier .profile de l’administrateur du Serveur
A chaque ouverture de session par l’administrateur de Visual TOM, le script vtom_init.[$SHELL] est exécuté et les
variables d’environnement Visual TOM sont valorisées.
! A chaque nouvelle installation d’un module de Visual TOM, une ligne de commande de lancement du script
vtom_init.[$SHELL] est rajoutée à la fin du fichier .profile de l’administrateur de Visual TOM. Supprimez les lignes de
commande obsolètes.
C. Les variables d’environnement de l’administrateur de l’agent
Les variables d’environnement de l’administrateur du serveur Visual TOM sont définies dans le fichier
vtom_init.[$SHELL] .
Absyss ©
Liste des variables d’environnement utilisées par le module serveur de Visual TOM
Générales
HOST Nom de la machine
TOM_HOME Répertoire d’installation
TOM_ADMIN Répertoire des scripts d’administration
TOM_USER_ADMIN Nom de l’administrateur du serveur
Serveur
ABM Répertoire du module Serveur
ABM_BIN Répertoire des exécutables du module agent
ABM_LOGS Répertoire des comptes-rendus d’exécution des Traitements
ABM_SPOOL Répertoire de la file d’attente des Traitements

La validation de l’installation est réalisée par un ensemble d’étapes.
A. Démarrage du processus agent
Connectez-vous avec l’utilisateur d’administration du serveur et lancez la commande « adminc » :
Menu « adminc »
Absyss ©
Choisissez l’option 2 pour démarrer le processus agent.
 Remarque :
Les procédures d’administration sont génériques. Elles peuvent nécessiter un paramétrage de l’administrateur pour
s’adapter au contexte.
B. Mise à jour de la base de données
Une base de données est générée lors de l’installation. Il est nécessaire de mettre à jour cette base de données pour
tenir compte des paramètres tels que le nom de la machine ou celui de l’utilisateur d’administration.
Agent
Avec le menu « Domaine Exploitation / Agents », affichez la fenêtre de définition des Agents.
Cliquez sur « Nouveau » et saisissez le nom de la Machine où l’agent est hébergé.
Déclaration d’un agent distant installé sur la machine physique « itanium »
C. Validation du bon fonctionnement de la partie agent de Visual TOM
Suivi des agents
Vérifiez la disponibilité de l’agent en utilisant le suivi des agents, à l’aide du menu « Pilotage / Suivi des Agents ».
Absyss ©
Fenêtre de suivi des agents
Association de l’Unité de soumission à l’Environnement
Ouvrez la liste des Environnements à l’aide du menu principal « Domaine/Environnements… ». Accédez à la

définition de l’Environnement « exploitation ».
Associez l’Unité de soumission à l’aide du bouton de la colonne « Valeurs possibles ».
Association de
l’Unité de
soumission à
l’Environnement
Fenêtre de définition d’un Environnement
Modification d’un Traitement
Depuis le Supra manager, ouvrez le graphe de l’Environnement « exploitation ».
Basculez vers le mode conception en utilisant le bouton en bas à gauche de la fenêtre représentant le graphe de
l’Environnement.
Double cliquez sur l’Application pour obtenir la représentation graphique des Traitements. Cliquez sur le Traitement
« job2 » avec le bouton droit de la souris pour obtenir son menu contextuel. Cliquez sur « Définition », la fenêtre de
définition du Traitement s’affiche. Choisissez la Machine correspondant à l’agent distant.
Absyss ©
Lancement de l’exécution
Ouvrez le graphe de l’environnement « exploitation » depuis la fenêtre Supra manager, comme vu précédemment,
pour obtenir la représentation graphique des Applications.
Cliquez sur l’Application « appli_test » avec le bouton droit de la souris, choisissez le menu « Actions », puis l’item
« Forcer à A VENIR ».
Double cliquez sur l’Application pour obtenir la représentation graphique des Traitements. Ceux-ci sont passés au
statut « A VENIR » et vont s’exécuter les uns après les autres.
Visualisation du compte rendu d’exécution
Cliquez deux fois sur le Traitement « job2 » pour obtenir la liste des compte-rendus d’exécution. Vous pouvez
également y accéder en utilisant le bouton droit de la souris et le menu contextuel du Traitement, puis l’item
« Logs ».
La Liste des compte-rendus d’exécution de ce Traitement s’affiche. Double cliquez sur le premier élément de la liste,
ou utilisez le menu contextuel de l’élément : le contenu du fichier compte-rendu s’affiche.
3.2 INSTALLATION D’UN AGENT WINDOWS
! La version de l’agent doit impérativement être inférieure ou égale à celle du serveur.
Pour utiliser un Traitement modèle, la version de l’agent doit être la même que celle du serveur.
Dans le cas d’une réinstallation ou mise à jour, il est nécessaire d’effectuer une désinstallation de Visual TOM. Pour
désinstaller Visual TOM, il faut arrêter tous les processus de Visual TOM :
• Les processus agents actifs.
Lorsque Visual TOM est inactif et après avoir effectué une sauvegarde (fichier vtom.ini, queues batch/submitter pour
l’agent), vous désintallez avec le setup fourni.
 Remarques :
• Les services TCP de Visual TOM, déclarés dans le fichier %windir%\system32\drivers\etc\services ; ils seront
les ports par défaut lors de la prochaine installation (mais pourront être modifiés).
• Les répertoires modifiés après l'installation (ex: la base de données) qui pourront être conservés, ou être
supprimés par le gestionnaire de fichiers.
• Les variables d’environnement système préfixées par TOM ou ABM (exemple « TOM_BIN ») ne sont pas
supprimées. La variable PATH n’est pas mise à jour.
Il est préférable d’effectuer la désinstallation lorsqu’il n’y a plus aucun Traitement actif.
Absyss ©
3.2.2 Préparatifs
Visual TOM étant installé à partir du compte administrateur du système, le mot de passe administrateur sera
nécessaire pour installer Visual TOM.

Absyss ©
Cliquez sur le bouton « Suivant » ; choisissez les numéros de ports de communication.
Choix des numéros de ports de communication des processus
Le fichier %windir%\system32\drivers\etc\services est mis à jour par le programme d’installation.
Cliquez sur le bouton « Suivant » sur les fenêtres suivantes jusqu’à la fenêtre ci-dessous :
Absyss ©
! Il est impératif de redémarrer le serveur pour finaliser l’installation. Au redémarrage, le service démarre
automatiquement.
 Remarques :
• Deux commandes sont fournies avec le groupe de programme de Visual TOM pour une gestion plus rapide
des services.
• Pour utiliser l’agent 64 bits, utilisez le setup approprié.

Mis à part le démarrage et l’arrêt du processus agent, géré en tant que service, la procédure de validation de
l’installation de l’agent est identique à la validation sous Unix.
3.3 INSTALLATION D’UN AGENT AS400
3.3.1 Pré-requis
Le système d’exploitation OS 400 doit être de version V5R3 ou supérieure.
Il est nécessaire de disposer des logiciels TCP/IP.
Visual TOM est compatible avec le mode « sécurité 40 » (niveau de protection des objets).
Les profils doivent être définis en MAJUSCULE.
Un travail est soumis avec l'Utilisateur et la Queue Batch définis dans le Traitement Visual TOM. Visual TOM soumet :
• un CLP, stocké dans une bibliothèque quelconque,

• une commande en utilisant les paramètres du Traitement (Un CL peut être exécuté via une commande).
Les paramètres de la soumission (exemple : JOBD) sont chargés depuis la queue batch et sont sur-chargeables au
niveau des paramètres du Traitement Visual TOM.
Absyss ©
Quand le traitement est soumis, il produit des comptes-rendus d’exécution en fonction du répertoire de logs indiqué
dans le fichier de configuration « VTOM ». Ces comptes-rendus sont visualisables :
• dans l’interface graphique,

• avec la commande « WRKLNK »,
• via le browser Windows.
S’il y a une installation précédente de l’agent Visual TOM, vous pouvez la sauvegarder ou la désinstaller.
 Remarque :
Un modèle de Traitement est disponible pour créer un Traitement AS400.
3.3.2 Contrôle des ports de communication TCP

Les ports de communication qui seront utilisés par l’agent sont créés automatiquement lors de la phase
d’installation. Les noms de ces numéros de ports TCP sont :
• bdaemon, port d’écoute de l’agent. Ce port TCP doit avoir la même valeur que le port bdaemon déclaré sur
le serveur Visual TOM.
• tomDBd , port utilisé par l’agent pour communiquer avec le Serveur Visual. Ce port TCP doit avoir la même
valeur que le port tomDBd déclaré sur le serveur Visual TOM.
Ces ports sont surchargés par la présence éventuelle de leur définition dans le fichier de configuration « VTOM ».
Pour contrôler la présence ou l’absence d’utilisation des numéros de ports de communication, effectuez les actions
suivantes :
• Lancer la commande cfgtcp ; le menu « Configure TCP/IP » s’affiche.

• Choisissez l’option 21 « Configure related tables » ; le menu « Configure related tables » s’affiche.
• Choisissez l’option 1 « Work with service table entries » ; le menu « Work with service table entries »
s’affiche.
• Vérifiez que les valeurs des numéros de ports TCP correspondant à cellles de tomDBd et bdaemon déclarés
sur le serveur ne sont pas utilisées, sauf par les numéros autoDBd et autobdeamon (cas d’une installation
précédente de l’agent Visual TOM). Si ces valeurs sont utilisées par d’autres noms, il faut faire appel au
responsable réseau pour qu’il vous attribue deux numéros de ports TCP. Puis, il faut modifier les numéros
des services tomDBd et bdaemon dans le fichier /etc/services ou le fichier
« %SystemRoot%\system32\drivers\etc\services » selon que le serveur Visual TOM soit sur une machine
Unix ou une machine NT.
Sur le système OS400, la modification du numéro de port implique une suppression du service et une nouvelle
création de ce service. Ceci doit être fait par le menu CFGTCP, en utilisant l’utilisateur QSECOFR.
! Pour les noms de service, la casse doit être respectée (« tomDBd » et « bdaemon »).
3.3.3 Sauvegarde d’une installation

Pour sauvegarder une installation, il faut arrêter l’agent Visual TOM et sauvegarder l’installation courante.
A. Arrêt de l’agent
Affichez le menu « Administration de l’agent AS400 » en ouvrant une session avec l’utilisateur VTOM (mot de passe
VTOM).
Absyss ©
Menu d’administration de l’agent AS400
Choisissez l’option 3 « Arrêt de l’agent » et fermer la session courante (commande « signoff »).
B. Sauvegarde d’une installation
Ouvrez une session avec l’utilisateur QSECOFR ; le mot de passe doit être fourni par l’administrateur système.
Sauvegardez l’installation courante avec les commandes suivantes :
CRTSAVF QGPL/VTOMXXX
------------- XXX correspond au numéro de version installée (exemple : VTOM561-------------------
SAVLIB LIB(VTOM) DEV(*SAVF) SAVF(QGPL/VTOMXXX)
Sauvegarde d’une installation de l’agent
Arrêtez l’agent (cf paragraphe ci-dessus) et supprimez la bibliothèque « VTOM ». Pour supprimer cette bibliothèque
« VTOM » :
• affichez les objets de la bibliothèque avec la commande suivante :
WRKLIB VTOM
• Utilisez la touche « 4 ».
Absyss ©

Avant d’effectuer le transfert de l’archive vers la machine AS400, il faut créer une enveloppe AS400 de réception
pour cette archive. La création d’une enveloppe s’effectue avec la commande suivante :
CRTSAVF QGPL/VTOMOS400
Création d’une enveloppe de réception de l’archive
L’archive est située dans le répertoire « Installation ».

Le fichier VTOMOS400 doit être transféré par FTP vers la librairie AS400 QGPL.
lcd D:\AGENT\AS400
cd QGPL
quote site namefmt 0
bin
put VTOMOS400
quit
Transfert en mode binaire par FTP de l’archive VTOMOS400 vers la librairie GQPL
3.3.6 Installation
L’installation de l’agent consiste à créer un environnement AS400 pour l’agent et puis à lancer la procédure
d’installation :
RSTOBJ OBJ(QINSTAPPCD VTOMINSTAL) SAVLIB(VTOMXXX) DEV(*SAVF)
SAVF(QGPL/VTOMOS400) RSTLIB(QTEMP)
------------- XXX correspond à la version à installer -----------------------------------
Restauration de l’objet contenu dans l’archive
Saisissez la commande suivante, puis pressez la touche F4 (ne pas presser la toucher ENTER)
QTEMP/VTOMINSTAL
Lancement de la procédure d’installation
Remplacez « XXX » par la version (ex : 581) dans l’écran ci-dessous.
Absyss ©
Le jeu de caractères utilisé est précisé en dernier paramètre (00297 correspond à EBCDIC FR, 00037 correspond à
EBCDIC UK).
A la fin de la procédure d’installation, un message indique le bon déroulement et le menu d’administration de l’agent
AS400 est affiché.
Absyss ©
 Remarque :
La première installation est réalisée à partir du compte QSECOFR. Lors de cette installation, le compte administrateur
de Visual TOM est automatiquement créé (mot de passe par défaut : valeur de l’administrateur VTOM) et utilisable
pour les installations/désinstallations suivantes.

Ces tests consistent à valider les fonctions du menu d’administration présenté dans le paragraphe précédent et à
soumettre un Traitement par l’agent AS400 depuis un serveur UNIX ou Windows.
A. Démarrage de l’agent
Connectez-vous avec le compte d’administration de Visual TOM.
Choisissez l’option 2 du menu d’administration.
Si le démarrage de l’agent s ‘effectue sans erreur, détruisez le fichier « VTOMXXX » en utilisant la commande
suivante :
DLTF QGPL/VTOMXXX
Destruction du fichier
Si le démarrage de l’agent s’effectue anormalement, vérifiez que la bibliothèque QGPL n’est pas utilisée par le
système (cette bibliothèque doit posséder le type « PROD »).
 Remarque :
La jobq utilisée est celle indiquée dans la jobd « VTOM/VTOM ».
B. Arrêt de l’agent
Connectez-vous avec le compte d’administration de Visual TOM.
Choisissez l’option 3 du menu d’administration pour arrêter l’agent.
Absyss ©
C. Consultation des variables d’environnement de l’agent
Choisissez l’option 8 du menu d’administration pour consulter les variables d’environnement de l’agent. Le tableau
suivant fournit une liste non exhaustive des variables d’environnement.
NOM SECTION Valeurs Commentaires
ABM general /VTOM/ABM Répertoire de l'ABM
ABM_LOGS general /VTOM/ABM/logs Répertoire contenant les LOGS
ABM_SPOOL general /VTOM/ABM/spool Répertoire contenant les fichiers spool
CCSID general 00297 Jeu de caractères EBCDIC FR
bdaemon ports 30004 Port de l’agent Visual TOM
tomDBd ports 30001 Port du serveur Visual TOM
TRACE_FILE BDAEMON /VTOM/TRACES/bdaemon.l Répertoire des traces

og
TRACE_LEVEL BDAEMON 6 Niveau de traces (0 à 10)
Si les ports sont définis dans la section « ports », les valeurs surchargent celles indiquées dans la table des services.
!
D. Gestion des Queues Batch
Choisissez l’option 5 du menu d’administration.
VARIABLES Valeurs Définition
[managers] Liste des utilisateurs habilités à arrêter l’agent AS400
mg01 VTOM Compte d’administration des queues batch
[queue01] Définition de la première queue :
Vous devrez définir les queues que vous voulez utiliser.
qbatch
name Nom de la queue (stockée dans VTOM/TCLSRC)
10
maxrun Nombre maximum de travaux actifs simultanément
-1
maxwait Nombre maximum de travaux dans la queue (-
1=nomax)
Absyss ©
nameshell QBATCH
priorite 20 Nom du CLP qui exécute le Traitement :
Priorité
user01 VTOM,10,10
user02 any,-1,-1 Pour l'utilisateur VTOM, maxrun=10, maxwait=10
Pour les autres utilisateurs, maxrun=nomax,

maxwait=nomax
grp01 users,10,10
Notion de groupe
mg01 VTOM
Manager de la jobq
JOBQ
JOB
Paramètres de la SBMJOB
JOBD
…
…
…
CPYENVVAR
…
Paramètres de la SBMJOB
Absyss ©
E. Validation du fonctionnement de l’agent
Au niveau du serveur Visual TOM, il faut créer :
• un Utilisateur de nom « VTOM »,

• un nom de Machine correspondant à l’agent AS400,
• une Queue Batch de nom « QBATCH »,
• une Application,
• un Traitement, dont le champ script contient juste le caractère « # ».
! Le nom d’un Job AS400 ne doit pas dépasser 10 caractères (Limite système), son nom doit commencer par une lettre.
Création de l’Utilisateur VTOM
Utilisez le menu principal « Domaine/Utilisateurs ». Créez l’Utilisateur.
Fenêtre de création d’un Utilisateur
Création de l’Agent
Utilisez le menu principal « Domaine/Machines ». Créez l’Agent avec création automatique de l’Unité de Soumission.
Absyss ©
Fenêtre de création de l’Agent
Création de la Queue Batch
Utilisez le menu principal « Domaine/Queues batch ». Créez la Queue Batch.
Fenêtre de création d’une queue batch
Association de l’Utilisateur, de l’Unité de Soumission et de la Queue Batch à l’Environnement
Utilisez le menu principal « Domaine/Environnement ». Dans la définition de l’Environnement, associez l’Utilisateur,

l’Unité de Soumission et la Queue Batch, en utilisant le bouton « Valeurs possibles ».
Création d’un Traitement
Ouvrez le graphe de l’Application « appli_test » de l’Environnement « exploitation », en mode conception.
Absyss ©
Bouton
« Sélection »
Bouton
« Ajouter un
Accès au
nœud »
graphe par le
menu
contextuel de
l’Application
Traitement
Bouton
« Mise en
Exploitation »
Graphe de l’Application
Sélectionnez le bouton « Ajouter un nœud ». Avec le bouton gauche de la souris, cliquez sous le dernier Traitement
« job3 ». Un nœud graphique apparaît.
Sélectionnez le bouton « Sélection ». Utiliser le menu contextuel nœud graphique nouvellement créé. Choisissez
l’item « Créer un Traitement ».
 Exemple 1 :
Créez un Traitement. Insérez les paramètres suivants :
Paramètre 1, pour préciser la commande à exécuter : CMD=DLYJOB 5
Exécutez le Traitement ; celui-ci doit se terminer correctement, après une attente de 5 secondes.
Onglet
Paramètres
Mode
d’exécution
Unité de
soumission
Utilisateur
Queue
Batch
Fenêtre de définition du Traitement
Absyss ©
Paramètres du Traitement
! Pour être réellement exécuté, le Traitement doit être en mode Exécution et mis en exploitation.
 Exemple 2 :
Créez un Traitement. Valorisez le champ script avec « # », valorisez et/ou surchargez les paramètres de soumission
comme suit :
CMD=[nom_bib]/[nom_clp]
JOBD=[valeur du parametre]
 Exemple 3 :
Créez un Traitement. Valorisez le champ script avec « [nom_bib]/[nom_clp] ». Pour surcharger un paramètre de
soumission, valorisez les paramètres comme suit :
JOBD=[valeur du paramètre]
 Remarque :
Les paramètres du Traitement sont valorisés comme suit :
CMD=[nom_bib]/[nom_clp] PARM(‘xxx’ ‘yyy’)
3.3.8 Démarrage automatique de l’agent
Pour que l’agent AS400 démarre automatiquement lors du boot de la machine, il faut modifier le fichier de commandes exécuté au
boot. La procédure de modification de ce fichier est la suivante :
• Extraire le fichier des commandes qui démarre au boot :
RTVCLSRC QSTRUP QCLSRC
• Insérer les lignes suivantes entre NOWTRS et RETURN dans le fichier
ADDLIBLE VTOM
MONMSG MSGID(CPF0000)
CALL PGM(VTOM/BDAEMON)
MONMSG MSGID(CPF0000)
• Compiler le fichier de commande :
CRTCLPGM QSYS/QSTRUP QGPL/QCLSRC
Absyss ©
3.3.9 Module de réponse automatique

Ce module est installé sur un agent Windows. Il permet de décrire les réponses à apporter automatiquement lorsque
des messages sont émis sur la machine AS400, dans une queue de message (par exemple queue de message de
l’opérateur système « QSYSOPR »).
L’installation consiste à copier l’exécutable.
Les données de configuration et les données liées aux messages sont stockées dans le fichier
« messageManager.cfg ». Ce fichier est situé dans le même répertoire que l’exécutable.
Le module est utilisable, que le traitement ait été soumis via Visual TOM ou non.
Cet exécutable est utilisable en mode automatique ou manuel, avec affichage permanent ou non.
Au démarrage, le fichier de configuration doit être initialisé.
Message au premier démarrage.
Fenêtre de chargement de la configuration
Absyss ©
Fenêtre de description de la configuration.
Machine
Champ obligatoire. Le champ machine indique le serveur contenant un message.
Plusieurs instances de ce programme sont exécutables simultanément.
Utilisateur
Champ obligatoire. Le champ utilisateur indique le compte sous lequel la réponse est effectuée. Cet utilisateur doit
disposer des droits pour avoir la visibilité de messages et y répondre.
Mot de passe
Champ obligatoire.
Rafraîchissement
Ce champ indique la fréquence à laquelle l’exécutable vérifie l’existence de messages, et y répond. S’il y a plusieurs
règles de réponse correspondant au message, la première est utilisée (ordre de création / affichage).
Quand ce mode n’est pas actif, la fenêtre se ferme après 1 cycle de vérification.
Mode interactif
Lorsque ce mode est activé, la fenêtre est masquée dans la barre de tâches, et s’affiche à l’écran lorsqu’un message
nécessite une réponse qui n’a pas été automatisée.
Absyss ©
Lorsque ce mode est désactivé, la fenêtre n’est pas masquée dans la barre de tâches et reste affichée à l’écran. La
fenêtre peut être minimisée manuellement, mais ne réapparaitra pas automatiquement à l’arrivée d’un message
dont la réponse est manuelle.
Queue de message
Champ obligatoire. Ce champ correspond au chemin de la librairie contenant les messages de la queue QSYSOPR
(%LIBL% indique la librairie de l’utilisateur mentionné).
Réponse automatique
Ce champ active ou non les réponses automatiques déclarées.
Champ
Ce champ sélectionne un des attributs du message.
Valeur
Champ obligatoire correspondant au texte attendu.
Réponse par défaut
Lorsque ce champ est validé, c’est la réponse définie sur l’AS400 qui est utilisée pour une réponse automatique.
Autre réponse
Ce champ définit la réponse automatique à apporter au message.
Fenêtre de création d’une réponse automatique à un message
La fenêtre « Historique des réponses automatiques et manuelles » fournit les informations suivantes : date,
utilisateur ayant répondu, réponse apportée, type manuel ou automatique.
La fenêtre « Détail des messages » liste les messages en attente de réponse.
Absyss ©
3.4 INSTALLATION D’UN AGENT GCOS7
3.4.1 Pré-requis
La validation des pré-requis doit être réalisée avec le Responsable Systèmes/Réseaux du site.
La communication avec le système GCOS7 via VIPLET doit être validée.
3.4.2 Installation
A. Mise à jour sur GCOS7
Créez une « startup système » avec le nom suivant : <nom_projet>_<nom_user>_B :
• Nom_projet est le nom de projet associé à l’utilisateur de connexion..

• nom_user est un utilisateur de connexion « opérateur » dédié à la soumission des Jobs Visual TOM.
• B indique une session en mode batch et non en mode interactif.
Créez l’utilisateur dans le projet OPERATOR ou dans un autre projet de type « main ».
Créez si nécessaire une startup IOF pour générer le message qui indiquera que la connexion est effective (message
indiqué dans le fichier « vtom.ini », paramètre « GCOS_CNX_STEPS »).
 Remarque :
Une « startup système » peut être considérée comme profil d’un utilisateur. Vous pouvez préférer une startup
projet.
 Exemple :
Membre OPERATOR_OPABS01_B, stocké dans la bibliothèque « SITE.STARTUP ».
Le contenu de cette startup est :
MESSAGE 'VTOMJID '&VTOMJID' '&JOBID;
! Vérifiez que l’utilisateur déclaré lors de la création de la startup (ex : OPABS01) a le droit d’exécuter la startup.
B. Installation d’un agent Windows
Installez un agent Windows standard. Reportez-vous au chapitre d’installation d’un agent Windows.
C. Création d’une Queue Batch pour l’agent GCOS7
Ajoutez le nom de la queue batch de l’agent GCOS7 à la liste des valeurs du paramètre ABM_QUEUES du fichier
« vtom.ini » (par exemple « queue_gcos7 »).
[BDAEMON]
ABM_QUEUES=/queue_w9x:10 /queue_wnt:10 /queue_gcos7:64
…
Absyss ©
D. Paramétrage de la connexion
Modifiez le fichier de configuration « vtom.ini » comme indiqué dans l’exemple ci-dessous :

[VT2GCOS_AGENT:]
# Traces de la partie agent
;TRACE_FILE=C:\vtom\traces\bdaemon.log
; TRACE_LEVEL=6
; TRACE_FILE_SIZE=2
[VT2GCOS_SERVER:]
AGENTS=
JAVA_PATH=C:\Program Files\Java\jre6\bin\
JAR_PATH=C:\vtom\abm\bin\vtom2gcos7.jar
# Url du serveur viplet
VIPLET_URL=http://192.00.00.01/viplet/
# User de connexion Viplet
VIPLET_USER=xxx
VIPLET_CNX_GRP=Absyss
VIPLET_CNX_NAME=Bull_GCOS7
# Mode prompt : Connexion a GCOS avec user (1400), projet (1500), mot de passe (1600) et message de détection
# de connexion
GCOS_CNX_STEPS=$$ 1400=OPABS01,$$ 1500=OPABSYSS,$$ 1600=ABSYSSVAC, CONNEXION OPERATEUR
# Mode ecran : Connexion a GCOS avec valeurs des champs, a separer par ‘/’. Si plusieurs ecrans, separer par ‘,’.
# Indiquer la chaine permettant d’identifier la connexion.
GCOS_CNX_STEPS=V2/MBOX,S:
# Répertoire de gestion des spools. Les répertoires doivent exister. Ne pas utiliser le répertoire spool standard. Mettre un séparateur à la fin
SPOOLS=c:\vtom\abm\spoolgcos\
LOGS= c:\vtom\abm\logs\
LOGS_ACTIV=1
LOOPTIME=5
# Nombre de tentatives sur la lecture d’un fichier (fichiers spool et fichier temporaires de logs)
RETRY=1000
WAIT_BETWEEN_RETRIES=1000
TRACE_SCREEN=1
TRACE_FILE_DIR=C:\vtom\traces
# Traces de la partie serveur
TRACE_FILE_NAME=vtom2gcos.log
TRACE_FILE=1
TRACE_LEVEL=6
TRACE_FILE_SIZE=2
Pour crypter une valeur d’un des steps du paramètre « GCOS_CNX_STEPS », utilisez l’utilitaire « bcrypt » et
remplacez la valeur calculée précédée du caractère « * ».
E. Copie des fichiers de l’agent GCOS7
Sélectionnez dans le répertoire « Installation » l’archive de l’agent GCOS7 et copiez-le vers le répertoire
%ABM_BIN%.
! Après la copie des fichiers, le nom du fichier « SUBMIT_QUEUE_GCOS7 » doit être en phase avec le nom déclaré dans
le fichier « vtom.ini ». Ce nom est établi comme suit : Submit_ « Nom_de _Queue_Batch » .bat
3.4.3 Validation de l’installation de l’agent

• un nom de Machine correspondant à l’agent windows installé, qui gère la connexion à GCOS7,
• une Queue Batch de nom « queue_gcos7 »,
• un Traitement.
Le Traitement sera défini avec l’Utilisateur « TOM ».
Absyss ©
Fenêtre de création de la Machine
Association de l’Utilisateur, de l’Unité de soumission et de la Queue Batch à l’Environnement

l’Unité de soumission et la Queue Batch, en utilisant le bouton « Valeurs possibles ».
Absyss ©
Bouton
« Sélection »
Bouton
« Ajouter un
Accès au nœud »
graphe par le
menu
contextuel de
l’Application Traitement
Bouton
« Mise en
Exploitation »
 Exemple :
Champ script, pour préciser la commande à exécuter : #EJ J-VALID LIB=SITE.JCL
Script
Mode
d’exécution
Unité de
soumission
Utilisateur
Queue
Batch
Absyss ©
Sur GCOS7, dans la bibliothèque « SITE.JCL », créez un membre « J-VALID » avec le contenu suivant :
$JOB J-VALID ;
SEND ‘TRAITEMENT SOUMIS PAR VISUAL TOM’ ;
$ENDJOB ;
Exécutez le Traitement ; celui-ci doit se terminer correctement.
! Le JCL doit impérativement s’appeler « J-VALID ».
3.5 INSTALLATION D’UN AGENT GCOS8
3.5.1 Pré-requis
Dans le cas d’une installation initiale, une bande magnétique 18 pistes contenant le nom de l’UMC « VAB0T00 » est
fournie. Dans le cas d’une réinstallation ou une mise à jour de l’agent, le fichier « ABM.C » est livré via ftp ou sur
bande magnétique.
3.5.2 Installation
A. Mise à jour sur GCOS8
Créez un utilisateur UMC VAB000.
B. Restauration des fichiers sur GCOS8
Copiez le contenu de la bande magnétique sur le système GCOS8. La copie de la bande magnétique créera deux
catalogues : TOM et TOM-V1.
Dans le catalogue TOM, les répertoires suivants sont créés :
• EXEC,
• FIC,
• JCL ,
• SRC.
Dans le catalogue VTOM-V1, le répertoire « FIC » de la base de données de la workstation wd est créé.
C. Compilation
Assurez vous que le source est prévu pour un fonctionnement en mode « snumb » alétaoire, sans mode « privity ».
Vérifiez que le fichier « ABM.C » livré dans le répertoire « TOM/SRC » contient les valeurs ci-dessous :
int flag_snumb_attribute = 0 ;
int mode_privity = 0 ;
Compilez le fichier source « ABM.C ». La compilation du fichier créera un fichier objet « ABM.O » dans le répertoire
« TOM/SRC ».
CWD TOM
CWD SRC
NSC ABM.C F=OM O=ABM.O
Compilation du fichier ABM.C
Absyss ©
D. Edition des liens
Lancez le JCL « ABM.L » à partir du répertoire TOM/SRC. L’édition des liens créera un exécutable « ABM.V » dans le
répertoire « TOM/EXEC ».
$ SELECT VAB0T00/TOM/JCL/IDENT
$ LKED
$ RESOURC VSPACE=300K
$ LIMITS 100,100K,,75000,,15K
$ PRMFL O*,R,R,VAB0T00/TOM/SRC/ABM.O
$ PRMFL O1,R,R,VAB0T00/TOM/SRC/CSGCOS.O
$ PRMFL V*,W,R,VAB0T00/TOM/EXE/ABM-N.V
$ prmfl cl,q,r,sys_rcv/w3cv00r12000/lib.oml
$ data n*
$ ascii
GENERATE_RUN_UNIT -FC v* -NAME abm & -ENTRY C$ENTRY
LIBRARY -FC cl -language sockets -S
INCLUDE -FC O1
SOFTWARE_STACK_SEGMENT 6k -USE_DATA_STACK
CREATE_REFERENCE -SYMREF C$PROGRAM & -SYMREF EASEE$ENTRIES
CREATE_HEAPS -DATA 128k -DESC_HEAP 1K
JCL d’édition de liens ABM.L
E. Déclaration des numéros de port TCP
Mettez à jour le fichier « sys_etc/services » du système GCOS8 en fonction des ports définis sur le serveur Visual
TOM :
• port du service tomDBd,

• port du service bdaemon.
F. Démarrage de l’agent
Démarrez l’agent GCOS8 par la commande : JRN ABM.E

$ SELECT VAB0T00/TOM/JCL/IDENT
$ NOTE
$ NOTE AGENT "VTOM" GCOS8
$ NOTE -> LANCEMENT EN MODE NORMAL
$ NOTE
$ RUN RUFILE=VAB0T00/TOM/EXE/ABM-N.V
$ RESOURC VSPACE=1000K,CSSIZE=400K
$ LIMITS 100,100K,,100K,,16K
$ WORKST VTOM,PERM,40
$ PRMFL AT,Q,S,SYS_ETC/AGENTS
$ PRMFL HT,Q,S,SYS_ETC/HOSTS
$ PRMFL WD,Q,R,VAB0T00/VTOM-V1/FIC/WD
$ DATA CZ
ABM [port bdaemon] [port tomDBd]
JCL de démarrage de l’agent GCOS8
Absyss ©

• un nom de Machine,
• une Queue Batch de nom « $job$ »,
• un Traitement.
Le Traitement sera défini avec l’Utilisateur « TOM ».
Absyss ©

Bouton
« Sélection »
Bouton
« Ajouter un
Accès au nœud »
graphe par le
menu
contextuel de
Bouton
« Mise en
Exploitation »
 Exemple :
Champ script, pour préciser la commande à exécuter : VAB00T00/TOM/JCL/JVTOM
Absyss ©
Script
Mode
d’exécution
Unité de
soumission
Utilisateur
Queue
Batch
Sur GCOS8, dans le répertoire «TOM/JCL », créez un JCL « JVTOM » avec le contenu suivant :
$ IDENT VAB0T00, S **VTOM**
$ RUN RUFILE=VAB0TOO/TOM/EXE/TBEGIN.V
$ RESOURC VSPACE=1000K, CSSIZE=400K
$ LIMITS VSPACE=100, 100K, , 100K, , 16K
$ WORKST VTOM, PERM, 40
$ PRMFL HT, Q, S, SYS_ETC/HOSTS
$ PRMFL WD, Q, R, VAB0T00/VTOM-V1/FIC/WD
$ DATA CZ
$ TSTEP 2 [adresse IP du serveur Visual TOM] [port de tomDBd]
! Le JCL doit s’appeler « JVTOM ».
3.5.4 Réinstallation ou mise à jour de l’agent

Dans le cas d’une réinstallation ou d’une mise à jour de l’agent, vous utilisez les catalogues et répertoires créés lors
de l’installation initiale. Effectuez les actions suivantes :
• reportez le paramétrage existant sur le nouveau fichier ABM.C (gestion des snumbs, mode privity),
• reportez le paramétrage des numéros de port
• arrêtez l’agent,
• compilez
• éditez les liens,
• démarrez l’agent.
Absyss ©
3.6 INSTALLATION D’UN AGENT VMS
3.6.1 Pré-requis

Avant d’effectuer le transfert de l’archive vers la machine VMS, créez un répertoire d’installation.
Utilisez un système de transfert de fichiers tel que ftp pour copier les fichiers d’installation sur le système VMS.
! Certains systèmes de transfert de fichiers VMS ne respectent pas le format des fichiers ; leur utilisation pour la copie
de l’archive peut provoquer des erreurs dans la phase d’installation.
A partir de votre accès ftp, copiez les deux fichiers d’installation VTOM035.A et VTOM035.B sur le répertoire
précédemment créé.
Fichiers d’installation
Selon le type de machine (Digital Alpha ou Vax), copiez l’utilitaire « FIX_SAVESET_ALPHA » ou « FIX_SAVESET_VAX »
dans le répertoire d’installation.
Utilitaires VMS
Absyss ©
3.6.3 Installation
A. Mise en place de l’archive
Mise en œuvre du Patch
Copiez l’utilitaire FIX_SAVESET du répertoire d’installation vers le répertoire « sys$system » à l'aide de la commande
"copy" VMS.
Exécutez à partir du répertoire d'installation les commandes suivantes :

>mc fix_saveset.exe [Nom_complet_du_repertoire_d'installation]VTOM035.A
>mc fix_saveset.exe [Nom_complet_du_repertoire_d'installation]VTOM035.B
Application du patch sur les fichiers d’installation
Procédure
Utilisez la procédure d’installation standard « VMSINSTALL » pour installer l’agent Visual TOM.
La procédure « VMSINSTALL » doit être exécutée sous le compte « SYSTEM » ; elle se déroule en mode interactif avec
la convention syntaxique suivante, en précisant où se trouvent les fichiers d’installation (distribution volumes) :
@ sys$update:vmsinstal
* Do you want to continue anyway [NO]? Yes 
* Are you satisfied with the backup of your system disk [YES]? 
* Where will the distribution volumes be mounted: DKB300: 
* Products: vtom 
* Enter installation options you wish to use (none): 
* Indiquez votre support pour installer VTOM035 ex : dua2 ? dkb300: 
* Indiquez l'Owner de l'application, exemple : 500,1 ? 500,1 
*Pouvons-nous commencer l'installation de VTOM035 [O/n] ? 
*Enter the products to be processed from the next distribution volume set.
Products: 
Procédure d’installation : les valeurs à utiliser sont indiquées en gras.
Pour une machine Digital Alpha, exécutez la commande suivante :
Particularité
Pour une machine Digital Alpha, exécutez la commande suivante :

$ RENAME ABM_BIN_AXP:*.EXE_AXP ABM_BIN_AXP:*.EXE /LOG
Action spécifique à une installation sous AlphaVms
B. Activation du « compte utilisateur » administrateur de l’agent
La procédure d’installation crée un compte utilisateur VMS « VTOM035 ». Ce compte est en charge de
l’administration de l’agent Visual.
Le compte utilisateur « VTOM035 » est créé à l’état inactif avec un mot de passe expiré.
Activez le compte « VTOM035 » et modifiez son mot de passe ainsi :
Absyss ©
$set def sys$system:

$run authorize
UAF> mod vtom035/flag=nodisuser
%UAF-I-MDFYMSG, user record(s) updated
UAF> mod vtom035/pass=XXXXX
%UAF-I-MDFYMSG, user record(s) updated
UAF> exit
%UAF-I-DONEMSG, system authorization file modified
%UAF-I-NAFNOMODS, no modifications made to network proxy data base
%UAF-I-RDBNOMODS, no modifications made to rights data base
Activation du compte utilisateur VTOM035
 Remarque :
Si le mot de passe n’est pas modifié, il sera nécessaire de le changer lors de la prochaine connexion.
C. Modification du fichier « startup » de l’administrateur de l’agent
Etablissez une connexion avec l’utilisateur SYSTEM. Editez le fichier « sys$startup:vtomstartup.com » pour prendre
en compte la modification des symboles suivants :
• TOM_REMOTE_SERVER : nom ou adresse IP de la machine serveur.

• TOM_REMOTE_PORT : port tomDBd de la machine serveur (20001 par défaut).
• TOM_LOCAL_PORT : port bdaemon de la machine serveur (20004 par défaut).
• TOM_LITTLE_INDIAN : si le serveur Visual TOM est installé sur un système Unix autre que Linux (processeur
Intel), assurez-vous que cette variable n'est pas positionnée ; si elle existe, supprimez-la ou deassignez-la.
deassign /system
TOM_LITTLE_ENDIAN
Commande utiliser pour déassigner un symbole
D. Gestion de la relance des Traitements
 Remarques :
• La variable d’environnement positionnée par la commande « tstep » est « TOM_JOB_POINT ».
• Le terminal renvoie par défaut la chaîne en minuscules. Utilisez la commande « tstart » avec des noms
d’arguments en minuscules.
 Exemple :
tstart "prod" "app" "job1"
démarre le Traitement « job1 » de l'Application « app » de l'Environnement « prod ».
E. Contrôle des paramètres d’installation
Après l’installation, il est impératif de vérifier la cohérence entre le propriétaire, le groupe défini lors de la procédure
d’installation, et les attributs du répertoire d’installation. Effectuez cette vérification avec la commande suivante :
$dir/sec vtom$root:[000000...]
Contrôle des attributs du répertoire d’installation
Absyss ©
Modifiez éventuellement le propriétaire des fichiers Visual TOM en remplaçant 500,1 par le propriétaire et le groupe
corrects et DKB300 par le disque où s'est faite l'installation, en agissant ainsi :
$set file/owner=<500,1> VTOM$ROOT:[000000...]*.*
$set file/owner=<500,1> DKB300:[000000]VTOM035.DIR
Correction des paramètres d’installation
F. Démarrage de la startup de l’administrateur de l’agent
Toujours avec une connexion établie sous le compte « SYSTEM », activez la startup ainsi :
$@ sys$startup:vtomstartup.com
Démarrage de la startup de l’administrateur de l’agent
G. Paramétrage de la Queue Batch de soumission des Traitements
Les Traitements Visual TOM sont soumis dans la Queue Batch « VTOM$BATCH »., créée pendant la phase
d’installation avec une seule entrée. Cette unique entrée est utilisée par le processus associé à l’agent. Modifiez la
Queue Batch ainsi pour définir le nombre d’entrées :
set queue VTOM$BATCH /job_limit=<valeur>
Paramétrage de queue batch VTOM$BATCH
3.6.4 Arrêt et démarrage de l’agent

Démarrez l’agent sous l'utilisateur VTOM035 ainsi :
$ abm_start
Arrêt de l’agent
Arrêtez l’agent sous l'utilisateur VTOM035 ainsi :

$ abm_stop
Démarrage de l’agent
Controlez que l’agent est actif dans la queue batch « VTOM$BATCH » ainsi :
$ sh ent
Contrôle de l’activité de l’agent

• un Utilisateur de nom « VTOM035 »,

• un nom de Machine correspondant à l’agent VMS,
• une Queue Batch de nom « VTOM$BATCH »,
• un Traitement.
Création de l’Utilisateur VTOM035
Utilisez le menu principal « Domaine/Utilisateurs ». Créez l’Utilisateur.
Absyss ©
Fenêtre de création d’un Utilisateur
Absyss ©

Bouton
« Sélection
» Bouton
« Ajouter un
Accès au nœud »
graphe par le
menu
contextuel de
Bouton
« Mise en
Exploitation »
 Exemple de script VMS :

Créez un script « Sélection » dans « DKB300 :[VTOM035.SCRIPTS] ».
$reply /bell /all "message"
Absyss ©
Script
Mode
d’exécution
Unité de
soumission
Utilisateur
Queue
Batch
Pour utiliser les commandes Visual TOM avec des paramètres comportant des majuscules, passez ces paramètres
! entre guillemets.
3.7 INSTALLATION D’UN AGENT Z/OS
3.7.1 Pré-requis
Le système d’exploitation MVS ou Z/OS doit disposer de TCP/IP et JES2. La version du système d’exploitation
Z/OS doit être supérieure ou égale à la version V1R11.
Un travail est soumis avec l'Utilisateur ayant soumis l’agent.
Le port TCP de l’agent doit être indiqué dans le fichier « TCPIP.ETC.SERVICES » sous la forme :
bdaemon 30004/tcp
Quand le traitement est soumis, il produit des compte-rendus d’exécution. Ces compte-rendus sont visualisables :
• dans l’interface graphique,

• sur le système, avec les commandes standard.
S’il y a une installation précédente de l’agent Visual TOM, vous pouvez la sauvegarder ou la désinstaller.
3.7.2 Contrôle des ports de communication TCP

Les ports de communication qui seront utilisés par l’agent sont spécifiés manuellement lors de la phase
d’installation.
Absyss ©
Pour contrôler la présence ou l’absence d’utilisation des numéros de ports de communication, effectuez les actions
suivantes :
• Lancer la commande « netstat » (ISPF Command Shell, menu 6).

• Vérifiez que la valeur du numéro de port TCP correspondant à celle spécifiée dans le fichier
« TCPIP.ETC.SERVICES » n’est pas utilisée.
Sur le système Z/OS, la modification du numéro de port implique un redémarrage du processus agent.
! L’agent lance les travaux et informe le serveur lorsque le moteur demande l’état du traitement.
3.7.3 Sauvegarde d’une installation

Pour sauvegarder une installation, il faut arrêter l’agent Visual TOM et sauvegarder l’installation courante.
A. Arrêt de l’agent
Depuis TSO/ISPF, utilisez la commande STOP : « P SBDAEMON », si l’agent a été lancé en STC, sinon utilisez la
commande STOP : « P JBDAEMON ».
Depuis un poste distant :
• positionnez la variable « TOM_REMOTE_SERVER »,

• utilisez la commande « bdown ».
B. Sauvegarde d’une installation
Copiez les 2 DataSets d’installation « [userid].VTOM[version].JCL » et « [userid].VTOM[version].LOAD » avec les

commandes fournies par le système. Ajoutez à la sauvegarde le fichier « [userid].VTOM[version].SPOOL » contenant
les données concernant les travaux en cours.
Arrêtez l’agent (cf paragraphe ci-dessus) et supprimez les DataSets d’installation, ainsi que le fichier
« [userid].VTOM[version].SPOOL » contenant les données concernant les travaux en cours.
3.7.5 Transfert des archives

Décompressez l’archive contenant les 2 datasets : VT-CSM-MVS.[version].Z ou VT-CSM-ZOS.[version.Z]. Les archives
sont déposées sur votre accès ftp.
Créez si besoin un utilisateur qui sera chargé de gérer l’agent.
Archives de l’agent Z/OS
Absyss ©
Les fichiers « VTOM[version].JCL.XMI » et « VTOM[version].LOAD.XMI » doivent être transférés en mode binaire par
FTP, à partir de votre accès ftp vers le répertoire d’accueil de l’utilisateur Visual TOM.
3.7.6 Installation
L’installation de l’agent consiste à restaurer 2 DataSets contenant le programme exécutable et les JCLs, et
paramétrer le JCL de lancement de l’agent :
• Utilisez le menu 6 sous « ISPF »

• Exécutez la commande : RECEIVE INDSNAME(VTOM[version].JCL.XMI)
Restauration d’un des DataSets contenus dans l’archive
• Entrez le nom du DataSet cible, comme par exemple : DA(ABSYSS.VTOM[version].JCL)

• Exécutez la commande : RECEIVE INDSNAME(VTOM[version].LOAD.XMI)
• Entrez le nom du DataSet cible, comme par exemple : DA(ABSYSS.VTOM[version].LOAD)
• Utilisez le menu 3.4 sous « ISPF » pour vérifier que les DataSets ont bien été créés.
• Paramétrez le JCL de lancement de l’agent « SBDAEMON » situé dans le DataSet « JCL. »
• Autorisez le DataSet « LOAD » en le positionnant dans l’APF (Authorized Program Facility).
• Paramétrez la gestion des codes retour dans le membre VTOMINI du dataset « LOAD » , en valorisant les
variables suivantes :
o TOM_MAXRC : valeur numérique indiquant le seuil de code retour au delà duquel un traitement
est considéré en erreur (sauf si cette valeur est surchargée dans le JCL exécuté ou dans les RVS :
si les 3 sont positionnés, la description RVS est prioritaire).
o TOM_MINRC : valeur numérique indiquant le seuil de code retour en dessous duquel un
traitement est considéré en erreur (sauf si cette valeur est surchargée dans le JCL exécuté ou
dans les RVS : si les 3 sont positionnés, la description RVS est prioritaire).
o Lorsque ces variables ne sont pas positionnées, leur valeur par défaut est « 0 ».
• Paramétrez si besoin le niveau de traces dans le JCL de lancement de l’agent, en valorisant les
variables suivantes :
o TRACE LEVEL (valeur de 0 à 10),
o TRACE_STDOUT (valeur 1 pour produire un flux de sortie, sinon 0).
• Déplacez ou copiez la procédure « SBDAEMON » livrée dans une « PROCLIB ». Adaptez les chemins des DSN
en fonction du lieu d’installation.
Absyss ©

Ces tests consistent à soumettre un Traitement par l’agent Z/OS depuis un serveur UNIX ou Windows.
A. Démarrage de l’agent
Réalisez, au choix, l’une des opérations suivantes :
• Depuis TSO/ISPF, utilisez la commande START : « S BDAEMON », par exemple sous l’option LOG de SDSF.
• Lancez le JCL JBDAEMON en utilisant le menu 3.4 avec l’action SUB. Vérifiez son lancement avec le menu
« SD.ST ».
! La charge de l’agent peut exiger la mise à jour du paramètre REGION, dans le JCL de lancement. L’utilisation multiple
de piles TCP/IP peut exiger l’utilisation d’une carte supplémentaire dans le JCL de lancement (exemple de définition
d’une pile TCP : « SYSTCPD DD DSN=TCPIP.DATA,DISP=SHR »).
B. Validation du fonctionnement de l’agent
• une Queue Batch, de nom « queue_zos »,

• un Traitement , dont le champ script contient le nom du JCL à exécuter.
! Le nom de l’Utilisateur de soumission n’est pas significatif. Le nom de la queue batch n’est pas significatif mais il est
recommandé de fournir un nom significatif tel que proposé ci-dessus.
Utilisez le menu principal « Domaine/Agents ». Créez l’Agent avec création automatique de l’Unité de Soumission.
Absyss ©
Association de l’Utilisateur, de l’Unité de Soumission et de la Queue Batch à l’Environnement

Bouton
« Sélection »
Bouton
Accès au « Ajouter un
graphe par le nœud »
menu
contextuel de
l’Application
Traitement
Bouton
« Mise en
Exploitation »
Absyss ©
 Exemple :
Créez un Traitement. Insérez le JCL suivant :
Mode
d’exécution
Unité de
soumission
Queue Utilisateur
Batch
! Pour être réellement exécuté, le Traitement doit être en mode Exécution et mis en exploitation.
Exemple de JCL :
//JOBTEST JOB
// EXEC PGM=IEFBR14
3.7.8 Fonctionnalités
L’agent Z/OS autorise :
• l’utilisation de la ressource fichier, PDS ou membre de PDS, sans utilisation de caractères joker,
• l’utilisation de la ressource générique,
• l’utilisation de RVS pour gérer le paramétrage des travaux,
• l’arrêt d’un traitement,
• la consultation du script,
• la consultation des logs d’exécution : la sortie standard correspond à la sortie SYSLMESG, la sortie des erreurs
à JESJCL.
L’agent Z/OS ne dispose pas d’un mode commande (gestion des Ressources notamment). L’édition du script en
écriture n’est pas disponible.
Absyss ©
 Remarques :
• La fonctionnalité RVS est mise en œuvre par paramétrage du fichier vtom.ini du serveur comme indiqué ci-
dessous :
[VTOM_MVS]
actif=1
• La longueur de la chaîne à remplacer doit être identique à la longueur de la chaîne de remplacement.
• Les 2 mots clés particuliers : MAXRC et MINRC ne sont pas utilisés pour effectuer un remplacement de chaîne
mais pour valoriser les valeurs minimum et maximum du code retour.
3.7.9 Programme de synchronisation « tstartwait »

Ce programme a pour objectif de démarrer une Application ou un Traitement à la demande à l’état à venir, non
cyclique, et de se synchroniser sur sa terminaison (terminé, en erreur, non planifié, déplanifié).
Ce programme est livré sous forme de dataset, tout comme l’agent. La procédure d’installation est la même.
Un JCL modèle est fourni dans le dataset. Son paramétrage est effectué via une carte « DD » nommée « TSWINI »
utilisable sous forme de « SYSIN » ou de membre de bibliothèque.
Le paramétrage de « TSWINI » est indiqué dans le tableau ci-dessous :
Paramètre Type Valeur Commentaire

par
défaut
TOM_REMOTE_SERVER Obligatoire indique le serveur Visual TOM à qui

s’adresse la commande (nom ou IP).
TOM_PORT_tomDBd Obligatoire indique le port du service « tomDBd » du

serveur Visual TOM.
TOM_POLL_INTERVAL Facultatif 30 indique l’intervalle en secondes entre 2

vérifications de statut.
TOM_EXIT_ERROR Facultatif 1 précise le code retour du programme si

l’Application ou le Traitement se termine
en erreur.
TOM_EXIT_TERMINE Facultatif 0 précise le code retour du programme si

l’Application ou le Traitement se termine
avec succès.
TOM_EXIT_DEPLA Facultatif 1 précise le code retour du programme si

l’Application ou le Traitement se
déplanifie.
TOM_EXIT_NOPLA Facultatif 1 précise le code retour du programme si

l’Application ou le Traitement se non
Absyss ©
planifie.
TOM_EXIT_MODE Facultatif STATUS pour un traitement, privilégie le code

retour du traitement Visual TOM à celui
indiqué par TOM_EXIT_ERROR ou
TOM_EXIT_TERMINE, lorsque le
paramètre est valorisé à « RC ». Par
défaut, le paramètre est valorisé à
« STATUS », lequel pointe vers les valeurs
de TOM_EXIT_ERROR ou
TOM_EXIT_TERMINE.
TOM_NOT_STARTED_TIMEOUT Facultatif -1 attente maximale en secondes au-delà de

laquelle le programme se termine avec un
code retour 128 si l’Application ou le
Traitement n’est pas démarré (prioritaire
sur TOM_MAX_DURATION).
TOM_MAX_DURATION Facultatif -1 à partir de la demande, temps maximum

en secondes au-delà duquel le
programme se termine avec un code
retour 128 si l’Application ou le
Traitement est toujours en cours.
TRACE_STDOUT Facultatif 0 active les traces sur la sortie standard

lorsque sa valeur est à 1.
TRACE_LEVEL Facultatif 0 précise le niveau de traces, de 0 à 10.
Absyss ©
3.8 INSTALLATION EN MODE CLUSTER
3.8.1 Principe
Le principe des clusters (exemples : MC Service Guard pour HP, HACMP pour IBM, MS Cluster pour Microsoft) est
d'utiliser l'une des machines réelles en activité et l'autre en attente. Lorsque la machine « en activité » n'est plus
opérationnelle, la machine en attente en reprend l'activité et les ressources, à l’initiative du cluster.
Schéma de principe
3.8.2 Serveur Visual TOM en mode actif / passif

Le package serveur est installé sur les différents nœuds du cluster susceptibles de prendre le relai. Les services Visual
TOM sont actifs uniquement sur le nœud actif.
Des scripts et procédures sont disponibles pour l’arrêt /relance des processus serveur.
L’accusé de réception de fin d’un traitement (commande « tsend ») doit répondre au nœud actif. Le nœud actif n’est
pas obligatoirement celui qui a initié la demande de soumission. Dans un contexte standard hors cluster, la
commande « tsend » s’adresse au serveur en faisant référence à la valeur de la variable « TOM_REMOTE_SERVER ».
Pour pouvoir répondre au nœud actif, indépendamment de la valeur de « TOM_REMOTE_SERVER », il est nécessaire
de valoriser la variable « TOM_SERVER_CLUSTER » sur les nœuds hébergeant le module Serveur.
Absyss ©
 Remarque :
Il est conseillé de déclarer cette variable sur les nœuds du cluster :
• sur Windows, en tant que variable d’environnement système,

• sur Unix, en tant que variable dans le fichier « .profile » de l’utilisateur d’administration Visual TOM.
! Le démarrage des moteurs est conditionné par la configuration mise en place. Pour disposer d’un démarrage
automatique des moteurs en cas de bascule, le paramétrage suivant doit être effectué :
• Sur windows, ajouter dans la section « [GLOBALES] » du fichier « vtom.ini » le paramètre suivant :
restartEngine=1
• Sur unix, ajouter dans la section « [GLOBALES] » du fichier « .vtom.ini » le paramètre suivant :
restartEngine=1
3.8.3 Agent Visual TOM en mode actif / passif

La déclaration de la machine dans le référentiel Visual TOM correspond à la machine simulée par le cluster.
L’aiguillage vers la machine réelle est fait par le cluster.
Le package agent est installé sur les différents nœuds du cluster susceptibles de prendre le relai. Les services Visual
TOM sont actifs sur l’ensemble des nœuds si la ressource disque est partagée (répertoire des logs), sinon le seul
l’agent actif est celui du nœud opérationnel.
3.8.4 Agent Visual TOM en mode actif / actif

A. Bascule applicative
Dans ce cadre l’agent est actif sur l’ensemble des nœuds. L’applicatif est adressé par une machine logique. Pour
chaque machine logique est associé un répertoire log (traces d’exécutions). Si la ressource n’est pas partagée par les
agents, elle est basculée par le cluster.
Pour que l’agent Visual TOM soit opérationnel dans ce contexte, l’administrateur doit :
• déclarer et utiliser des noms logiques correspondant aux applicatifs,

• créer des répertoires log spécifiques à chaque applicatif, pour les nœuds impactés,
• configurer l’agent Visual TOM (fichier vtom.ini).
Absyss ©
Déclaration de l’Agent logique
[CLUSTER]
applicatif_paie:1
applicatif_2:1
applicatif_3:1
[applicatif_paie]
ABM_LOGS:/vtom/applicatif_paie/logs
[applicatif_2]
ABM_LOGS:/vtom/applicatif_2/logs
[applicatif_3]
ABM_LOGS:/vtom/applicatif_3/logs
Extrait du paramétrage agent
• configurer le serveur Visual TOM (fichier vtom.ini).

[CLUSTER]
applicatif_paie:1
applicatif_2:1
applicatif_3:1
Extrait du paramétrage serveur
Absyss ©
B. Bascule du package agent
Dans ce cadre l’agent est basculé sur un nœud où un agent est déjà actif. Pour rendre possible la cohabitation de
plusieurs agents sur un même nœud, il est impératif de :
• disposer d’un administrateur Visual TOM différent sur les 2 nœuds (ex : vtom1 et vtom2),
• disposer d’un répertoire d’installation différent sur les 2 nœuds (ex : /vtom1 et /vtom2),
• mettre à jour le fichier de configuration .vtom.ini des agents susceptibles de se retrouver sur le même nœud.
 Remarque :
Dans le référentiel, la déclaration de la machine doit soit adresser l’adresse IP de l’agent (package à basculer), soit un
alias.
[general]
BindIP=192.90.84.102
Extrait du paramétrage agent
! Cette fonctionnalité est disponible pour Unix et Windows.
Absyss ©
4 MODULES XVISION
4.1 MODULE IHM
Le module IHM (Interface Homme Machine) permet de concevoir les modèles de planification et d’ordonnancement,
et d’en assurer le pilotage.
 Remarques :
• L’utilisateur doit disposer de droit d’écriture sur le répertoire temporaire de l’utilisateur au sein du système ;
le paramètre « java.io.tmpdir » permet de surcharger cet emplacement.
• Si nécessaire, le fichier de configuration « VtomXvision.l4j.ini », à créer dans le répertoire où se trouve
VtomXvision.exe, permet de préciser ce paramètre.
• Les paramètres surchargeables dans le fichier « VtomXvision.l4j.ini »sont les suivants :
-Dvtom.user.language=en
-Dvtom.java.io.tmpdir=.
-Dvtom.user=TOM
-Dvtom.password=TOM
-Dvtom.cpassword=xxx
-Dvtom.server=localhost:30007
-Dvtom.desktop=mydesk
• Ces paramètres sont également surchargeables dans la commande java de lancement de l’interface.
! L’utilisation des Modèles de Traitement est assujettie au contenu du fichier licence.
4.1.1 Pré-requis
La version du module IHM doit être la même que celle du serveur Visual TOM.
4.1.2 Installation sous Unix

Il est recommandé d’utiliser un système Windows disposant d’un lecteur CD-ROM et de transférer par FTP le
package du CD-ROM vers le système Unix.
 Remarque :
L’installation d’un module IHM est intégrée à l’installation du module Serveur.
! La procédure décrit l’installation d’un module IHM sur un serveur où ni module Serveur ni module Agent n’est
installé. Le cas échéant, procédez à une installation de serveur Unix, décrite précédemment.
Absyss ©
A. Désinstallation
Une désinstallation est nécessaire avant toute réinstallation. Procédez ainsi :
• arrêtez les processus IHM,

• effectuez une sauvegarde du répertoire d’installation,
• supprimez le répertoire d’installation.
B. Transfert de l’archive
• VT-SES pour la solution IHM Linux intégrée au module serveur.
Copiez les archives du dossier représentant le module à installer vers le répertoire temporaire d’installation. Les
fichiers copiés sont :

• <module.os.version> archive du module serveur à installer (le serveur comprend l’IHM)
• bin pour le fichier <module.os.version>,

• ascii pour les fichiers install_vtom et install_vtom.ini.
C. Exécution de la procédure d’installation
et effectuez les actions suivantes :
• décompressez l’archive
• restaurez le répertoire « visual »
• modifiez les droits d’accès,
• associez la variable TOM_VISUAL au profil des utilisateurs de l’interface.
 Exemple :
cd /usr/vtom
uncompress VT-XVI-HPUX.51.Z
tar xvf VT-SDS-HP.51 visual
cd visual
chmod +x *
Mettez à jour le profil des utilisateurs susceptibles d’utiliser l’interface. Assurez-vous que la variable DISPLAY est bien
! positionnée. Assurez-vous de la disponibilité de JAVA.
Absyss ©
D. Validation de l’installation
Positionnez-vous dans le répertoire où a été installé le module, sous l'utilisateur root, et effectuez les actions
suivantes :
• définissez la variable « DISPLAY »,

• définissez la variable « TOM_VISUAL »,
• lancez l’interface.
 Exemple :
export TOM_VISUAL=.
./VtomXvision.ksh
La fenêtre de connexion s’affiche.
Fenêtre de connexion.
Etablissez la connexion, en spécifiant le Domaine (machine hébergeant le serveur Visual TOM).
4.1.3 Installation sous Windows

A. Désinstallation
Une désinstallation est nécessaire avant toute réinstallation. Procédez ainsi :
• arrêtez les processus IHM,

• effectuez une sauvegarde du répertoire d’installation,
Désintallez avec le setup fourni.
Absyss ©
 Remarques :
• Les répertoires modifiés après l'installation (ex: la base de données locale) qui pourront être conservés, ou
être supprimés par le gestionnaire de fichiers.
• Si un module serveur et/ou agent était installé auparavant, les variables d’environnement système préfixées
par TOM ou ABM (exemple « TOM_BIN ») ne sont pas supprimées. La variable PATH n’est pas mise à jour.
B. Lancement du programme d’installation
 Remarque :
Pour éviter que l’utilisateur n’installe d’autres modules, un package ne contenant que l’interface est disponible.
Absyss ©
Cliquez sur le bouton « Suivant » sur les fenêtres suivantes jusqu’à la fenêtre ci-dessous :
 Remarque :
Il n’est pas nécessaire de redémarrer le poste client pour finaliser l’installation.
C. Validation de l’installation
Cliquer sur le raccourci « IHM Visual TOM » se trouvant dans le groupe de programmes généré par l’installation. La
fenêtre de connexion s’affiche.
Absyss ©
Fenêtre de connexion.
Etablissez la connexion, en spécifiant le Domaine (machine hébergeant le serveur Visual TOM).
4.1.4 Gestion de la langue

Pour utiliser la langue française ou anglaise, utilisez les commandes suivantes :
• javaw -Duser.language=fr -Dfile.encoding=UTF-8 -Xmx256m -jar VtomXvision.jar

• javaw -Duser.language=en -Dfile.encoding=UTF-8 -Xmx256m -jar VtomXvision.jar
L’utilisation de la langue française implique l’utilisation des dates au format JJ/MM/AAAA.

!
L’utilisation de la langue anglaise implique l’utilisation des dates au format MM/JJ/AAAA.
Les messages issus du serveur sont restitués dans la langue d’installation du serveur (exemples : échec de connexion,
résultat de la simulation d’une intégration de lot,…).
4.1.5 Composant Dossier d’exploitation

A. Installation
Ce composant est installé soit en complément de l’interface graphique, et accessible directement via cette interface,
soit en mode stand-alone.
L’installation est réalisée comme suit :
• en mode stand-alone, décompressez l’archive « VtomReport » dans le répertoire de votre choix,

• en complément de l’interface graphique, décompressez l’archive dans le répertoire « visual ».
B. Validation de l’installation
En mode stand-alone :
• Positionnez-vous dans le répertoire où vous avez décompressé l’archive,

• exécutez la ligne de commande suivante :
• java -jar VtomReport.jar -s [serveur Visual TOM] -p [port du processus vtserver] -m Design
• sélectionnez le modèle ; cette action produit la génération du rapport.
Absyss ©
En mode intégration dans l’interface :
• associez le droit au profil d’un utilisateur,

• connectez-vous sur le compte auquel le profil est associé,
• utilisez l’item « Editions » du menu « Outils ».
4.1.6 Modules additionnels

Les modules additionnels sont délivrés par le support sur demande. Ces modules sont :
• module WYSIWYG pour la gestion des consignes.
 Remarque :
Le module WYSIWYG est opérationnel sur les plateformes Windows 32/64, Solaris X86 et Linux.
Pour effectuer la mise en œuvre du module, décompressez l’archive fournie par le support dans le répertoire
« visual ».
Absyss ©
5 MISE EN ŒUVRE DU PORTAIL WEB
Le portail web intègre les fonctions suivantes :
• exploration du référentiel,
• pilotage,
• gestion des bureaux.
Le serveur http Visual TOM fourni est prêt à l’emploi.
 Remarques :
• Cette fonctionnalité est opérationnelle uniquement avec le serveur http fourni.
• Le navigateur doit accepter les cookies.
• Les comptes Visual TOM déclarés authentifiés via LDAP sont pris en compte.
• Le nom du serveur doit être renseigné et connu au niveau des alias hosts, local ou DNS. Le nom du host est
utilisé dans l’URL.
! L’authentification LDAP est soumise à l’utilisation d’un module externe Java ; la commande java doit être disponible
et indiquée dans le PATH au démarrage du processus.
5.1 INSTALLATION SOUS UNIX
La désinstallation est manuelle. Les actions particulières relatives aux composants d’une version inférieure ou égale à
5.2 sont les suivantes :
• La variable d’environnement ISERVER_INI doit être supprimée,

• L’exécutable iserver doit être supprimé (répertoire « services »).
Il est recommandé d’utiliser un système Windows disposant d’un lecteur CD-ROM et de transférer par FTP le
package du CD-ROM vers le système Unix.
 Remarque :
L’installation du serveur http Visual TOM est intégrée à l’installation du module Serveur.
! La procédure décrit l’installation sur un serveur où ni module Serveur ni module Agent n’est installé. Le cas échéant,
procédez à une installation de serveur Unix, décrite précédemment.

• VT-SES pour la solution http Visual TOM intégrée au module serveur.
Copiez l’archive du dossier représentant le module à installer vers le répertoire temporaire d’installation. Le fichier
copié est « <module.os.version> » (archive du module serveur à installer (le serveur comprend le serveur http).
Pour la copie de ce fichier, il est recommandé d’utiliser un système Windows, disposant d’un lecteur CD-ROM, et de
transférer le fichier par FTP. Les modes de transfert du fichier est « bin ».
Absyss ©
5.1.3 Exécution de la procédure d’installation

Positionnez-vous dans le répertoire d’installation temporaire où vous avez extrait le fichier, sous l'utilisateur root, et
effectuez les actions suivantes :
• décompressez l’archive,
• restaurez le fichier vthttpd dans le répertoire « $TOM_BIN »,
• restaurez le fichier vthttpd.ini dans le répertoire « $TOM_ADMIN »,
• restaurez le répertoire « www » dans le répertoire « $TOM_HOME »,
• modifiez les droits d’accès,
• créez un lien vers vthttpd.ini à partir de « $TOM_HOME ».
 Exemple :
cd /usr/vtom
uncompress VT-XVI-HPUX.51.Z
tar xvf VT-SDS-HP.53 www
tar xvf VT-SDS-HP.53 vtom/bin/vthttpd
tar xvf VT-SDS-HP.53 admin/vthttpd.ini
cd vtom/bin
chmod +x vthttpd
cd /usr/vtom
ln –s admin/vthttpd.ini vthttpd.ini

Ouvrez un navigateur local au processus vthttpd :
• définissez la variable « DISPLAY »,

• accédez l’url « http://localhost:30080 ».
Absyss ©
La page suivante s’affiche.
Page d’accueil du portail
Etablissez la connexion, en précisant un compte utilisateur et son mot de passe pour accéder au Domaine.
5.2 INSTALLATION SOUS WINDOWS
Les actions relatives aux composants d’une version inférieure ou égale à 5.2 sont les suivantes :
• Le processus iserver, installé en tant que service, doit être désinstallé.

• La variable d’environnement ISERVER_INI doit être supprimée,
• L’exécutable iserver.exe doit être supprimé (répertoire « services »).
 Exemple :
Suppression du service :
cd /d %TOM_BIN%\..\services
instsrv Visual_TOM_Iserver -remove
Suppression du service
Les actions relatives aux composants d’une version supérieure ou égale à 5.3 sont réalisées en utilisant le setup.

Lancez l’exécutable, puis choisissez le module à installer.
Absyss ©
Installation du serveur http.

Ouvrez un navigateur local au processus vthttpd, accédez l’url « http://localhost:30080 ».
La page suivante s’affiche.
Page d’accueil du portail.
Etablissez la connexion, en précisant un compte utilisateur et son mot de passe pour accéder au Domaine.
Absyss ©
5.3 PARAMÉTRAGE
Le portail est préconfiguré : il est directement opérationnel et utilise les ports par défaut.
Les paramètres sont les suivants :
Section Nom Valeur par défaut Objet
params updateMode [vtnotifier] | Indique le type de mise à jour des données.

vtserver:nb_sec | Par défaut, les pages sont dynamiques.
file:/rep/fic1
Le mode « vtserver :nb_sec » précise un
cycle de rafraîchissement des données en
secondes, initié au démarrage du
processus.
Le mode « file:/rep/fic1 » indique le fichier

à prendre en compte pour afficher les
données. Ce fichier est produit par la
commande « vthttpd -dump db.dat ». La
prise en compte d’un fichier mis à jour est
dynamique.
cacheFile [:memory:] | Indique le cache utilisé. Le fichier utilisé

/rep/fic2 doit être différent de celui précisé dans le
paramètre updateMode.
vtserverHost [localhost] Indique la machine hébergeant le

Domaine.
vtserverPort [30007] Indique le port du processus vtserver.
httpPort [30080] Indique le port du serveur http.
httpSecureP Indique le port du serveur https (ex :

ort 30081)
httpCertPath Indique le nom complet du certifcat (ex :

C :\server.crt).
sessionPath [./session] Indique le répertoire de stockage des

sessions.
sessionTime [900] Indique le délai d’inactivité avant

out expiration de la session.
httpRoot [./www] Indique le répertoire de base des pages

web.
httpAcl Spécifie une liste d’adresses interdites

et/ou autorisées. Par défaut, toutes les
Absyss ©
adresses sont autorisées.
httpCgiEnv Spécifie une liste de couple

[variable]=[valeur] pour transmettre des
paramètres au CGI.
httpCgiExt Spécifie une liste de cgi appelés en fonction

de l’extension des fichiers.
httpCgiInterp Force l’utilisation d’un seul interprêteur.
httpAliases Spécifie une liste de liens symboliques.
httpAllowed Spécifie une liste de répertoires autorisés.

URI
instructions url Spécifie l’url qui indique la localisation des

consignes. (mode V4). Une valeur nulle
invalide la fonctionnalité, toute autre
valeur la valide.
 Remarque :
La visibilité des logs d’exécution et des consignes est assujettie à un mode de mise à jour dynamique des pages.
Pour Unix, le fichier de paramétrage est nommé vthttpd.ini et est stocké dans le répertoire « $TOM_ADMIN ».
Pour Windows, le fichier de paramétrage est nommé vthttpd.ini et est stocké dans le répertoire « %windir% ».
Les ACL sont définis par une liste d’adresses où les éléments sont séparés par une virgule. Chaque sous-réseau est
préfixé de « + » pour autorisation, « - » pour interdiction.
Absyss ©
 Exemples :
# Autorisation de l’adresse 127.0.0.1
httpAcl=+127.0.0.1/32
# Autorisation des adresses commençant par 127.0

httpAcl=+127.0.0.1/16 #
# Interdiction toutes adresses, puis autorisation des addresses

# commençant par 192.168.84
httpAcl=-0.0.0.0/0,+192.168.84.0./24 #
# Autorisation des adresses 192.168.84.11 et 192.168.84.12

httpAcl=+192.168.84.11/32,+192.168.84.12/32
# Fournit des paramètres à l’interprêteur CGI

httpCgiEnv=VAR1=VALUE1,VAR2=VALUE2
# Spécifie une redirection de répertoires

httpAliases= /etc/=/my_etc,/tmp=/my_tmp
L’utilisation du protocole https nécessite la création d’un certificat. Pour créer un certificat, les scripts ci-dessous sont
donnés à titre d’exemples.
 Exemples :
Windows
@echo off
set OPENSSL_CONF=c:\OpenSSL-Win32\bin\openssl.cfg
@rem Generate a Private Key
openssl genrsa -des3 -out server.key 1024
@rem Generate a CSR (Certificate Signing Request)
openssl req -new -key server.key -out server.csr
@rem Remove Passphrase from Key
copy server.key server.key.org
openssl rsa -in server.key.org -out server.key
@rem Generating a Self-Signed Certificate
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
@rem Merge Certificate and Private Key
type server.key > vthttpd.crt
type server.crt >> vthttpd.crt
Absyss ©
Unix
#!/bin/sh
# Generate a Private Key
openssl genrsa -des3 -out server.key 1024
# Generate a CSR (Certificate Signing Request)
openssl req -new -key server.key -out server.csr
# Remove Passphrase from Key
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
# Generating a Self-Signed Certificate
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
# Merge Certificate and Private Key
cat server.key > vthttpd.crt
cat server.crt >> vthttpd.crt
5.4 DÉMARRAGE DU PROCESSUS
Sur Windows, le démarrage du service est automatique. Toutefois, le processus peut être lancé en ligne de
commande :
vthttpd -console
Sur unix, le démarrage automatique du processus doit être intégré aux procédures de démarrage du système par
l’administrateur du système. Toutefois, le processus peut être lancé en ligne de commande :
nohup /vtom/vtom/bin/vthttpd &
5.5 ARRÊT DU PROCESSUS
Sur Windows, l’arrêt du service termine le processus.
Sur unix, l’arrêt du processus est effectué en ligne de commande :

kill [pid du processus]
ou
vtdcs -i
Absyss ©
6 MISE EN ŒUVRE DE LA SECURISATION DES FLUX AVEC SSL
La sécurisation des flux est intégrée sur tous les échanges entre les différents modules : serveur/moteur, agents
Windows/Linux/Unix, interface graphique, mode commande. Le protocole TLS V1.2 est pris en charge.
Si un Visual TOM Enterprise Server et un Visual TOM Backup Server sont utilisés, la configuration SSL doit être mise
en place pour chacun d’eux ; Si un Visual TOM Enterprise Server et un Visual TOM Departmental Server sont utilisés
(pour gestion des mises en production), la configuration SSL doit être mise en place pour chacun d’eux.
Pour implémenter un certificat spécifique, le fichier server.crt doit être positionné à la racine de l’installation de
Visual TOM.
6.1 CONFIGURATION DU SERVEUR
Les ports « svtserver » (30017 par défaut), « svtnotifier » (30018 par défaut) doivent être indiqués dans le fichier des
services, en complément des services existant. Cette déclaration induit la vérification du certificat et de la clé privée,
et donc l’usage de SSL. Le port de « vtapiserver » (30002 par défaut) est défini dans son fichier de configuration
« vtomapiserver.ini » stocké dans le répertoire « [install]/vtom/bin ».
6.2 UTILISATION DE L’INTERFACE
Pour que les échanges soient sécurisés, l’interface doit se connecter sur le port de « svtserver ». Aucune
configuration n’est nécessaire. Lorsque ce mode est utilisé, un cadenas est affiché dans le bandeau bas de la fenêtre
principale. Un clic sur ce cadenas affiche le certificat.
Exemple de certificat
Le mode non sécurisé reste opérationnel.
6.3 CONFIGURATION POUR LES AGENTS
Le port « sbdaemon » (30014 par défaut) et le port de « svtmanager » (30010 par défaut) doivent être indiqués dans
le fichier des services, en complément des services existant. Cette déclaration induit l’usage de SSL. Dans ce cas, le
mode commande utilisé dans les traitements soumis par l’agent bénéficie de l’échange sécurisé.
 Remarques :
❑ La déclaration de l’Agent dans le référentiel doit indiquer l’usage de SSL (Agent et Manager).
❑ Le suivi des Agents et le suivi des Managers indique si le mode SSL est utilisé.
Absyss ©
6.4 CONFIGURATION POUR LE MODE COMMANDE
Pour que les échanges soient sécurisés, à partir d’une commande Visual TOM lancée manuellement sur le serveur ou
sur un agent, la variable d’environnement « TOM_SSL » doit être valorisée manuellement à 1.
Pour que les échanges soient sécurisés, à partir d’une commande Visual TOM lancée via l’Agent, le fichier de
configuration « .vtom.ini » doit contenir une section pour chaque commande autorisée, et le paramétrage associé.
Ci-dessous un exemple :
[VTEXPORT]
SSL=1
6.5 CONFIGURATION POUR LE SERVEUR HTTP
Lorsque le serveur est démarré par les scripts d’administration, le fichier de configuration « vthttpd.ini » doit
contenir :
svtserver=[numéro de port sécurisé]
L’entrée par défaut « vtserver » ne doit pas être utilisée.
Lorsque le serveur est démarré manuellement sous le compte d’administration Visual TOM sans utiliser les scripts,
l’utilisateur en interactif doit exporter la variable « TOM_SSL » avec pour valeur « 1 ».
Dans tous les cas, le fichier de configuration « vtom.ini » doit contenir une section « [VTHTTPD] » avec :
SSL=1
6.6 CONFIGURATION POUR LE SERVEUR D’API REST
Lorsque le serveur est démarré par les scripts d’administration, le fichier de configuration « vtomapiserver.ini » doit
contenir :
port=[numéro de port sécurisé]
6.7 CONFIGURATION GLOBALE
Pour simplifier la configuration des processus « vt* » et des commandes « vt* », la section « [GLOBALES] » doit
contenir :
SSL=1
 Remarques :
❑ En configuration primaire / backup, il est impératif d’invalider SSL pour le processus « vtserver » du primaire
et du backup, en précisant leur paramétrage :
[GLOBLALES]
SSL=1
[VTSERVER]
SSL=0
❑ Le processus server API REST n’est pas pris en charge par la configuration globale définie dans le fichier
« vtom.ini ».
Absyss ©
7 MISE EN ŒUVRE DE LA SECURISATION DES SOUMISSIONS
Visual TOM propose de restreindre la liste des répertoires contenant des scripts à exécuter, pour un compte
d’exécution sur une machine. Une vérification est effectuée avant exécution du script ; si le répertoire n’est pas
autorisé pour l’utilisateur indiqué dans la définition du Traitement, le Traitement est statué en erreur.
Pour que cette sécurisation soit prise en compte par un agent, la section « BDAEMON » doit être renseignée.
Exemple 1 : autorisation pour un seul répertoire pour un compte

[BDAEMON]
allowDirectories=user1@D:\VTOM\scripts
Exemple 2 : autorisation pour un seul répertoire pour tous les comptes

[BDAEMON]
allowDirectories=D:\VTOM\scripts
Exemple 3 : autorisation pour 2 répertoires pour un compte

[BDAEMON]
allowDirectories=user1@D:\VTOM\scripts, user1@D:\scripts
 Remarque :
Le caractère séparateur des éléments autorisés est la virgule.
Absyss ©
8 MISE EN ŒUVRE DE IGRAPHBUILDER
Le module IgraphBuilder a pour objet la génération de pages html et de graphes svg représentant un état
d’avancement de la production Visual TOM. Il s’appuie sur les disponibilités du Domaine Visual TOM et du serveur
http Visual TOM.
Ce module requiert la disponibilité de Java Runtime Environment.
 Remarques :
• Cette fonctionnalité est opérationnelle uniquement avec le serveur http fourni.
• La configuration du serveur http doit indiquer un mode de rafraîchissement permanent.
8.1 INSTALLATION SOUS UNIX

Décompressez le fichier igraphbuilder.zip livré dans le répertoire « Installation » dans le répertoire de votre choix.
Transférez ce répertoire vers votre serveur Unix.
 Remarque :
Les fichiers peuvent être décompressés dans le répertoire « www » dans lequel sont installés les fichiers du portail
web.

Exécutez les commandes suivantes dans un SHELL :
• cd [rep_install]
• java –jar IgraphBuilder.jar
8.2 INSTALLATION SOUS WINDOWS
Décompressez le fichier igraphbuilder.zip livré dans le répertoire « Installation » dans le répertoire de votre choix.
 Remarque :
Les fichiers peuvent être décompressés dans le répertoire « www » dans lequel sont installés les fichiers du portail
web.

Exécutez les commandes suivantes dans un SHELL :
• cd [rep_install]
• java –jar IgraphBuilder.jar
Absyss ©
8.3 PARAMÉTRAGE
IgraphBuilder est préconfiguré : il est directement opérationnel et utilise les ports par défaut. La personnalisation des
pages est réalisable en modifiant les scripts xsl et/ou le fichier css fourni.
Les paramètres, indiqués dans le fichier « www/igraphbuilder.ini » sont les suivants :
Section Nom Valeur par Objet

défaut
VTHTTPD host [localhost] Nom de la machine hébergeant le serveur http
port [30080] Port d'écoute du serveur http
IGRAPHBUILDER buildFrequenc 10 Fréquence (en minutes) de rafraichissement des

y fichiers (html, svg, xml en fonction des options).
xslDirectory ./xsl Répertoire des scripts xsl (liste des

environnements, graphe d’environnement, graphe
d’application).
targetDirector ./pages Répertoire de stockage des pages générées (html,

y svg, xml en fonction des options chosies).
L'ensemble des fichiers svg, svgz, htm, html, xtmp
est régulièrement purgé de ce répertoire.
startComman Commande exécutée en début de cycle (aucune si

d vide).
Dans la commande, la macro « {targetDirectory} »

sera remplacée par le nom du répertoire cible. Par
exemple, la commande peut purger le répertoire
« targetDirectory ».
endCommand Commande exécutée en fin de cycle (aucune si

vide).
Dans la commande, la macro « {targetDirectory} »

sera remplacée par le nom du répertoire cible.
Exemple (Windows) :
xcopy /E /C /I /Q /Y "{targetDirectory}" final
=> copie les fichiers générés dans le répertoire

« final ».
Absyss ©
saveXml [0] | 1 Ecriture des fichiers xml non transformés dans le

répertoire cible (valeur 1). Cette option est utile en
phase de personnalisation des scripts xsl
uniquement.
FILTER active [0] | 1 Activation des filtres (valeur 1).
environments Filtre en fonction de leur nom : tous (valeur nulle

ou !), tous ceux dont le nom contient une chaine
de caractères (N:+text), tous ceux dont le nom ne
contient pas une chaine de caractères (N:-text).
applications Filtre en fonction de leur nom ou de leur famille :

toutes (valeur nulle ou !), toutes celles dont le
nom contient une chaine de caractères (N:+text),
toutes celles dont le nom ne contient pas une
chaine de caractères (N:-text),
toutes celles dont la famille contient une chaine de

caractères (F:+text), toutes celles dont la famille
ne contient pas une chaine de caractères (F:-text)
jobs Identique aux applications.
TRACES traces [0] | 1 | 2 | Type de traces (0 aucune, 1 console, 2 fichier, 3

3 console et fichier)
debug [0] | 1 Affiche les traces en mode debug (valeur 1)
directory . Nom du répertoire des traces
fileSize -1 Taille du fichier de trace (en Mo), -1 pour illimité
Absyss ©
9 INSTALLATION DE L’AGENT SNMP
9.1 PRINCIPES DE FONCTIONNEMENT
Le serveur Visual TOM reçoit du moteur une information de fin de traitement. En fonction du paramétrage du
traitement, une alarme est transmise à l’agent SNMP.
L’agent SNMP formate ces alarmes au format SNMP, puis émet les traps vers le port UDP 162 (port standard). La
machine destinataire des traps est désignée dans un fichier de configuration Visual TOM.
L’agent est composé de 2 processus : l’un est chargé de l’envoi des traps, l’autre de l’interrogation de la Mib.
 Remarque :
L’agent utilise le protocole SNMP V1.
9.2 AGENT SNMP UNIX
Il est nécessaire de mettre à jour le fichier de configuration « .vtom.ini » pour activer SNMP.
9.2.1 Installation
L’agent est pré-installé lors de l’installation du module Serveur. Les éléments spécifiques à l’agent SNMP ont la
localisation suivante :
• $TOM_BIN, pour les processus agent (exécutables tsnmp et fw2vtmib)

• $TOM_ADMIN, pour le fichier de configuration du processus agent (fichier vtom.con).
 Remarque :
L’agent peut être installé sur un serveur différent de celui qui héberge le serveur Visual TOM.
Pour installer l’agent, procédez comme suit :
• Transférez l’archive VT-XFR-SNMP-<OS>.<version>.Z dans le répertoire cible de votre système Unix, en mode
binaire,
• Installez le package ainsi :
cd <repertoire cible>
zcat VT-XFR-SNMP-<OS>.<version>.Z | tar xf - .
 Remarque :
Il n’est pas indispensable d’être connecté sous le compte « root » pour installer l’agent. Habituellement, un compte
« vtom » est créé, qui est propriétaire de l’arborescence Visual TOM et assure la gestion des processus.
Absyss ©
9.2.2 Paramétrage du fichier des services

Le port de l’agent doit être spécifié dans le fichier des services comme suit :
AgtVTOM 30161/tcp
AgtVTOM 30161/udp
AgtVTOM 30162/tcp
AgtVTOM 30162/udp
Ce port représente le port d’écoute de l’agent pour la réception des alarmes provenant du serveur Visual TOM.
 Remarque :
Si l’agent est hébergé sur un autre serveur que celui qui héberge le serveur Visual TOM, le fichier des services doit
également être modifié sur le serveur Visual TOM.
9.2.3 Paramétrage de la configuration SNMP

Le fichier vtom.con doit être configuré comme suit :
port = 30161
Host_Trap = <superviser snmp>
entreprise = 1.3.6.1.4.1.2190.166
Oid_Text_Trap = 1.3.6.1.4.1. 2190.100.5.8
Oid_Code_Trap = 1.3.6.1.4.1. 2190.100.5.7
portTrap = <port superviser>
portVtomMib=30162
community=public
Les paramètres ont la signification suivante :
• port : port de l’agent SNMP Visual TOM déclaré dans le fichier « services »
• Host_Trap : machine ou IP vers laquelle les Traps SNMP de l’agent SNMP Visual TOM sont routées.
• entreprise : paramètre fixe
• Oid_Text_Trap : paramètre fixe
• Oid_Code_Trap : paramètre fixe
• portTrap : port vers lequel sont routées les traps (par défaut, port 162)
• portVtomMib : port utilisé pour l’interrogation de la Mib
• community : nom de la communauté (public (valeur par défaut), private ou security)
 Remarque :
La casse doit être respectée. Seule la communauté « public » est prise en compte.
9.2.4 Gestion des processus Agent

Sous le compte d’administration de Visual TOM, utilisez les commandes suivantes :
• tsnmp –s, pour démarrage du processus agent d’envoi de traps,

• tsnmp –t, pour arrêter le processus agent,
• tsnmp –v, pour afficher le statut du processus agent,
• fw2vtmib –s, pour démarrage du processus agent d’interrogation de la Mib,
• fw2vtmib –t, pour arrêter le processus agent,
• fw2vtmib –v, pour afficher le statut du processus agent.
Absyss ©
Pour démarrer les processus automatiquement, adaptez la procédure start_servers.snmp, ou adaptez la procédure
start_servers. Ces procédures sont localisées sous « $TOM_ADMIN ».
 Remarque :
L’arrêt des processus serveur nécessite un redémarrage de l’agent SNMP.
9.3 AGENT SNMP WINDOWS
Il est nécessaire de mettre à jour le fichier de configuration « vtom.ini » pour activer SNMP.
9.3.1 Installation
Les éléments spécifiques à l’agent SNMP ont la localisation suivante :
• <rep_install>\vtom\bin, pour le processus agent

• %TOM_BIN% pour le fichier de configuration du processus agent (fichier vtom.con).
 Remarques :
• L’agent peut être installé sur un serveur différent de celui qui héberge le serveur Visual TOM.
• Le fichier vtom.con peut être positionné dans un autre répertoire. Pour cela, déclarez une variable
d’environnement %TOM_ADMIN%, créez le répertoire correspondant, et déposez le fichier dans ce
répertoire.
Pour installer l’agent en complément d’un module déjà installé, utilisez le package VT-XFR-SNMP.
9.3.2 Paramétrage du fichier des services

Le port de l’agent doit être spécifié dans le fichier des services comme suit :
AgtVTOM 30161/tcp
AgtVTOM 30161/udp
Ce port représente le port d’écoute de l’agent pour la réception des alarmes provenant du serveur Visual TOM.
 Remarque :
Si l’agent est hébergé sur un autre serveur que celui qui héberge le serveur Visual TOM, le fichier des services doit
également être modifié sur le serveur Visual TOM.
Absyss ©
9.3.3 Paramétrage de la configuration SNMP

Le fichier vtom.con doit être configuré comme suit :
port = 30161
Host_Trap = <superviser snmp>
entreprise = 1.3.6.1.4.1.2190.166
Oid_Text_Trap = 1.3.6.1.4.1.2190.100.5.8
Oid_Code_Trap = 1.3.6.1.4.1.2190.100.5.7
portTrap = <port superviser>
portVtomMib=30162
Les paramètres ont la signification suivante :
• port : port de l’agent SNMP Visual TOM déclaré dans le fichier « services
• Host_Trap : machine ou IP vers laquelle les Traps SNMP de l’agent SNMP Visual TOM sont routées.
• entreprise : paramètre fixe
• Oid_Text_Trap : paramètre fixe
• Oid_Code_Trap : paramètre fixe
• portTrap : port vers lequel sont routées les traps (par défaut, port 162).
• portVtomMib : port utilisé pour l’interrogation de la Mib.
 Remarque :
La casse doit être respectée. Seule la communauté « public » est prise en compte.
9.3.4 Gestion du processus Agent

Vérifiez dans les propriétés du service que son mode de démarrage est automatique. Pour activer l’agent, démarrez
le service.
 Remarque :
L’arrêt des processus serveur nécessite un redémarrage de l’agent SNMP.
9.4 INTÉGRATION FRAMEWORK SNMP
9.4.1 Installation
Les éléments spécifiques à l’intégration ont la localisation suivante, sur Unix :
• $TOM_BIN, pour le processus agent (exécutable tsnmp)

• $TOM_ADMIN, pour le fichier de configuration du processus agent et la MIB (fichiers vtom.con et vtom.mib).
Les éléments spécifiques à l’intégration ont la localisation suivante, sur Windows :
• <rep_install>\vtom\bin, pour le processus agent

• %TOM_BIN% pour le fichier de configuration du processus agent et la MIB (fichiers vtom.con et vtom.mib).
 Remarque :
L’intégration de la MIB dans les différents Frameworks varie selon le Framework, sa version, le système
d’exploitation, les procédures d’utilisation en vigueur chez l’agent.
Absyss ©
9.4.2 Description de la MIB

Ci-dessous la liste des informations disponibles dans la MIB.
Champ Lecture/écriture Format

Nom du serveur VTOM Lecture x(30)
Adresse IP Lecture 999.999.999.999
Version du produit Lecture 9.99.9999
Date de péremption Lecture 99/99/9999
Informations sur les contextes d’exploitation
Date d’exploitation Nom Lecture x(30)
Valeur Lecture 99/99/9999
Liste des jobs qui Lecture x(512)
bloquent la date
Machine Nom Ecriture x(30)
Période Nom Lecture x(30)
Queue Nom Lecture x(30)
Calendrier Nom lecture x(30)
Ressource Nom lecture x(30)
Type lecture x(5) Texte | Date | Fichier |
Numérique | Poids | Pile
Valeur écriture x(256)
Utilisateur Nom lecture x(30)
Environnement Nom lecture x(30)
Date ( défaut ) écriture x(30)
Machine ( défaut ) écriture x(30)
Queue( défaut ) écriture x(30)
Utilisateur( défaut ) écriture x(30)
Calendrier ( défaut ) écriture x(30)
Période ( défaut ) écriture x(30)
Informations sur les moteurs d’exploitation
Niveau d’avancement Environnement lecture x(30)
Type lecture x(30) A VENIR | EN COURS |
DEPLANIFIE | NON PLANIFIE |
TERMINE | ERREUR
Valeur lecture 999%
Etat des moteurs Environnement lecture x(30)
Etat écriture 9 ON | OFF
PID lecture 99999
Information sur les serveurs
Etat des serveurs Nom du serveur lecture x(30)
Etat écriture 9 ON | OFF
PID lecture 99999
Absyss ©
Information sur les agents rattachés au serveur

Etat des agents Nom de l’agent lecture x(30)
Etat écriture 9
Informations sur les filtres des traps
Niveau de filtrage des Class lecture x(30)
Traps Sévérité lecture x(15) INFO | WARNING | FATAL
Etat écriture 9 ENABLE | DISABLE
9.4.3 Exemples d’intégration de la MIB
Configuration AIX 4.3.2
Le port 30161 doit être positionné dans le fichier /etc/sdd.conf :

1.3.6.1.4.1.2190 30161 20
Le manager SNMP doit être relancé :
/etc/rc.snmp stop
/etc/rc.snmp start
Configuration SOLARIS 2.10
Le fichier tsnmp.reg doit être généré dans le répertoire /etc/snmp/conf. La structure est la suivante :
Agents =
{
{
name= “tsnmp”
substrees = { 1.3.6.1.4.1.2190.166 }
timeout = 2000000
watch-dog-time = 86400
port = 20161
}
}
Le fichier tsnmp.rsrc est facultatif. Sa localisation est répertoire /etc/snmp/conf. La structure est la suivante :
Resource =
{
{
registration_file = “/etc/snmp/conf/tnsmp.reg”
policy = “spawn”
type = “legacy”
command = “<rep install vtom >/vtom/bin/tsnmp –s”
}
}
Le fichier vtom.con doit être copié sous $TOM_ADMIN ou le répertoire local au binaire tnsmp.
Le manager SNMP doit être redémarré.
Absyss ©
10 PRINCIPES DE FONCTIONNEMENT DES PROCESSUS
Les processus de Visual TOM fonctionnent en mode Client / Serveur Le protocole de communication utilisé est
TCP/IP.
10.1 PROCESSUS SERVEUR
Le module serveur comprend deux types de processus :
• les processus de gestion des objets de la production : accès à la base de données, connexions avec les IHM et
mises à jour à partir de ces IHM, connexions avec les API REST publiques et mode commande,
• les processus d’ordonnancement appelés moteurs.
10.1.1 Processus de gestion de la production

Le module serveur comprend un processus « vtserver » : lorsqu’il démarre, celui-ci se met en écoute :
• sous Unix, les exécutables associés à ce processus sont installés dans le répertoire référencé par la variable
$TOM_BIN,
• sous Windows, les exécutables associés à ce processus sont installés dans le répertoire
<répertoire_installation>\vtom\bin.
Le module serveur comprend un processus « vtmonitor » lancé automatiquement par le processus « vtserver ».Ce
processus « vtmonitor » est dédié à la gestion des alarmes :
• sous Unix, l’exécutables associé à ce processus est installé dans le répertoire référencé par la variable
$TOM_BIN,
• sous Windows, l’exécutable associé à ce processus est installé dans le répertoire
« <répertoire_installation>\vtom\bin ».
Le processus vtserver lance 3 threads (vtserver, vtnotifier, tomDBd). 3 ports de communication sont utilisés (un pour
chaque thread).
10.1.2 Processus de gestion de la base de données

Le module serveur comprend un processus « vtsgbd » qui gère la base de données (création de la base, des tables),
les accès et les mises à jour. Lorsqu’il démarre, Postgres se met en écoute sur un port.
Le processus « vtsgbd » reçoit des requêtes du module « vtserver » :
• IHM : demandes de connexion, de modification ou d’ajout d’objets dans la base de données,…

• Agents : indication de fin de traitement, demande de valorisation d’une ressource, …
• Moteurs : demande des caractéristiques des objets d’un environnement.
Absyss ©
10.1.3 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
TOM_BIN,
• pour chaque environnement actif, le moteur associé effectue des tâches de planification, d’ordonnancement
et de surveillance de l’activité des agents de Visual TOM.
Pour chaque entité d’un Environnement (Application et Traitement), les tâches d’ordonnancement sont les
suivantes :
• évaluation de la planification,
• évaluation des contraintes horaires de début et de fin,
• évaluation des dépendances (liens),
• évaluation des ressources,
• demande de soumission à l’Agent.
• suivi de l’activité des Agents pour les travaux en cours.
10.1.4 Processus serveur d’APIs REST

Le module serveur comprend un processus « vtapiserver » qui répond aux requêtes des APIs REST publiques :
lorsqu’il démarre, celui-ci se met en écoute sur un port.
Les APIs sont accessibles et documentées à l’adresse par défaut « https://[vtomservername]:30002/swagger-ui/ ».
Leur utilisation est sécurisée et nécessite la création de jetons de sécurité à partir de l’interface.
10.2 PROCESSUS AGENT
L’agent correspond au processus « bdaemon ». Lorsque l’agent démarre il se met en écoute sur un port :
• Sous Unix, l’exécutable associé au processus se trouve dans le répertoire référencé par la variable
$ABM_BIN.
• Sous Windows, l’exécutable associé au processus se trouve dans le répertoire
<répertoire_installation>\abm\bin.
Le processus bdaemon reçoit des demandes :
• de validation de Ressources fichiers et génériques,

• de soumission d’un Traitement, envoyée par les Moteurs,
• de tests d’activité des Traitements en cours,
• d’édition de scripts envoyées par les modules IHM,
• de consultations et de suppressions des log envoyées par les IHM.
 Remarque :
Sur Windows, l’agent peut être lancé à partir d’un explorateur ou d’une invite de commande ; dans ce cas, les actions
d’arrêt et de démarrage à partir du suivi des Agents ne sont pas opérationnelles.
Absyss ©
10.3 PROCESSUS DE MISE À JOUR DE L’AGENT
Le manager correspond au processus « vtmanager ». Ce processus a pour objectif de prendre en charge les mises à
jour des agents Unix, Linux et Windows, pilotées depuis l’interface graphique. Il est installé sur chaque système
hébergeant un processus agent Unix, Linux ou Windows.
Absyss ©
10.4 PROCESSUS INTERFACE GRAPHIQUE
Le module Interface graphique comprend un seul processus (VtomXvision). Il établit la connexion sur le port du
processus « vtserver » :
Sous Unix, l’exécutable associé au processus se trouve dans le répertoire associé à la variable $TOM_VISUAL,
Sous Windows, l’exécutable associé au processus se trouve dans le répertoire <répertoire_installation>\visual.
Absyss ©
11 ADMINISTRATION DES PROCESSUS
11.1 ADMINISTRATION SOUS UNIX
Deux menus d’administration des processus de Visual TOM sont disponibles dans le répertoire $TOM_ADMIN :
• admins, pour la gestion des processus serveur,

• adminc, pour la gestion du processus agent.
Menu d’administration admins
Option 1 :
• Affiche les processus serveur, agent, interface et moteur.
Option 2 et 3 :
• Démarre ou arrête les processus serveur.
Option 4 :
• Affiche un sous menu de démarrage / arrêt des moteurs.

• Ce sous menu est accessible uniquement si les processus serveur sont actifs.
• Les moteurs sont gérés globalement (ex : arrêt de tous les moteurs) ou unitairement (la saisie du nom
provoque un changement d’état : actif à inactif ou inversement).
Option 5 :
• Appel du menu adminc.
Option 6 :
Absyss ©
• Appel de l’interface graphique. Cet appel est opérationnel uniquement si les processus serveur sont actifs.
Option 7 :
• Appel de l’utilitaire de sauvegarde vtbackup, quel que soit l’état des processus serveur. La base est
sauvegardée dans le répertoire $TOM_BACKUP.
Menu d’administration adminc
Option 1 :
• Affiche le processus agent, avec l’état des queues batch prises en charge.
Option 2 et 3 :
• Démarre ou arrête le processus agent.
Option 4 et 5 :
• Démarre ou arrête le processus manager.
Le démarrage des processus serveur est tracé dans le fichier « serveurs.log ». Le démarrage des processus manager
et agent est tracé dans le fichier « client.log ».
Pour éviter que ces fichiers ne remplissent l’espace disque, il est nécessaire de gérer leur taille, avec par exemple
l’utilitaire externe « logrotate ». Cet utilitaire doit être installé et configuré par l’administrateur système.
Exemple de fichier de configuration :

/home/vtom/serveurs.log {
size 10M
rotate 3
compress
delaycompress
missingok
notifempty
}
Absyss ©
11.2 ADMINISTRATION SOUS WINDOWS
Les exécutables associés aux processus serveur et agent sont lancés automatiquement lors du démarrage de la
machine. Ils apparaissent en tant que services sous Windows. Les processus sont démarrés et/ou arrêtés à partir de
la fonction « Démarrer\programmes\Paramètres\Panneau de configuration\Services ».
Deux fichiers de commandes « tom-start.bat » et « tom-stop.bat » installés dans le répertoire

<répertoire_installation>\vtom\tools permettent respectivement de démarrer et d’arrêter les processus serveur et
agent.
 Remarque :
Un moteur peut être lancé interactivement par la commande « estart [environnement] ».
Absyss ©
12 CONFIGURATION DU SERVEUR
La configuration d’un serveur est basée sur 3 types de paramètres :
• Les numéros de ports utilisés par les différents processus,

• Les variables d’environnement accessibles par l’administrateur Visual TOM,
• Le fichier de paramétrage « vtom.ini ».
12.1 PORTS DE COMMUNICATION
Les numéros de ports de communication sont définis dans le fichier /etc/services pour un système Unix ou dans le
fichier %windir%\system32\drivers\etc\services pour un système Windows.
Ces numéros de communication ont des valeurs identiques sur toutes les machines utilisant Visual TOM ; les valeurs
par défaut de ces ports de communication sont les suivantes :
Services Ports Commentaire
(standard ou sécurisé) (Non SSL ou SSL)

vtmanager 30000/tcp
Port du gestionnaire de mise à jour de l’agent local
svtmanager 30010/tcp
tomDBd 30001/tcp Port serveur sous-jacent
vtapiserver 30002/tcp Port serveur pour les APIs REST

bdaemon 30004/tcp
Port agent si utilisation locale au serveur
sbdaemon 30014/tcp
30007/tcp
vtserver Port serveur principal. Port de connexion pour l’interface
30017/tcp
svtserver graphique
vtnotifier 30008/tcp
Port serveur sous-jacent
svtnotifier 30018/tcp
vtsgbd 30009/tcp Port serveur sgbd
12.2 VARIABLES D’ENVIRONNEMENT
Pour Unix, les variables d’environnement sont définies dans le fichier « vtom_init.[$SHELL] ». Elles sont positionnées
dans le shell courant lors de l’ouverture de session de l’administrateur Visual TOM, et connues des processus soumis
par cet utilisateur.
Pour Windows, une partie des variables d’environnement est définie sur le système. Ces variables sont de type
système. Tout utilisateur connecté hérite de ces variables.
D’autres variables sont issues du fichier de paramétrage vtom.ini (ex : répertoire des bases)
Absyss ©
Pour unix, ces variables sont les suivantes :
Nom Valeur Commentaire
HOST Nom de la machine

TOM_HOME Répertoire d’installation Différent ou égal à la variable
$HOME
TOM_ADMIN Répertoire des scripts Contient admins
d’administration
TOM_USER_ADMIN Administrateur Visual TOM A les droits d’utilisation d’exécuter
admins
TOM_SUBMITTER Préfixe des noms de script associés
aux queues batch
TOM_REXX Surchage du path de l’interprêteur Variable obsolète (à remplacer par
rexx personnalisation de queue batch)
TOM_BACKUP Répertoire de sauvegarde de la base
TOM_BASES Répertoire contenant la base de
données
TOM_BIN Répertoire des exécutables serveur
TOM_STATS Répertoire des statistiques Vide par défaut
TOM_TRACES Répertoire des traces serveur et Vide par défaut
moteur
PATH Chemin enrichi par la valeur de
TOM_BIN
TOM_TRACE_REMOTE_SERVER 1 Affiche le nom du serveur auquel
s’adresse le mode commande. La
variable TOM_REMOTE_SERVER
doit être valorisée.
Pour windows, ces variables sont les suivantes :

TOM_BIN Répertoire des exécutables serveur Mode commande et services
TOM_BIN
TOM_TRACE_REMOTE_SERVER 1 Affiche le nom du serveur auquel
s’adresse le mode commande. La
variable TOM_REMOTE_SERVER
doit être valorisée.
 Remarque :
La prise en compte d’une nouvelle variable système induit un redémarrage de la machine.
Absyss ©
12.3 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é
nommé « .vtom.ini ».
Sous Windows, ce fichier est généré au cours de la phase d’installation du serveur dans le répertoire %windir%.
On y trouve notamment :
• la valeur du répertoire de la base (item « bases » de la section « GLOBALES »).

• la valeur du répertoire des exécutables (item « bin » de la section « GLOBALES »).
La structure de ce fichier est organisée en sections.
 Remarques :
• Une modification du fichier concernant les traces ne nécessite pas un redémarrage des processus serveur,
moteur et agent. La modification est prise en compte après 60 secondes.
• Toute autre modification de ce fichier nécessite un redémarrage des processus concernés.
• Le fichier vtom.ini / .vtom.ini peut être déplacé ; créez la variable d’environnement %TOM_INI_PATH% /
$TOM_INI_PATH et indiquez les répertoires de recherche.
12.4 FICHIER DE CONFIGURATION VTOMAPISERVER.INI
Sous Unix, ce fichier est généré dans répertoire $TOM_BIN lors de l’installation du serveur.
Sous Windows, ce fichier est généré au cours de la phase d’installation du serveur dans le répertoire %TOM_BIN%.
• le port utilisé par ce serveur (section « vtapiserver »).

• les adresses et ports des processus « vtserver » et « vtsgbd » (sections « vtserver » et « vtsgbd »).
 Remarques :
• Toute modification du fichier de configuration nécessite un redémarrage du processus.
• En cas de mise à jour de version, le fichier de paramétrage doit être mis à jour s’il a été personnalisé lors de
l’installation ou mise à jour précédente.
Absyss ©
12.5 SÉCURISATION DE L’ACCÈS À LA BASE DE DONNÉES
Par défaut, la connexion à la base de données ne demande pas de mot de passe. Pour sécuriser l’accès, procédez
comme indiqué dans la procédure ci-dessous.
 Remarques :
• Un compte en lecture seule est disponible : « vtomro » (pas de mot de passe).
• En configuration primaire backup, la gestion des mots de passe doit être alignée.
• La récupération d’une base de données à partir d’une sauvegarde réalisée par « vtbackup » doit être en
cohérence avec la configuration de l’accès (voir la procédure de mise à jour des fichiers vtom.ini et
.pgpass/pgpass.conf ci-dessous).
• La base de données doit être démarrée.
12.5.1 Configuration sous Unix

Indiquez le mot de passe dans la base de données
cd $TOM_HOME/sgbd/bin
./psql -U vtom –h localhost –p <port vtsgbd>
ALTER USER vtom WITH PASSWORD '<nouveau mdp vtom>' VALID UNTIL 'infinity';
ALTER USER vtomadmin WITH PASSWORD '<nouveau mdp vtomadmin>' VALID UNTIL 'infinity';
\q
Cryptez le mot de passe

cd $TOM_BIN
bcrypt <nouveau mdp vtom>
bcrypt <nouveau mdp vtomadmin>
Absyss ©
Modifiez le fichier de configuration vtom.ini
[VTOM_SGBD]
PASSWORDADMIN=<nouveau mdp vtomadmin crypté par bcrypt>

USER=vtom
PASSWORD=<nouveau mdp crypté par bcrypt>
DBNAME=vtom
PORT=<port vtsgbd>
HOST=localhost
Modifiez les fichiers de configuration de la base « en remplaçant les méthodes d’authentification
cd $TOM_HOME/sgbd/share/postgresql
vi pg_hba.conf.sample
--- lignes impactées : 83/86 et 91
#host all all all @authmethodhost@
local all all all md5
#host replication @default_username@ all @authmethodhost@
host replication @default_username@ all md5
cd $TOM_BASES/sgbd
vi pg_hba.conf
#host all all all @authmethodhost@
local all all all md5
#host replication @default_username@ all @authmethodhost@
host replication @default_username@ all md5
Dans le répertoire d’accueil du compte d’administration de Visual TOM, créez un fichier « .pgpass » avec les droits
600.
cd $HOME
vi .pgpass
----- début du contenu du fichier
<nom du serveur>:<n°de port vtsgbd>:*:vtomadmin:<nouveau mdp vtomadmin >
<nom du serveur>:<n°de port vtsgbd>:*:vtom:< <nouveau mdp vtom>
-----fin du contenu du fichier
12.5.2 Configuration sous Windows

Indiquez le mot de passe dans la base de données :
cd /d %TOM_HOME%/sgbd/bin
psql -U vtom –h localhost –p <port vtsgbd>
ALTER USER vtom WITH PASSWORD '<nouveau mdp vtom>' VALID UNTIL 'infinity';
ALTER USER vtomadmin WITH PASSWORD '<nouveau mdp vtomadmin>' VALID UNTIL 'infinity';
\q
Absyss ©
Cryptez le mot de passe
cd /d %ABM_BIN%
bcrypt <nouveau mdp vtom>
bcrypt <nouveau mdp vtomadmin>
Modifiez le fichier de configuration vtom.ini
[VTOM_SGBD]
PASSWORDADMIN=<nouveau mdp vtomadmin crypté par bcrypt>

USER=vtom
PASSWORD=<nouveau mdp crypté par bcrypt>
DBNAME=vtom
PORT=<port vtsgbd>
HOST=localhost
Modifiez le fichier de configuration de la base en remplaçant les méthodes d’authentification
cd /d %TOM_HOME%/sgbd/share
notepad pg_hba.conf.sample
--- lignes impactées : 83 et 86
host all all 0.0.0.0/0 md5
local all all md5
cd /d %TOM_HOME%/bases/sgbd
notepad pg_hba.conf
host all all 0.0.0.0/0 md5
Dans le répertoire des données d’applications du compte du service « AbsyssSGBD », créez un fichier
« pgpass.conf ».
cd /d %APPDATA%/postgresql
notepad pgpass.conf
----- début du contenu du fichier

<nom du serveur>:<n°de port vtsgbd>:*:vtomadmin:<nouveau mdp vtomadmin >
<nom du serveur>:<n°de port vtsgbd>:*:vtom:< <nouveau mdp vtom>
-----fin du contenu du fichier
Absyss ©
12.5.3 Configuration en contexte primaire/backup

Dans les fichiers « pg_hba.conf.sample » et « pg_hba.conf », du serveur primaire et du serveur de backup, les lignes
concernant la réplication sont impactées de la manière suivante :
host replication vtomadmin all md5
Sur le primaire une entrée doit être ajoutée dans le fichier « .pgpass » ou « pgpass.conf » en fonction de
l'architecture sous la forme :
<nom du serveur de backup>:<numéro de port vtsgbd>:*:vtomadmin:<nouveau mdp vtomadmin >
<nom du serveur primaire>:<numéro de port vtsgbd>:*:vtomadmin:<nouveau mdp vtomadmin >
Sur le backup une entrée doit être ajoutée dans le fichier « .pgpass » ou « pgpass.conf » en fonction de l'architecture
sous la forme :
<nom du serveur primaire>:<numéro de port vtsgbd>:*:vtomadmin:<nouveau mdp vtomadmin >
<nom du serveur de backup>:<numéro de port vtsgbd>:*:vtomadmin:<nouveau mdp vtomadmin >
Absyss ©
13 CONFIGURATION DE L’AGENT
La configuration d’un agent est basée sur 3 types de paramètres :
• Les numéros de ports utilisés par le processus,

• Les variables d’environnement accessibles par l’administrateur Visual TOM,
• Le fichier de paramétrage « vtom.ini ».
13.1 PORTS DE COMMUNICATION
Les numéros de ports de communication sont définis dans le fichier /etc/services pour un système Unix ou dans le
fichier %windir%\system32\drivers\etc\services pour un système Windows.
Les principaux ports utilisés sont les suivants :
Services Ports Commentaire
(standard ou sécurisé) (non SSL ou SSL)

vtmanager 30000/tcp
Port du gestionnaire de mise à jour de l’agent local
svtmanager 30010/tp
tomDBd 30001/tcp Port serveur sous-jacent
bdaemon 30004/tcp
Port agent
sbdaemon 30014/tcp
 Remarque :
Les autres ports, décrits sur le serveur, sont néanmoins utilisés par certaines commandes. Dans certains cas,
l’utilisation de tous les ports peut être justifiée.
13.2 VARIABLES D’ENVIRONNEMENT
Pour Unix, les variables d’environnement sont définies dans le fichier « vtom_init.[$SHELL] ». Elles sont positionnées
dans le shell courant lors de l’ouverture de session de l’administrateur Visual TOM, et connues des processus soumis
par cet utilisateur.
Pour Windows, une partie des variables d’environnement est définie sur le système. Ces variables sont de type
système. Tout utilisateur connecté hérite de ces variables.
D’autres variables sont issues du fichier de paramétrage vtom.ini (ex : traces)
Absyss ©
Pour unix, ces variables sont les suivantes :
HOST Nom de la machine Non obligatoire
TOM_HOME Répertoire d’installation Différent ou égal à la variable

$HOME
TOM_ADMIN Répertoire des scripts Contient admins

d’administration
TOM_USER_ADMIN Administrateur Visual TOM A les droits d’utilisation d’exécuter

admins
TOM_SUBMITTER Préfixe des noms de script associés

aux queues batch
TOM_REXX Surchage du path de l’interprêteur Variable obsolète (à remplacer par

rexx personnalisation de queue batch)
ABM Répertoire du module agent
ABM_BIN Répertoire des exécutables agent
ABM_LOGS Répertoire des traces d’exécution
ABM_SPOOL Répertoire pour les travaux en cours Fichiers temporaires
PATH Chemin enrichi par la valeur de Non obligatoire

ABM_BIN
Pour windows, ces variables sont les suivantes :
ABM_BIN Répertoire des exécutables agent Mode commande agent et services
ABM_LOGS Répertoire des traces d’exécution

ABM_BIN
 Remarque :
La prise en compte d’une nouvelle variable système induit un redémarrage de la machine. Ces variables sont
définies dans le registre Windows.
Absyss ©
13.3 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é
nommé « .vtom.ini ».
Sous Windows, ce fichier est généré au cours de la phase d’installation du serveur dans le répertoire %windir%.
• la gestion de la substitution d’identité (items « users » de la section «BDAEMON »).

• la gestion des queues batch (item « ABM_QUEUES » de la section « BDAEMON »).
 Remarque :
Une modification de ce fichier nécessite un arrêt / relance des processus.
13.4 GESTION DES UTILISATEURS DE SOUMISSION
Sous Unix, l’agent assure naturellement la substitution d’identité ; le Traitement est exécuté sous le compte indiqué
dans les caractéristiques du Traitement dans le référentiel.
Sous Windows, le compte de service associé à l’agent (AbsyssBatchManager) est « LocalSystem » par défaut.
Il y a deux solutions pour soumettre des travaux sur un compte particulier :
• indiquer au niveau du service un compte utilisateur particulier ; dans ce cas, tous les travaux sont soumis
avec les droits de ce compte, indépendamment des caractéristiques du Traitement,
• indiquer au niveau du service un compte disposant de droits spécifiques, et paramétrer le fichier de
configuration vtom.ini afin que la substitution d’identité puisse se faire, conformément aux caractéristiques
du Traitement.
Les droits requis sur le compte de service pour assurer la substitution sont les suivants :
• ouvrir une session en tant que service,

• agir en tant que partie du système d’exploitation,
• outrepasser le contrôle de défilement,
• augmenter les quotas,
• remplacer un jeton de niveau processus,
• créer un objet jeton,
• prendre possession des fichiers ou d’autres objets.
Les attributs suivants du compte de services sont pré-requis :
• le mot de passe n’expire jamais,

• l’utilisateur ne peut pas changer de mot de passe,
• si le compte est membre du groupe utilisateur, il est nécessaire de lui attribuer les droits manuellement ; si le
compte est membre du groupe administrateur, il s’octroie ces droits.
Le fichier vtom.ini doit contenir le domaine, l’utilisateur, son mot de passe crypté avec l’utilitaire bcrypt, pour
pouvoir effectuer la substitution d’identité.
Absyss ©
Lorsque la substitution d’identité est mise en place, et que le Traitement doit être soumis sous le compte du service
sans pour autant indiquer ce compte avec son mot de passe dans le fichier de configuration « vtom.ini », le
Traitement doit disposer d’une variable « TOM_IMPERSONATE » ayant pour valeur 1 (onglet Contexte de la
définition du Traitement).
 Remarques :
• Pour que l’utilisateur de soumission du traitement dispose de ses lecteurs réseaux, la gestion des utilisateurs
doit être activée ainsi que l’option « users_logon » (section « BDAEMON »).
• Les mots-clés de la section « USERS » doivent être renseignés sous la forme [user][n] où n représente un
chiffre. La séquence numérique doit être respectée.
• Sur Windows 2008, le lancement du service « détection de services interactifs est nécessaire s’il doit y avoir
interaction.
• Sur Windows 2008, le compte administrateur utilisé ne doit pas être affecté à un groupe contenu dans un
autre groupe.
• Les noms longs ou comportant des caractères spéciaux sont gérés avec des alias.
• La modification de paramétrage est prise en compte sans nécessité d’arrêt/relance des procesus.
• La substitution d’identité est opérationnelle avec le compte de service « LocalSystem ».
• Les droits associés aux utilisateurs sont respectés, l’Agent ne s’octroie pas automatiquement des droits qui
ne lui sont pas conférés.
• L’accès à un répertoire ne doit pas être sujet à une validation interactive. Les droits doivent explicitement
donner l’accès au répertoire.
Par défaut, l’Agent ouvre une session sous le compte de soumission pour exécuter le Traitement, ce qui nécessite un
privilège pour ouvrir une session locale sur ce compte ; ce privilège est défini dans la stratégie de sécurité locale.
Pour exécuter un Traitement sous un compte de soumission ne disposant pas de ce privilège, il est nécessaire
d’associer la variable de Contexte « TOM_LOGON_MODE » au Traitement, avec la valeur « NETWORK » (la valeur par
défaut étant « LOGON ».
Cette variable peut également être associée à un Environnement ou une Application, une Unité de soumission ou un
Agent, et sera héritée par les Traitements.
Absyss ©
 Exemple :
[BDAEMON]
users=1
users_logon=1
[USERS]
user1=<domaine>,<utilisateur>,<mot de passe crypté>
user2=<domaine>,<utilisateur>,<mot de passe crypté>
user2.alias=Albert DUPONT
...
usern=<domaine>,<utilisateur>,<mot de passe crypté>
TRACE_LEVEL=0
Extrait du fichier vtom.ini
13.5 GESTION DES QUEUES BATCH
L’agent assure la gestion d’un ensemble de queues batch. Il y a deux solutions pour personnaliser l’exécution des
travaux :
• Modifier les queues batch existantes, livrées en standard,

• Créer une nouvelle queue batch.
Pour créer une nouvelle queue batch sur Unix, effectuez les opérations suivantes :
• créez un fichier tom_submit.xxx par copie du fichier tom_submit.ksh, dans le répertoire $TOM_ADMIN,
• effectuez votre personnalisation dans le fichier tom_submit.xxx,
• copiez le répertoire $ABM/config/queues/queue_ksh vers queue_xxx (cp –rp),
• modifiez le fichier $ABM/config/queues/queue_xxx/queue.conf en remplaçant ksh par xxx,
• créez un lien sous $ABM_BIN de xxx vers /bin/ksh (ln –s),
• relancez l’agent.
Absyss ©
 Exemple :
cd $TOM_ADMIN
cp –p tom_submit.ksh tom_submit.myq
cd $ABM/config/queues
cp –rp queue_ksh queue_myq
cd queue_myq
vi queue.conf
queue_myq
10
-1
/vtom/abm/bin/myq
20
Contenu du fichier queue.conf
cd $ABM_BIN
ln –s /bin/ksh myq
Le fichier queue.conf utilise les 5 paramètres suivants (ordre d’apparition dans le fichier) :
• nom de la queue,
• nombre maximum de travaux en exécution simultanée,
• nombre maximum de travaux en attente,
• shell utilisé (chemin et nom ; le nom du shell doit être équivalent à l’extension du nom de la queue),
• priorité (paramètre obsolète).
Le fichier users indique le nombre maximum de travaux simultanés et le nombre maximum de travaux en attente
pour une liste d’utilisateurs.
 Exemple :
Pour l’utilisateur oracle, 10 travaux peuvent s’exécuter simultanément, 5 travaux peuvent être en attente
oracle:10:5
Contenu du fichier users
 Remarque :
La déclaration de l’utilisateur « any » dans le fichier users indique rend cette queue accessible à tous les utilisateurs.
Pour créer une nouvelle queue batch sur Windows, effectuez les opérations suivantes :
• créez un fichier submit_queue_xxx.bat par copie du fichier submit_queue_wnt.bat, dans le répertoire

%ABM_BIN%,
• effectuez votre personnalisation dans le fichier submit_queue_xxx.bat,
• modifiez l’item ABM_QUEUES de la section BDAEMON dans le fichier vtom.ini,
• relancez l’agent.
Absyss ©
Le nombre de travaux simultanés est spécifié après le nom de la queue, dans le fichier vtom.ini.
 Exemple :
cmd
cd /d %ABM_BIN%
copy submit_queue_wnt.bat submit_queue_myq.bat

[BDAEMON]
TRACE_FILE=F:\vtom\TRACES\bdaemon.log
ABM_LOGS=F:\vtom\LOGS
ABM_BIN=F:\vtom\ABM\BIN\
ABM_QUEUES=/queue_w9x:10 /queue_myq:10
TRACE_LEVEL=0
Qu’il s’agisse d’Unix ou de Windows, le Traitement n’est pas soumis à partir du répertoire où le script est localisé.
! L’utilisation de chemins relatifs dans le script peut avoir un impact sur l’exécution. La personnalisation d’une queue
batch rend transparent l’utilisation relative ou absolue des chemins et fichiers dans le script.
13.6 VARIABLES CONNUES POUR LES TRAVAUX EXÉCUTÉS
Lors de la soumission d’un Traitement, le Moteur transmet à l’agent un ensemble de variables d’environnement. Les
principales variables sont affichées par la queue batch, et sont disponibles dans le compte rendu d’exécution du
Traitement.
TOM_REMOTE_SERVER Nom du serveur à l’origine de la demande d’exécution, conditionne le

retour de la commande tsend
TOM_JOB_ID Identifiant du Traitement dans la base de données
TOM_JOB Nom du Traitement
TOM_JOB_COMMENT Commentaire du Traitement
TOM_APPLICATION Nom de l’Application contenant le Traitement
TOM_APP_COMMENT Commentaire de l’Application
TOM_ENVIRONMENT Nom de l’Environnement contenant l’Application contenant le

Traitement
TOM_DATE Date associée au Traitement par héritage
TOM_DATE_VALUE Valeur de la date correspondant à la journée de production traitée
TOM_USER Nom de l’utilisateur sous lequel est exécuté le Traitement
TOM_SCRIPT Nom du script exécuté
TOM_SCRIPT_ARGS Liste des paramètres du Traitement
Absyss ©
TOM_QUEUE_PRIORITY Priorité du Traitement
TOM_JOB_RETRY Nombre de reprises effectuées
TOM_JOB_POINT Valeur du label de reprise (valeur par défaut : 0). Cette valeur
alphanumérique est mise à jour soit manuellement dans l’interface,
soit automatique avec la commande vtstep.
TOM_JOB_EXEC Mode d’exécution
TOM_FAMILY Nom de la famille associée au Traitement
TOM_QUEUE Nom de la queue batch associée
TOM_LOG_ACTION Action à effectuer sur les fichiers traces d’exécution
TOM_HOST Nom de la machine d’exécution
 Remarque :
La valeur de ces variables peut être utile pour la personnalisation d’une queue batch. La variable « JAVA_HOME »,
valorisée dans la queue batch pour définir la version de Java à utiliser, est surchargeable avec une variable associée à
la définition de l’Agent :
• JAVA_HOME : chemin d’accès au jre/jdk (JAVA_CMD = JAVA_HOME/bin/java)
• JAVA_CMD : chemin d’accès direct à la commande java directement (prioritaire sur JAVA_HOME)
• JAVA_TRACE_LEVEL : positionnement de -Dtrace.level avec la valeur de la variable
• JAVA_TRACE_SOURCE : positionnement de -Dtrace.source avec la valeur de la variable
• JAVA_OPTS : positionnement d’une ligne d’options passées à java (prioritaire sur JAVA_TRACE_LEVEL et
JAVA_TRACE_SOURCE).
13.7 GESTION DES TRACES D’EXÉCUTION
Sur Unix et Windows, tout traitement exécuté dispose de deux fichiers de traces d’exécution (logs), stockés dans le
répertoire $ABM_LOGS. Ces fichiers sont nommés comme suit :
• [nom_environnement]_[nom_application]_[nom_traitement]_[AAMMJJ]-[HHMMSS].o (sortie standard),

• [nom_environnement]_[nom_application]_[nom_traitement]_[AAMMJJ]-[HHMMSS].e (sortie erreur).
Pour les autres systèmes d’exploitation, le format est spécifique (exemple : pour GCOS7, le Job Output Report est
stocké dans le fichier SYSOUT, son nom est identifié par le Run Output Number du traitement).
Absyss ©
13.8 GESTION DES PRIORITÉS D’EXÉCUTION
Sur Unix uniquement, la gestion des priorités est prise en charge suite à :
• Paramétrage du fichier vtom.ini,

• Déclaration des queues batch dans le référentiel.
Les paramétrages sont les suivants, au choix :
• DISABLED : la gestion est désactivée.

• BY_ONE : après chaque fin de Traitement, la priorité des travaux présents dans la file est incrémentée de 1.
• BY_PRIORITY : après chaque fin de Traitement, la priorité des travaux présents dans la file est incrémentée
de la priorité initiale.
La priorité est définie par un identifiant numérique contenu en suffixe du nom de la queue batch, dans le référentiel.
 Exemple :
Gestion de la priorité sur la queue batch « queue_ksh » :
• création d’une queue batch « queue_ksh.0 » pour les Traitements non prioritaires,
• création d’une queue batch « queue_ksh.3 » pour les Traitements peu prioritaires,
• création d’une queue batch « queue_ksh.7 » pour les Traitements relativement prioritaires,
• création d’une queue batch « queue_ksh.10 » pour les Traitements prioritaires.
Création d’une queue batch dans le référentiel
Associez aux Traitements la queue batch adaptée.
Les Traitements utilisant la queue batch « queue_ksh » auront une priorité 5.
Paramétrez vtom.ini
[BDAEMON]
ABM_QUEUES_PRIORITY_INCREMENT:BY_ONE
 Remarques :
• Les Traitements ayant une priorité initiale à 10 la conservent et sont prioritaires quelque soit la priorité des
autres Traitements.
• Les Traitements ayant une priorité initiale à 0 la conservent.
• La priorité par défaut est 5.
Absyss ©
13.9 VISION DU CODE RETOUR
Pour disposer d’une vision du code retour des travaux Unix et Windows dans l’interface graphique, il est nécessaire
d’utiliser l’option « -r » de la commande « tsend » située dans les queues batch. Par défaut, le code retour est affiché
(Unix / Windows).
 Exemples :
…
call %TOM_SCRIPT% %arg%
set RETCODE=%ERRORLEVEL%
IF %RETCODE% EQ 0 goto TERMINE
…
:TERMINE
tsend -sT -r%RETCODE%
…
Aperçu partiel d’une queue batch de type Windows adaptée
13.10 VISUALISATION DES TRACES SUR LES CONNECTEURS
L’activation des traces sur les connecteurs est réalisée en modifiant la ligne de commande dans la queue batch du
connecteur.
Ces traces sont opérationnelles sur les connecteurs prenant en charge les types de travaux suivants : WebServices,
AP BO, Transferts, Mail et Visual TOM.
Ces traces sont visibles dans la trace d’exécution du traitement.
Pour ajouter un niveau de trace, modifiez l’appel du connecteur comme indiqué ci-dessous
…
Java -Dtrace.level=[all|debug|info|warn|error|none] –jar $ABM_BIN/vtom2mail.jar $*
Pour ajouter l’affichage du fichier source, modifiez l’appel du connecteur comme indiqué ci-dessous:
…
Java -Dtrace.source=[0|1] –jar $ABM_BIN/vtom2mail.jar $*
 Remarque :
Le niveau de traces par défaut est « info ». Par défaut, le fichier source n’est pas affiché.
17:04:00 | INFO | Vtom2Mail.java: 51 | Vtom2Mail : 5.6.1 EN NT 2013/08/30 Visual Tom (c) Absyss
17:04:00 | INFO | Vtom2Mail.java: 58 | Retrieve connection properties from environment
Extrait d’une trace d’exécution
Absyss ©
13.11 MÉCANISME DE SÉCURISATION DU MOTEUR
Pour pallier le gel d’un moteur issu d’une communication bloquante avec un agent ayant accepté une connexion et
ne pouvant répondre, le paramétrage du moteur implique la mise en place du paramètre :
• secureEngineTimeout, pour fixer le délai au-delà duquel le moteur est redémarré automatiquement après un
gel.
 Remarque :
Ce mécanisme ne doit pas être mis en place par défaut. La mise en place doit avoir pour origine un gel constaté.
La mise en œuvre de ce paramètre nécessite une connaissance approfondie du paramétrage global et des
mécanismes associés.
…
[TENGINE:<nom>]
secureEngineTimeout=300
…
Exemple de paramétrage
Absyss ©
14 INTÉGRATION LDAP
Par défaut, l’utilisateur se connecte directement sans authentification LDAP. Un mot de passe est spécifié dans
l’objet « Compte utilisateur ».
4 modes de gestion sont disponibles :
• création d’un compte Visual TOM avec ses Profils,

• utilisation d’un attribut LDAP, sans création d’un compte Visual TOM, correspondance des noms indiqués
dans l’attribut avec des Profils existants,
• utilisation des groupes LDAP, sans création d’utilisateur, avec correspondance automatique des noms de
groupes avec les Profils existants,
• utilisation des groupes LDAP, sans création d’utilisateur, avec table de correspondance de noms de groupes
avec des Profils existants.
Pour une connexion basée sur un attribut ou les groupes LDAP, le compte ne doit pas être créé dans Visual TOM.
Quel que soit le mode choisi :
• le paramétrage LDAP doit être validé par l’administrateur (accès par le bouton « paramètres »).
• la connexion LDAPS est établie par le serveur Visual TOM, le certificat du client doit être intégré dans le
répertoire « [rep_install]\vtom\bin ». La procédure d’import du certificat est indiquée dans le fichier
« ldapcheck.ini » stocké sous ce répertoire. Le stockage du certificat est personnalisable, via paramétrage de
ce fichier « ldapcheck.ini ».
 Remarque :
Les paramètres indiqués sont uniques et utilisés par l’ensemble des comptes authentifiés via LDAP.
Fenêtre de déclaration d’un compte avec authentification LDAP
Absyss ©
14.1 AUTHENTIFICATION
Fenêtre de paramétrage LDAP
Utilisateur du Domaine
L’utilisateur du Domaine est le compte avec lequel la vérification est effectuée sur l’annuaire, pour authentifier le
compte de l’utilisateur qui se connecte à l’interface.
Base de recherche
Champ obligatoire. Arborescence à partir de laquelle est effectuée la recherche en fonction du critère défini dans
la base de recherche.
Filtre de recherche
Champ obligatoire. Critère permettant de restreindre la recherche à l’entrée correspondant à l’utilisateur.

« {account} » est remplacé par le compte utilisateur au moment de la connexion.
Correspondance
Les autres paramètres de la zone Correspondance ne doivent pas être utilisés lorsque le compte est créé sur
Visual TOM.
Absyss ©
14.2 CONNEXION SANS DÉCLARATION DES COMPTES
Pour s’affranchir de la création des comptes dans Visual TOM et faire correspondre le profil définit dans l’AD avec un
profil existant dans Visual TOM, l’administrateur doit renseigner les éléments de correspondance.
14.2.1 Connexion basée sur un attribut LDAP
L’utilisateur du Domaine est le compte avec lequel la vérification est effectuée sur l’annuaire, pour authentifier le
compte de l’utilisateur qui se connecte à l’interface.
Base de recherche
Champ obligatoire. Arborescence à partir de laquelle est effectuée la recherche en fonction du critère défini dans la
base de recherche.
Filtre de recherche

Absyss ©
Type de correspondance
Champ obligatoire. Le type indique si les droits sont basés sur les valeurs d’un attribut LDAP ou sur le nom des
groupes LDAP.
Attribut pour les profils
Champ obligatoire. Nom de l’attribut dans l’annuaire contenant la liste des profils (profilesVtom ci-dessus ; cet
attribut de l’annuaire contiendra une liste de profils Visual TOM). Le premier nom de profil valide est utilisé par
défaut.
Caractère de séparation des profils
Champ obligatoire. Caractère utilisé pour délimiter les noms de profils s’il y en a plusieurs.
 Exemple :
Sur l’attribut « Description » d’un utilisateur de l’AD, l’administrateur indique une liste de noms de profils Visual
TOM séparés par une virgule.
Dans les paramètres LDAP Visual TOM, le champ « Attribut pour les profils » contiendra « Description ».
14.2.2 Connexion basée sur les groupes LDAP
Absyss ©
Champ obligatoire. L’utilisateur du Domaine est le compte avec lequel la vérification est effectuée sur l’annuaire,
pour authentifier le compte de l’utilisateur qui se connecte à l’interface.
Base de recherche
Champ obligatoire. Arborescence à partir de laquelle est effectuée la recherche en fonction du critère défini dans la
base de recherche.
Filtre de recherche

Type de correspondance
Champ obligatoire. Le type indique si les droits sont basés sur les valeurs d’un attribut LDAP ou sur le nom des
groupes LDAP.
Type de LDAP
Champ obligatoire.
Correspondance automatique
La correspondance automatique indique que les noms des profils qui seront associés à l’utilisateur correspondent
aux noms des groupes LDAP. La non-correspondance automatique indique que les noms des utilisateurs ou des
groupes LDAP sont associés à des profils Visual TOM ; cette association est paramétrée dans l’onglet « Autorisation
LDAP » de la fenêtre « liste des comptes utilisateurs ».
Fenêtre liste des comptes utilisateurs
Absyss ©
Fenêtre d’association d’un groupe LDAP à un profil Visual TOM
 Remarque :
La liste des utilisateurs et groupes LDAP est affiché à partir du bouton situé à droite de la fenêtre.
Absyss ©
15 CONFIGURATION DE L’INTERFACE
La configuration de l’interface est basée sur les ports de communication, sur le fichier de paramétrage
VTXVision.ini situé :
• dans le répertoire $HOME de l’utilisateur pour Unix,

• dans le répertoire %USERPROFILE% de l’utilisateur pour Windows,
et sur un fichier facultatif [USER].dat stocké dans le répertoire « visual ».
 Exemples :
/home/exploit
C:\Documents and Settings\exploit.EXPLDOMAIN
 Remarques :
• Aucune variable d’environnement n’est nécessaire.
• En mode pilotage, la vision du code retour d’exécution des travaux Unix et Windows, est assujetti au
paramétrage des queues batch.
15.1PORT DE COMMUNICATION
Les ports utilisés sont les suivants :
Service Port Commentaire
vtserver 30007/tcp Port en écoute sur le serveur
vtnotifier 30008/tcp Port en écoute sur le serveur
 Remarque :
La déclaration de ces ports n’est pas obligatoire au niveau du fichier %windir%\system32\drivers\etc\services.
Absyss ©
15.2 FICHIER DE CONFIGURATION VTXVISION.INI
Les paramètres de l’interface sont indiqués ci-dessous :
Valeur par
Section Nom Objet
défaut
TRACE level 0 Niveau de traces, de 0 à 10
screen 1 0 pour ne pas afficher les traces sur

écran
directory . Répertoire de stockage du fichier

référencé par l’item FileName.
File 0 1 pour afficher les traces dans un

fichier
FileName VTXvision.log Nom du fichier trace.
fileSize 0 Taille du fichier en Mo. Les nouveaux

éléments remplacent les plus anciens.
SERVER hostname Valeur du domaine par défaut

proposé par la fenêtre de connexion
serverPort 30007 Valeur du port sur lequel est

effectuée la connexion
lastUser TOM Nom du dernier utilisateur connecté

proposé par la fenêtre de connexion
hostList Liste des domaines sur lesquels une

connexion a eu lieu a partir du poste
Language Langue utilisée
password Mot de passe crypté correspondant

au dernier utilisateur connecté
IHM hideMemoryWatcher 1 0 pour afficher la consommation

mémoire.
hideLocalTimeWatcher 0 1 pour masquer les informations du

poste client
hideDomainTimeWatch 0 1 pour masquer les informations du

er serveur Visual TOM.
hideTimezoneWatcher 0 0 pour afficher les heures des

fuseaux.
Absyss ©
showWorkBench 1 0 pour masquer l’espace de travail
showPendingExploit 1 0 pour masquer l’affichage des

travaux non mis en exploitation lors
de la connexion et déconnexion de
l’utilisateur
screenNumber 0 Numéro associé à l’écran sur lequel

s’affiche la fenêtre de connexion
backgroundImage 1 Image d’arrière-plan de la fenêtre de

connexion
NETWORK compressionLevel 0 Niveau de compression pour

l’échange des données entre serveur
et Ihm. La valeur est comprise entre 0
et 9
vtom documentation Répertoire ou URL contenant les

fichiers documentations et consignes
vtom browser Item facultatif (lecteur intégré dans

l’interface) Logiciel d’édition des
documentations et consignes
(navigateur, éditeur)
Pour l’item « documentation » de la section « vtom », le nom du répertoire contenant les consignes d’exploitation ne
! doit pas contenir la chaîne de caractères « webdoc ». Cette valeur surcharge celle qui est déclarée dans le fichier
« vtom.ini ».
Le respect de la casse est indispensable.
 Remarques :
Par défaut, le nom des fichiers docs et consignes est construit à partir du nom des objets, selon le modèle suivant :
• [environnement]_[application]_doc.htm, pour un fichier de documentation d’application,

• [environnement]_[application]_recovery.htm, pour un fichier de consignes d’application,
• [environnement]_[application]_[traitement]_doc.htm, pour un fichier de documentation de traitement,
• [environnement]_[application]_[traitement]_recovery.htm, pour un fichier de consignes de traitement.
Le paramètre « documentation » de la section « vtom » est issu du fichier vtom.ini du serveur. Si ce paramètre n’est
pas renseigné, c’est le paramètre du fichier « VtXVision.ini » qui est utilisé. Si ce paramètre n’est pas renseigné dans
un des deux fichiers, le chemin pris en compte est « [rep_install]/visual/doc ».
Absyss ©
 Exemple :
[TRACE]
level=0
screen=1
directory=.
file=0
fileName=VTXvision.log
fileSize=-1
[SERVER]
hostName=localhost
serverPort=30007
lastUser=TOM
hostList=
[IHM]
hideMemoryWatcher=1
[NETWORK]
compressionLevel=9
[vtom]
#browser="C:\Program Files\Internet Explorer\iexplore.exe"
#documentation=http://localhost/documentation/localhost
documentation= F:\VT-documentation\www\localhost
Exemple de fichier VTXVision.ini
Absyss ©
16 CONFIGURATION DU MOTEUR
16.1 MISE À JOUR DU RÉFÉRENTIEL LORS DE LA BASCULE DE DATE
Pour intégrer un fichier d’export ou un lot de mise en production lors de la bascule de Date, le fichier de
paramétrage « vtom.ini » doit être configuré pour permettre l’exécution d’un script spécifique.
Les items de configuration sont les suivants :
• AfterChangeOfDateCmd : description du script avec son chemin (ex : /opt/vtom/scripts/maj_ref.sh).

• AfterChangeOfDateCmdRename : choix de renommage ou non du script en fin d’exécution ; le script est
suffixé en « .ok » ou en « .ko » en fonction de sa terminaison. (Valeurs acceptées : 1|y|Y|1|n|N, avec 1 par
défaut).
Dans la section « GLOBALES », le script est utilisé par tous les moteurs. Dans la section « TENGINE », le script est
utilisé par l’environnement concerné.
Le script reçoit les paramètres positionnels suivants :
• Nom de l’environnement,
• Nom de la Date,
• Valeur de la Date au format jj-mm-aaaa.
 Remarques :
❑ Quand la Date bascule (la fonction de « reset » est effectuée ainsi que la mise à jour de la Date), et si la
variable est positionnée avec un nom de script présent et accessible en lecture, ce script est exécuté. La fin
du script est bloquante pour la suite des actions du moteur.
❑ Un échec du script (code retour différent de 0), ou l’insuffisance de droits pour son exécution, provoque
l’arrêt du moteur. L’absence du script ne provoque pas l’arrêt du moteur. Dans tous les cas, l’arrêt du moteur
est historisé.
❑ Une trace indique le démarrage et la terminaison du script. Les traces doivent être activées.
❑ Pour un moteur, la bascule de 2 dates se fait toujours séquentiellement. Par contre, pour 2 moteurs traitant
une Date, les 2 exécutions peuvent être simultanées. Il faut donc veiller à la bonne écriture des scripts en cas
d’exécution concurrente.
❑ L’écriture du script est à la charge du client. Ce script doit vérifier s’il y a des lots de gestion des mises en
production à intégrer en exploitant la commande « vttdf », ou des fichiers d’export à intégrer. Dans tous les
cas, il faudra choisir des noms signifiants pour les lots et fichiers d’export.
16.2 AUTRES BESOINS
L’annexe C décrit les différents paramètres acceptés par le moteur.
Absyss ©
17 MODE COMMANDE SÉCURISÉ
Pour que le serveur accepte une commande en ligne sécurisée, 2 actions sont nécessaires :
• Paramétrer le fichier de configuration « vtom.ini » situé sur le serveur, en valorisant la variable

« enableCommandSecurity » à 1.
• Pour chaque utilisateur à l’origine d’une commande, et sur chaque machine concernée, créer le fichier de
pré-authentification avec la commande « vtcmd ».
 Remarques :
❑ Le fichier de pré-authentification peut contenir plusieurs pré-authentifications vers des serveurs différents.
Ce fichier est nommé « .vtompass » et est stocké dans le répertoire d’accueil de l’utilisateur (par exemple,
cela correspond à %HOMEDRIVE%/%HOMEPATH% si ces variables sont définies, sinon à la valeur de la
variable %USERPROFILE% sur Windows 10).
❑ Le fonctionnement est restreint aux commandes « vt* » excepté : vtcmd, vtomkill, vttdf, vtmonitor, vthttpd,
tengine.
Exemple :
[rep_install]\vtom\vtom\bin\vtcmd /login /server antipodes /port 30007 /account TOM /password xxx
Exemple :
Absyss ©
18 API REST SÉCURISÉES
Les API REST ne sont pas utilisables sans Jeton de sécurité.
La sécurité du serveur d’API propose :
• des Stratégies : une stratégie est un regroupement d’APIs et de méthodes. Les Stratégies sont associées aux
Jetons.
• des Jetons : un Jeton dispose d’une période de validité, de filtres IP et d’un ensemble de stratégies, est actif
ou non.
 Remarques :
❑ La création de Stratégies et de Jetons de sécurité nécessite un droit dans le Profil de l’utilisateur.
❑ Les Jetons de sécurité sont utilisables à partir des entêtes http ou en paramètre de l’URL.
❑ Les APIs sont utilisables en mode https.
❑ Le serveur Visual TOM renvoie le port du serveur d’api à l’interface ; le serveur d’api doit être installé sur le
serveur Visual TOM, l’accès au port du serveur d’API doit être autorisé pour l’interface.
Fenêtre de définition d’une stratégie
Portée
La portée de la stratégie liste les APIs utilisables. La sélection des APIs est facilitée par un filtre sur les actions et sur
les objets.
Absyss ©
Filtrage
Le filtrage permet de restreindre les APIs sur des types d’objets en fonction de leur nom.
 Exemple de valeurs pour un objet de type Date :

Toutes les Dates : D*
Toutes les Dates dont le nom commence par « D » : D*
Les Dates « date_1 » et « date_2 » : date_1,date_2
Fenêtre de définition d’un Jeton d’autorisation
Date d’activation et d’expiration
Le Jeton est valide uniquement lorsque la date d’utilisation est située dans la période définie.
Filtrage IP
Si aucun filtre n’est défini, toutes les adresses sont valides. Elles sont précisées en IPV4 et IPV6.
 Exemples :
Uniquement l’adresse 192.90.84.99 : -0.0.0.0/0,- ::0,+192.90.84.99
Toutes les adresses sauf 192.90.84.99 : +0.0.0.0/0,+ ::0,-192.90.84.99
Uniquement les accès locaux : -0.0.0.0/0,-::/0,+::1,+127.0.0.0/8
Absyss ©
19 PRINCIPALES COMMANDES SERVEUR
Pour obtenir de l’aide sur une commande, utilisez les commandes suivantes :
• [commande] –h
• vthelp [commande]
! L’utilisation du mode commande serveur sur une machine nécessite l’installation locale d’un module serveur.
19.1 PROCESSUS SERVEUR
19.1.1 Démarrage des processus

Windows
[rep_install]\vtom\tools\TOM-START.BAT
Unix
admins
19.1.2 Arrêt des processus
Windows
[rep_install]\vtom\tools\TOM-STOP.BAT
Unix
admins
Absyss ©
19.2 PROCESSUS MOTEUR
19.2.1 Démarrage du moteur de l’environnement spécifié

Windows et Unix
tengine [nom_environnement]
ou
estart [nom_environnement]
19.2.2 Arrêt du moteur de l’environnement spécifié
Windows et Unix
estop [nom_environnement]
19.2.3 Test de l’état d’un moteur sur un environnement
Windows et Unix
epresent [nom_environnement]
19.2.4 Remise à zéro de l’indicateur d’état d’un moteur dans la base
Windows et Unix
eclear [nom_environnement]
19.3 SAUVEGARDE ET RESTAURATION DE LA BASE
Windows ou Unix : sauvegarde physique de la base

vtbackup
Windows ou Unix : sauvegarde par copie logique du référentiel
vtexport > base.dat
Windows : restauration après sauvegarde physique de la base
cd %TOM_BIN%
cd ..
cd ..
rmdir /S /Q bases
mkdir bases
echo “sauvegarde issue de vtbackup…”
xcopy /E /H vtomdb.2008-11-26-09h35m27s bases
echo ‘’Mise a jour des droits sur le repertoire…’’
Absyss ©
Unix : restauration après sauvegarde physique de la base

cd $TOM_HOME/bases
rm –rf *
echo “sauvegarde issue de vtbackup…”
cp –rp ../ vtomdb.2008-11-26-09h35m27s/* .
Windows ou Unix : restauration après copie logique du référentiel
vtimport -f base.dat
 Remarque :
La commande est autorisée sur le serveur Primaire et sur le serveur de Backup.
Un modèle de Traitement est disponible pour créer une sauvegarde de la base Visual TOM. Ce modèle doit être
utilisé par une action glisser/coller, de l’arbre du domaine vers un graphe d’Application.
Sélection du Modèle
Paramétrage du Traitement
19.4 PURGES
19.4.1 Statistiques
• Paramètre 1 : fonction (export, purge, liste des dates)
• Paramètre 2 : "date de début de de fin"
vtstools –p "JJ-MM-AAAA JJ-MM-AAAA"
 Remarque :
Avant la purge, les données peuvent être sauvegardées.
Absyss ©
 Exemple :
vtstools –e "22-10-2008 26-10-2008" > stats_20081022-20081026.dat
vtstools –p "22-10-2008 26-10-2008"
! Les commandes « tpurge » et « tstat » sont obsolètes.
Un modèle de Traitement est disponible pour gérer les données statistiques. Ce modèle doit être utilisé par une
action glisser/coller, de l’arbre du domaine vers un graphe d’Application.
19.4.2 Historique
• Paramètre 1 : fonction (export, purge, liste des dates)
• Paramètre 2 : "date de début date de fin"
vthtools –p "JJ-MM-AAAA JJ-MM-AAAA"
Absyss ©
 Remarque :
Avant la purge, les données peuvent être sauvegardées.
 Exemple :
vthtools –e "22-10-2008 26-10-2008" > stats_20081022-20081026.dat
vthtools –p "22-10-2008 26-10-2008"
Un modèle de Traitement est disponible pour gérer les données de l’historique. Ce modèle doit être utilisé par une
action glisser/coller, de l’arbre du domaine vers un graphe d’Application.
Absyss ©
19.5 SUIVI
19.5.1 Journées d’exploitation

Commande d’affichage des dates d’exploitation bloquées : vtlist –v bloquage
Commande d’affichage des dates d’exploitation avec leur valeur : vtlist –v dates
19.5.2 Anomalies
Commande d’affichage des travaux en erreur : vtlist –v ENERREUR
Commande d’affichage des travaux déplanifiés : vtlist –v DEPLANIFIE
19.5.3 Risques
Commande d’affichage des travaux retenus : vtlist –v retenu
Commande d’affichage de l’état des moteurs : vtlist –v env
19.5.4 Périmètre technique

Commande d’affichage de la connexion aux machines agents et de l’état des agents : vtmachine –all
Commande d’affichage des processus serveurs, moteurs et sessions (ihm et commande) : vtping
Absyss ©
20 PRINCIPALES COMMANDES AGENT
Pour obtenir de l’aide sur une commande, utilisez les commandes suivantes :
• [commande] –h
• vthelp [commande]
L’utilisation du mode commande agent sur une machine nécessite l’installation locale d’un module agent. La variable
! TOM_REMOTE_SERVER indique à qui sont adressées les commandes.
 Remarque :
Pour afficher le nom du serveur auquel s’adresse une commande en ligne lors de l’usage de cette commande,
l’utilisateur doit déclarer la variable « TOM_TRACE_REMOTE_SERVER » avec une valeur à 1.
20.1 PROCESSUS AGENT
20.1.1 Démarrage du processus

Windows
[rep_install]\vtom\tools\TOM-START.BAT
Unix
adminc
20.1.2 Arrêt du processus
Windows
[rep_install]\vtom\tools\TOM-STOP.BAT
Unix
bdown -a
ou
adminc
20.2 GESTION DES RESSOURCES
20.2.1 Gestion des piles

Affichage du contenu : tpush –name [nom] –info
Ajout d’un élément : tpush –name [nom] –value [valeur]
Suppression d’un élément : tpop –name [nom]
Effacement : tempty –name [nom]
20.2.2 Gestion des ressources textes

Affichage du contenu : tval –name [nom] –info
Modification de la valeur : tval –name [nom] –value [valeur]
Absyss ©
20.2.3 Gestion des ressources numériques

Affichage du contenu : tval –name [nom] –info
Modification de la valeur : tval –name [nom] –value [valeur]
Incrémentation de la valeur : tval –name [nom] –inc [valeur]
20.2.4 Utilitaire de vérification de fichier

La commande « tfile » réalise un test sur des fichiers ou répertoires en fonction de critères. Le code retour renvoyé
par le programme équivaut au nombre d’objets répondant aux critères.
Cet utilitaire, disponible pour Unix et Windows, est employée principalement dans la ressource générique, pour
étendre les capacités de la ressource fichier.
 Exemple :
Vérifier qu’un fichier est présent et cohérent : si ce fichier existe, il ne doit pas être en cours de transfert ou utilisé
par un processus.
rem %1 : nom du fichier
rem %2 : nombre de fichier devant répondre à la sélection
tfile -m W -f %1
if "%ERRORLEVEL%" == "%2" goto OK
:KO
echo "Erreur : Il y a %ERRORLEVEL% fichier(s) correspondant a la sélection"
exit /B %ERRORLEVEL%
:OK
echo "Succès : il y a %ERRORLEVEL% fichier(s) correspondant a la sélection"
:fin
exit /B 0
Script Windows utilisant l’utilitaire tfile
Le masque correspond à une ouverture en accès exclusif (-m W).
La documentation associée à l’utilitaire est obtenue par la commande « tfile –h ».
Absyss ©
ANNEXE A : LISTE DES COMMANDES SERVEUR
Commande Objet
abswhat Affiche l’estampille correspondant à la version de l’exécutable fourni en

paramètre
eclear Réinitialise dans la base l’état du moteur de l’environnement fourni en

paramètre
epresent Effectue un test de présence du moteur pour l’environnement fourni en

paramètre
estart Démarre le moteur de l’environnement fourni en paramètre
estop Arrête le moteur de l’environnement fourni en paramètre
tchkdate Vérifie l’état d’une date d’exploitation
tdateinfo Affiche les caractéristique d’une date
tdeldate Supprime une date d’exploitation
tdelres Supprime une ressource
tengine Démarre le moteur de l’environnement fourni en paramètre
tgetdate Affiche la valeur de la date d’un environnement
vtlist Affiche des listes sur l’état des travaux, sur les objets du domaine
vtmachine Affiche l’état des machines et de l’agent associé
tmodmach Modifie le nom d’une machine logique ou la valeur de la machine physique
tremote Exécute une commande sur un ensemble de machines agentes
treset Réinitialise un ensemble d’applications liées à une date d’exploitation
teresetApp Réinitialise une application
tresetJob Réinitialise un traitement
vtaddapp Crée ou modifie une application
vtaddaccount Crée un compte de connexion
vtadddate Crée ou modifie une date d’exploitation
vtaddjob Crée ou modifie un traitement
vtaddmach Crée un agent
Absyss ©
vtaddunit Crée une unité de soumission
vtaddperiod Crée une période
vtaddprofile Crée un profile
vtaddqueue Crée une queue batch
vtaddres Crée ou modifie une ressource
vtaddtoken Crée un jeton
vtadduser Crée un utilisateur de soumission
vtbackup Sauvegarde la base de données
vtcmd Crée un fichier de pré-authentification pour le mode commande
vtcopy Effectue un transfert de fichier vers un agent
vtdcs Arrête un processus serveur ou agent
vtdelalarm Supprime une alarme
vtdelaccount Supprime un compte
vtdelapp Supprime une application
vtdelcal Supprime un calendrier
vtdelenv Supprime un environnement
vtdelinstruction Supprime une consigne
vtdeljob Supprime un traitement
vtdellink Supprime un lien
vtdelmach Supprime une machine
vtdelunit Supprime une unité de soumission
vtdelperiod Supprime une période
vtdelprofile Supprime un profil
vtdelqueue Supprime une queue batch
vtdeltoken Supprime un jeton
vtexport Exporte le référentiel dans un fichier
vthelp Affiche une aide globale sur les commandes et sur le paramétrage (vtom.ini)
Absyss ©
vtimport Charge le référentiel à partir d’un fichier
vtplan Affiche la planification des traitements et applications pour une date ou plage
de date
vtlclient Affiche des informations sur le système
vtmsg Ajoute un message dans la console d’événements
vtomkill Termine un processus
vtping Affiche l’état des processus serveurs, moteurs et sessions (ihm et commande)
vthtools Sauvegarde et purge les données historiques
vtstools Sauvegarde et purge les données statistiques
vttdf Gestion des lots de mise en production (listes, transfert, simulation, intégration)
Absyss ©
ANNEXE B : LISTE DES COMMANDES AGENT
Commandes Unix et Windows
Commande Objet
abswhat Affiche l’estampille correspondant à la version de l’exécutable fourni en

paramètre
bcrypt Crypte les mots de passe fournis en paramètre
bdaemon Soumet le processus agent
bdel Supprime la référence d’un traitement pris en charge par le bdaemon
bdown Arrête le processus agent
bstat Affiche l’utilisation des queues batch
buser Affiche les travaux en cours pour l’utilisateur courant
tempty Vide le contenu d’une pile
tfile Vérifie un fichier / répertoire en fonction d’un type d’accès
tmail (**) Envoie un message électronique
tping Affiche l’état du processus agent
tpop Supprime le premier élément d’une pile
tpush Ajoute un élément dans une pile
tsend Indique le statut de terminaison d’un traitement
tsms Envoie un message court
vtstep Modifie le label de reprise d’un traitement (alphanumérique)
tval Modifie ou affiche la valeur d’une ressource
vtcmd Crée un fichier de pré-authentification pour le mode commande
vtcopy Effectue un transfert de fichier vers un agent
vtdcs Arrête un processus serveur ou agent
vtmsg Ajoute un message dans la console d’événements
vtping Affiche l’état du processus agent et des sessions (ihm et commande)
vtstart Démarre un traitement à la demande
Absyss ©
Absyss ©
Commandes correspondantes sur les autres systèmes
Commande OS400 VMS GCOS8

abswhat - - -
bcrypt bcrypt - -
bdel bdel - -
bstat bstat - -
buser buser - -
tempty tempty tempty -
tfile
tmail - - -
tping - - -
tpop tpop tpop
tpush tpush tpush -
tsend tsend tsend tsend
tsms - - -
vtstep vtstep tstep -
tval tval tval tval
vtcmd - - -
vtcopy - - -
vtdcs - - -
vtmsg - - -
vtping - - -
vtstart vtstart tstart (*) -
Les systèmes GCOS7 et Z/OS ne disposent pas du mode commande agent. Toutefois, un programme spécifique
« tstartwait » est livré pour Z/OS.
(*) : Demande des travaux sans modification des paramètres.
(**) : Les paramètres par défaut de la commande « tmail » peuvent être indiqués dans le fichier tmail.ini. Ces mêmes
paramètres peuvent être surchargés à l’exécution. Pour plus d’information sur les paramètres, utilisez la commande
« tmail –h » ou « vthelp tmail ».
Commandes spécifiques OS400
Commande Objectif
VTLSTJOB Liste de toutes les tâches en exécution
VTLSTMSGW Liste des messages en attente de réponse dans
une queue de message
VTSNDRPLY Envoi d’une réponse à un message
Absyss ©
ANNEXE C : PARAMÈTRES DE CONFIGURATION DU FICHIER VTOM.INI
Section Nom Module Module Valeur par Objet Système

Server Agent défaut
Processus serveur
GLOBALES Bases Vtsgbd Répertoire contenant la base de données Windows
Sécurité du mode commande
GLOBALES enableCommandSecurity Serveur 0 [1] Forçage d’une pré-authentification (valeur 1) Commun

pour exécution d’une commande, initiée par la
commande « vtcmd ».
GLOBALES SSL Serveur Agent 0 [1] Forçage du mode SSL pour l’ensemble des Commun
commandes en ligne.
Démarrage / Redémarrage automatique des Moteurs
GLOBALES restartEngine Moteur 0 [1] Démarrage automatique (valeur 1) en cas de Commun

bascule du package serveur dans une
configuration cluster
Gestion des classes de Machines
classes_machines classe1 à classe[n] Tremote Liste des machines d’une classe sur lesquelles Commun
sont exécutées une commande à partir de
l’utilitaire tremote.
Communication entre le Serveur et l’Agent
Absyss ©
VTSERVER daemonNotChecked Serveur machine1, Désactive la vérification cyclique de l’état des Commun
machine2,… machines spécifiées.
VTSERVER ACL Serveur Autorise la communication avec le réseau Commun

indiqué (+a.b.c.d,+a.b.c.e) ou l’interdit (-
a.b.c.d).
Exemple : ACL=+192.90.84.0/24,-192.90.84.121
Communication entre le Moteur et l’Agent
GLOBALES delaiWait Moteur 300 Durée en secondes à partir de laquelle un Commun

Traitement est considéré dans le statut indiqué
par le paramètre « StatusFailExist » si le Moteur
ne parvient pas à joindre l’Agent.
GLOBALES nbWaitRetry Moteur 5 Nombre de tentatives de connexion maximum Commun

pour renvoi de la même demande à l’agent.
GLOBALES StatusFailSubmit Moteur ENERREUR Statut d’un Traitement qui n’a pu être soumis Commun
[ENCOURS, sur l’Agent.
DEPLANIFIE]
GLOBALES StatusFailExist Moteur ENERREUR Statut d’un Traitement soumis mais inconnu de Commun
[ENCOURS] l’agent lors d’un test d’activité.
GLOBALES delaiHost (*) Moteur 90 Délai d’attente en secondes entre 2 tentatives Commun
de connexion à un agent.
GLOBALES loglongnames bdaemo 1[0] Permet de réduire le nom des fichiers dont la Agent
n taille est limitée par le système d’exploitation Windows
Absyss ©
(valeur 0)
GLOBALES FQDNHostname Moteur Permet de transmettre à l’agent le nom long du Commun

serveur Visual TOM
GLOBALES DomainName Moteur Permet de forcer la valeur de la variable Commun

TOM_REMOTE_SERVER, et surcharge
« FQDNHostname ».
Log loglongnames bdaemo 1[0] Permet de réduire le nom des fichiers dont la Agent Unix
n taille est limitée par le système d’exploitation
(valeur 0)
GLOBALES secureEngineTimeout Moteur 0 Fixe le délai en secondes au delà duqueI le Commun

moteur est redémarré suite à une absence
d’activité pertinente (ex : dialogue avec le
processus vtserver). Le temps fixé doit être
adapté, et au moins supérieur au temps de
bascule des dates. La valeur 0 indique que le
mécanisme de redémarrage est désactivé.
GLOBALES maxLogSize Moteur 1 073 741 824 Taille maximum, exprimée en octets, pour
l’affichage des traces d’exécution.
GLOBALES maxScriptSize Moteur 10 485 760 Taille maximum, exprimée en octets, pour
l’affichage et l’édition des scripts.
GLOBALES TOM_CONNECT_TIMEOUT Moteur 5 Valeur du timeout sur une connexion. Ce Commun

paramètre peut être appliqué à un programme
spécifique (nouvelle section).
GLOBALES TOM_EXCHANGE_TIMEOUT Moteur 120 Valeur du timeout sur un échange. Ce Commun

paramètre peut être appliqué à un programme
Absyss ©
spécifique (nouvelle section).
Gestion des Liens OU
GLOBALES AcceptOrItems Moteur 0 [1] Gestion des Liens OU. Les objets dont le nom Commun
est préfixé par « OU_ » ou « OR_ » sont
considérés comme étant un lien de type OU.
GLOBALES forceOrItemsToSimu Moteur [0] 1 Force la simulation (valeur « 1 ») sur le nœud Commun
représentant le « OU ».
Gestion du mode d’exécution
GLOBALES modeExecApp Moteur 0 [1] Inhibe le mode d’exécution « EXECUTION » de Commun

l’application ; seul le mode d’exécution du
Traitement est pris en compte (valeur 0).
Gestion des chemins de script
Job tagScript Moteur Permet de spécifier un caractère pour inhiber le Commun

chemin par défaut des scripts défini au niveau
de l’environnement.
Gestion des contraintes liées aux Heures
GLOBALES useLinkBeforeEndTime Moteur 0 [1] Permet de privilégier l’heure maximum de Commun

démarrage par rapport aux liens amont d’une
Application ou d’un Traitement.
Absyss ©
GLOBALES useJobEndTimeInsteadAp Serveur 0 [1] Permet de désactiver l’évaluation de la Commun

pEndTime contrainte d’heure maximum de démarrage de
l’Application en tant que contrainte du
Traitement (valeur 1).
GLOBALES useJobStartTimeInsteadA Serveur 0 [1] Permet de désactiver l’évaluation de la Commun

ppStartTime contrainte d’heure minimum de démarrage de
l’Application en tant que contrainte du
Traitement (valeur 1).
Gestion des contraintes liées à la planification
GLOBALES JobCheckAppConstraints Moteur o [n] Permet de désactiver l’évaluation des Commun

contraintes de planification et le mode
d’exécution d’une Application lorsque
l’Application est forcée à « En cours », pour
exécuter les Traitements de cette Application
(valeur n).
Gestion des contraintes liées aux Ressources
GLOBALES resnopla Moteur 0 [1] Permet de statuer une Application ou un Commun

Traitement à non planifié à la place de
déplanifié en cas de ressource non valide
(valeur 1).
GLOBALES timeBexist Moteur 120 Cycle d’évaluation en secondes : vérification des Commun
ressources, des travaux en cours, et du temps
maximum d’exécution des traitements.
Gestion des Ressources de type pile
Absyss ©
GLOBALES statusPileAll Moteur 0 [1] Statue le Traitement à chaque itération (valeur Commun
0) ou attend que la pile soit vide (valeur 1). En
cas d’erreur sur une itération, l’élément courant
n’est pas dépilé, les éléments restant à dépiler
subsistent dans la pile.
GLOBALES statusPileOne Moteur 0 [1] Traite le premier élément de la pile uniquement Commun
(valeur 1) ou l’ensemble (valeur 0).
Gestion des Ressources de type Fichier
GLOBALES fileresdelay (**) bdaemon 0 Intervalle de temps minimum en secondes sans Commun
modification du fichier, requis pour considérer
le fichier présent. Ce paramètre ne doit pas être
mentionné dans la déclaration de la Ressource
fichier.
GLOBALES fileresdelay1 bdaemon Optionnel. Pour être utilisé, ce paramètre doit Commun
être mentionné dans la déclaration de la
Ressource fichier et dans le fichier de
configuration.
configuration.
configuration.
Absyss ©
Gestion des Ressources de type Générique
GLOBALES timeoutResGen Moteur 5 Temps d’exécution maximum en secondes du

script associé, au-delà duquel la Ressource est
considérée invalide. Durant ce temps
d’évaluation, le moteur est en attente.
Gestion des Ressources de type externe
GLOBALES timeoutResExtern Moteur 30 Temps d’exécution maximum en secondes pour

l’évaluation d’une Ressource SAP Event, d’une
Ressource SGBD ou fichier distant.
Gestion des Ressources de type Poids
GLOBALES NonLibResPoidsAppliTer Moteur 0 [1] Invalide (valeur 1) la libération de ressource de Commun

m type poids lors d’une terminaison normale ou
en erreur d’une Application.
GLOBALES NonLibResPoidsJobTerm Moteur 0 [1] Invalide (valeur 1) la libération de ressource de Commun

type poids lors d’une terminaison normale ou
en erreur d’un Traitement.
Gestion du Rattrapage de Date
GLOBALES nbJoursRattrapage (***) Moteur 2 [2 à 10] Nombre de journées à partir duquel le mode Commun
Rattrapage est activé (10 maximum)
Gestion des Dates
GLOBALES JobBlockDateSyst Moteur 0 [1] Permet le blocage (valeur 1) d’une date de type Commun
système
Absyss ©
GLOBALES ResetDateOnAppCopy Serveur [0] 1 Permet d’affecter la date par défaut de Commun
l’environnement cible lors de la copie
d’application d’un environnement vers un autre
(valeur 1), ou partage la date entre les
environnements source et cible (valeur 0).
GLOBALES resetDateWithoutFlush Moteur [0] 1 Permet de réduire le temps de bascule de date. Commun
Gestion des liens
GLOBALES AppCheckDateValue Moteur 1 [0] Permet de valider un lien en tenant compte Commun
(valeur 1) de la cohérence de valeur de 2 dates
lorsque 2 applications liées disposent de dates
différentes.
GLOBALES deplan_obj Moteur 0 [1] Sur un traitement non planifié disposant de Commun
l’option « ne pas déplanifier les successeurs »,
et disposant d’un successeur lié par un lien
obligatoire, inhibe la déplanification de ce
successeur (valeur 1) ; le successeur reste à
venir.
GLOBALES forceDeplanSuccOnError Moteur 1 [0] Force la déplanification immédiate d’un Commun

successeur d’une application ou traitement
(valeur 1) même si celui-ci dispose de l’option
ne pas déplanifier les successeurs, et que le lien
entre le prédécesseur et le successeur est non
valide.
Gestion des travaux cycliques
Absyss ©
GLOBALES relanceAppCycliqueEnErr Moteur 0 [1] Permet de continuer les cycles d’une Commun
eur Application de type cyclique même si son statut
est en erreur
GLOBALES relanceJobCycliqueEnErre Moteur 0 [1] Permet de continuer les cycles d’un Traitement Commun
ur de type cyclique même si son statut est en
erreur
GLOBALES relanceAppCycliqueDepla Moteur 0 [1] Permet de continuer les cycles d’une Commun
nParRes Application (valeur 1) de type cyclique si la
déplanification est due à l’invalidité d’une
Ressource, en prenant en compte la non
planification liée au paramètre resnopla.
GLOBALES relanceJobCycliqueDepla Moteur 0 [1] Permet de continuer les cycles d’un Traitement Commun
nParRes (valeur 1) de type cyclique si la déplanification
est due à l’invalidité d’une Ressource, en
prenant en compte la non planification liée au
paramètre resnopla.
Gestion des priorités
GLOBALES usePriority Moteur 1 [0] Autorise (1) ou non (0) la gestion des priorités Commun
et affiche l’attribut dans l’interface graphique
(1) ou le masque (0). La section d’un moteur
peut surcharger la valeur globale « 1 » valeur
par « 0 ».
Gestion des mises en production
GLOBALES AfterChangeOfDateCmd Moteur Nom du script à exécuter lors de la bascule de Commun

Date.
Absyss ©
GLOBALES AfterChangeOfDateCmdR Moteur 1 [0] Autorise (1) ou non (0) le renommage Commun
ename automatique du script en fin d’exécution.
Utilisation d’un agent GCOS8 ou ZOS
VTOM_GCOS8 Actif vtserver 1 [0] Fournit l’accès aux contextes dans l’interface Commun
GLOBALES GNSP Moteur 0 [1] Prise en charge du gestionnaire réseau GNSP Commun
entre le Moteur et l’Agent GCOS8.
Utilisation de l’interface SNMP
VTOM_SNMP agent vtserver Nom du serveur hébergeant l’agent SNMP Commun
VTOM_SNMP Actif vtserver 1 [0] Activation de l’interface SNMP Commun
Utilisation de l’interface Patrol
VTOM_PATROL agent Nom du serveur hébergeant l’agent Patrol Commun
VTOM_PATROL Actif 1 [0] Activation de l’interface Patrol Commun
VTOM_PATROL user Utilisateur Patrol Commun
VTOM_PATROL password Mot de passe de l’utilisateur Patrol Commun
Gestion des paramètres d’un environnement
TENGINE:[env] Paramètres moteurs Moteur Permet à un environnement de disposer d’un Commun

mode de fonctionnement différent, pour un
ensemble de paramètres
Absyss ©
Gestion des traces
TENGINE:[env] TRACE_FILE_COUNT Moteur 0 (****) Nombre de fichiers Commun
TENGINE:[env] TRACE_FILE_SIZE 0 (****) Taille des fichiers en Mo Commun
TENGINE:[env] TRACE_FILE Nom des fichiers Commun
TENGINE:[env] TRACE_LEVEL 0[1 à 6] Niveau de trace Commun
[exe_name] TRACE_FILE_COUNT Binaires Binaires 0 (****) Nombre de fichiers Commun
BDAEMON
VTSERVER
TSEND
[exe_name] TRACE_FILE_SIZE 0 (****) Taille des fichiers en Mo Commun
[exe_name] TRACE_FILE Nom des fichiers Commun
[exe_name] TRACE_LEVEL 0[1 à 6] Niveau de trace Commun
[exe_name] TRACE_SOURCE 0 [1] Affichage de la référence dans le source Commun
[exe_name] TRACE_STDOUT 0 [1] Forçage de l’affichage sur la sortie standard Commun
[exe_name] SSL 0[1] Force l’usage de SSL. Invalide le paramètre de la Commun

section « GLOBALES » pour la commande
Absyss ©
spécifiée.
TBATCH32… TRACE_FILE_COUNT Binaires 0 (****) Nombre de fichiers Agent

Windows 95
/ 98 /
Millenium
TBATCH32 TRACE_FILE_SIZE 0 (****) Taille des fichiers en Mo Commun
TBATCH32 TRACE_FILE Nom des fichiers Commun
TBATCH32 TRACE_LEVEL 0[1 à 6] Niveau de trace Commun
Gestion du script de rattrapage
GLOBALES ManualRecovery Moteur 0 [1] Force (valeur 1) l’exécution du script de Agent

rattrapage même si la relance est de type Windows
manuel.
Gestion des Queues batch sous Windows
BDAEMON ABM_QUEUES bdaemon queue_wnt :10 Prise en compte des queues batch listées, avec Agent
[,queue_xxx :n] pour chacune le nombre d’exécutions Windows
simultanées
Gestion des utilisateurs sous Windows
BDAEMON users bdaemon 0 [1] Prise en compte de la substitution d’identité Agent

(valeurs 0 ou 1). Ce paramètre exige l’utilisation Windows
de la section USERS
Absyss ©
BDAEMON users_logon bdaemon 0 [1] Prise en compte de l’exécution du script de Agent

logon. (valeurs 0 ou 1). Ce paramètre exige Windows
l’utilisation de la gestion des utilisateurs
Windows.
USERS user1 à user[n] bdaemon Caractéristiques du compte de soumission sous Agent

la forme : domaine, utilisateur, mot de passe Windows
crypté.
Gestion cluster applicatif
CLUSTER [nom machine logique] bdaemon 0 [1] Liste des machines logiques faisant partie du Commun
cluster pour visualisation des logs dans
l’interface
[nom machine ABM_LOGS bdaemon Répertoire des logs de la machine logique Commun
logique]
Gestion cluster
GLOBALES BindIP bdaemon Ecoute de l’agent sur une adresse précise pour Commun
autoriser une utilisation multiple d’agents sur
bstat une machine. La valeur correspond à une
adresse IP.
bdown
Gestion des priorités sous Unix
BDAEMON ABM_QUEUES_PRIORITY_ bdaemon BY_ONE Affecte une priorité au Traitement en file Agent Unix
INCREMENT d’attente, en fonction de la de la queue batch
associée.
Absyss ©
DISABLED : la gestion est désactivée.
BY_ONE : après chaque fin de Traitement, la

priorité des travaux présents dans la file est
incrémentée de 1.
BY_PRIORITY : après chaque fin de Traitement,

la priorité des travaux présents dans la file est
incrémentée de la priorité initiale.
BDAEMON ABM_QUEUES_PRIORITY_TRACES bdaemon NON [OUI] Affiche les traces spécifiques à la gestion des Agent Unix
priorités dans le fichier de traces de l’agent.
Restriction sur les répertoires de soumission
BDAEMON allowDirectories bdaemon Liste les couples « utilisateur/répertoire » Commun

autorisés pour soumission.
Gestion d’un agent en DMZ
BDAEMON connectToServer bdaemon 0 [1] Supprime les initiatives de connexion de l’agent Commun
vers la zone de confiance. Les informations sont
stockées localement et récupérées à l’initiative
du Moteur (TSEND pour les fins d’exécution,
TVAL pour les modifications de ressources).
Gestion de l’historique
GLOBALES histo binaires 0 [1] Historise (valeur 1) les actions IHM et le mode Commun
serveur commande de l’agent local au serveur.
Absyss ©
GLOBALES histo binaires 0 [1] Historise (valeur 1) le mode commande de Commun

agent l’agent distant au serveur. La valeur de ce
paramètre est indépendante de celle du
serveur.
Gestion des statistiques
GLOBALES stats vtserver 1 [0] Enregistre les données statistiques d’exécution Commun
des applications et traitements.
Paramètres généraux de l’agent Windows
BDAEMON ABM_BIN bdaemon Répertoire contenant les binaires agent. Agent

Windows
BDAEMON ABM_LOGS bdaemon Répertoire contenant les traces d’exécution des Agent
traitements. Windows
BDAEMON ACL bdaemon Autorise la communication avec le réseau Commun

indiqué (+a.b.c.d,+a.b.c.e) ou l’interdit (-
a.b.c.d).
Exemple : ACL=+192.90.84.0/24,-192.90.84.121
Paramètres de connexion de l’agent GCOS7
GCOS7 CnxInfo Correspondant bdaemon Lettre de connexion Agent

Windows
GCOS7 CnxInfo User bdaemon Utilisateur de connexion Agent

Windows
Absyss ©
GCOS7 CnxInfo Password bdaemon Mot de passe de l’utilisateur de connexion Agent

Windows
GCOS7 CnxInfo Terminal bdaemon Type de terminal utilisé Agent

Windows
GCOS7 CnxInfo ConnectionName bdaemon Nom de la session définie dans Amaril Agent
Windows
GCOS7 CnxInfo DatanetFile bdaemon Chemin complet du fichier jogdnsx.cn0 Agent

Windows
GCOS7 CnxInfo VisibleEmulator bdaemon 0 [1] Affichage des fenêtres de l’émulateur lors de la Agent
connexion. Windows
Serveur de backup
VTSERVER FORCE_TIMEOUT_BASCU vtserver Temps maximum de prise de décision (contrôle Serveur de

LE des agents) pour la bascule, spécifié en backup
secondes, à indiquer dans la configuration du
serveur de backup.
VTSERVER MIN_TIMEOUT_BASCULE vtserver Temps pendant lequel le serveur de backup Serveur de

contrôle l’état du serveur primaire, et à l’issue backup
duquel est effectué le contrôle des agents.
GLOBALES backup_monitor_loop vtserver 10 Cycle de vérification de l’état de la Commun

synchronisation exprimé en secondes.
GLOBALES TOM_TSEND_WAIT_RETRY Mode 30 Nombre de secondes entre 2 tentatives vers le Agent

commande
serveur.
Absyss ©
GLOBALES TOM_TSEND_MAX_RETRY Mode 120 Nombre de tentatives maximum vers le serveur. Agent
commande
GLOBALES BACKUP_MODE vtserver Mode d’utilisation du serveur de backup : en Serveur de

mode réplication uniquement (valeurs « r » ou backup
« R »), ou en mode switch pour réplication avec
transfert de responsabilité (« s » ou « S »).
GLOBALES BACKUP_SYNC_TIMEOUT vtserver 900 Délai en secondes après lequel le serveur passe Serveur
en mode stand alone en cas d’erreurs de primaire
synchronisation avec le serveur de backup.
GLOBALES BACKUP_SYNC_TIMEOUT vtserver [backup_sync_ti Script exécuté lorsque le serveur passe en mode Serveur
_SCRIPT meout.bat / stand alone, depuis le répertoire TOM_BIN. Si la primaire
backup_sync_ti variable TOM_BIN n’est pas positionnée,
meout.sh]
le répertoire courant d’exécution est utilisé
(TOM_BASES).
Paramètres de connexion
(processus vtserver vers le processus vtsgbd)
VTOM_SGBD MAXRETRY vtserver 180 Nombre maximum de tentative de connexion Commun

du processus vtserver vers le processus vtsgbd.
VTOM_SGBD WAITRETRY vtserver 10 Délai d’attente en secondes entre 2 tentatives Commun

de connexion du vtserver vers le vtsgbd.
VTOM_SGBD TRY_CONN_TIMEOUT vtserver 120 Délai maximum avant arrêt du processus Commun
« vtserver » en cas de perte de connexion avec
la base de données.
Absyss ©
Documentations et consignes
Vtom documentation Interface Répertoire ou URL contenant les fichiers Commun

documentations et consignes (valeur par Ihm
défaut).
Gestion mémoire
GLOBALES MALLOC_ARENA_MAX binaires binaires Nombre de pools mémoire utilisés par GLIBC. Commun
(*****) serveur agent
UNIX
(*) La valeur du paramètre « delaiWait » doit être supérieure à la valeur de « delaiHost ».
(**) Exemple de déclaration de la Ressource fichier : /repertoire/nomfichier(fileresdelay2). Le paramètre « fileresdelay » ne s’applique que sur le premier
fichier d’un masque (ex : *.csv).
(***) Rattrapage.
(****) La valeur 1 (TRACE_FILE_COUNT) désactive la rotation et ne tient pas compte de la taille maximum du fichier (TRACE_FILE_SIZE).
(*****) Paramétrage impactant sur la consommation mémoire et les performances.
 Remarques :
• Les paramètres liés au Moteur peuvent être spécifiques à un Environnement, en les utilisant dans la section « [TENGINE:<nom de
l’environnement>] ».
• L’édition immédiate d’un script depuis l’interface est conditionnée par la non utilisation du paramètre « fileresdelay ».
! Le respect de la casse est indispensable.
Absyss ©
Absyss ©
Absyss ©
ANNEXE D : VARIABLES D’ENVIRONNEMENT IMPACTANT LE FONCTIONNEMENT
Nom Valeur par défaut Objet Système
Communication entre l’Agent et le Serveur
TOM_CONNECT_TIMEOUT 5 Timeout de connexion en secondes vers un serveur primaire/backup Commun
TOM_TSEND_DELAY 500 Nombre de tentatives vers le serveur primaire. Commun
TOM_TSEND_WAIT_RETRY 30 Temporisation en secondes entre chaque tentative. Commun
TOM_TSEND_MAX_RETRY 120 Nombre de tentatives maximum vers le serveur de backup. Commun
Absyss ©
SIMPLICITE, FIABILITE, AGILITE,

AU SERVICE DE LA PERFORMANCE INFORMATIQUE ET METIER
www.absyss.com
Absyss – 15/17, Boulevard du Général de Gaulle – 92120 Montrouge - Tel : 33 1 40 84 89 01 – Fax 1 40 84 88 40 – www.absyss.com
SAS au capital de 500.000 € - RCS Nanterre B 353 281 561 – APE 5829A – FR 94 353 281 561

Visual TOM Guide Administrateur

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Visual TOM Guide Administrateur

Transféré par

Droits d'auteur :

Formats disponibles

Visual TOM Guide Administrateur

SIMPLICITE, FIABILITE, AGILITE,

Visual TOM Guide Administrateur

1.1.3 Visual TOM XVision VT-XVI (Conception, Pilotage) ......................................................................................................................................... 10

1.1.4 Visual TOM Modules optionnels ..................................................................................................................................................................... 10

1.2 Terminologie de base. .................................................................................................................................................................................... 10

2.1.2 Préparatifs ...................................................................................................................................................................................................... 11

2.1.3 Transfert de l’archive ...................................................................................................................................................................................... 11

2.1.4 Le fichier de configuration de l'installation : install_vtom.ini ......................................................................................................................... 12

2.1.5 Lancement du script d’installation.................................................................................................................................................................. 12

2.1.6 Fichier de configuration du profil de l’administrateur du Serveur .................................................................................................................. 13

2.1.7 Validation de l’installation .............................................................................................................................................................................. 15

2.1.8 Repartir d’une base de données vide ............................................................................................................................................................. 19

2.2 Installation d’un serveur Windows ................................................................................................................................................................. 19

2.2.2 Préparatifs ...................................................................................................................................................................................................... 20

2.2.3 Lancement du programme d’installation........................................................................................................................................................ 20

2.2.4 Validation de l’installation .............................................................................................................................................................................. 24

2.3 Mise en œuvre de la solution de Backup Visual TOM ..................................................................................................................................... 25

2.3.2 Installation et configuration du serveur primaire ........................................................................................................................................... 25

2.3.3 Installation et configuration du serveur de backup ........................................................................................................................................ 26

2.3.4 Procédure de démarrage des serveurs ........................................................................................................................................................... 26

2.3.5 Procédure d’arrêt des serveurs ...................................................................................................................................................................... 27

2.3.6 Mécanisme de basculement automatique ..................................................................................................................................................... 27

2.3.7 Test d’activité ................................................................................................................................................................................................. 27

2.3.8 :Installation et configuration du serveur de backup en mode réplication uniquement .................................................................................. 29

2.3.9 Mode commande sur le serveur de backup.................................................................................................................................................... 30

3 Module Agent .................................................................................................................................................................................................31

3.1.2 Préparatifs ......................................................................................................................................................................................................31

3.1.3 Transfert de l’archive ......................................................................................................................................................................................31

3.1.4 Le fichier de configuration de l'installation : install_vtom.ini .........................................................................................................................32

3.1.5 Lancement du script d’installation ..................................................................................................................................................................32

3.1.6 Fichier de configuration du profil de l’administrateur du Serveur ..................................................................................................................32

3.1.7 Validation de l’installation ..............................................................................................................................................................................34

3.2 Installation d’un agent Windows ....................................................................................................................................................................37

3.2.2 Préparatifs ......................................................................................................................................................................................................38

3.2.3 Lancement du programme d’installation........................................................................................................................................................38

3.2.4 Validation de l’installation ..............................................................................................................................................................................40

3.3 Installation d’un agent As400 .........................................................................................................................................................................40

3.3.2 Contrôle des ports de communication TCP ....................................................................................................................................................41

3.3.3 Sauvegarde d’une installation ........................................................................................................................................................................41

3.3.4 Désinstallation ................................................................................................................................................................................................42

3.3.5 Transfert de l’archive ......................................................................................................................................................................................43

3.3.6 Installation ......................................................................................................................................................................................................43

3.3.7 Validation de l’installation ..............................................................................................................................................................................45

3.3.8 Démarrage automatique de l’agent................................................................................................................................................................51

3.3.9 Module de réponse automatique ...................................................................................................................................................................52

3.4 Installation d’un agent GCOS7 ........................................................................................................................................................................55

3.4.2 Installation ......................................................................................................................................................................................................55

3.4.3 Validation de l’installation de l’agent .............................................................................................................................................................56

3.5 Installation d’un agent GCOS8 ........................................................................................................................................................................59

3.5.2 Installation ......................................................................................................................................................................................................59

3.5.3 Validation de l’installation ..............................................................................................................................................................................61

3.5.4 Réinstallation ou mise à jour de l’agent..........................................................................................................................................................63

3.6 Installation d’un agent VMS ...........................................................................................................................................................................64

3.6.2 Transfert de l’archive ......................................................................................................................................................................................64

3.6.3 Installation ...................................................................................................................................................................................................... 65

3.6.4 Arrêt et démarrage de l’agent ........................................................................................................................................................................ 67

3.6.5 Validation de l’installation .............................................................................................................................................................................. 67

3.7 Installation d’un agent Z/OS ........................................................................................................................................................................... 70

3.7.2 Contrôle des ports de communication TCP .................................................................................................................................................... 70

3.7.3 Sauvegarde d’une installation ........................................................................................................................................................................ 71

3.7.4 Désinstallation ................................................................................................................................................................................................ 71

3.7.5 Transfert des archives..................................................................................................................................................................................... 71