Dollar Uni

Dollar Universe v5.
Manuel de rfrence
Dollar Universe Solutions pour Windows, Unix et VMS
Version 1.3
24 aot 2005
COPYRIGHT
Copyright ORSYP
Les composants suivants de DOLLAR UNIVERSE sont protgs par Copyright :
le manuel d'installation,
laissez-vous guider,
le manuel d'administration,
le manuel de rfrence,
le manuel interface Motif,
le manuel interface commandes,
le manuel Global Control,
le manuel Business Views,
le manuel Web control,
le manuel DQM,
tous les textes et titres des entres et crans du logiciel.
DOLLAR UNIVERSE, UNIVER$E GP et UNIVER$E DQM sont des marques dposes de ORSYP.
Les termes suivants sont la proprit d'ORSYP :
Unit de Gestion ou UG.
Uproc.
IBM, AS/400, OS/400 sont des marques dposes de International Business Machines Corporation.
DEC, VMS et OpenVMS sont des marques dposes de Hewlett Packard Corporation.
Windows NT et Windows 2000 sont des marques dposes de Microsoft Corporation.
PATROL est une marque dpose de BMC software.
SAP Solutions est une marque dpose de SAP.
Java est une marque dpose de Sun Microsystems.
Tomcat est une marque dpose de Apache Software Foundation.
Oracle, Oracle8, PL/SQL, SQL*Plus sont des marques dposes de Oracle Corporation.
Les autres noms peuvent tre des marques de leur propritaire respectifs.
Dollar Universe v5.1 Manuel de rfrence
Table des matires

Introduction
Objectifs fonctionnels ................................................................................................................ 1

Planification et ordonnancement des travaux .............................................................. 2
Gestion des files d'attente de travaux .......................................................................... 2
Contrle de l'exploitation ............................................................................................ 2
Prsentation gnrale ................................................................................................................. 2
La description des travaux........................................................................................... 3
La planification............................................................................................................ 4
Ordonnancement et lancement des travaux ................................................................. 5
Le contrle et la surveillance d'exploitation ................................................................ 5
Statistiques d'excution ............................................................................................... 6
Simulation d'exploitation............................................................................................. 6
La scurit de l'exploitation......................................................................................... 6
Exploitation rpartie en client-serveur......................................................................... 8
Interfaces avec $U ....................................................................................................... 9
Les concepts d'environnement
11
Introduction ............................................................................................................................. 11
Rle des concepts d'environnement........................................................................... 11
Prsentation ............................................................................................................... 11
Les socits.............................................................................................................................. 13
Indpendance des socits ......................................................................................... 13
Caractristiques complmentaires des socits ......................................................... 13
Les espaces .............................................................................................................................. 14
Les units de gestion................................................................................................................ 14
Dfinition .................................................................................................................. 14
Types d'units de gestion........................................................................................... 15
Traitement informatique hirarchis.......................................................................... 16
Mise en oeuvre des units de gestion ........................................................................ 17
Les noeuds ............................................................................................................................... 21
Dfinition .................................................................................................................. 21
Administration centrale ou locale.............................................................................. 22
Caractristiques complmentaires du noeud ............................................................. 23
Dclaration de l'environnement applicatif ............................................................................... 24
Les applications et les domaines ............................................................................... 24
Les rpertoires application ou UG............................................................................. 24
Les utilisateurs
27
Dfinitions ............................................................................................................................... 27
Le contrle d'accs................................................................................................................... 27
Le contrle d'accs aux serveurs - les proxies ........................................................... 27
Le contrle d'accs aux donnes et aux fonctions fichier SECURITY................... 29
La personnalisation des interfaces ........................................................................................... 29
Personnalisation de l'interface caractres ..................................................................29

Personnalisation du Global Control...........................................................................31
Les comptes de soumission......................................................................................................31
Dfinition...................................................................................................................31
Utilisation du code auteur..........................................................................................31
Le paramtrage
33
Les ressources ..........................................................................................................................33

Dfinition...................................................................................................................33
Codification ...............................................................................................................34
Les classes d'incompatibilit....................................................................................................35
Rle ...........................................................................................................................35
Utilisation des classes d'incompatibilit ....................................................................35
Les uprocs ................................................................................................................................36
Dfinition...................................................................................................................36
Les procdures ou programmes (DCL, shell, CL, .bat) .............................................37
Les variables ..............................................................................................................40
Priode fonctionnelle et date de traitement................................................................41
Mmorisation des vnements...................................................................................43
Successeurs................................................................................................................44
Les conditions d'excution.......................................................................................................44
Caractristiques gnrales des conditions..................................................................45
Caractristiques complmentaires .............................................................................48
Les diffrents types de conditions .............................................................................49
Formule de lancement ou rseau de conditions .........................................................53
Consignes de terminaison ..........................................................................................54
Les sessions..............................................................................................................................55
Dfinition...................................................................................................................55
Chemins "normal" et "erreur"....................................................................................56
Environnement d'excution .......................................................................................57
Reconduction de la valeur des variables dune uproc................................................57
Limites de stockage ...................................................................................................58
La planification
59
Les calendriers .........................................................................................................................59

Environnement d'application du calendrier ...............................................................59
Modle de calendrier .................................................................................................60
Gnration des jours fris ........................................................................................60
Etendue du calendrier ................................................................................................60
Type des jours............................................................................................................61
Impact des modifications d'un calendrier ..................................................................61
Les rgles de planification .......................................................................................................61
Dfinition...................................................................................................................61
Exemples ...................................................................................................................62
Les tches d'exploitation ..........................................................................................................63
Dfinition...................................................................................................................63
Modle de tche.........................................................................................................64
Diffrents types de tches..........................................................................................64
Caractristiques techniques communes .....................................................................65
Planification d'une tche............................................................................................67
Mise en production
73
Manipulation............................................................................................................................73
Oprations de mise jour ..........................................................................................73
Verrouillage technique des objets.............................................................................. 73

Gestion des versions ................................................................................................................ 74
Uprocs ....................................................................................................................... 74
Sessions ..................................................................................................................... 74
Changement d'environnement.................................................................................................. 74
Transfert vers un espace ............................................................................................ 74
Distribution vers des units de gestion ...................................................................... 75
Extraction / insertion de donnes............................................................................... 77
Verrouillage fonctionnel des objets........................................................................... 77
Historique des distributions ....................................................................................... 77
Simulation de planification...................................................................................................... 78
Objectifs .................................................................................................................... 78
Manipulation du planning prvisionnel ..................................................................... 78
Ordonnancement
81
Le rle du moteur batch ........................................................................................................... 81

Le processus d'automatisation ................................................................................... 81
Les composants du moteur batch............................................................................... 82
Implantation du moteur batch.................................................................................... 82
Soumission au travers du rseau................................................................................ 82
Etapes d'excution d'une tche .................................................................................. 82
La planification des travaux..................................................................................................... 83
Le fonctionnement du calculateur ............................................................................. 83
Impact des modifications d'une tche........................................................................ 84
Activation - dsactivation d'une tche ....................................................................... 84
Ordonnancement - lancement des travaux ............................................................................... 85
Le lanceur .................................................................................................................. 85
Le lancement ............................................................................................................. 86
Oprations sur les lancements ................................................................................... 87
La base des vnements............................................................................................. 88
Pilotage des lancements............................................................................................. 89
Soumission de l'uproc................................................................................................ 93
Terminaison des travaux............................................................................................ 93
Communication inter machines ............................................................................................... 94
Rle de l'changeur ................................................................................................... 94
Principes de fonctionnement ..................................................................................... 94
Interruptions de service............................................................................................................ 95
Suivi de l'exploitation
97
Suivi des excutions ................................................................................................................ 97

Objectifs .................................................................................................................... 97
Contrle centralis..................................................................................................... 97
Etats des travaux........................................................................................................ 98
Diagnostics de l'exploitation...................................................................................... 98
Interventions sur les excutions................................................................................. 99
Historiques et statistiques ...................................................................................................... 101
Historique des excutions........................................................................................ 102
Statistiques .............................................................................................................. 102
Oprations de purge............................................................................................................... 103
Base des vnements ............................................................................................... 103
Suivi des excutions ................................................................................................ 103
Historiques............................................................................................................... 103
Fichiers log .............................................................................................................. 104
Release notes
105
Release notes Dollar Universe v5.0 SPRE0025.....................................................................105

Utilisateurs...............................................................................................................105
Paramtrage .............................................................................................................105
Mise en production ..................................................................................................105
Ordonnancement......................................................................................................105
Suivi de l'exploitation ..............................................................................................106
Release notes Dollar Universe v5.1 .......................................................................................106
Glossaire
107
Index
111
Introduction
Objectifs fonctionnels
Les principaux objectifs de Dollar Universe sont : la diminution des contraintes pesant sur l'organisation
technique charge de la gestion de l'exploitation informatique et la recherche d'une fiabilit optimale du cycle
d'exploitation. Pour atteindre ces objectifs, Dollar Universe propose :
des fonctions couvrant l'essentiel du processus central d'exploitation, au travers desquelles il permet
d'assurer, tout moment, une surveillance prcise, et un contrle global de la cohrence de l'exploitation,
une automatisation de l'ensemble de l'exploitation batch supprimant les contraintes de prsence humaine
pour l'excution quotidienne du cycle d'exploitation et permettant de grer automatiquement des
squences de traitement de reprise quand des incidents sont constats,
une structuration de l'environnement applicatif adaptable aux normes et standards de chaque site,
des fonctions apportant aux processus d'exploitation une stabilit et une flexibilit accrues face aux
volutions des configurations physiques et de l'environnement applicatif. Les possibilits offertes par
Dollar Universe permettent ainsi de limiter le nombre et l'importance des oprations de maintenance
ncessaires, accroissant ainsi la qualit rsultante des processus d'exploitation.
La figure, ci-dessous, dcrit chronologiquement les principales tapes du cycle de vie d'une application
informatique.
Gestion des
procdures
Documentation
du paramtrage
Mise en
exploitation
Interfaces
Planification
batch
Soumission
batch
Managers
Contrle de
l'exploitation
Documentation
de l'exploitation
Supervision
Etapes de vie d'une application informatique
Introduction 1
Dollar Universe propose un ensemble de fonctions permettant de grer chacun des thmes voqus dans la
figure ci-dessus. Les managers, les fonctions de documentation, de supervision et de gestion des produits
constituent des modules indpendants du module d'automatisation, objet de cette documentation.
Les interfaces (Motif, Windows, commandes) sont dcrites dans des manuels spcifiques.
Planification et ordonnancement des travaux

La planification des procdures batch repose sur des calendriers, un par entit logique gre, gnrs de faon
semi-automatique.
La planification peut tre effectue procdure par procdure, ou au contraire dfinie pour un ensemble de
procdures. Dollar Universe permet de dfinir des modles d'enchanement de procdures appeles sessions.
Au del des avantages spcifiques que prsentent les sessions, elles permettent de n'exprimer qu'une seule
planification pour un ensemble de procdures.
Les dates d'excution peuvent tre exprimes en prcisant les dates et heures d'excution souhaites
(planification explicite) ou en dfinissant des algorithmes dont seront dduites automatiquement les dates
recherches (planification implicite).
Afin d'viter une ventuelle redfinition de ces algorithmes, ils peuvent tre stocks dans des "rgles de
planification" gres individuellement par Dollar Universe.
Enfin, afin de permettre la prise en compte des exceptions l'application des algorithmes, sans que celles ci en
affectent leur dfinition, des dates d'exception peuvent tre dfinies. Chacune de ces dates permettra
d'invalider une date calcule par application d'une rgle ou d'en forcer une autre.
Gestion des files d'attente de travaux

Dollar Universe s'appuie, dans la mesure du possible, sur les capacits des systmes d'exploitation grer les
files d'attente de travaux.
Sous UNIX ou Windows, o cette fonction n'est pas propose par le systme, cette gestion peut tre effectue
par un produit additionnel de Dollar Universe : DQM (Distributed Queue Management).
Le rle de celui-ci est de permettre une organisation technique de la production, au del de l'organisation
fonctionnelle permise par Dollar Universe, tout en dissociant la prise en charge de ces diffrentes contraintes.
Contrle de l'exploitation
Dollar Universe propose un ensemble de fonctions qui permettent de suivre et d'intervenir dynamiquement sur
le processus d'exploitation.
Conu autour d'un cran de visualisation de l'exploitation en cours, le contrle d'exploitation constitue lui
seul un vrai poste de travail permettant un contrleur d'exploitation d'excuter l'ensemble des tches qui lui
incombent sans jamais perdre de vue le droulement de l'ensemble des vnements d'exploitation.
Prsentation gnrale
Dollar Universe est conu pour apporter une rponse globale d'automatisation aux exploitants quelle que soit
la forme de leur exploitation.
A ce titre, Dollar Universe distingue deux notions essentielles :
La socit,
L'unit de gestion.
2 Introduction
La notion de socit permet, sur un mme environnement informatique, partir d'une seule installation de
Dollar Universe, de grer indpendamment l'exploitation de plusieurs socits distinctes.
Dollar Universe assure, via ses fonctions de contrle d'accs et la conception de son architecture technique,
une dissociation parfaitement tanche de leur exploitation.
Au sein d'une socit, Dollar Universe permet de dfinir plusieurs environnements permettant d'excuter
paralllement plusieurs exploitations disjointes, comme pourraient le ncessiter plusieurs entits d'une mme
socit utilisant les mmes applications sur des donnes diffrentes. Ces environnements sont appels units
de gestion.
Dollar Universe peut grer plusieurs milliers d'units de gestion.
La description des travaux

Description lmentaire d'un travail
Elle porte essentiellement sur l'identification de la procdure (DCL, CL, shell), la dfinition de ses
caractristiques techniques et des conditions requises pour son excution.
Dollar Universe distingue trois types principaux de conditions :
des conditions d'enchanement, traduisant la dpendance d'un travail par rapport un autre,
des conditions de non simultanit de travaux entre eux,
des conditions de disponibilit de ressources.
Pour chacune de ces conditions, Dollar Universe permet de leur associer des critres tels que :
un compte utilisateur de soumission,
une date fonctionnelle (date pour laquelle est excut un travail),
un tat du traitement attendu,
une unit de gestion ou un groupe d'units de gestion d'excution.
Ces conditions (jusqu' 99 pour une mme procdure) peuvent tre assembles dans une expression Boolenne
associant les contraintes avec des oprateurs logiques : ET, OU, =, PAS =, ( et ).
La syntaxe libre de cette expression et les larges possibilits de paramtrage offertes permettent de transcrire
fidlement la logique fonctionnelle rgissant l'excution des divers travaux. Elle permet de mettre en oeuvre,
simplement, le traitement d'excutions normales (enchanement suite l'excution normale d'un traitement) et
des situations d'incidents (chemins dgrads ou reprise).
La procdure associe ses conditions d'excution est appele "uproc".
Description d'une chane de travaux

De faon plus macroscopique, Dollar Universe gre, pour des procdures prsentant des contraintes
d'exploitation homognes (mmes conditions de planification par exemple), une notion de chane de
procdures, appele session.
La session permet d'ordonner de manire arborescente des travaux en distinguant pour chaque travail, le ou les
travaux qui le suivent, en cas d'excution normale et en cas d'excution anormale. Les enchanements ainsi
dfinis au sein d'une session ne se substituent pas aux conditions d'enchanement dfinies au niveau de chaque
travail mais les compltent.
Il est ainsi possible de dfinir au niveau de chaque travail (voir paragraphe "Description lmentaire d'un
travail" page 3) les conditions fonctionnelles qui lui sont associes et, via la session, de leur superposer l'ordre
d'enchanement des travaux souhaits pour leur exploitation. Ceci permet d'intgrer des impratifs
d'exploitation (contrainte horaire, optimisation de la consommation de ressource) sans altrer l'expression des
conditions fonctionnelles.
Introduction 3
L'ensemble des possibilits offertes par Dollar Universe, pour dcrire les travaux :
facilite la maintenance des processus d'exploitation,
encourage et simplifie la mise en oeuvre de traitements dgrads ou de reprise, en cas d'incident.
Elles contribuent ainsi la qualit de l'exploitation et facilitent ses volutions.
La planification
La planification s'applique indiffremment des travaux isols ou des sessions.
Elle s'appuie sur la dfinition prliminaire des objets suivants :
des rfrentiels de temps constitus de calendriers civils,
un ensemble de priodicits d'excution nommes rgles de planification, prdfinies ou dfinissables en

fonction de chaque besoin.
Les calendriers
Dollar Universe permet de dfinir un calendrier par unit de gestion.
Il propose des fonctions permettant de gnrer automatiquement des calendriers :
sur une priode maximale de 25 ans,
avec positionnement automatique de jours chms paramtrable (option),
avec positionnement automatique des jours fris franais (option).
Au del de cette gnration, le type (ouvr, chm, fri) d'un jour quelconque d'un calendrier reste
modifiable.
La charge de travail lie la dfinition ou la maintenance des calendriers est quasiment nulle.
Les rgles de planification

En standard, Dollar Universe propose les rgles de planification les plus frquemment usites.
Il demeure possible de dfinir des rgles de planification spcifiques pour rpondre des cas prcis.
Une rgle de planification, c'est :
un cycle de base, savoir un nombre quelconque de jours, semaines ou mois,
un nombre de jours depuis le dbut ou avant la fin du cycle de base,
la liste des jours de la semaine autoriss pour l'excution,
un sens de report de la date d'excution permettant, dans le cas o le jour obtenu par application de la
rgle au calendrier n'est pas un jour d'activit, de dcaler cette date au premier jour d'activit prcdent ou
suivant la date obtenue.
Une rgle de planification peut ainsi traduire des frquences d'excution du type :
tous les jours ouvrs,
tous les premiers mardis ouvrs du mois,
tous les 87 jours...
La planification des travaux

Dollar Universe propose principalement deux mthodes de planification, d'utilisation ventuellement
conjointe, permettant de prendre en compte des excutions rcurrentes et/ou alatoires :
4 Introduction
La planification implicite consiste, aprs analyse du cycle d'excution du travail concern :
associer de une sept rgles de planification pour obtenir la planification finale souhaite,
dfinir les heures d'excution du travail (un horaire par type de jour dans la semaine ou jusqu' 1500
lancements par jour), ainsi qu'un intervalle de temps d'attente pour que les conditions soient satisfaites.
Au terme de cet intervalle, l'excution sera abandonne ou force (option),
dfinir d'ventuelles interdictions d'excution (jusqu' 52 dates).
La planification explicite consiste numrer une une les dates, horaires et intervalles d'attente des travaux
(jusqu' 26 dates).
Dollar Universe, en matire de planification, apporte une rponse naturelle, progressive la majeure partie des
cas envisageables. En proposant conjointement, une gnration automatique des calendriers, la possibilit
d'adapter les priodicits de soumission habituelles, de traiter par des dates d'exception ou des dates explicites
les cas alatoires, Dollar Universe limite les oprations de maintenance du planning d'exploitation tout en
prservant la capacit d'intervention des exploitants.
Ordonnancement et lancement des travaux

Dollar Universe excute un ordonnancement et un lancement dynamique de chacun des travaux, bass sur des
processus acycliques ragissant en fonction des vnements qu'ils constatent en temps rel (heure, fin ou dbut
d'un travail, changement d'tat d'une ressource, mise jour des paramtres d'exploitation, ...).
Dollar Universe n'utilise aucun planning prdfini, mais interprte, en fonction des vnements d'exploitation
qui surviennent et des interventions ventuelles des exploitants, l'ensemble des informations descriptives des
travaux et les lments de planification qui leur sont associs.
Cette interactivit totale de Dollar Universe lui confre :
de trs hautes performances (consommation de ressources minimale du fait de l'absence de processus

cycliques, soumission "juste temps" des travaux, ...),
une souplesse et une ractivit exceptionnelle,
un rel confort d'utilisation, la capacit d'intervention des exploitants tant respecte en temps rel.
Le contrle et la surveillance d'exploitation

Dollar Universe accorde une place particulirement importante au contrle et la surveillance d'exploitation,
aux seules fins de faciliter le suivi de l'exploitation, d'acclrer l'identification des incidents, leur diagnostic et
les processus de reprise correspondants. Une fonction spcifique leur est ddie.
Organise autour d'un cran de suivi, elle permet de visualiser dynamiquement (alarme sonore,
rafrachissement automatique de l'cran) tout ou partie des travaux excuts ou en cours d'excution. Associe
des critres de slection fins, la fonction de suivi permet de focaliser l'attention des exploitants concerns sur
les travaux stratgiques.
A partir de cette fonction, toutes les informations essentielles sont directement accessibles :
le compte rendu d'excution mis en forme par Dollar Universe, consignant les tapes franchies par le
travail et, ventuellement, pour les travaux en attente de lancement, les vnements attendus. Ce compte
rendu d'excution peut accueillir des commentaires ou consignes d'exploitation transmis depuis
l'interprteur de commande via une commande spcifique de Dollar Universe,
le log d'excution du travail,
les prochains travaux soumettre, ...
ainsi que les principales fonctions permettant d'intervenir sur le droulement du processus d'exploitation :
les reprises sur incident,
Introduction 5
le lancement interactif d'un travail non planifi,
la mise jour d'un vnement d'exploitation.
La fonction de contrle concentre en un seul point tous les lments permettant l'exploitant d'intervenir de
manire circonstancie sur un processus d'exploitation en cours.
Statistiques d'excution
Dollar Universe mmorise pour chaque excution des travaux, la consommation des ressources essentielles
(CPU, I/O directes et bufferises, mmoire, temps elapsed, ...) sur les cent dernires excutions et en calcule
les valeurs mdianes.
L'ensemble de ces informations peuvent tre visualises, interactivement, sous forme graphique.
Pour effectuer des simulations de temps d'excution prcises, elles peuvent tre mises jour (limination de
"points aberrants", cration de valeur estime pour de nouveaux travaux jamais excuts).
Simulation d'exploitation
Dollar Universe propose plusieurs fonctions de simulation :
la simulation de planification d'un travail,
la simulation d'un planning prvisionnel.
La simulation de planification
La fonction interactive de planification des tches permet de simuler une tche donne, en utilisant le
calendrier de rfrence sur une priode quelconque paramtrable
La simulation d'un planning prvisionnel

A partir de l'ensemble des informations dfinies, Dollar Universe peut mettre en forme, sur une dure et
partir d'une date quelconques (ventuellement dans le pass), le planning d'exploitation.
La scurit de l'exploitation
La scurit de l'exploitation est une des lignes de conduite majeure de Dollar Universe.
Elle se dcline en trois thmes :
la scurit par la gestion des mises en exploitation du paramtrage des travaux,
la scurit par le contrle d'accs aux fonctions de Dollar Universe,
la scurit par l'architecture technique de Dollar Universe.
La gestion des mises en exploitation

Dollar Universe gre pour chaque socit quatre espaces permettant, sans accroissement significatif de la
charge de travail, une mise au point progressive des processus d'exploitation.
Ces espaces peuvent tre ddis, en fonction des besoins, la recette des applications, la formation des
utilisateurs, aux tests d'intgration, la simulation d'exploitation et l'exploitation elle-mme.
Toutes les fonctions de Dollar Universe sont dotes d'une fonction permettant interactivement, au sein mme
de la fonction de passer d'un espace un autre.
Un mme travail peut disposer dans chacun de ces espaces d'un paramtrage diffrent correspondant
chacune des tapes de son volution fonctionnelle ou technique. Dollar Universe propose en standard des
6 Introduction
fonctions interactives permettant aprs mise au point du paramtrage dans un espace donn de le transfrer
vers un autre espace (transfert de l'espace de test vers l'espace de simulation par exemple).
A chaque fois que les fonctions interactives de transfert sont utilises, les oprations effectues font l'objet
d'une journalisation mmorisant notamment :
le travail concern,
l'oprateur,
les espaces source et cible,
les dates et heures d'excution de l'opration.
Les bases de donnes ainsi constitues sont interrogeables interactivement. Elles permettent par des requtes
circonstancies (utilisation de multiples critres de slection tels que : date, travail concern, oprateur, ...), de
reconstituer posteriori le scnario d'volution du paramtrage prsent dans l'espace d'exploitation, par
exemple.
Ces fonctions facilitent ainsi l'analyse de disparits entre un paramtrage attendu et le paramtrage
oprationnel.
Le contrle d'accs
Chaque utilisateur doit, pralablement toute connexion, tre identifi par Dollar Universe. Cette
identification permet notamment de lui attribuer un profil utilisateur.
Pour chaque profil utilisateur, il est possible de personnaliser les droits d'utilisation des interfaces de Dollar
Universe.
Pour l'interface caractres : il est possible d'autoriser ou non l'usage de chaque fonction et au sein de
chaque fonction, l'usage de chacune des options ou touches fonction disponibles. La dfinition des menus
complte cette fonctionnalit.
Pour les interfaces Motif, Windows et Commandes, la dfinition des actions autorises ou interdites est
ralise par l'intermdiaire du fichier SECURITY (cf. manuel d'administration).
Pour l'interface Windows : il est possible de dfinir un bureau standard pour chaque profil complt d'un
bureau utilisateur spcifique (cf. manuel de Global Control).
Ce contrle d'accs coupl aux fonctions de dfinition des proxies (autorisation de connexion donne par un
serveur des clients) permettent d'adapter prcisment l'ergonomie et l'tendue de l'usage de Dollar Universe
en fonction des besoins de chacun.
L'architecture de Dollar Universe

Plusieurs facettes de l'architecture de Dollar Universe contribuent la scurit de fonctionnement de
l'exploitation.
Le contenu de chaque change utilisateur / Dollar Universe est mmoris. Ainsi, quelles que soient les
circonstances d'utilisation (arrt machine inopin par exemple), lors de sa prochaine connexion Dollar
Universe, l'utilisateur reprendra son dialogue l'endroit prcis o il l'avait abandonn. Ces dispositions sont
prises afin que toute tche entreprise sur le paramtrage d'exploitation trouve, en toutes circonstances, une fin
normale.
Dans des circonstances identiques (arrt machine inopin) les processus de base sont conus pour ne jamais
perdre (tant que le systme d'exploitation ne la perd pas lui-mme) la trace des travaux en cours.
Enfin, par souci de ne pas altrer les performances de chacun des espaces, du fait d'une surcharge d'un autre
par exemple, les processus de base de Dollar Universe sont disjoints pour chacun des espaces actifs.
La conception et la nature des fonctions de Dollar Universe concourent faciliter une gestion mthodique de
l'exploitation au sein d'environnements strictement dlimits. Les possibilits de personnalisation offertes
permettent de proposer chacun un outil prcisment adapt ses missions.
Introduction 7
Tous ces lments, conjointement une architecture technique rigoureuse et structure, donnent au processus
d'exploitation, dans son ensemble, une plus grande clart et contribuent renforcer la matrise que les
exploitants en ont.
Exploitation rpartie en client-serveur

En utilisant les protocoles standards, tels que DECNET et TCP/IP, Dollar Universe assure sa communication
client - serveur entre les diffrents modules Dollar Universe d'un rseau.
Dollar Universe permet ainsi, l'automatisation de squences de travaux sur plusieurs machines, le contrle et
le pilotage depuis un point central, la fiabilisation et l'optimisation des processus d'exploitation multi - sites.
Caractristiques en exploitation rpartie

L'unit de gestion est le concept majeur de la gestion d'exploitations rparties.
Une unit de gestion peut rsider sur un noeud quelconque d'un rseau, dont l'identifiant fait partie des
informations descriptives de l'unit de gestion.
De plus, Dollar Universe gre pour les units de gestion :
un type d'unit de gestion (usine, dpt, agence commerciale, units de gestion franaises, par exemple)
diffrenciant chacune des units de gestion par son critre essentiel vis vis du processus d'exploitation,
des relations de dpendances entre units de gestion.
Dans ce cadre, chacune des fonctions de Dollar Universe faisant rfrence la notion d'unit de gestion
(expression des conditions dans la description des travaux, dfinition des travaux dpendants d'un travail dans
une session, ...) sait interprter des expressions du type :
les units de gestion de type X,
les units de gestion qui dpendent de l'unit de gestion courante,
les units de gestion de type X dpendant de l'unit de gestion courante,
Ainsi chacune des fonctions concernes de Dollar Universe peut tre paramtre par rapport l'organisation
logique de l'exploitation informatique. Dollar Universe prend en charge, au moment de l'excution, la
transposition entre les rfrences logiques utilises et la ralit physique du rseau, par rapport la description
des units de gestion.
Dollar Universe permet de dcrire de ce fait des processus flexibles aux volutions de configurations.
En imaginant un processus d'exploitation consistant soumettre un travail sur toutes les machines des agences
commerciales d'une socit, la majeure partie des volutions pourront tre excutes sans modifier le
paramtrage d'exploitation. Par exemple :
ajout d'une nouvelle agence commerciale : cration d'une nouvelle unit de gestion de type agence
commerciale. La session au sein de laquelle est excute la soumission est inchange (travail A soumet
travail B sur toutes les agences commerciales),
concentration de deux agences commerciales sur une mme machine : mise jour du noeud pour l'unit
de gestion concerne, la session reste inchange.
Les informations descriptives des units de gestion sont mmorises dans une base de donnes pour laquelle
Dollar Universe fournit les outils ncessaires sa tldistribution sur l'ensemble des noeuds concerns.
La gestion cooprative d'exploitation rpartie

L'expression des conditions dans la description des travaux peut utiliser les expressions logiques portant sur
les units de gestion.
Dans ce contexte, il devient possible d'exprimer une synchronisation de travaux s'excutant sur des units de
gestion rsidant sur des noeuds diffrents :
8 Introduction
"Le travail A ne s'excute pour l'unit de gestion X que si le travail B est correctement excut sur les units
de gestion de type Z".
Dans ce cas, sans qu'il soit ncessaire de grer au sein de l'applicatif l'envoi de pseudo-fichiers, Dollar
Universe met en oeuvre une vritable gestion cooprative multi-machines. Il met des requtes destination
des noeuds de rsidence des units de gestion du type concern pour dterminer si la condition est bien
satisfaite. Ds que l'vnement attendu surviendra, la machine mettrice sera automatiquement informe.
Ces fonctions sont gestion vnementielle (la requte n'est pas mise cycliquement). Elles sont gres dans
une fonction spcifique de communication assurant elle-mme, y compris en cas de rupture temporaire du
rseau, la scurit des missions et de la rception de requtes.
La gestion centralise d'exploitation

Afin de limiter la charge du rseau et de ne traiter que les informations strictement utiles au suivi de
l'exploitation, chacun des travaux est dot d'un indicateur mentionnant s'il peut faire ou non l'objet d'un
contrle centralis.
Le suivi de l'exploitation des travaux stratgiques des units de gestion concernes sera report sur le noeud
dfini comme noeud de contrle centralis. Les fonctions de contrle d'exploitation permettront ainsi de
visualiser dynamiquement, non seulement les travaux des units de gestion locales, mais aussi, les travaux
essentiels des units de gestion contrle centralis.
La gestion centralise des exploitations rparties peut tre tendue la dfinition du paramtrage
d'exploitation des sites distants.
Dollar Universe propose, dans cet objectif, une notion de modle de paramtrage. Un modle est un
paramtrage inoprant, il devient oprationnel aprs tldistribution vers une unit de gestion cible.
Cette notion de modle permet de grer depuis un seul noeud tous les paramtrages d'un ensemble
d'exploitations rparties.
Il convient galement de noter que toutes les fonctions interactives de Dollar Universe permettent de visualiser
le paramtrage d'un autre noeud sans ncessiter de connexion sur le noeud concern.
La tldistribution du paramtrage
De manire identique aux fonctions de transfert entre espaces, chaque lment du paramtrage d'exploitation
de Dollar Universe peut tre distribu interactivement sur les units de gestion de l'architecture.
Chaque opration de distribution est journalise, constituant ainsi une base historique interrogeable
interactivement.
Les potentialits de Dollar Universe lui permettent de traiter toutes les formes d'exploitation locales, rparties
gestion centralise ou locale. Il apporte, de ce fait, une contribution significative dans des volutions d'un
mode un autre.
La flexibilit et l'indpendance des processus par rapport la ralit physique des configurations confre
l'exploitation une stabilit accrue, gage d'une maintenance rduite et d'une meilleure fiabilit.
Interfaces avec $U
Dollar Universe fournit un ensemble d'interfaces pour accder ses fonctions :
interface graphique (X/MOTIF, Windows),
interface en mode caractre (gestionnaire d'cran UAM dvelopp par ORSYP),
interface sous forme de commandes.
Par ailleurs, Dollar Universe propose de manire standard de nombreuses interfaces avec des fonctions
externes telles que :
Introduction 9
la gestion d'alarmes,
les produits de sauvegardes,
les applications WEB,
les ERP,
...
10 Introduction
Les concepts d'environnement
Introduction
Rle des concepts d'environnement
Les fonctions de dfinition de l'environnement et d'administration gnrale prsentes dans cette partie
permettent la structuration, l'organisation et la prparation de l'automatisation.
Elles jouent ainsi un rle fondamental vis vis des processus d'exploitation dfinis par la suite et intressent
ce titre plus particulirement les personnes en charge de l'administration de Dollar Universe.
Le chapitre "concepts d'environnement", aprs une rapide prsentation de l'architecture gnrale propose,
dcrit chacun des concepts participant cette architecture, en prcisant :
Leur rle vis vis de la structuration de l'environnement et leur mode d'administration,
Leur rle vis vis de l'automatisation de l'exploitation ainsi que les informations de nature fonctionnelle
qui y sont attaches.
Le chapitre "applications" prsente l'administration attache aux applications, prliminaire indispensable

l'automatisation des procdures applicatives.
Il prsente galement l'administration des tables permettant la dclaration de l'environnement applicatif, et
l'utilisation de cette mme dclaration pour les besoins propres de Dollar Universe.
Le chapitre "utilisateurs" prsente les diffrentes notions d'utilisateurs considres au sein de Dollar Universe,
en prcisant :
Leur administration,
La dfinition de leurs droits d'accs aux diffrentes fonctions de Dollar Universe.
Prsentation
Dollar Universe gre plusieurs concepts permettant de mettre en oeuvre une structuration logique de
l'environnement de travail.
On distingue trois principaux niveaux d'organisation des donnes:
Les socits,
Les espaces,
Les units de gestion (UG).
Les concepts d'environnement 11
La figure suivante met en vidence l'ensemble de ces concepts.

Socit A
Socit B
Espace application
Espace intgration
Espace simulation
Espace exploitation
UG1
UG2
UG3
Les concepts d'environnement de Dollar Universe
La socit est le concept d'environnement du plus haut niveau. Chaque socit correspond une nouvelle
installation du produit. Peuvent tre installes : une mme socit sur plusieurs noeuds, plusieurs socits sur
un mme noeud.
Les socits sont des environnements tanches d'exploitation qui ne peuvent communiquer qu'au travers de
fonctions d'import / export de paramtrage.
Une socit est dcoupe en quatre espaces : application, intgration, simulation et exploitation.
Les espaces sont galement des environnements tanches d'exploitation mais qui bnficient de fonctions
interactives de transfert de paramtrage (au sein d'une mme socit). Certains espaces acceptent galement la
dfinition de versions d'objets (uproc et session).
Le schma ci-dessous montre les principaux objets grs par Dollar Universe ainsi que leur implantation
logique en fonction des diffrents concepts d'environnement proposs.
SOCIETE
Excutables et utilitaires de configuration

Fichiers d'administration et d'autorisations
Fichiers spcifiques non grs par espace
Univers de dveloppement
Espace
Application
uprocs
data
logs
Espace
Intgration
uprocs
data
logs
Univers de production
Espace
Simulation
uprocs
data
logs
Espace
Exploitation
uprocs
data
logs
Rpartition des Objets par concept d'environnement
Les notions d'espaces ne sont pas gres de faon individualise. Les tables de Dollar Universe ne les
connatront que par la diffrenciation permise dans la dfinition des chemins d'accs aux objets des
applications et aux donnes propres chaque unit de gestion.
Enfin, l'ensemble de cette structuration logique de l'environnement est indpendante de l'organisation
physique des moyens informatiques et, par consquent, se trouve prsente su chaque noeud (machine) du
rseau.
Par ailleurs, l'architecture cooprative de Dollar Universe n'imposant aucune contrainte quant l'organisation
des quipes d'exploitation en charge de l'administration et du suivi de l'exploitation (absence de notions de
matre ou d'esclave), c'est au travers de la notion de ces mmes noeuds que l'organisation propre chaque
contexte pourra tre traduite.
12 Les concepts d'environnement
Les socits
La socit constitue la notion d'environnement de plus haut niveau gre par Dollar Universe. Une socit doit
tre dfinie l'installation de Dollar Universe. Elle constitue, la plupart du temps, la seule socit existante du
systme d'information, mais toutes les autres notions dfinies dans Dollar Universe y font rfrence.
Ce concept permet de mettre en oeuvre un partitionnement strict des donnes. Il assure "l'tanchit" de
plusieurs socits (au sens juridique du terme) sur un systme d'informatique unique.
Indpendance des socits

La mise en oeuvre de socits consiste en la cration d'environnements compltement disjoints.
Les socits disposent d'outils spcifiques (moteur batch par socit, par exemple), faisant l'objet
d'exploitations indpendantes. Dans le cas o une dissociation aussi stricte n'est pas ncessaire, la notion
d'unit de gestion permettra d'excuter des exploitations parallles.
Si plusieurs socits partagent un systme informatique (elles peuvent utiliser les mmes excutables), les
diverses fonctions de Dollar Universe pourront fonctionner paralllement, pour le compte de chacune des
socits, sans qu'il n'y ait jamais interfrence dans leur fonctionnement ni partage des donnes.
Caractristiques complmentaires des socits

Chaque socit autorise la dclaration d'informations d'intrt gnral telles que :
Le type d'diteur utilis
Cette information permet de dfinir (sous VMS), l'diteur utiliser dans l'ensemble des fonctions de
Dollar Universe qui accdent des fichiers du systme d'exploitation (fichiers de commandes et fichiers
log, principalement).
Note : sous Unix, le type d'diteur utilis est dfini dans le fichier d'environnement uxsetenv (cf. manuel
d'administration).
Le verrouillage des objets

Cette information permet de dfinir si, lors d'opration de transfert ou de distribution, les uprocs et
sessions doivent rester modifiables ou non.
Le noeud matre
Cette information permet de dclarer le noeud matre d'une socit.
On se reportera la rubrique "noeuds" du prsent chapitre pour de plus amples informations sur la
signification de la notion de noeud matre et sur les prcautions d'utilisation qui y sont attaches.
Le rpertoire socit
Cette information permet de dclarer l'emplacement physique (nom de rpertoire) des divers fichiers
d'une socit (tables d'administrations, fichiers de rgles de planification, fichiers des autorisations, etc...)
pour le noeud concern.
Note : la dfinition de ce support est double pour autoriser la compatibilit avec les anciennes versions de Dollar
Universe qui reconnaissait l'implantation des fichiers d'une socit par univers (regroupement d'espaces deux par
deux); elle ncessite du coup une mme dclaration dans les deux supports proposs pour une mme socit. Une
mme socit pouvant tre installe diffremment sur chaque noeud, on vitera systmatiquement de distribuer
cette table.
Les espaces
Afin de tester progressivement les applications en dveloppement ou en maintenance, dans des conditions qui
simulent au mieux les conditions de production, Dollar Universe offre quatre environnements de travail
appels espaces. Ils sont nomms :
l'espace d'application,
l'espace d'intgration,
l'espace de simulation,
l'espace d'exploitation.
Les espaces d'application et d'intgration sont ddis l'environnement de dveloppement des processus
d'exploitation. Les espaces de simulation et d'exploitation s'adressent la production informatique elle-mme.
Dollar Universe gre, pour certains espaces, des versions d'uprocs et de sessions (voir paragraphe "Gestion des
versions" page 74 ).
Les mmes fonctions de Dollar Universe sont prsentes dans tous les espaces. Le changement d'espace peut
tre ralis trs simplement par l'utilisateur, les outils de transfert des objets d'un espace l'autre sont
systmatiquement proposs ds que cela est possible.
Les natures d'objets gres au niveau espace sont les suivantes :
Paramtrage : uprocs, sessions, calendriers, tches,
Suivi : lancements, excutions, vnements, historiques,...
Ne sont pas grs par espace, mais au niveau socit :
Administration : toutes les tables,
Paramtrage : rgles, ressources, classes d'incompatibilit.
Les units de gestion

Dfinition
L'unit de gestion dsigne un environnement logique d'excution. Elle est prise en compte dans toutes les
fonctions de Dollar Universe et y joue un rle essentiel.
Une unit de gestion est systmatiquement associe un noeud. Ainsi, l'affectation d'une procdure une
unit de gestion suffit dsigner l'environnement physique dans lequel le job sera excut. La notion de noeud
devient transparente dans l'utilisation quotidienne des fonctions de Dollar Universe, au profit de la notion
d'unit de gestion.
Une configuration rpartie ou centralise est vue, de ce fait, comme une machine unique sur laquelle rside
un ensemble d'units de gestion.
Principaux aspects de l'unit de gestion :
permet, dans un mme environnement physique, la cohabitation d'exploitations parallles d'applications

identiques mais prsentant des contraintes d'exploitation diffrentes (environnements de donnes,
applications),
constitue la notion essentielle de l'informatique distribue. L'UG permet de simuler une architecture
informatique distribue sur une architecture centralise. De ce fait, l'unit de gestion facilite les volutions
d'architecture des solutions informatiques (architecture centralise vers architecture rpartie ou vice versa)
et rend insensible ces volutions les mthodes d'exploitation,
ne peut pas tre dfinie sur plusieurs noeuds. Toutefois, un noeud peut en accueillir plusieurs.
Utilisation
L'exploitation amne grer en permanence deux vues diffrentes de l'organisation informatique de
l'entreprise :
La vue logique qu'en ont les applications,
La vue physique des moyens informatiques qu'impose l'exploitation.
Dollar Universe permet de construire les processus techniques d'exploitation partir des notions logiques que
constituent les units de gestion, repoussant l'interprtation des paramtres logiques en donnes physiques au
moment de l'excution finale des processus informatiques.
Cette interprtation est faite dynamiquement, par rapport aux informations descriptives des units de gestion
contenues dans les tables d'administration de Dollar Universe. Cette flexibilit confre aux processus
d'exploitation une stabilit ingale, et donc, une fiabilit optimale.
L'exemple suivant illustre ces propos. Des chanes de traitements peuvent impliquer plusieurs units de
gestion : par exemple la consolidation de statistiques commerciales issues d'agences commerciales au niveau
d'une direction rgionale.
Si le traitement de consolidation doit soumettre des traitements dans les environnements de chacune des
agences ou copier des fichiers localiss dans chacun des environnements agence concerns, que se passera-t-il
en cas d'volution de l'organisation des agences (monte en charge progressive d'une application, dport des
moyens informatiques d'une agence sur une nouvelle machine, ...) ?
Dans la plupart des cas, les traitements doivent tre modifis pour tenir compte du nouveau contexte.
Toutefois, Dollar Universe permet d'viter des oprations de maintenance rptitives sur les processus
existants. La seule intervention consiste modifier une table d'administration pour crer une nouvelle unit de
gestion ou modifier les caractristiques techniques d'une unit de gestion existante.
Afin d'apporter une rponse complte, Dollar Universe permet de dfinir des relations hirarchiques entre
units de gestion. Ces relations pourront tre tablies, par exemple, entre une direction rgionale et l'ensemble
de ses agences commerciales. Ce type de relation est appel dans Dollar Universe le "traitement informatique
hirarchis" ou TIH.
Units de gestion et espaces

Les units de gestion sont prsentes dans chacun des espaces, moins d'une restriction explicite lors de leur
dfinition (possibilit de les dfinir de manire restrictive pour les espaces de l'environnement de
dveloppement ventuellement).
De cette manire, l'environnement et le paramtrage des processus d'exploitation peuvent rester identiques
depuis leur dveloppement jusqu' leur exploitation.
Types d'units de gestion

Dollar Universe permet de regrouper les units de gestion par type (type "usine", "agence", ...). L'utilisation de
cette classification par type des units de gestion permet d'identifier, par exemple, des agences commerciales
sans les nommer individuellement. Ces possibilits "d'adressage gnrique" d'un ensemble d'units de gestion
peut tre utilis :
pour constituer des ordres de dclenchement au sein de chanes de traitement,
pour dfinir des conditions (enchanement, non simultanit, prsence de fichiers, etc.),
pour mettre en forme des commandes spcifiques de Dollar Universe,
pour distribuer du paramtrage d'exploitation l'attention de ces environnements.
Le type de l'unit de gestion est un lment important de la gestion de l'environnement et l'lment essentiel
sur lequel repose le traitement informatique hirarchis (TIH). Partie intgrante du code de l'unit de gestion,
Il caractrise fonctionnellement l'unit de gestion.
Une unit de gestion est caractrise par un code constitu de la manire suivante :
le premier caractre reprsente le type de l'unit de gestion. C'est ce caractre qui est pris en compte dans
les relations gres dans le TIH,
les autres caractres constituent un identifiant complmentaire.
Dollar Universe n'impose aucune contrainte particulire dans la codification de ces units de gestion. Il
apparat cependant souvent utile de dfinir, sur chaque noeud, une unit de gestion de nature technique
regroupant des fonctions d'intrt gnral.
Note : il pourra tre utile de rserver un type particulier ("N" par exemple) pour dsigner des units de gestion
prsentes en un seul exemplaire sur chaque noeud. La prsence de ces units de gestion et d'un type d'unit de
gestion ddi facilitera la distribution des tables et des autres objets dont une seule occurrence est prsente sur un
noeud donn, quel que soit le nombre d'unit de gestion et d'espaces prsents (par exemple, uprocs ou sessions).
En effet, la dfinition de la cible des units de gestion pour effectuer des distributions pour ce type d'objets se
limitera alors au formalisme "N" (toutes les units de gestion de type "N").
Traitement informatique hirarchis

Dollar Universe permet de dfinir des relations hirarchiques entre units de gestion appeles le "traitement
informatique hirarchis" ou TIH.
Au travers d'un symbolisme propre au TIH, Dollar Universe permet de dcrire des chanes de traitements sans
prjuger du nom et du nombre d'units de gestion concernes. Il garantit ainsi la stabilit du paramtrage de
l'exploitation sous Dollar Universe quelles que soient les volutions de la configuration matrielle utilise
(cration ou regroupement de sites) ou de l'organisation informatique (cration ou suppression d'agences
commerciales par exemple).
Formalisme
Ces expressions gnriques permettent de combiner les informations contenues dans les types d'units de
gestion et dans les dpendances des units de gestion. Des exemples du formalisme associ peuvent tre :
{XY} dsigne "toutes les UG de type 'X' dpendantes des UG de type 'Y' dont dpend l'UG sur laquelle
est formule cette expression",
{X } dsigne "toutes les UG de type 'X' dpendantes de l'UG sur laquelle est formule l'expression",
{ Y} dsigne "toutes les UG de type 'Y' dont dpend l'UG sur laquelle est formule l'expression",
} dsigne "la mme UG" que celle sur laquelle est formule l'expression.
Ces expressions gnriques peuvent tre utilises :
dans l'expression de conditions associes des procdures,
dans l'expression d'ordre de dclenchement au sein d'une chane de traitements.
Elles permettent de corrler l'excution d'une uproc sur une unit de gestion l'excution d'une uproc sur un
sous-ensemble d'units de gestion. L'interprtation de l'expression gnrique est ralise dynamiquement. Les
conditions utilisant ces expressions prennent automatiquement en compte les crations, suppressions ou
modifications d'units de gestion.
Si l'on considre une reprsentation du rseau d'units de gestion telle que figure ci-dessous
La mise en oeuvre des diffrents formalismes est la suivante :
{XY}
Ce formalisme permet " une fille de voir tous ses frres ou cousins" :
A02 "voit" X11 et X12

A01 "voit" X01, X02, X11 et X12
{X }
Ce formalisme permet " un pre de voir tous ses fils (mais pas ses neveux)" :
Y01 "voit" X01 et X02

Y02 "voit" X11 et X12
{ Y}
Ce formalisme permet " une fille de voir son ou ses pres":
X01 "voit" Y01

A02 "voit" Y02
A01 "voit" Y01 et Y02
Note : ces formalismes permettent d'explorer les dpendances dans le sens "descendant" de celles-ci et
uniquement dans ce sens. Ds lors que le besoin s'en fait sentir, il suffit de dfinir des dpendances inverses pour
pouvoir parcourir celles-ci dans le sens "ascendant". D'ailleurs et comme l'illustre le schma ci-dessus, les
dpendances peuvent tre totalement mailles et ne ncessitent aucune hirarchie particulire entre les diverses
units de gestion, mme si c'est trs souvent le cas.
Mise en oeuvre des units de gestion

Afin de faciliter la comprhension de cette reprsentation logique de l'environnement et de dmontrer la
puissance du concept d'unit de gestion, nous donnons ci-dessous quelques exemples d'utilisation possibles.
Les exemples suivants ne sont fournis que pour dmontrer l'tendue des cas d'utilisation possibles du concept
d'unit de gestion. Celui-ci sera systmatiquement utilis ds lors que l'on peut constater une rplication des
traitements.
Application une entreprise industrielle

Supposons qu'une entreprise soit btie autour d'une organisation commerciale constitue de directions
rgionales contrles par une direction centrale et pilotant elles-mmes des usines et des agences
commerciales.
Une dfinition immdiate des units de gestion de cette organisation consiste en crer autant qu'il y a
d'entits direction centrale, directions rgionales, agences et usines.
Chacune des entits de mme nature exploitera, selon toute vraisemblance, des applications informatiques
identiques ou du moins de mme nature. Cette similitude peut tre traduite en attribuant un mme type d'unit
de gestion aux units de gestion correspondantes.
Les units de gestion cres pourront tre les suivantes :
Direction centrale : C01,
Directions rgionales : R01 et R06,
Usines : U07, U16 et U34
Agences : A01, A02, A11, A12 et A13.
Parmi les traitements informatiques, des traitements de consolidation, par exemple, peuvent mettre en
vidence des dpendances fonctionnelles entre ces entits.
La consolidation des informations de production journalire est assure directement par la direction centrale,
tandis que les statistiques commerciales sont agrges dans un premier temps au niveau rgional puis au
niveau central. Le schma suivant traduit un exemple possible de ces dpendances fonctionnelles.
Liens fonctionnels des UG
Ces dpendances fonctionnelles peuvent tre traduites par des relations de dpendance entre les units de
gestion. Les units de gestion sont ainsi organises en une forme de rseau.
En fonction de la disponibilit des moyens matriels informatique, ce rseau peut tre support par plus ou
moins de noeuds tel que figur ci-dessous :
Support du rseau des UG par la configuration physique
Rappelons que l'ensemble des processus tant dcrit partir du rseau d'units de gestion, ceux-ci demeurent
indpendant de la configuration physique.
Exemple 1 : diffusion de l'application "statistiques commerciales" aux

agences ou comment utiliser le type d'UG dans les processus de distribution
L'application statistiques commerciales est dveloppe sur le site de paris. Son automatisation est ralise sur
ce mme site puis diffuse l'attention des agences, principales intresses par cette application. Paralllement
la diffusion de l'application, les procdures dfinies au sein de Dollar Universe seront distribues sur toutes
les units de gestion de type 'A'.
Les agences concernes par cette distribution sont : A01, A02, A11, A12, A13.
Par ce biais gnrique, aucune agence ne sera oublie, et Dollar Universe prendra automatiquement en charge
cette diffusion sur les sites concerns.
Exemple 2: dclenchement des traitements agences sur dcision des rgions

ou comment utiliser le formalisme {x } dans un processus de dclenchement
Suite la diffusion de l'application statistiques commerciales et des procdures automatises au sein de Dollar
Universe, une chane de traitements est construite telle que figure ci-dessous.
Celle-ci utilise le formalisme TIH "{A }" permettant de dclencher le traitement "statistiques" sur toutes les
agences dpendantes de la rgion concerne. Par ce biais hirarchique, et suivant que le "top_utilisateur" sera
activ sur une rgion ou une autre, le dclenchement du traitement "statistiques" s'effectuera bien sur les
agences dpendantes de la rgion concerne.
Par exemple, si le traitement top_utilisateur est activ sur la rgion R01, le traitement statistiques sera
dclench sur les agences A01, A02, A11.
La chane de traitements ainsi constitue demeure indpendante de la rgion d'excution, du nombre d'agences
et de leur rattachement telle ou telle rgion.
Exemple 3 : synchronisation des traitements statistiques avec la constitution

du stock ou comment utiliser le formalisme {XY} dans un processus de
synchronisation
Le traitement statistiques voqu ci-dessus ne peut en fait s'excuter que si la valorisation des stocks a t
effectue au sein de chacune des usines de la rgion laquelle est rattache l'agence concerne. Il porte ainsi
sous Dollar Universe une condition d'enchanement traduisant cette synchronisation.
Celle-ci utilise le formalisme TIH "{UR}" permettant au traitement "statistiques" d'attendre que le traitement
stocks se soit bien droul sur l'ensemble des usines dpendantes de la rgion laquelle l'agence concerne est
rattache.
Par exemple, pour que le traitement statistiques s'excute sur l'agence A02, il est ncessaire que le traitement
stocks se soit bien droul pour les usines U07 et U16. Il en va bien sur de mme pour les agences A01 et
A11.
La synchronisation de traitements ainsi constitue demeure indpendante de la rgion d'excution, du nombre
d'usines et de leur rattachement telle ou telle rgion.
Exemple 4 : synchronisation des traitements statistiques avec les stocks

logiques ou comment utiliser le formalisme { y} dans un processus de
synchronisation
Le traitement statistiques voqu ci-dessus ne peut galement s'excuter que si chaque agence d'une mme
rgion a rendu disponible l'ensemble des prises de commandes non livres, celles-ci influant bien videmment
sur les stocks rellement disponibles.
Il porte ainsi sous Dollar Universe une condition d'enchanement traduisant cette synchronisation.
Celle-ci utilise le formalisme TIH "{AR}" permettant au traitement "statistiques" d'attendre que le traitement
commandes se soit bien droul sur l'ensemble des agences rattaches la rgion courante.
Par exemple, pour que le traitement statistiques s'excute sur l'agence A02, il est ncessaire que le traitement
commandes se soit bien droul pour les agences A01, A02 et A11. Il en va bien sur de mme pour les
agences A01 et A11.
La synchronisation de traitements ainsi constitue demeure indpendante de la rgion d'excution, du nombre
d'agences.
Exemple 5 : synchronisation des traitements statistiques avec la tarification

ou comment renverser les dpendances d'UG dans un processus de
synchronisation
Le traitement statistiques voqu ci-dessus ne peut enfin s'excuter que si la tarification des produits est
rendue disponible par la direction centrale chaque rgion (sachant que cette tarification est ventuellement
diffrente pour chaque rgion).
Il porte ainsi sous Dollar Universe une condition d'enchanement ncessitant que le traitement tarifs, de
rcupration des fichiers tarifs gnrs sur le site central, se soit bien termin pour la rgion laquelle l'agence
concerne est rattache.
Celle-ci utilise le formalisme TIH "{ R}" permettant au traitement "statistiques" d'attendre que le traitement
stocks se soit bien droul sur la rgion laquelle l'agence concerne est rattache.
Ce formalisme ncessite du mme coup la dfinition d'une dpendance, inverse par rapport aux dpendances
prcdemment dfinies, entre chaque agence et sa rgion de rattachement, tel que figur dans le schma cidessous (flches "montantes") :
Ainsi, par exemple, pour que le traitement statistiques s'excute sur l'agence A02, il est ncessaire que le
traitement tarifs se soit bien droul pour la rgion R01.
La synchronisation de traitements ainsi constitue demeure indpendante de la rgion d'excution.
Application de gnration de documentation

Cet exemple considre une application batch charge de gnrer une documentation multilingue pour
diffrents types de matriels de haute technologie.
Cette application regroupe un ensemble de travaux paramtrs en fonction du type de matriel concern et en
fonction de la langue dans laquelle la documentation doit tre gnre.
Une mme chane de traitements s'excutera ainsi pour un ensemble d'units de gestion directement issues de
la combinaison type de matriel - langue.
Cette disposition permet de restreindre au maximum le nombre de traitements dfinir dans Dollar Universe,
les units de gestion s'y substituant (un mme traitement s'excutera par contre autant de fois que d'units de
gestion); l'interprtation de la signification de l'unit de gestion est ralise au moment de l'excution du
traitement, celui-ci n'ayant plus qu' traduire le code de l'unit de gestion en type de matriel et en code
langue.
Dans le cas o des traitements seraient communs toutes les langues par exemple, une hirarchie pourrait tre
introduites entre les diffrentes units de gestion dfinies pour traduire le besoin de synchronisation des divers
traitements concerns.
Application de traitements de vacations

Cet exemple considre une application batch charge de rceptionner un nombre trs important de fichiers en
provenance de divers clients (des commandes issues de vente par correspondance, par exemple).
Cette application ncessite une optimisation technique particulire des ressources disques consommes. En
effet, compte tenu du grand nombre de fichiers reus chaque jour, on souhaite rpartir ceux-ci sur chaque
disque de la machine rceptrice afin d'quilibrer les entres sorties sur chacun d'eux lors du traitement de ces
fichiers.
Lors de la prise en charge de ces fichiers par l'application celle-ci va effectuer un mme traitement autant de
fois qu'il y a de disques.
On utilisera ainsi les units de gestion pour dclarer chacun de ces disques et faire excuter les traitements
autant de fois qu'il y a d'units de gestion du type disques.
Traitement / {D }
Disque
1
Disque
2
Disque
3
Disque
4
Utilisation des UG pour reprsenter des objets techniques
Outre la rduction du nombre d'objets dfinir au sein de Dollar Universe, cette reprsentation prsente
l'avantage de n'imposer aucune intervention particulire sur le paramtrage d'exploitation ds lors que l'on
souhaitera ajouter un disque la configuration en regard du nombre croissant de fichiers reus (en dehors de la
dclaration du nouveau disque en tant qu'unit de gestion).
Les noeuds
Dfinition
Dollar Universe propose une architecture d'automatisation d'exploitation rpartie. A ce titre, il prend donc en
compte les architectures cluster et rseau.
Le noeud au sens de Dollar Universe a la mme signification que le sens informatique dsignant une machine
sur un rseau.
Tel que prcis prcdemment, la notion de noeud est en fait occulte (dans le paramtrage de Dollar
Universe) au profit de l'unit de gestion pour permettre une meilleure flexibilit des processus d'exploitation
constitus.
Le noeud n'intervient donc que lors de l'excution relle d'un traitement sur une machine.
Par ailleurs, Dollar Universe propose pour ses versions oprant avec TCP/IP, la possibilit de dsigner les
noeuds de manire logique, un fichier fournissant la correspondance entre la notion de noeud fourni par Dollar
Universe et le nom de la machine physique telle que reconnue par TCP/IP (cf. Manuel d'administration).
Administration centrale ou locale

Noeud matre
Mme si Dollar Universe bnficie d'une architecture cooprative et autorise du mme coup une
administration centrale ou locale, il permet de restreindre la gestion de ses tables d'administration en un point
focal grce la notion de noeud matre.
Cette disposition est bien souvent souhaitable en regard de l'importance des informations que contiennent ces
tables d'administration (description de l'environnement tant physique que logique).
Chaque noeud reconnat ainsi un noeud matre, qui lors de l'installation de la socit est dfini comme tant le
noeud lui-mme, ce qui l'autorise modifier ses propres tables d'administration.
La dclaration, dans la table des socits, d'un noeud matre diffrent du noeud courant entrane l'impossibilit
de mettre jour localement les tables d'administration. Celles-ci ne pourront plus tre mises jour qu' partir
d'un autre noeud par une distribution de celle-ci.
Note : la notion de noeud matre est indpendante de la notion de noeud de contrle centralis.
Le schma ci-dessous illustre la notion de noeud matre :
noeud1
noeud2
ADMINISTRATION
table socit
Matre = noeud1
ADMINISTRATION
table socit
Matre = noeud1
Distribution
Mise
jour
Consultation
noeud3
ADMINISTRATION
table socit
Matre = noeud5
Illustration de la notion de noeud matre
Note : comme l'indique le schma ci-dessus, la notion de noeud matre ne sert qu' empcher une modification
locale des tables d'administration et n'indique nullement une dpendance en terme de gestion de la plate-forme;
exemple : le noeud 3 reconnat noeud 5 comme noeud matre mais peut tout fait tre aliment (via une
distribution) par un autre noeud.
Contrle centralis
Dollar Universe permet une exploitation rpartie sur un ensemble de noeuds; ce titre, il autorise galement le
contrle centralis de certaines de ses tches en un noeud central de l'architecture.
Cette option de contrle centralis est paramtrable pour chaque tche (la valeur par dfaut est donne par une
variable logique cf. paragraphe "Contexte fourni par Dollar Universe" page 38) afin de ne remonter sur le
noeud central que les informations ncessaires au suivi de l'exploitation.
Une option de la dfinition du noeud permet de le dclarer comme noeud de contrle centralis du suivi
d'exploitation.
Ainsi, pour chaque noeud, il est possible de dclarer un noeud de contrle centralis sur lequel remonteront les
tats d'excution de toutes les tches dclares avec l'option contrle centralis.
Par ailleurs, il est noter qu'un seul noeud peut tre dclar comme noeud de contrle centralis (au sein d'une
table des noeuds), de telle sorte que la distribution de la table des noeuds vers un ensemble d'autres noeuds
entrane la reconnaissance par tous ces noeuds d'un seul noeud de contrle centralis (ventuellement distinct
du noeud matre).
L'exemple ci-dessous illustre cette notion de noeud de contrle centralis et l'impact de la notion de noeud
matre.
noeud1
noeud2
ADMINISTRATION
table socit
Matre = noeud1
table des noeuds
Centralis = noeud2
ADMINISTRATION
table socit
Matre = noeud1
table des noeuds
Centralis = noeud2
Distribution
de la table
des noeuds
Noeud8
noeud3
ADMINISTRATION
table socit
Matre = noeud8
table des noeuds
Centralis = noeud9
ADMINISTRATION
table socit
Matre = noeud5
table des noeuds
Centralis = noeud2
Illustration de la notion de noeud de contrle centralis et de l'impact de la notion de noeud matre et des oprations de
distribution de la table des noeuds
Caractristiques complmentaires du noeud

Habilitation aux espaces
La dfinition des noeuds dans Dollar Universe permet de prciser l'habilitation aux environnements de
dveloppement (espaces d'application et d'intgration) et d'exploitation (simulation et exploitation).
Cette fonction permet de restreindre ventuellement l'usage de Dollar Universe sur cette machine aux espaces
qui auront t indiqus.
Note : afin d'viter les disparits de paramtrage, il est recommand de localiser l'environnement de
dveloppement des processus d'exploitation sur un noeud de dveloppement unique, et de distribuer les objets de
Dollar Universe partir de ce seul noeud.
Le schma suivant illustre une telle organisation :
Noeud de production
Noeud de dveloppement
Dveloppement
Transfert
Exploitation
Exploitation
Distribution
du
paramtrage
Exploitation
Noeud de production
Illustration de l'habilitation des noeuds aux espaces
Note : cette organisation est valable pour l'ensemble des oprations de dfinition de paramtrage et de mise jour
de celui-ci : modification, transfert, distribution.
Rpertoires
Dollar Universe ne connaissant pas priori l'architecture du noeud cible, ces informations lui permettent
d'accder directement aux donnes et excutables du noeud.
Dclaration de l'environnement applicatif

Les applications et les domaines
Les dveloppements informatiques font classiquement l'objet d'un dcoupage en sous-ensembles. Le domaine
fonctionnel et l'application sont les deux critres de distinction que propose Dollar Universe.
Un domaine est dfini par un code et un libell,
Une application est dfinie par un code, un libell et un domaine d'appartenance. Plusieurs applications
peuvent appartenir au mme domaine.
L'application et le domaine servent Dollar Universe des fins d'analyse et de structuration sur l'ensemble des
uprocs qu'il gre.
En effet, la dfinition des uprocs est lie une application (donc un domaine), cf. paragraphe "Les uprocs"
page 36.
Les rpertoires application ou UG

Les notions d'espaces et d'units de gestion permettent de dfinir une organisation logique de l'espace
informatique. A chacune de ces notions peut tre associe, de manire facultative, une structuration physique
de l'ensemble de l'environnement, dfinie dans le cadre des tables d'administration de Dollar Universe.
Cette organisation physique est conue pour permettre de construire un maillage de l'espace disque l'aide de
chemins d'accs aux rpertoires de rsidence des principaux objets informatiques manipuls et des donnes.
Dollar Universe n'imposant pas de contrainte particulire sur cette organisation, il permet de prendre en
compte les normes et standards propres chaque client.
Chaque rpertoire applicatif peut ainsi tre dfini :
Sous VMS, en prcisant soit un nom de disque (code de quatre caractres) et un nom de rpertoire, soit un
nom logique global,
Sous OS400, en saisissant le nom de la bibliothque concerne,
Sous UNIX ou Windows, en saisissant directement le nom et le chemin d'accs au rpertoire concern.
Les valeurs des chemins d'accs aux rpertoires application sont restitues, dans des variables
d'environnement (UNIX et Windows), variables (AS400), ou symboles (VMS et OPENVMS), lors de
l'excution des uprocs, voir paragraphe "Contexte fourni par Dollar Universe" page 38).
Note : la dfinition de l'environnement est bien entendu facultative, sauf pour Dollar Universe qui retrouve ses
propres donnes et excutables au travers de ces tables.
Les rpertoires application

Dollar Universe peut grer par noeud / univers / application les chemins d'accs aux excutables (ou autres
objets assimils) des applications.
A la diffrence des donnes pour lesquelles il est possible de distinguer des chemins d'accs espace par
espace, Dollar Universe ne gre les rpertoires d'excutables que par univers (exploitation ou dveloppement).
Par ailleurs, cette dclaration est indpendante des units de gestion rsidantes sur le noeud concern, les
objets concerns tant indpendants des donnes sur lesquelles ils oprent, et, par consquent, communs
l'ensemble des units de gestion qu'ils desservent.
La table correspondante peut tre dfinie de manire centrale et distribue sur chacun des noeuds ncessitant
la connaissance de l'environnement applicatif ainsi dcrit.
Les rpertoires UG
Au mme titre que les excutables applicatifs, Dollar Universe propose de dclarer pour chaque triplet {espace
/ unit de gestion / application} (le noeud est implicite, l'unit de gestion tant rsidante sur un seul noeud), un
chemin d'accs aux donnes propres de l'application pour l'unit de gestion concerne.
La table correspondante peut galement tre dfinie de manire centrale et distribue sur chacun des noeuds
ncessitant la connaissance de l'environnement applicatif ainsi dcrit.
Les utilisateurs
Dfinitions
Dollar Universe distingue deux principaux types d'utilisateurs :
Les utilisateurs des interfaces de Dollar Universe (caractre, commandes, Motif et Windows),
les comptes de soumission utiliss lors de l'excution de l'exploitation batch.

Note : un mme utilisateur peut cumuler les deux fonctions.
Les utilisateurs sont regroups par profil. Ces profils rgissent l'accs aux fonctions et aux donnes de Dollar
Universe (cf. paragraphe "Le contrle d'accs" page 27).
La dfinition des profils utilisateurs permet galement d'organiser le poste de travail de chacun sous Dollar
Universe, conformment ses besoins effectifs (cf. paragraphe "La personnalisation des interfaces" page 29).
Chaque utilisateur doit, pralablement toute connexion, tre identifi par Dollar Universe. Cette
identification est ralise par la cration d'un utilisateur dans la "table des utilisateurs" ce qui permet
notamment de lui attribuer un profil utilisateur et un code auteur.
Le code auteur est un trigramme (une signature), permettant de caractriser un utilisateur. Il sert de rfrence
pour identifier le compte de soumission utiliser pour excuter une tche sous Dollar Universe (cf. paragraphe
"Les comptes de soumission" page 31).
Le contrle d'accs
Au del des droits d'accs des systmes (cf. manuel d'administration), Dollar Universe propose deux types de
contrle d'accs ses fonctions et ses donnes :
La dfinition de proxy permettant de contrler globalement l'accs un serveur pour chacun de ses
clients,
La dfinition, pour un nud donn, des actions autorises ou interdites sur les interfaces commandes,
Motif et Windows (Global Control).
Le contrle d'accs aux serveurs - les proxies

Sur Unix et Windows, limplmentation du protocole de scurit bas sur les proxies permet dinterdire ou
dautoriser laccs un site de donnes.
Les utilisateurs 27
Un utilisateur Dollar Universe est identifi par un utilisateur systme donn (groupe ou domaine nom
d'utilisateur systme) connect une machine. Cette association "utilisateur systme/utilisateur Dollar
Universe" est appele proxy.
Les proxies sont dfinies localement au serveur qui effectue le contrle pour les applications qui sont
l'initiative de la connexion, ce peut tre :
W32 pour les utilisateurs d'un systme Windows,
UNX pour les utilisateurs d'un systme Unix,
VMS pour les utilisateurs d'un systme VMS,
AS4 pour les utilisateurs d'un systme AS400,
MPE pour les utilisateurs d'un systme MPE,
WEB pour les utilisateurs Internet provenant de Dollar Universe Web Control,
DOC pour les utilisateurs Publisher,
REP pour les utilisateurs Reporter.
Des commandes (cf. manuel d'administration) permettent de dfinir et de modifier le fichier binaire des
proxies utilis par le serveur d'IO de Dollar Universe. Ces commandes sont autonomes et n'ont pas besoin de
la prsence du serveur d'IO pour fonctionner.
Exemple de fichier des proxies dfinies pour la socit TEST50
L:\Proxy>lstproxy
SIO v.501 proxy file : L:\universe\TEST50\mgr\uxioproxy.dta (3 def)
SYSTEM U_NODE
GROUPNAME
USERNAME
UNIVERSE_USERNAME
-------------------------------------------------------------------AS4
*
*
*
*NONE
UNX
*
*
test50*
*SAME
(test50*)
W32
devnt*
devel
*
test50a
L:\Proxy>
Utilisateurs non rfrencs dans Dollar Universe

Si les proxies Dollar Universe sont activs, un utilisateur non rfrenc dans la gestion des proxies de Dollar
Universe ne peut pas ouvrir l'interface Dollar Universe.
Un utilisateur non rfrenc dans les tables d'administration de la socit Dollar Universe ne peut pas ouvrir
l'interface Dollar Universe.
Dclaration d'un utilisateur proxy sur un serveur

La variable U_PROXY_FILE doit tre dfinie dans le fichier d'environnement et pointer sur le fichier des
proxies. Ce fichier est alors charg au dmarrage du serveur d'IO.
Si la variable d'environnement n'existe pas, le serveur n'effectue aucune gestion des proxies et autorise l'accs
tous ses clients.
Si la variable est dfinie mais si le fichier des proxies n'existe pas, il est alors cr automatiquement et aucun
client ne peut se connecter au serveur avant qu'une entre ne soit dfinie dans le fichier des proxies.
Les commandes de gestion des proxies

Des commandes permettent de grer le fichier des proxies. Elles sont dtailles dans le manuel
d'administration.
Commande
28 Les utilisateurs
Description
lstproxy
liste le contenu du fichier de dfinition des proxies.
setproxy
ajoute ou modifie la dfinition d'une ligne dans le fichier des proxies.
delproxy
supprime un enregistrement dans le fichier des proxies.
getproxy
vrifie la cohrence du fichier de proxies.
loadproxy_io
Notifie la modification du fichier des proxies au serveur d'IO.
Le contrle d'accs aux donnes et aux fonctions fichier

SECURITY
Dollar Universe propose un contrle d'accs sur ses fonctions et sur ses donnes en fonction des espaces.
Le contrle d'accs repose sur la dfinition de profils utilisateurs (associ l'utilisateur lors de sa dfinition
dans la table des utilisateurs) et de droits associs ces profils. Des droits spcifiques peuvent galement tre
dfinis pour des utilisateurs particuliers.
Ces contrles sont dcrits dans un fichier qui comporte : des enttes, des contrles, et des mots cls pour les
oprations et pour les objets (cf. manuel d'administration pour la description de l'utilisation de ce fichier).
Le contrle d'accs sur les actions repose directement sur les actions cites. Par exemple : Display, Create,
Updatel'action est autorise ou non pour le type d'objet indiqu.
Les objets sont protgs selon leur type. Par exemple : uproc, Task (tche), Engine (automate) ou selon un
sous ensemble de ceux ci, par exemple uproc=U* (qui restreint le contrle aux uprocs dont le code dbute par
un U).
Pour chaque objet il existe un certain nombre de cls pouvant ainsi faire l'objet de restrictions.
Les contrles sont diffrents selon les profils. Le profil PROFADM a accs tous les objets et toutes les
actions.
La personnalisation des interfaces

Ces fonctions sont disponibles pour les interfaces caractres et Windows.
Les interfaces Motif et commandes ne permettent pas la modification du vocabulaire ou de l'organisation des
interfaces.
L'objectif de cette fonction est de permettre la constitution de menus personnaliss pour les interfaces
caractre et Windows en fonction des souhaits de chacune des organisations.
Pour l'interface caractre, elle permet de dfinir :
La hirarchie des menus,
Le squencement des diverses rubriques constitutives de chaque niveau de menu.
Pour l'interface Windows, elle permet de dfinir :
Le bureau standard pour un profil,
Le bureau utilisateur par dfaut.
Les libells des transactions ou des dossiers peuvent tre modifis compltant ainsi parfaitement la
personnalisation recherche.
Personnalisation de l'interface caractres

Non disponible sous Windows.
Les utilisateurs 29
Dollar Universe propose les diffrentes transactions qui le constitue avec la liste des options et des touches de
fonction possibles. Une transaction peut se composer d'un seul programme ou d'une arborescence de
programmes susceptibles de s'enchaner en fonction des options ou touches fonction utilises.
Par exemple, au travers de la transaction de contrle de l'exploitation on fait appel, via les touches de fonction
appropries, d'autres programmes (intervention sur lancements, gestion des automates, etc.). Ces
programmes constituent le second niveau de l'arborescence voque ci-dessus.
Certains programmes peuvent tre directement associs une transaction, ou au contraire, tre appels au sein
d'une autre transaction par le biais d'une option ou d'une touche fonction. On peut citer, par exemple, la
gestion des automates (constituant une transaction en tant que telle), qui peut tre appele depuis une option
de la fonction de contrle de l'exploitation.
L'administrateur peut personnaliser lui mme les transactions standard de Dollar Universe en affectant ou
dsaffectant les options ou touches fonction associes un programme. Toutefois, ces possibilits se limitent
aux deux premiers niveaux de l'arborescence de programme d'une transaction donne.
Recommandations
Pour des raisons de maintenance volutive, il est fortement recommand de ne pas modifier les transactions
fournies en standard au sein de Dollar Universe, celles-ci tant livres chaque nouvelle version ("annule et
remplace"). Il convient donc de dupliquer les transactions avant de les adapter.
La gestion des transactions, propose par Dollar Universe, est base sur une description de programmes
"lmentaires" dont la gestion est incorpore aux modules interactifs de celui-ci : rubrique "gestion des
programmes". Celle-ci n'est pas disponible dans les menus standards, afin d'viter des modifications
intempestives, mais peut facilement tre active (ajout de la transaction correspondante dans le profil voulu)
afin de permettre des maintenances volutives simplifies : par exemple, un excutable rcemment livr
propose une nouvelle fonction sous forme d'une touche fonction spcifique; celle-ci sera dclare dans le
programme correspondant et affecte la transaction souhaite.
Restrictions
La liste des programmes appels depuis une option ou une touche de fonction ne peut pas faire l'objet d'un
ajout portant sur un autre programme qu'un de ceux prvus en standard dans Dollar Universe.
Dans ces conditions, l'utilisation des fonctions d'ajout est extrmement restrictive, un quelconque programme
de Dollar Universe ne pouvant pas tre ajout une quelconque transaction. A fortiori, des programmes
"utilisateur" ne peuvent pas tre greffs. Par contre, les diffrentes options ou touches de fonction des
programmes appels peuvent galement tre affectes ou dsaffectes.
Personnalisation
L'interface caractre de Dollar Universe repose sur le systme des profils utilisateurs auxquels l'administrateur
de Dollar Universe affecte ou non des transactions.
Ces transactions peuvent tre standard (fournies avec Dollar Universe) ou adaptes par l'administrateur en
fonction des besoins. Pour personnaliser l'usage des fonctions, il est possible :
de crer des transactions spcifiques (duplication d'une transaction standard et adaptation des options et
touches fonction qui lui sont associes), puis d'affecter cette transaction ceux des profils utilisateur qui
en ont besoin,
lors de la cration des profils utilisateur, de dfinir des restrictions d'usage sur les transactions qui leur
sont affectes (suppression de touches fonction ou d'options).
Il appartient l'administrateur de choisir la mthode qui lui semble la plus efficace, sachant que ces deux
mthodes se traduisent par les mmes effets. Il peut ainsi s'agir, par exemple, de fournir une nouvelle
transaction de contrle de l'exploitation dnue de la touche de fonction de changement d'environnement
destination de plusieurs profils distincts. Si le nombre de profils utilisateur qui bnficient de cette transaction
est important, il sera plus efficace de crer une transaction spcifique et de l'affecter aux profils concerns.
30 Les utilisateurs
Sinon, la modification des caractristiques de la transaction lors de la cration de chacun des profils concerns
sera plus rapide.
Transactions d'un profil en interface caractre

Comme au niveau gnral, les transactions affectes chaque profil pourront tre amnages en fonction de
chaque besoin.
Cette possibilit ne fait pas pour autant double emploi avec l'amnagement possible des transactions standards.
En effet, les transactions constituent un niveau intermdiaire autorisant la dfinition d'une transaction aux
possibilits rduites par rapport la transaction standard.
Celle-ci peut alors tre directement affecte plusieurs profils, sans avoir adapter pour chaque profil cette
mme transaction standard.
Pour chaque profil utilisateur, il est possible de personnaliser strictement les prrogatives d'utilisation de
Dollar Universe. Ainsi, il est possible d'autoriser ou non l'usage de chaque fonction, et, au sein de chaque
fonction, l'usage de chacune des options ou touches fonction disponibles.
Personnalisation du Global Control

La personnalisation de l'interface Windows de Dollar Universe repose sur la dfinition du bureau standard (du
profil) et du bureau utilisateur.
Un bureau standard est dfini par dfaut pour chaque profil fourni par Dollar Universe lors de son installation
: PROFADM (administrateur), PROFDEV (dveloppeur) et PROFEXP (exploitant).
Un utilisateur ayant le profil administrateur (PROFADM) peut crer et modifier des bureaux associs aux
profils (un profil = un bureau standard). Il peut galement donner aux utilisateurs d'un profil la possibilit de
crer leur propre bureau utilisateur, qui sera donc spcifique chaque utilisateur.
La manipulation des bureaux est dcrite dans le manuel de Global Control.
Les comptes de soumission

Dfinition
Chacune des deux populations d'utilisateurs peut constituer un compte de soumission avec, toutefois, les
restrictions suivantes :
Les utilisateurs "dveloppement" ne peuvent tre utiliss comme compte de soumission que dans l'univers
de dveloppement,
Les utilisateurs "production" ne peuvent tre utiliss comme compte de soumission que dans l'univers
d'exploitation.
Par contre, les utilisateurs "mixtes" ( la fois dveloppement et production) peuvent tre utiliss comme
compte de soumission dans tous les espaces.
Utilisation du code auteur

Le code auteur est un trigramme (une signature) permettant de caractriser un utilisateur. Sa dfinition est
obligatoire pour tout compte utilisateur. Il sert de rfrence pour identifier le compte utiliser, pour excuter
une tche sous Dollar Universe.
Tous les travaux planifis au sein de Dollar Universe, mme s'ils le sont au titre d'un utilisateur
(dveloppement ou production) ne mmorisent en ralit que le code auteur, de telle sorte que, dans les
Les utilisateurs 31
oprations de mise en production, une conversion automatique puisse s'effectuer entre des comptes de
soumission.
Ceci s'opre lors de phases de transfert (traduction automatique d'un utilisateur dveloppement en un
utilisateur production ayant le mme code auteur), mais galement dans les phases de distribution (par
exemple, traduction automatique d'un utilisateur exploitant d'un noeud donn en un autre utilisateur exploitant
d'un autre noeud).
L'exemple suivant illustre ses apports.
Exemple : une tche est planifie en espace d'application et est associe un compte de soumission "cpttest".
Le code auteur de ce compte est "001".
La tche concerne fait l'objet d'une distribution vers une unit de gestion distante.
Sur le noeud supportant l'unit de gestion concerne, le compte "cpttest" n'est pas dfini, mais un autre
compte dont le username est "compta" et le code auteur "001" existe.
Le code auteur permettra, au moment d'excuter la tche concerne de lui associer, grce au code auteur, le
compte "compta".
Cet exemple montre qu'il n'est pas ncessaire de standardiser les comptes de l'ensemble des noeuds concerns
par un processus d'exploitation de Dollar Universe. Il suffit simplement d'associer la rfrence que constitue le
code auteur des comptes existants.
Le code auteur contribue donc la portabilit des tches dfinies sous Dollar Universe, de leur environnement
de test vers leur environnement d'exploitation.
32 Les utilisateurs
Le paramtrage
Les ressources
Sur Windows, UNIX et VMS, une ressource permet, via un identifiant logique, de dcrire une ressource
systme ou logique (virtuelle) que l'on souhaite surveiller pour conditionner l'excution de traitements.
Dfinition
Une ressource s'identifie par une rfrence.
La rfrence est un identifiant logique permettant l'uproc de s'adapter son environnement d'excution.
Ainsi, en cas de changement de noeud, voire mme de systme d'exploitation, la description de l'uproc
s'adaptera pour prendre en compte les spcificits recenses de ceux-ci.
Les rfrences de ressource sont dfinies globalement pour un noeud donn, quel que soit l'espace.
Une ressource se caractrise par sa nature :

FIL : fichier
VMS, UNIX, Windows
LOG : logique
VMS, UNIX, Windows
PRC : process
VMS
DSK : disque
VMS
LNM : nom logique
VMS
SYS : objets systme
VMS
QUE : queue batch
VMS
Une ressource s'identifie par :
son nom : nom physique de la ressource surveiller, au sens du systme d'exploitation.
sa localisation : nom de l'objet de stockage de la ressource (ex : le nom du rpertoire pour un fichier).
La "localisation" de la ressource est exclusivement utilise pour les ressources de nature "FIL" et "LNM".
La notion de "localisation" correspond rpertoire, pour la nature de ressource "FIL" (sous VMS et
openVMS, ventuellement, sous forme de nom logique ou de lien symbolique, sauf si le nom de la
ressource est galement exprime sous forme de nom logique), ou un nom de table, pour la nature de
ressource "LNM".
Note: cette localisation peut faire rfrence des ressources non rsidentes sur le noeud d'analyse de la ressource,
sous rserve que la primitive du systme d'exploitation utilise (correspondant la nature et attribut dfinis), le
permette.
Le paramtrage 33
Si la ressource est dfinie "exclusive", elle ne pourra pas tre partage par une autre uproc conditionne. Dans
le cas contraire, des quotas peuvent tre dfinis pour grer le partage de la ressource entre plusieurs uprocs
(voir paragraphe "Condition de ressource" page 52 pour le fonctionnement des quotas):
Quota 1
Valeur maximum du quota 1 de la ressource,

pouvant varier de 0 9999 (0 par dfaut).
Quota 2
Valeur maximum du quota 2 de la ressource,

pouvant varier de 0 9999 (0 par dfaut).
Enfin, une ressource est examine selon une frquence propre (par l'automate surveillant : voir paragraphe
"Supplance du surveillant de ressources" page 91 ).
Codification
Le nom de la ressource ou la localisation peuvent tre codifi avec les lments fonctionnels proposs par
Dollar Universe. Les expressions suivantes peuvent tre insres dans le nom des ressources.
Ces codifications ne sont utilisables que pour des natures de ressource "LOG", "FIL" et "LNM. Elles peuvent
s'insrer un quelconque endroit du nom ou de la localisation.
"!UG!" permet d'insrer le code de l'unit de gestion dans le nom de la ressource, ce code est obtenu
partir des informations dfinies dans le "contrle inter-UG" de la condition de ressource. Si
l'interprtation de ces informations dsigne plusieurs units de gestion, le nom de la ressource rendu
gnrique par l'insertion de cette expression correspondra autant de nom de ressources qu'il y a d'units
de gestion dsignes.
Attention : mme si les units de gestion vises par la condition ne sont pas rsidentes sur le noeud
d'valuation, les ressources correspondantes seront recherches localement (sauf si la localisation fait
rfrence une ressource externe au site).
"!DTRAIT!" permet d'insrer au sein du nom de la ressource, la date de traitement telle qu'exprime dans
le "contrle de la date de traitement" de la condition de ressource, au format AAAAMMJJ.
"!SOC!" permet l'insertion du nom de la socit courante lors de l'examen de la condition de ressource.
"!ESP!", permet l'insertion du code espace courant (A, I, S, X) lors de l'examen de la condition de
ressource dans l'identifiant de la ressource.
De plus, sous VMS et openVMS, les noms logiques sont accepts uniquement pour les ressources de nature
"FIL", et si la localisation n'est pas, elle mme, exprime l'aide d'un nom logique. Si Dollar Universe
contrle la syntaxe des expressions spcifiques utilises ("!ESP!", "!SOC!", ...), Il ne peut contrler la
restriction d'utilisation des noms logiques prcdemment dcrite.
Sous UNIX, VMS ou Windows, pour une ressource FIL , le nom du fichier peut utiliser le caractre
gnrique * , un quelconque emplacement du nom. Ce caractre ne peut, par contre, pas tre utilis dans
la localisation du fichier. Les caractres ? ou [ ] ne sont pas pris en compte par lautomate.
Sous Windows, pour une ressource de type fichier, les chemins UNC sont grs ( partir de la version 5 de
Dollar Universe). Pour que la dtection des fichiers indiqus par le chemin UNC fonctionne, il faut que le
lanceur et le surveillant aient les droits d'accder ce chemin UNC. De ce fait, les services Windows associs
ces automates doivent tre dmarrs au titre d'un utilisateur possdant ces droits (droits d'authentification sur
le domaine Windows et droits d'accs au fichier notamment).
Note : sous VMS et openVMS, afin de rendre le processus d'exploitation aussi indpendant que possible de
l'organisation de l'environnement, il est conseill d'utiliser les noms logiques plutt pour dfinir la localisation
(chemin d'accs) d'un fichier que pour dfinir son nom. De manire gnrale, la variabilisation des nom et
localisation des ressources s'effectuera en fonction du caractre "dynamique" (volution avec le temps) des
paramtres proposs : ainsi, les concepts "statiques" ("!UG!", "!SOC!" et "!ESP!") seront plutt utiliss dans la
variabilisation de la localisation, les concepts "dynamiques" ("!DTRAIT!") Seront quant eux plutt utiliss dans
la variabilisation du nom de la ressource.
34 Le paramtrage
Exemple : rception et consolidation de fichiers en provenance de magasins

L'uproc charge de la consolidation des fichiers en provenance des magasins dispose d'une condition de
ressource base sur la rfrence dfinie comme suit :
Nature
FIL
Nom
comm_t!DTRAIT!g.dat
Localisation
rep_!ESP!!UG!
Le "contrle inter-UG" associ cette condition est un formalisme TIH du type "{M }" (tous les magasins
dpendants du sige, "M01" et "M02", par exemple).
Le "contrle de la date de traitement" associ cette condition fait rfrence une date de traitement
identique celle de l'uproc considre (mme jour, par exemple).
Au moment du pilotage de l'uproc, pour le 21 dcembre 2004, Dollar Universe traduit les symboles "!UG!" Et
"!DTRAIT!" par leurs valeurs issues du "contrle inter-UG" et du "contrle de la date de traitement".
Si l'on considre de plus que ce pilotage s'effectue en espace d'exploitation, les fichiers surveiller seront :
REP_XM01:COMM_T20041221G.dat
REP_XM02:COMM_T20041221G.dat
O REP_XM01 et REP_XM02 seront des noms logiques dsignant les rpertoires de stockage des fichiers
COMM_T20041221g.dat.
Si l'option "toutes sont ncessaires" dans le "contrle inter-UG" est choisie, les deux fichiers devront tre
prsents pour que la condition soit satisfaite.
Les classes d'incompatibilit

Rle
Les conditions de non-simultanit permettent de dfinir des exclusions de traitement extrmement prcises.
Toutefois, elles ne sont pas symtriques. En effet, quand deux uprocs ne doivent pas s'excuter simultanment
, la condition de non-simultanit doit tre prsente dans la description de chacune des uprocs.
Cette contrainte peut tre gnante dans le cas ou des applications entires doivent tre considres comme
tant non compatibles donc globalement non-simultanes.
Sur Windows, UNIX et VMS, les classes d'uprocs apportent une solution simple et efficace pour traiter ce cas
de figure.
Utilisation des classes d'incompatibilit

L'association d'une uproc une classe permet de dcrire des processus de non simultanit d'excution, selon
les rgles suivantes :
une uproc peut appartenir une et une seule classe (dclaration dans les informations gnrales de
l'uproc),
une uproc peut tre dfinie comme tant incompatible avec une ou n classes.
Les rgles d'examen de ces incompatibilits sont les suivantes :
l'examen est effectu en local uniquement,
pour toute uproc lance (on admet que ses contraintes d'incompatibilits ont t satisfaites), Dollar
Universe mmorise :
sa classe d'appartenance (rfrences de type "appartenance"),
les classes avec lesquelles elle est incompatible (rfrences de type "incompatibilits"),
au moment du lancement de toute uproc, Dollar Universe s'assure :
Le paramtrage 35
que sa classe d'appartenance n'est pas dj mmorise parmi les classes rfrences en type
"incompatibilits",
que les classes avec lesquelles elle est incompatible, ne sont pas dj mmorises en tant que classe
rfrences en type "appartenance".
Ainsi, une uproc donne ne pourra tre excute simultanment avec aucune des uprocs associes une des
classes avec laquelle elle est dclare incompatible. De mme, aucune uproc ne pourra s'excuter
simultanment celle-ci si elles sont dclares incompatibles avec sa classe d'appartenance.
Note : l'examen des classes d'incompatibilit est effectu localement par le lanceur et ne considre donc que les
uprocs s'excutant au titre des units de gestion rsidentes sur le noeud d'examen.
Les incompatibilits dcrites au moyen des classes sont systmatiquement examines avant le pilotage
(examen des conditions d'excution) de l'uproc concerne. A ce titre, la notion de classe ne figure pas dans la
formule de lancement.
Exemple : classes d'uprocs
Les traitements de sauvegarde offrent un bon exemple de classe d'incompatibilit. En effet, il est prfrable
qu'aucune autre nature de traitement ne soit excute en mme temps.
Ainsi toutes les uprocs de sauvegarde seront dclares comme appartenant une classe avec laquelle toutes
les autres uprocs seront dfinies comme incompatibles.
Les uprocs
Dfinition
La procdure, que ce soit une procdure ".bat" sous Windows, un script de shell sous UNIX, une procdure
".com" en DCL sous VMS ou un programme en CL sous OS400 (CL, DCL, shell sont dsigns dans la suite
de cette documentation sous le vocable gnrique de "CL" comme "Command Language"), constitue un des
objets essentiels de la production informatique.
Outre des possibilits spcifiques qu'il apporte dans le cadre du CL, Dollar Universe lui associe un ensemble
d'informations complmentaires. Le regroupement du CL et de ses informations complmentaires est appel
uproc.
L'uproc dsigne donc le regroupement :
d'un ensemble de caractristiques et de conditions logiques partir desquelles sera vrifie l'excutabilit
de la procdure (opration dite de "pilotage de l'uproc" ). Ces informations sont dfinies, de manire
totalement interactive, lors de l'criture de la procdure.
du CL : Dollar Universe apporte, ce niveau, un symbolisme (issu du TIH par exemple) et des
commandes spcifiques. Le langage de commande de l'uproc est excut directement sous le systme
d'exploitation concern, sans le contrle de Dollar Universe. Il est vident que dans le cas o des
commandes spcifiques de Dollar Universe sont insres dans le CL, celles-ci ne sont pas excutables en
dehors de Dollar Universe.
des informations dites de "terminaison" dont le but est de dfinir des "post traitements" prenant en charge
des mises jour ou des purges des fichiers historiques, ou, prparant l'enchanement de travaux
dpendants.
L'uproc ainsi constitue est un objet autonome, dont les constituants sont indissociables au sens de Dollar
Universe.
Les uprocs sont destines tre places par Dollar Universe en attente d'excution dans une queue batch (ou
soumise en arrire plan, sous UNIX ou Windows, en l'absence d'un gestionnaire de files d'attente de travaux).
36 Le paramtrage
D'autre part, il est conseill, pour des raisons de facilit, de manipulation et de maintenance de raliser des
procdures homognes au plan fonctionnel et courtes (formules de lancement simplifies, expression de
conditions plus simples).
Codification
A partir de la version 4.1 de Dollar Universe, la codification des uprocs est libre. L'association du domaine et
de l'application se fait de faon externe.
L'uproc constitue la pice matresse de l'ensemble de l'architecture fonctionnelle de Dollar Universe.
Les fonctions de cration et de gestion des uprocs sont disponibles dans chacun des espaces grs par Dollar
Universe. Sur le noeud et au sein de l'espace dans lequel elles sont cres, les uprocs sont immdiatement
excutables dans l'environnement d'une quelconque des units de gestion prsentes.
Dans le cas o l'on souhaite raliser des excutions d'uproc dans un autre espace, un transfert d'espace devra
tre ralis. Dans le cas o l'on souhaite excuter une uproc sur une unit de gestion rsidant sur un autre
noeud que son noeud de dveloppement, une distribution devra tre ralise.
Cinmatique d'criture
Une application de Dollar Universe est spcialement ddie la dfinition des uprocs. L'organisation
correspondante est prsente ci-dessous, elle met en vidence les principales fonctions de la dfinition des
uprocs et montre l'tendue des possibilits offertes par Dollar Universe.
Des uprocs ayant des spcifications fonctionnelles complexes trouveront les moyens de les traduire, alors que
des uprocs simples ne ncessiteront qu'un minimum de saisie (limitation la dfinition des "caractristiques
gnrales").
SELECTION
DE LUPROC
Caractristiques
gnrales
Variables
Ecriture du C.L.
Classes
dincompatibilit
Contrle gnral
de cohrence des
informations
saisies
Conditions
dexcution
Consignes de
terminaison
Successeurs
Fonctions
obligatoires
Fonctions
facultatives
Cinmatique de l'criture des uprocs
Les procdures ou programmes (DCL, shell, CL, .bat)

Procdures internes ou externes
Deux options sont proposes concernant le mode de gestion du langage de commande associ l'uproc selon
que celui-ci est gr par Dollar Universe ou de faon indpendante.
Le paramtrage 37
Le choix de grer le langage de commande (CL) hors Dollar Universe implique l'identification du fichier
contenant le langage de commande correspondant. Ce paramtre est un nom de fichier dont les conventions
d'criture sont conformes celles du systme d'exploitation concern. Le chemin d'accs ce fichier peut tre
quelconque (mais doit bien sur exister sur le noeud o l'uproc s'excutera), il peut tre renseign explicitement
ou par l'intermdiaire d'une variable d'environnement qui devra tre dclare :
dans le login du compte de soumission de la tche pour tre reconnue par l'automate
et dans le fichier denvironnement logique pour tre connu de linterface.
Pour les uprocs CL interne :
le fichier contenant le langage de commande est cr avec le nom et le numro de version de l'uproc
(NOM_UPROC.VERSION). Il est stock dans un rpertoire de Dollar Universe (rpertoire des
procdures de l'espace : UXPxx) dclar lors de l'installation; cf. Manuel d'installation.
Dollar Universe assure une volution conjointe du numro de version de l'uproc et du numro de version
du fichier contenant le CL associ. Pour les autres uprocs, cette volution parallle n 'est pas assure.
Lors des oprations de transfert, de distribution et d'extraction, Dollar Universe assure le transport de
l'uproc et de son CL interne.
Ecriture des procdures

Les fonctions interactives d'criture des uprocs proposes par Dollar Universe utilisent l'diteur standard du
systme d'exploitation concern.
Sous UNIX, une variable d'environnement (cf. manuel d'administration) permet de choisir l'diteur qui
devra tre utilis en mode lecture et en mode criture. Par dfaut l'diteur vi est utilis sous UNIX.
Sous VMS, le choix est laiss entre les diteurs edt et tpu. Il fait partie des caractristiques de la socit.
Au sein du langage de commande, Dollar Universe autorise l'insertion de commandes spcifiques permettant
la communication avec les applications; il s'agit de fonctions telles que :
jalonner le langage de commande de l'uproc (points d'avancement de l'excution),
manipuler des fichiers en bnficiant d'une liste de paramtres permettant d'exploiter pleinement les
possibilits offertes par le traitement informatique hirarchise. L'utilisation des verbes correspondants
permettra de simuler une dmultiplication de la ligne d'instruction correspondante, et, ceci autant de fois
que ncessaire en fonction du nombre d'occurrences correspondant la rsolution de l'expression TIH.
Par exemple, l'expression "{XY}" insre comme paramtre du verbe de copie permettra de copier le
fichier concern de toutes les units de gestion de type "X" dpendant directement de l'unit de gestion de
type "Y" o est excute l'uproc,
dclencher une uproc sur un ensemble d'units de gestion,
restituer dans des variables ddies le nom des rpertoires o rsident les objets informatiques de chacune
des applications gres par Dollar Universe. La commande correspondante permet d'viter la dsignation
explicite, dans le CL Associ l'uproc, d'informations qui peuvent tre diffrentes en fonction du contexte
d'excution (espace, units de gestion).
transmettre des messages dans l'historique simplifi des excutions d'uprocs gr par Dollar Universe
(trace automate), etc.
Les commandes de Dollar Universe qui peuvent tre insres dans le CL sont dcrites dans le manuel de
l'interface commande.
Paramtres d'excution
La transmission de paramtres procde, sous Dollar Universe, de diffrentes manires, explicites ci-dessous.
Les commandes spcifiques sont dtailles dans le manuel de l'interface commande de Dollar Universe.
Contexte fourni par Dollar Universe
38 Le paramtrage
Dollar Universe fournit, lors de son dmarrage, un ensemble de variables d'environnement ou de noms
logiques qui peuvent tre utiliss pour l'criture de la procdure. Ces variables sont les mmes quelque soit le
systme d'exploitation concern, mais demeurent prfixes de manire distincte suivant chacun d'eux ("S_"
sous UNIX, VMS ou Windows, "MX" sous OS400).
Cet environnement logique est disponible dans le pr traitement : U_ANTE_UPROC, dans le script de l'uproc
et dans le post traitement : U_POST_UPROC (voir paragraphe "Traitements complmentaires" page 93).
Nom
Fonction
Format
EXE
Rpertoire application.
FIC
Rpertoire UG.
LO*GOUT
Procdure de mnage qui s'excute en fin de sance de travail.
S_APPLI
Application de l'uproc.
2 car
S_CODAUTEUR
Code auteur du compte de soumission.
3 car num
S_CODNOEUD
Code noeud UNIVERSE correspondant au noeud Decnet ou au cluster

alias.
10 car
S_CODSESS
Nom de la session.
10 car
S_CODUG
Code de l'unit de gestion courante.
10 car
S_DATRAIT
S_DATRAIT_E
Date de traitement de l'uproc en cours d'excution.
AAAAMMJJ
S_DATRAIT_X
Date de traitement au format U_FMT_DATE.
S_DATRAIT_A
Date de traitement.
S_DOMAINE
Domaine de l'uproc.
S_ESPEXE
Code de lespace courant.
S_LOGINPLUS
Indicateur permettant plusieurs login sous le mme nom utilisateur, en

sacrifiant la mmorisation de contexte.
S_LOGINSTD
Rserv au dveloppement ORSYP.
S_NUMJALON
Numro de jalon (step) servant aux reprises dexcution.
AAMMJJ
X, S, I ou A
2 car num
S_NUMPROC
Numro d'ordre de l'uproc courante.
7 car num
S_NUMSESS
Numro d'ordre de la session.
7 car num
S_NUMVERSESS
Numro de version de la session.
3 car num
S_NUMLANC
Numro de lancement.
7 car num
unix_status
Sous UNIX, exit restitu par U_ANTE_UPROC.
S_P1 S_P30
Paramtres passs luproc par une commande uxordre ou uxset parm.
S_SIBATCHNP
Nombre de paramtres passs.
S_PID
Numro d'identit du processus.
S_PROCEXE
Nom de l'uproc courante.
S_REP_EXEC
Adresse du rpertoire des excutables de UNIVERSE.
S_REPRISE
S_CODREPRISE
Indicateur de reprise d'excution.
S_RESEXE
Sous VMS, code retour standard de l'uproc (voir paragraphe

"Soumission de l'uproc" page 93).
RESEXE
Sous Windows ou Unix, code retour standard de l'uproc.
S_SBPROC
Paramtres techniques de lancement de l'uproc.
S_SIGSOC
S_SOCIETE
Code socit.
S_T
Mmorisation de $STATUS en sortie de l'uproc.
S_U_LANGUE
Langue courante de Dollar Universe.
0 30
10 car
O ou N
6 car
FR ou EN
Le paramtrage 39
S_U_RETCOMM
Code retour spcifique aux commandes spciales batch de UNIVERSE.
S_UPROC_LANC
Nom de la procdure DCL d'excution.
S_USERNAME
Code utilisateur de soumission.
S_VEREXE
Numro de version de l'uproc courante.
3 car num
U_CDJ_DISABLE
Flag de dsactivation du serveur d'affichage.
O ou N
U_FMT_DATE
Format de saisie et daffichage des dates, combinaison de YYYY

(anne), MM (mois), DD (jour du mois) et ventuellement un sparateur
choisi parmi /: ou -.
S_VERIFY
Mmorisation de mode vrification.
U_LOGIN_SET
Indicateur de passage dans le login pour viter les boucles.
S_EXECFORCE
Indicateur de soumission sans vrification des conditions (lancement

sans pilotage).
O ou N
S_FORCEFINPER
Indicateur de lancement forc en fin de priode
O ou N
S_STAT_AVG
Sur Windows et UNIX : Temps elapsed moyen du job. Pour activer la

valorisation de S_STAT_AVG, positionner la variable
U_GET_STAT_AVG a Y dans l'environnement de Dollar Universe.
Transmission de paramtres complmentaires une procdure

Au del du contexte d'excution fourni (dcrit ci-dessus), il convient de dissocier les besoins de transmission
de paramtres selon que les processus concerns sont priodiques ou non; en effet, les processus priodiques
(soumission automatique, sans prsence humaine) ne ncessitent naturellement aucun paramtrage particulier
en dehors, ventuellement :
de la transmission de paramtres d'une procdure une autre,
de l'alimentation automatique d'un paramtrage par dfaut, dans la mesure o le CL ncessite

systmatiquement des paramtres lors de son lancement (c'est le cas de l'OS400, pour lequel un
programme, conu pour tre lanc indiffremment en batch ou en interactif, et ce dernier titre paramtr
lors de son criture, ncessitera systmatiquement de recevoir des paramtres).
Dollar Universe rpond ces besoins de la manire suivante :
au sein d'une mme session, deux procdures peuvent changer jusqu' 30 paramtres de 256 caractres
(cf. Manuel de l'interface commande pour le dtail sur l'criture du CL),
en permettant la gestion de paramtres purement applicatifs (appels variables) attachs aux uprocs avec
un mcanisme de valorisation explicit dans le paragraphe ci aprs.
Enfin, et pour les processus non priodiques, Dollar Universe propose pour le dclenchement d'uprocs batch,
une commande spcifique (uxordre) qui accepte le passage de paramtres. Voir manuel de l'interface
commande.
Les variables
Cette fonction de Dollar Universe permet de dfinir et saisir, par linterface graphique ou le mode
commandes, des variables aussi bien dans les phases de dveloppement des objets dexploitation que pendant
la production.
Lobjectif est donc de permettre une prparation manuelle ou semi automatique de lexploitation batch.
Principes gnraux
Dollar Universe permet donc :
de dfinir le nom et le type des variables lors de la dfinition des uprocs, ainsi quune valeur par dfaut
(qui pourra tre modifie par la suite),
40 Le paramtrage
de reconduire la valeur des variables entre les uprocs au sein d'une session (par l'excution d'une
commande spcifique Dollar Universe uxset var, cf. manuel de l'interface commande),
daffecter des variables aux tches et de modifier leur valeur si les valeurs par dfaut affectes dans les
uprocs doivent tre modifies pour cette planification,
daffecter des variables aux lancements et de modifier leur valeur dans les lancements, si les valeurs par
dfaut de la tche doivent tre modifies pour ce lancement,
de modifier leur valeur dans la reprise dune excution si une valeur devait tre modifie cette tape.
La valeur dune variable pourra galement tre modifie lors du dclenchement de la tche ou de la cration
du lancement en mode commande ou lors de lexcution du CL.
Caractristiques
Les variables sont dfinies dans les uprocs, elles sont nommes et prsentent les caractristiques suivantes :
Nombre maximum de variables : 80,
Longueur du nom de la variable : 20 caractres maximum,
Type de la variable : date, numrique ou texte,
Valeur de la variable : 255 caractres au maximum pour du texte, 12 caractres pour une variable
numrique (positive ou ngative).
La valorisation de ces variables est faite dans les uprocs lors de leur dfinition, au sein de la session par un
mcanisme de commandes, dans les tches, les lancements ou la reprise dexcution.
Valorisation
Les variables sont directement utilisables dans le CL de luproc. La valeur de la variable lors de lexcution
est :
lors de lexcution au sein dune session, la valeur peut tre reconduite par lexcution dune commande
dans le CL de luproc (commande uxset var, cf. manuel de l'interface commande),
ventuellement si lexcution a fait lobjet dune reprise, la valeur est celle indique lors de la reprise,
ou sinon, la valeur est celle affecte au lancement,
ou sinon, la valeur est celle affecte la tche,
ou sinon, la valeur est la valeur par dfaut de la variable indique lors de sa dfinition dans luproc (valeur
sur le nud local de lexcution de luproc).
Priode fonctionnelle et date de traitement

Dfinitions
Dollar Universe pratique une exploitation "au fil de l'eau" et ne connat pas de notion de journe
d'exploitation. Il privilgie la reconnaissance de priodes applicatives pour lesquelles s'excutent les
traitements.
La priode fonctionnelle permet donc de "dater" les donnes traites lors de l'excution d'une uproc.
Ainsi, tout lancement d'une uproc s'accompagne du calcul automatique ou d'une demande de date de
traitement directement fonction de la priode fonctionnelle de l'uproc (sauf si l'uproc est dfinie sans priode
fonctionnelle).
Les valeurs possibles de la priode fonctionnelle sont :
Sans
Quinzaine
Quadrimestre
Le paramtrage 41
Jour
Mois
Semestre
Semaine
Bimestre
Anne
Dcade
Trimestre
La date de traitement est exprime en jour, mois et anne, quelle que soit la priode fonctionnelle. Si l'un des
lments de la date de traitement n'est pas utile, il ne sera pas demand et prendra automatiquement la valeur
de la date de dbut de la priode envisage.
Cette date sert de modle de rfrence pour calculer automatiquement toutes les autres dates rencontres dans
le pilotage, l'excution du CL ou la terminaison.
Si l'uproc est de priode fonctionnelle :
Journalire, il est demand une date complte : jour mois anne,
Hebdomadaire, il est demand le numro de semaine (de 1 53) dans l'anne (nnaaaa) ou la date
correspondante (jour mois anne, qui est obligatoirement un lundi),
Dcadaire, il est demand d'abord le mois et l'anne puis le numro de la dcade (1, 2 ou 3), les dates de
traitement correspondantes tant le 1er, le onze et le 21 du mois,
Mensuelle, il est demand le mois et l'anne et la date traitement est automatiquement le 1er du mois,
Bimensuelle, il est demand d'abord le mois et l'anne, puis la quinzaine (1 ou 2) et la date traitement
correspondante est le 1er et le 16 du mois,
Trimestrielle, il est demand le numro du trimestre (1, 2, 3 ou 4) et l'anne. La date de traitement

correspondante est le 1er jour du trimestre.
Utilisations
La date de traitement figure dans les vnements enregistrs par Dollar Universe. Cette date permet de
conserver et de diffrencier les traces des excutions d'une tche (en complment des dates de planification et
d'excution).
La date de traitement est disponible au sein du CL, dans une variable rserve (cf. paragraphe "Paramtres
d'excution" page 38), pour pouvoir, par exemple, indiquer sur l'tat concern, la bonne priode comptable,
indpendamment de la date d'excution.
La date de traitement peut galement tre utilise dans la synchronisation des traitements (une uproc ne
s'excute que si elle s'est correctement droule le mois prcdent, ou si telle autre uproc s'est correctement
droule au titre du mme mois,...).
Exemple : date de traitement
Une uproc de saisie comptable est mensuelle, et chaque lancement il est demand une date au format
MMAAAA.
L'uproc de clture mensuelle est mensuelle, et il est ncessaire de conserver la trace dans le fichier historique
des vnements d'exploitation des 12 excutions correctes pour pouvoir lancer l'uproc de clture annuelle de
l'exercice.
Note: la priode fonctionnelle est indpendante de la priodicit de planification de l'uproc concerne, mme si
Dollar Universe propose en standard l'algorithmique permettant de calculer automatiquement les dates de
traitement en fonction des dates de planification (cf."Date de traitement d'une tche" page 70).
Exemple : un traitement de bilan comptable mensuel est systmatiquement soumis deux reprises chaque
mois :
le 30 de chaque fin de mois pour extraire un premier bilan du mois coul,
le premier lundi de chaque mois pour extraire un bilan complet intgrant la "cinquime" semaine du mois
coul.
Un exemple analogue peut tre fourni sur la base d'un traitement, soumis chaque fin de semaine, et dont
l'objectif est de restituer un rcapitulatif des mouvements comptables du mois courant.
42 Le paramtrage
La nature "applicative" de la priode fonctionnelle impose des conditions d'usage dans la synchronisation et le
dclenchement d'uprocs. On se reportera la description du Contrle sur la date de traitement pour connatre
ces limitations d'usage.
La modification de la priode fonctionnelle d'une uproc est autorise (depuis la version 4.1 de Dollar Universe
sous Windows, UNIX et VMS).
Mmorisation des vnements

Objectifs
La cohrence de la production informatique sous le contrle de Dollar Universe est assure grce la matrise
que Dollar Universe exerce sur chacun des vnements de l'exploitation.
Un certain nombre de ces vnements sont importants et leur prsence peut conditionner l'excution de
certaines uprocs. Cependant la majorit d'entre eux ne prsente pas d'intrt autre qu'informatif.
Pour viter de surcharger les historiques, Dollar Universe entretient un fichier spcifique des vnements qui
enregistre toutes les uprocs dclares "mmorises". Dollar Universe examine ce fichier pour value les
conditions d'excutions de chaque uproc.
Une uproc non mmorise ne pourra jamais tre cite dans les conditions d'une autre uproc.
L'entretien de la base des vnements s'effectue par le biais de cette mmorisation ou grce aux consignes de
terminaison. Ce fichier est diffrent du suivi des excutions et des historiques.
Caractristiques
Plusieurs paramtres permettent de dfinir la mmorisation :
Mmorisation : oui ou non

Cette notion indique si les excutions d'une uproc doivent tre mmorises ou non. La mmorisation d'une
excution d'une uproc correspond sous Dollar Universe la cration d'un vnement.
Si des conditions doivent tre dfinies sur une uproc, elle doit ncessairement tre "mmorise". Dans le
cas contraire, la "non mmorisation" permet de limiter la taille de la base des vnements de Dollar
Universe (par souci de performances et de lisibilit).
Mmorization par date de traitement

Dans le cas o l'uproc doit tre mmorise, cette information permet d'indiquer si l'on souhaite conserver
un ou plusieurs vnements pour une mme date de traitement (date calcule partir de la date
d'excution par application de la priode fonctionnelle).
Le choix "un" provoque la destruction du dernier vnement connu pour la date de traitement concerne,
quand une nouvelle excution est lance pour la mme date de traitement.
Cette purge automatique est complte par l'information nombre de dates.

Note : cette fonction peut se substituer aux Consignes de terminaison. Elle ne permet cependant pas, une gestion
aussi fine des vnements et ne peut s'y substituer systmatiquement.
Mmorisation pour n dates de traitement

Cette information dfinit la dure de rtention des vnements d'excution d'une uproc au sein de la base
des vnements (multiple de la priode fonctionnelle de l'uproc).
Exemple : uproc mmorise et non mmorise

Une uproc dont la fonction est de permettre la mise jour d'un fichier permanent de la clientle peut tre non
mmorise car il est peu probable que, fonctionnellement, elle puisse conditionner l'excution d'une autre
uproc.
Le paramtrage 43
Une uproc qui participe la clture mensuelle comptable sera trs certainement mmorise, car sa bonne
excution sur 12 mois conscutifs conditionnera le lancement de l'uproc de clture annuelle de l'exercice.
Successeurs
Dans le processus vnementiel du lanceur, c'est le dbut ou la fin d'excution de l'uproc conditionnante qui
provoque un nouvel examen, par le lanceur, des uprocs ventuellement conditionnes (et bloques) par cette
uproc.
Par dfaut, ce nouvel examen s'effectue dans n'importe quel ordre; l'objectif des successeurs est de dfinir un
ordre privilgi, dans le cas de la fin d'excution d'une uproc, de nouvel examen des uprocs en attente.
Rle
En fin d'excution de chaque uproc, Dollar Universe (le lanceur) examine la liste des tous les traitements dont
les uprocs sont en attente. Pour chacune d'entre elles, un nouveau lancement est effectu.
En standard, le pilotage des uprocs s'effectue dans un ordre alatoire.
La notion de successeur permet de dfinir un ordre d'examen des uprocs en attente d'vnement, et par
consquent de privilgier le lancement de telle ou telle uproc suite la fin d'excution d'une uproc donne.
Spcificits
La fonction propose rpond aux rgles suivantes :
les successeurs sont traits quel que soit l'tat de fin d'excution de l'uproc concerne (termin ou
incident),
les successeurs sont examins dans l'ordre dfini lors de leur saisie,
parmi les successeurs renseigns, ne sont traits que les uprocs en attente d'vnement sur l'uproc
concerne,
les successeurs sont identifis uniquement par des noms d'uprocs, les autres informations ncessaires
(unit de gestion, session, utilisateur, date de traitement) tant directement fournies par l'expression des
conditions d'excution de l'uproc concerne,
les uprocs en attente d'vnement sur l'uproc concerne et qui ne figurent pas parmi les successeurs
dsigns, sont soumises au pilotage selon les conditions normales d'examen de Dollar Universe.
Les conditions d'excution

Le conditionnement des uprocs permet de dcrire leur dpendance fonctionnelle vis vis d'autres uprocs ou
ressources.
Note : il n'est pas ncessaire de traduire les contraintes d'exploitation (gestion de chemins dgrads, srialisation
force de traitements, insertion de processus techniques tels que les sauvegardes,...) par le conditionnement, la
structure propose par Dollar Universe au niveau des sessions tant ddie cet effet.
Dollar Universe propose trois types de conditionnement avec la possibilit de combiner ceux-ci au sein d'une
formule de lancement qui est interprte chaque tentative de lancement.
Dollar Universe permet d'intgrer aux conditions des rfrences aux dates de traitement, units de gestion et
sessions d'excution. Ceci permet d'identifier trs prcisment les vnements attendus par chaque condition.
Note : tous les vnements d'exploitation (absence, lancement, excution, incident sur une uproc) sont conservs
par Dollar Universe en tant qu'vnements, si l'uproc est de type mmorise. Ce sont ces vnements qui servent
l'valuation de la condition.
44 Le paramtrage
Les conditions d'excution d'une uproc sont systmatiquement examines que cette uproc s'excute au sein
d'une session ou non (sauf dans un cas particulier - cf. paragraphe "Lancement forc en fin de priode" page
67). La session ne constitue qu'un modle d'enchanement externe l'uproc.
Les diffrents types de conditions d'excution sont les suivants :
Non-simultaneit,
Enchanement,
Ressources (sauf OS400).
Caractristiques gnrales des conditions

La formulation des conditions sous Dollar Universe repose sur :
l'identification de l'vnement (excution de l'uproc conditionnante),
la formulation logique de la condition.
L'objectif de ce paragraphe est de dcrire les caractristiques communes des conditions. Ces critres gnraux
sont galement valables pour l'expression des consignes de terminaison.
Les trois principaux critres permettant d'identifier un vnement sont dcrits ci-dessous.
Contrle sur la session

Le contrle de la session est utilis dans le cadre des conditions de type "non simultanit", "enchanement",
ainsi que pour des consignes de terminaison. Il permet de dterminer quelles sont les sessions dans lesquelles
Dollar Universe doit chercher les excutions ventuelles de l'uproc vise, pour valuer la condition ou pour
supprimer l'vnement correspondant (pour les consignes).
Les choix possibles sont les suivants :
Mme session et mme excution
Ce choix permet de restreindre la recherche des vnements conditionnants (ou dtruire) au sein de
l'excution de la session dans laquelle figure l'uproc conditionne (mme numro d'excution de session).
Ainsi, si la session s'excute une deuxime fois (ventuellement en mme temps) ou si l'uproc vise
s'excute pour le compte d'une autre session, les vnements d'excution correspondants ne seront pas
considrs dans la recherche.
Note : ce choix est utile si on n'opre pas une gestion trs fine des vnements au travers des consignes de
terminaison et si on doit soumettre plusieurs fois une mme session sans que ses diffrentes occurrences
d'excution ne se perturbent (cas frquent en dmonstration).
Mme session et toutes excutions

Ce choix permet d'tendre le cadre prcdent de recherche des vnements conditionnants (ou dtruire)
toutes les occurrences d'excution de la session de l'uproc conditionne. A l'inverse de la dfinition
prcdente, ce choix permettra de prendre en compte l'ventualit d'un prcdent passage prcdent de la
session.
La session de nom
Ce choix permet de dterminer prcisment la session de recherche des vnements conditionnants (ou
dtruire). Toutes les excutions de cette session seront considres.
Note : ce choix ne doit pas tre gnralis en raison de la moindre volutivit du paramtrage concern.
Quelle que soit la session

Valeur par dfaut. Ce choix est le plus gnral et permet une recherche dans l'ensemble des sessions et en
dehors de toute session (cas d'une uproc planifie isolment).
Le paramtrage 45
Note : ce mode fonctionnement devrait tre, si possible, prfr, le conditionnement d'une uproc (traduisant la
logique applicative) tant normalement indpendant des contraintes d'exploitations prises en charge au travers des
sessions.
Contrle sur l'unit de gestion

Le contrle sur l'UG est utilis dans le cadre des conditions de type "non simultanit", "enchanement" et
"ressources" (pour certaines natures lorsque le nom de fichier ou la localisation contient le code !UG!) ainsi
que pour les consignes de terminaison. Il permet de dfinir les units de gestion sur lesquelles doivent tre
recherches les excutions de l'uproc vise.
Les choix possibles sont les suivants :
Pour un type d'units de gestion
Ce choix permet d'tendre la recherche des vnements conditionnants (ou dtruire) toutes les units
de gestion d'un type donn.
Note : ce choix ne permet pas l'analyse des dpendances d'units de gestion et il est prfrable de restreindre son
utilisation certains cas bien spcifiques (traitement vocation technique, par exemple). On lui prfrera souvent
l'utilisation du TIH dcrit ci-dessous.
Pour une unit de gestion,
Ce choix permet de restreindre la recherche des vnements conditionnants (ou dtruire) une unit de
gestion spcifique.
Note : l'identique du choix prcdent, ce choix sert traiter des cas trs spcifiques. On lui prfrera, l'utilisation
du TIH, plus volutif.
Les units rattaches : TIH

Ce choix tend la recherche des vnements conditionnants (ou dtruire) toutes les units de gestion
rattaches l'unit de gestion d'excution de l'uproc conditionne (selon le formalisme TIH).
Se reporter au paragraphe "Traitement informatique hirarchis" page 16 pour plus d'informations sur
l'utilisation du formalisme TIH.
Les exemples suivants illustrent l'utilisation possible de ces formalismes :

"{ }" permet de restreindre la recherche des vnements conditionnants (ou dtruire) l'unit de gestion
d'excution de l'uproc conditionne. Ainsi si l'uproc conditionnante s'excute pour le compte d'une
autre unit de gestion, les vnements d'excution correspondants ne seront pas considrs dans la
recherche.
Note : ce choix est le dfaut considr par Dollar Universe lors de la cration d'une condition ou d'une consigne.
"{A }" permet de restreindre la recherche des vnements conditionnants (ou dtruire) l'ensemble des
units de gestion de type "A" dpendantes de l'unit de gestion d'excution de l'uproc conditionne.
Ce mode d'expression est souvent prfrer aux deux modes prcdents (type d'UG ou UG), de par son
volutivit naturelle comme en tmoigne les deux exemples suivants :
Exemple 1 : Utilisation du formalisme { }
Une chane de traitements comptables se droule tous les mois pour le compte de l'entreprise, selon des
conditions d'excution exprimes grce au formalisme "{ }".
Suite un recentrage ou absorption d'activit, l'entreprise se scinde en deux entits distinctes faisant l'objet
de comptabilits dissocies.
Il suffit de crer une deuxime unit de gestion et de dupliquer la planification de la chane de traitements
pour que celle-ci se droule de manire cohrente pour le compte de la deuxime entit, et ce,
indpendamment de la premire.
Exemple 2 : Utilisation du formalisme {A }
46 Le paramtrage
Les mises jour d'une base de donnes commerciale sont consolides chaque mois pour chaque rgion d'une
entreprise, selon des conditions d'excution exprimes grce au formalisme "{A }".
Deux rgions sont considres jusqu' ce jour, et la prise en compte de nouvelles agences s'effectuent
simplement par la dclaration de l'unit de gestion correspondante et sa dpendance l'une des deux rgions.
Suite un accroissement sensible du nombre d'agences, une nouvelle rgion est cre. Il suffit de dclarer
l'unit de gestion correspondante, de dupliquer la planification de la chane de traitements pour le compte de
cette nouvelle rgion, en dtruisant ventuellement la dpendance de certaines agences vis vis d'une des
rgions prexistantes pour crer leur dpendance vis vis de la nouvelle rgion.
Toutes sont ncessaires

Ce choix est complmentaire des prcdents, en permettant d'indiquer si, parmi l'ensemble des units de
gestion vises, on doit rechercher la validit de la condition sur toutes les units de gestion ou sur au
moins une d'entre elles.
De par la frquence d'utilisation du choix "oui", celui-ci est considr par dfaut lors de la cration d'une
condition.
Note : cette information n'ayant aucun sens vis vis des consignes de terminaison ou des conditions de nonsimultanit, elle n'est pas propose dans les fentres correspondantes. Dans ces deux cas, les vnements sont
considrs pour l'ensemble des units de gestion dsignes.
Contrle sur la date de traitement

La priode fonctionnelle (et par consquent, la date de traitement associe chaque excution) est utilise
dans le cadre des conditions de type "enchanement" et "ressources" (pour certaines natures de ressources)
ainsi que dans le cadre des consignes de terminaison.
En fonction de la date de traitement de l'uproc conditionne, elle permet de dterminer quelle est la date de
traitement pour laquelle Dollar Universe devra chercher les excutions ventuelles de l'uproc ou de la
ressource vise (par la condition ou la consigne).
Le contrle s'effectue donc sur la comparaison entre la date de traitement de l'uproc ou de la ressource
conditionnante avec la date de traitement de l'uproc conditionne, ce qui permet au moment du pilotage de
l'uproc d'tablir la relation entre sa date de traitement et la date de traitement recherche pour l'uproc ou la
ressource conditionnante.
Depuis la version 4.1 de Dollar Universe, la priode fonctionnelle d'une uproc peut tre modifie. Dollar
Universe prend donc en charge la rsolution des conditionnements concerns.
Si l'uproc conditionnante a une priode fonctionnelle plus petite que celle de l'uproc conditionne le contrle
doit rester cohrent. A cette fin, l'oprateur "quelque soit" est utilis.
Exemple : utilisation du contrle sur la date de traitement
Une uproc A servant laborer un solde journalier de comptes clients ne peut s'excuter que si l'uproc B en
charge de l'laboration du solde mensuel s'est bien droule, le mois prcdent.
L'uproc A est dclare de priode quotidienne, l'uproc B est dclare de priode mensuelle, l'uproc A
comporte une condition stipulant que l'uproc B doit s'tre bien droule "le mois prcdent".
En pratique, chaque excution prvue pour l'uproc A, Dollar Universe traduira sa date de traitement (par
exemple, le 25 juin 2004) en une date de traitement de l'uproc B (01/05/2004) selon la formule retenue ("mois
- 1")
Note : compte tenu de leur nature, les conditions de non-simultanit s'expriment simplement en dclarant si l'on
souhaite dfinir cette non-simultanit pour la mme date de traitement ou sans considrer celle-ci.
Les units calendaires proposes pour effectuer l'valuation des dates de traitement ou cart de date de
traitement varient avec la priode fonctionnelle de rfrence de l'uproc concerne; celle-ci est
systmatiquement propose ainsi que l'anne (unit la plus grande). Si "mois" est suprieur la priode
fonctionnelle de rfrence, il est galement propos (sauf pour la semaine - pour des raisons videntes de non
compatibilit de ces deux units).
Le tableau suivant rsume les units calendaires proposes en fonction de la priode fonctionnelle de l'uproc :
Le paramtrage 47
Units calendaires
P. F.
2M
3M
4M
6M
Sans
Jour
Semaine
Dcade
Quinzaine
*
*
*
Mois
Bimestre
*
*
Trimestre
Quadrimestre
Semestre
Anne
*
*
*
*
*
*
*
*
Units calendaires proposes en fonction de la priode fonctionnelle
Note : quand l'uproc conditionnante est "sans" priode fonctionnelle (ce qui correspond une priode infinie), ce
contrle est sans objet.
Ainsi la dfinition d'une condition d'enchanement d'une uproc avec priode fonctionnelle sur une uproc sans
priode fonctionnelle sera exprime avec un contrle de la date de traitement "quelconque".
Caractristiques complmentaires
Compte utilisateur
L'identification de l'utilisateur est utilise dans le cadre des conditions de type "non-simultanit",
"enchanement" et des consignes de terminaison.
Elle permet d'indiquer Dollar Universe de restreindre la recherche des vnements viss dans l'expression de
la condition ou de la consigne ceux qui correspondent une excution pour le compte d'un utilisateur
particulier.
Le choix propos est soit un compte utilisateur quelconque (par dfaut), soit le mme compte utilisateur que le
compte de soumission de l'uproc conditionne.
Condition attendue ou exclue

Ce choix permet d'indiquer Dollar Universe si l'on considre valide la condition telle qu'exprime ou bien
son contraire.
Cette option est principalement utilise dans le cadre de l'interface caractres de Dollar Universe qui distingue
des sous conditions nommes propositions qui sont implicitement relies entre elles (au sein d'une condition)
par des ET logiques. Ceci permet de prendre la contrapose d'une proposition tout en conservant une
expression trs simple de la formule de lancement.
Exemple : utilisation du choix "exclue"
L'uproc "IU_000" ne s'excute que si l'uproc "IU_001" n'est pas en cours d'excution mais si l'uproc
"IU_002" l'est.
La description lmentaire de ces deux conditions de non-simultanit s'effectue avec les numros de
condition et de proposition "01-01" et "01-02". La deuxime condition lmentaire s'exprime avec la
caractristique "exclue"
La formule de lancement "=C01" remplit correctement la logique applicative souhaite.
Note: les interfaces graphiques et commandes ne considrent que le niveau condition dans la formule de
lancement; ds lors la caractristique exclue est quivalente une condition inverse. Notons par ailleurs que
48 Le paramtrage
Dollar Universe effectue une conversion automatique des propositions en conditions lorsque l'interface graphique
est utilise pour mettre jour les conditions d'une uproc (la cohrence est ainsi prserve avec l'interface
caractre).
Condition fatale
Lorsque l'une des conditions de la formule de lancement prsente un caractre fatal, la non vrification de
cette condition, rencontre au cours d'un pilotage, empchera toute nouvelle tentative de pilotage pour
l'excution concerne.
En effet, dans le processus d'automatisation, quand une uproc est prte tre soumise (heure et date de
planification atteinte), mais qu'une ou plusieurs conditions non fatales n'ont pas t vrifies, l'uproc est mise
en attente des vnements non survenus. Lorsque tous les vnements attendus sont intervenus et si la fentre
de lancement est respecte, l'uproc est automatiquement "re-pilote".
Dans certains cas, on sait par avance qu'une condition non vrifie un instant, le restera suffisamment
longtemps pour qu'il soit inutile de mettre en attente l'uproc laquelle elle est associe. Le caractre fatal
associe une condition sert traduire ce cas.
L'excution de l'uproc prendra alors l'tat "refus au pilotage".
Exemple : utilisation du caractre fatal d'une condition d'enchanement
Une "gestion des stocks de produits finis" est automatise par Dollar Universe. Elle doit s'enchaner avec une
uproc "saisie des B.C" pour des UG agences, et avec l'uproc "saisie des demandes d'approvisionnement" pour
des UG usines.
Elle comporte donc des conditions d'enchanement qui traduisent cette logique.
On suppose pour simplifier que les saisies de B.C. ou de demandes d'approvisionnement sont les seules
oprations qui ncessitent la rvision des stocks.
Il peut tre intressant que ces conditions d'enchanement soient fatales, dans la mesure o, si les uprocs de
saisies sont interactives, et si le moteur tourne la nuit, leur absence un moment donn du fichier historique
des vnements d'exploitation pour cette date ne risque pas de changer au cours de la nuit (sauf si des saisies
peuvent avoir lieu pendant la nuit !).
Ainsi, le processus d'automatisation n'aura pas grer inutilement l'uproc en attente et les autres uprocs
s'enchanant sur son excution ou sa non-excution pourront tre soumises plus tt.
Exemple : utilisation du caractre fatal d'une condition de non simultanit
Supposons qu'au cours d'une journe plusieurs utilisateurs aient utilis une uproc de saisie des bons de
commande qui provoque une uproc batch de traitement quotidien des commandes. Le moteur batch, lors de
son dmarrage (on suppose que le moteur batch n'est lanc qu'au del d'une certaine heure), va chercher
excuter, autant de fois que l'uproc de saisie des bons de commande a t utilise, l'uproc de traitement
quotidien des commandes. Il est clair, dans ce cas, qu'une seule excution de cette uproc est suffisante.
L'utilisation de conditions de non simultanit avec elle-mme fatale permettra de limiter automatiquement
une seule le nombre d'excution de l'uproc concerne.
Les diffrents types de conditions

Condition d'enchanement
Les conditions d'enchanement permettent de mettre en relation des uprocs fonctionnellement dpendantes,
que celles ci s'excutent sur le mme noeud ou sur des noeuds diffrents.
La finalit de cette fonction est de rechercher, parmi les vnements mmoriss, ceux qui conditionnent
l'excution de l'uproc en cours de pilotage.
Cette famille de conditions permet de mettre en relation deux uprocs et de conditionner l'excution d'une
uproc (uproc conditionne) sur une excution ou non-excution d'une autre uproc (uproc conditionnante). Les
uprocs conditionnantes et conditionnes peuvent tre la mme uproc.
Ces conditions sont paramtrables partir des critres prcdemment voqus :
Le paramtrage 49
l'unit de gestion dans laquelle ou dans lesquelles a t excute l'uproc conditionnante (cf. "Contrle sur
l'unit de gestion" page 46).
la session d'excution de l'uproc conditionnante (cf. "Contrle sur la session" page 45),
une date de traitement prcise (cf. "Contrle sur la date de traitement" page 47),
le compte utilisateur de l'excution de la tche concernant l'uproc conditionnante, qui peut aussi tre celui
de la tche concerne,
Les caractristiques : fatale ou non, attendue ou exclue.
De plus, une condition d'enchanement fait rfrence l'tat de l'uproc conditionnante dans le fichier des
vnements. Les tats possibles sont :
Termine,
Incidente,
Absente.
Note : l'option "absente" signifie que l'uproc n'est ni en attente d'excution, ni en cours d'excution, ni termine
(bien ou mal), mais ne signifie pas que l'uproc n'est pas planifie. Elle peut mme avoir dj t lance et mise en
attente d'un vnement.
Les conditions d'enchanement s'appuient donc sur les notions de date de traitement, de compte utilisateur,
d'unit de gestion et trouvent les informations qu'elles exploitent dans le fichier des vnements de Dollar
Universe. Une uproc non mmorise ne peut donc pas jouer le rle d'une uproc conditionnante dans une
condition d'enchanement.
De mme, pour que les comparaisons de dates aient un sens, les uprocs cites en rfrence doivent avoir une
priode fonctionnelle compatible avec celle de l'uproc qui contient la condition d'enchanement.
Exemple : conditions d'enchanement
L'uproc de clture comptable mensuelle ne sera excute, pour un mois donn, que si l'excution au titre du
mois prcdent est termine correctement, et si la clture annuelle de l'exercice prcdent est termine
correctement.
L'une des solutions pour exprimer cette logique consiste utiliser des conditions d'enchanement. Il faut
prvoir dans ce cas deux conditions car la traduction logique du processus dcrit ci-dessus implique la
prsence d'un ET.
Condition 01
Enchanement de l'uproc de clture mensuelle avec elle-mme sur le mois prcdent
Date de traitement : "mois - 1",
Sens proposition : "attendue".
ET Condition 02
Enchanement avec l'uproc de clture annuelle de l'exercice prcdent
Date de traitement : mme anne
Sens proposition "attendue".
La formule de lancement est donc la suivante :
=C01 ET =C02
Exemple : interdiction d'appels des applications
Une fois mise en exploitation, une application peut quelquefois ncessiter des interruptions d'utilisation
temporaires (problmes applicatifs, surcharge des ressources informatiques obligeant limiter les
applications disponibles, ...).
Cet exemple expose un moyen simple mettre en oeuvre pour bloquer rapidement une application. Il suffit de
dvelopper dans chaque application, une uproc particulire sur laquelle toutes les uprocs de l'application
s'enchanent. Cette uproc est affecte toutes les UG qui utilisent l'application qu'elle contrle. Le bloqueur
peut tre actionn par l'quipe exploitation quand cela est ncessaire.
50 Le paramtrage
L'uproc est mmorise, l'vnement concernant son excution subsiste dans le fichier des vnements aprs
excution. Elle propose deux choix qui permettent une terminaison correcte (tat termin) ou pas (tat
incident).
Dans chaque uproc de l'application on cr la condition d'enchanement suivante sur le bloqueur :
Condition nn (proposition 01)
uproc d'enchanement : le bloqueur
Etat souhait : "incident"
Sens proposition : "exclue"
De cette manire, si le bloqueur n'a pas d'article sur le fichier des vnements car il n'a jamais t excut, ou
si il y en a un dans l'tat "termin", la condition nn est vrifie et n'empche pas l'excution.
Si par contre, on le rencontre dans l'tat "incident" (obtenu volontairement pour bloquer) la condition nn
n'est pas vrifie et l'excution sera impossible.
Pour remettre en service l'application, il suffit d'actionner nouveau le bloqueur en choisissant l'option
correspondant une terminaison dans l'tat "termin" qui remplacera donc dans le fichier des vnements le
code tat "incident" bloquant.
Condition de non simultanit

Cette famille de conditions permet d'identifier un ensemble d'uprocs dont l'excution ne doit pas avoir lieu
simultanment avec celle de l'uproc lancer. Ce contrle s'appuie sur la base des vnements locale au
moment du pilotage de l'uproc conditionne (une condition de non simultanit ne peut pas tre exprime vis
vis de l'excution d'une uproc sur une machine distante). Les tats d'excution sur lesquels peut porter une
condition de non simultanit traduisent son excution (ou sa potentialit d'excution) :
Dbut (vrification des conditions),
Attente d'excution (en queue batch),
Excution en cours,
Consignes en cours.
Chaque condition s'exprime selon les caractristiques prcdemment voques :
L'unit de gestion dans laquelle ou dans lesquelles a t excute l'uproc conditionnante (cf. "Contrle sur
l'unit de gestion" page 46).
La session d'excution de l'uproc conditionnante (cf. "Contrle sur la session" page 45),
Une date de traitement prcise ou sans (cf. "Contrle sur la date de traitement" page 47),
Le compte utilisateur de l'excution de la tche concernant l'uproc conditionnante, qui peut aussi tre celui
de la tche concerne,
Les conditions de non-simultaneit sont ncessaires chaque fois que l'on souhaite :
une non excution simultane d'uprocs utilisant en mise jour les mmes fichiers,
limiter la concurrence de deux uprocs trs consommatrices de ressources, ... .

Note : rappelons qu'il peut tre utile qu'une uproc comporte une condition de non simultanit avec elle-mme.
Ceci vitera, pour des uprocs stratgiques qu'un double lancement puisse tre fait par erreur.
Les conditions de non simultanit ne sont pas rflexives et devront tre saisies dans les deux uprocs qui ne
doivent pas s'excuter en mme temps.
Exemple : conditions de non simultanit
Une uproc mensuelle de traitement de fin de mois, telle que la valorisation des factures, utilisant des fichiers
permanents comme les fichiers clients ou les fichiers taux de T.V.A., ne peut admettre en simultanit les
uprocs de mise jour de ces fichiers permanents.
Toutes les uprocs comporteront des conditions de non simultanit telles que :
Le paramtrage 51
Toute excution des traitements de valorisation exclura la possibilit de mise jour,

Inversement, toute mise jour empchera le dbut du traitement de valorisation.
Condition de ressource
Cette tape permet de dclarer un pr requis d'excution pour l'uproc, bas sur la disponibilit ou l'tat de
ressources "systme" ou logiques.
Chaque condition s'exprime selon les caractristiques prcdemment voques :
L'unit de gestion pour laquelle est dfinie la ressource (cf. "Contrle sur l'unit de gestion" page 46).
Cette notion n'a de sens que si la variable !UG! est utilise dans le nom ou la localisation de la ressource.
Une date de traitement prcise ou sans (cf. "Contrle sur la date de traitement" page 47), de mme que
prcdemment cette notion n'a de sens que si la variable !DTRAIT! est utilise dans le nom ou la
localisation de la ressource.
Si l'uproc est "sans priode fonctionnelle", la date de traitement !DTRAIT! sera traduite par 00000000.
Certaines caractristiques sont particulires aux conditions de ressources :
Une ressource permanente permet d'viter le contrle de l'attribut de la ressource. Par dfaut une
ressource est considre comme "A vrifier" : l'attribut est donc systmatiquement contrl.
Note : l'examen des conditions de ressource porte sur des ressources locales ( moins qu'elle utilise la dsignation
UNC des fichiers ou qu'elle soit variabilise, sous VMS, avec un nom logique, lui permettant de dsigner une
ressource distante).
Attribut : exist (existence), freeblocks (espace disponible), etc. Les attributs disponibles sont fonction de
la nature de la ressource.
De plus, pour les attributs quantifiables, une ressource s'value par :
Oprateur
Oprateur logique permettant de comparer des valeurs (<, >, <=, >=, =)
Valeur
Valeur de comparaison : celle-ci est exprime dans l'unit propre chaque

ressource surveille et au systme d'exploitation hte; exemple : 50000,
indique que la valeur du seuil recherch est de 50000 blocks.
Une ressource exclusive signifie qu'une seule uproc, conditionne par cette ressource, pourra s'excuter
un instant donn. Si d'autres uprocs sont conditionnes galement par cette ressource, elles resteront en
attente de la libration de la ressource. Si l'exclusivit n'est pas porte par la ressource, elle peut tre
dfinie dans la condition de ressource, elle n'est alors valable que pour la dfinition de cette condition
particulire.
Les deux quotas consomms par la condition doivent tre disponibles. Si l'un des deux quotas (ou les
deux) sont suprieurs aux quotas disponibles au moment du pilotage, l'uproc restera en attente pour
"quota insuffisant".
La dfinition des conditions de ressources peut intgrer, pour certaines natures de ressources des informations
de nature applicative (par exemple, nom de fichier intgrant des dates assimilables la date de traitement, des
expressions de type TIH ou la rfrence une UG).
Les conditions de ressources participent galement l'laboration de la formule de lancement et peuvent se
dfinir tout comme les conditions d'enchanement (avec les mmes caractristiques - en dehors l'tat).
Note : il convient de noter, qu'en dehors d'une dfinition de quota, qu'une condition de ressource exprime la
disponibilit ou la prsence d'une ressource dans un tat donn, au moment du lancement de l'uproc concerne.
Toutefois, il peut arriver pour certains type de ressources ou dans certaines circonstances d'exploitation, aprs que
la vrification ait t ralise par Dollar Universe, que sa disponibilit ou son tat voluent. Si la stabilit de l'tat
de la ressource ou sa disponibilit constitue un pr-requis pour l'excution de l'uproc, il appartient l'utilisateur de
prendre les prcautions techniques ncessaires.
52 Le paramtrage
Formule de lancement ou rseau de conditions

Rle de la formule de lancement
La formule de lancement est une expression boolenne qui rassemble les conditions d'enchanement, de
ressources et de non simultanit par des oprateurs logiques : ET, OU, =, #.
La logique traduite par cette expression est analyse lors du pilotage de l'uproc. L'analyse des conditions
rsulte principalement de l'examen du fichier des vnements.
Le lancement de l'uproc dpend du rsultat de la vrification de cette expression. La valeur logique vraie ou
fausse de la formule de lancement dtermine respectivement la possibilit ou l'impossibilit d'excuter le CL
associ l'uproc.
En cas d'impossibilit, la condition non vrifie est affiche dans la trace automate de l'excution.
Note : Les classes d'uprocs ne rentrent pas dans l'expression de la formule de lancement. Les incompatibilits
d'excution qui en rsultent sont vrifies avant que ne soit vrifie l'expression logique traduite par la formule de
lancement.
Optimisation de la formule de lancement

L'exploitation de la formule de lancement par le pilotage est optimise dans un premier temps par une analyse
purement logique de l'expression de la formule, qui dtermine le caractre principal ou non de chaque
condition. Une condition est qualifie de principale si sa non vrification entrane la non vrification complte
de la formule.
C'est le cas typique des conditions non comprises entre des niveaux de parenthses, et prcdes de ET.
Dans un deuxime temps, le pilotage dtermine le caractre vrifi ou non vrifi de chaque condition par
rapport aux vnements mmoriss. Les conditions sont examines suivant leur ordre d'apparition dans la
formule. Quand une condition est principale, et que la valeur logique dduite est contraire ce qui est requis
(vrifie pour #Cnn et non vrifie pour =Cnn), l'analyse n'est pas poursuivie, et le pilotage est refus.
Ce procd impose donc quelques conseils d'utilisation :
Placer en tte de la formule les conditions qui sont les plus difficiles raliser afin de profiter au mieux de
l'analyse optimise.
Placer au dbut de la formule, dans la mesure du possible, les conditions qui ont un caractre fatal.
L'analyse de la formule de lancement sera ainsi restreinte au maximum si la condition fatale n'est pas
vrifie.
Si une des conditions fatales est non ralise, mme si elle n'est pas principale, le moteur est inform et le
caractre fatal peut bloquer les lancements ultrieurs.
Si l'organisation de la formule ne prend pas en compte cette prcaution, tout dcrochement prmatur (avant
l'analyse des conditions fatales) empche la dcouverte d'une ventuelle condition fatale non ralise, ce qui
conduit des tentatives de lancement successives inutiles.
Note : lors du pilotage de l'uproc, Dollar Universe mmorise l'vnement bloquant pour le lancement de l'uproc.
Toute intervention dans le contrle d'exploitation sur un autre vnement demeure sans effet. Par ailleurs, chaque
nouveau pilotage procde un nouvel examen systmatique de l'ensemble des conditions (celles pralablement
vrifies peuvent ne plus l'tre) de telle sorte que les ventuelles modifications sont prise en compte en temps rel,
l'exception toutefois de l'analyse du TIH.
Limites de la formule de lancement

La formule de lancement est limite 99 conditions, quelque soit le type de conditions.
Le paramtrage 53
Consignes de terminaison
Rle
Les consignes de terminaison d'une uproc sont effectues lorsque son excution se termine correctement (tat
Termin).
Elles permettent d'identifier les "purges" effectuer sur la base des vnements, c'est dire, les mmorisations
d'excutions antrieures d'uprocs effacer, que celles-ci soient termines correctement (tat termin) ou de
manire anormale (tat incident).
L'utilisation des consignes de terminaison peut tre motive :
par des besoins applicatifs,
par le souci de limiter le volume des vnements d'excution mmoriss.
Dans un contexte parfait, il devrait y avoir pour l'ensemble des uprocs mmorises gres par Dollar Universe
au moins une autre uproc charge d'effacer une quelconque de ses excutions dans la base des vnements.
Note : comme pour les conditions d'enchanement (dont les consignes constituent le pendant) la priode
fonctionnelle (format de la date de traitement) de l'uproc purger doit tre suprieure ou gale celle de l'uproc
la quelle est affecte la consigne ("mois" suprieure "dcade" suprieure "jour"...).
L'usage de consignes de terminaison n'est pas obligatoire, la mmorisation de l'uproc permettant de raliser
une gestion automatique des vnements mmoriss. Toutefois, les consignes de terminaison permettent
d'intervenir sur les vnements dans des cas trs spcifiques (destruction d'un vnement particulier par
exemple).
Exemple : consignes de terminaison
Une application batch ne peut s'excuter que si l'application interactive a t "ferme".
Une uproc de fermeture est donc dfinie avec la caractristique mmorise. Elle conditionnera tous les
traitements batch de l'application.
Une uproc d'ouverture est galement dfinie, avec comme consigne de terminaison, la destruction de
l'vnement d'exploitation relatif l'excution de l'uproc de fermeture.
Ainsi lorsque l'ouverture de l'application sera ralise, la mmorisation de l'uproc de fermeture sera dtruite
et aucun traitement batch ne pourra plus tre soumis.
Note : les consignes de terminaison ont un impact limit au noeud sur lequel elles sont effectues. Dans le cas
d'un conditionnement local, la consigne de terminaison purge l'vnement dans la base locale.
Fonctionnement rseau
Dans le cas d'un conditionnement rseau, l'vnement est inscrit la fois dans la base locale (celle de l'uproc
conditionne) et dans la base distante (celle de l'uproc conditionnante). Si une consigne de terminaison (ou une
suppression d'vnement) est effectue sur le noeud local (celui de l'uproc conditionne), l'vnement distant
persistera.
Cependant si une consigne de terminaison (ou une suppression d'vnement) est effectue sur le noeud distant
(celui de l'uproc conditionnante) alors tous les vnements inscrits sur les bases locales (pour les uprocs
conditionnes) seront purgs selon la consigne dcrite.
Rgle gnrale :
Toute modification de l'vnement sur le noeud distant (cration, modification, suppression ou purge par une
consigne) est transmis tous les noeuds qui ont mis, sur cet vnement, une demande. La correspondance est
ensuite examine localement entre l'tat demand et l'tat reu :
pour effectuer (ou non) le pilotage de l'uproc conditionne,
pour purger (ou non) l'vnement.
54 Le paramtrage
Les sessions
Dfinition
Une session est une arborescence d'uprocs homognes, non pas uniquement au plan fonctionnel (possibilit de
rassembler des traitements appartenant plusieurs applications ou domaines diffrents), mais en termes de
contraintes d'exploitation.
Une session est en fait un modle d'enchanement externe aux conditions d'excution des uprocs de la session.
La session prdfini ainsi un ordre de lancement, sachant qu' chaque tape Dollar Universe vrifie
systmatiquement les conditions d'excution des uprocs que la session lui indique de lancer.
La session offre un certain nombre de facilits, notamment en matire de :
Planification, pour laquelle la session constitue un lment simplificateur.

En effet, la planification de la session suffit pour que toutes les autres uprocs appartenant la session
soient automatiquement enchanes. Toutefois, en cas de besoin, une ou plusieurs des uprocs constitutives
de la session peuvent bnficier, par exception, d'une planification spcifique.
Maintenance de l'ordre de soumission des procdures. En effet, la dfinition des sessions est
compltement externe aux uprocs. En cas d'volution de la structure des enchanements, il n'est pas
ncessaire d'intervenir dans le langage de commande ou le paramtrage des uprocs concernes. Ceci
entrane une rduction du nombre d'interventions sur les uprocs et contribue donc une meilleure
fiabilit.
Contrle d'exploitation. Prsent dans toutes les fonctions de contrle d'exploitation, le concept de session
permet, simplement, de focaliser les actions de contrle sur des ensembles d'uprocs que la seule logique
applicative (utilisation de la notion d'application de Dollar Universe) ne traduit pas compltement.
Exemple : constitution d'une session

Une socit effectue de faon hebdomadaire une chane de comptabilit fournisseur.
L'dition des chques fournisseur est prise en compte par une application spcifique de mise en forme et
d'dition de chques.
Du point de vue de l'exploitation, la fonction n'est remplie que si les chques sont effectivement mis. La
session concrtise le regroupement des deux applications. Une session pourra donc tre cre pour traduire
cette ralit.
Codification
Une session est identifie par un code sur dix caractres alphanumriques ne comportant aucune contrainte
particulire.
Structure des sessions

Les liens entre les traitements mis en oeuvre par les sessions sont dcrits dans la figure suivante.
Niveau n
T1
OK
T2
T6
T3
KO
T4
T7
T5
T5
Niveau n+1
Niveau n+2
T8
Structure d'une session
Le paramtrage 55
Une session commence toujours par une seule uproc appele en-tte de session.
Ces liens permettent de dfinir des relations hirarchiques de type mre - fille. L'uproc du niveau n sera
appele mre des uprocs de niveau n+1 appeles uprocs filles. Chacune des uprocs dpendantes d'une mme
mre un mme niveau est appele uproc soeur. La session permet ainsi de dfinir des arborescences de
traitements complexes.
Une mme uproc peut apparatre plusieurs fois dans l'arborescence, des niveaux diffrents ou au mme
niveau.
L'ensemble des liens ainsi dfinis traduit l'organisation et le squencement d'exploitation des traitements et ne
se substitue en aucun cas aux liens fonctionnels que traduisent les conditions logiques dfinies au niveau des
uprocs. Il peut se faire qu'une partie de la structure d'une session soit dj partiellement traduite par ces
conditions et plus particulirement les conditions d'enchanement. La superposition de ces deux types de liens
est sans importance.
Note : en aucun cas, il ne convient de supprimer, au sein des uprocs, des conditions d'enchanement sous prtexte
qu'elles sont traduites dans le cadre de l'arborescence dfinie dans la session. L'existence des sessions se justifie,
entre autres, par la ncessit de dissocier les contraintes d'exploitation (traduites par l'arborescence de la session)
des contraintes logiques et applicatives qui sont dfinies au niveau de l'uproc. Les contraintes d'exploitation (non
excution simultane de deux traitements trs consommateurs de ressources par exemple) peuvent voluer
indpendamment des contraintes applicatives. Il est donc important pour des questions de simplicit et de fiabilit
des oprations de maintenance sur les processus d'exploitation de ne pas mlanger ces deux types de contraintes.
Caractristiques de planification
Les uprocs d'une session hritent de la planification, des caractristiques techniques (compte de soumission,
queue d'excution par exemple) ou fonctionnelle (date de traitement par exemple) de l'uproc en-tte de la
session (uproc situe au sommet de l'arborescence). Toutefois, dans le cas o il est souhaitable que ces
caractristiques ne soient pas reconduites, pour l'uproc concerne, une tche de type "provoque" ou
"optionnelle" devra tre cre, en mentionnant le nom et la version de la session concerne, le nom et la
version de l'uproc cible et l'unit de gestion de la tche initiale.
Des caractristiques propres pourront alors lui tre associes. Ainsi :
la dclaration d'une tche provoque permet, par exemple, de diffrer l'excution de la tche vers une
fentre de lancement prcise ou d'interdire cette excution pendant une plage horaire dtermine. Les
tches de la session dont l'excution dpend de celle-ci seront diffres d'autant,
la dclaration d'une tche optionnelle permet de dfinir pour cette tche des conditions de planification
particulires diffrentes de celles de la session. Dans ce cas, la session sera excute normalement, sauf la
tche optionnelle, si elle n'est pas planifie pour le jour et l'heure d'excution concern. Dans ce cas, la
non-excution sera assimile une fin normale, la session se poursuivant en exploitant le chemin normal
attach la tche non excute.
Ces nouvelles caractristiques seront reconduites sur les uprocs suivantes de la session. Dans le cas d'une
tche optionnelle, les caractristiques seront reconduites que la tche optionnelle s'excute ou non.
Note : la session peut galement tre utilise pour prendre en compte les contraintes d'exploitation, dissociant du
mme coup ce type de contraintes des contraintes applicatives prises en charge dans le cadre du conditionnement.
La session ne se substitue pas aux conditions d'excution des uprocs, ainsi, malgr l'ordre de soumission
impos par la session, Dollar Universe ralise un pilotage (vrification de la formule de lancement) de
chacune des uprocs qu'il a soumettre au sein d'une session.
Chemins "normal" et "erreur"

Une session est un regroupement d'uprocs, ordonn sous forme d'arborescence.
56 Le paramtrage
La session permet, en fonction de l'tat de l'excution, de distinguer des chemins diffrents au sein de
l'arborescence dfinie : le chemin normal lorsque l'uproc se termine dans l'tat Termin, le chemin erreur
lorsque l'uproc se termine dans l'tat Incident.
Ces possibilits attaches la session permettent d'envisager, lors d'un incident d'exploitation, de mettre en
oeuvre une squence de traitements dgrade au lieu d'une interruption pure et simple de la squence.
Environnement d'excution
L'unit de gestion d'excution de la session est normalement dtermine lors de la cration de la tche ou du
lancement o le triplet "session uproc en-tte unit de gestion" est dfini. L'unit de gestion est alors
reconduite par hritage comme environnement d'excution des uprocs suivantes de la session.
Il est cependant possible, pour chacune des uprocs de la session (sauf l'en-tte), de spcifier sa ou ses units de
gestion d'excution, en prcisant :
le code de l'unit de gestion,
ou un type d'unit de gestion,
ou une expression de type traitement informatique hirarchis (TIH).
Le TIH utilise les dpendances entre les units de gestion. Il est utilis dans le cadre des sessions et des
conditions pour dfinir un ensemble d'units de gestion cibles dans les ordres correspondants de
dclenchement ou de synchronisation des traitements. Se reportera au paragraphe "Traitement informatique
hirarchis" page 16 pour de plus amples informations sur l'utilisation du TIH.
L'exemple suivant illustre les possibilits offertes par le TIH.
Exemple : utilisation du TIH dans la dfinition de sessions
Supposons une organisation btie autour d'un sige administratif, de direction rgionales et d'agences
locales.
Les agences sont regroupes par rgion sous des directions rgionales.
Lors d'une excution d'une uproc sur une unit de gestion de type R (direction rgionale, l'expression "{A }"
signifie toutes les units de gestion de type A (agences) qui dpendent de la direction rgionale.
Cette possibilit de dsigner de faon gnrique des excutions des uprocs vers des units de gestion cibles
permet de concevoir des processus gnraux, s'adaptant automatiquement aux modifications de l'architecture
logique de l'environnement. Par exemple, l'ajout d'une unit de gestion agence sera transparente dans une
session dont un des objectifs serait de soumettre un mme traitement, partir d'une direction rgionale vers
toutes les agences qui dpendent d'elle.
Note : par dfaut, le formalisme TIH retenu sera "{ }" permettant une excution de l'ensemble des uprocs d'une
session au titre d'une mme unit de gestion.
Si une unit de gestion d'excution a t explicitement dsigne au niveau d'une uproc de la session, toutes les
uprocs filles hriteront de cette nouvelle unit de gestion d'excution (ou de cet ensemble d'units de gestion).
Reconduction de la valeur des variables dune uproc

La reconduction de la valeur des variables dune uproc au sein dune session nest pas automatique. Par
dfaut, si rien nest fait, la valeur de la variable nest pas reconduite et lautomate applique les rgles de
valorisation par dfaut.
La reconduction de la valeur dexcution luproc fille peut tre demande en excutant la commande uxset
var dans le CL de luproc ou dans le post traitement U_POST_UPROC. Trois types de reconduction de
valeurs dexcution peuvent tre demands :
une reconduction globale de la valeur des variables de luproc mre,
ne reconduire que les valeurs des variables de luproc mre connues de luproc fille, cest dire
lintersection entre la liste des variables reues et celles de luproc fille,
Le paramtrage 57
en citant explicitement les variables qui doivent tre reconduites et leur valeur.
(cf. Manuel de l'interface commande pour la syntaxe d'utilisation de cette commande).
Limites de stockage
Le nombre total d'uprocs gres dans une session est de 140. A chaque niveau de l'arborescence, on peut
dclarer jusqu' 20 uprocs dans le cas d'une terminaison normale et 20 uprocs dans le cas d'une terminaison
anormale de l'uproc dite uproc mre.
Note : Si une mme uproc figure plusieurs reprises dans une session, chacune de ses occurrences diminue de 1
unit le nombre total de traitements disponibles dans la session ( concurrence de 140).
58 Le paramtrage
La planification
La planification des tches constitue le point d'entre de l'automatisation, et donc, une de ses fonctions
majeures.
Elle permet, en fonction de calendriers et des rgles de planification (algorithmes de calculs pr dfinis), le
calcul automatique par le moteur batch des dates et heures de planification des diverses tches recenses.
Note : l'obtention d'une date et heure de planification ne signifie pas systmatiquement l'excution de la tche
l'heure de dbut ou mme dans la priode de planification (intervalle de temps sparant la date de dbut et la date
de fin), l'excution effective tant conditionne par les conditions attaches l'uproc concerne.
Les calendriers
Environnement d'application du calendrier
Les calendriers constituent sous Dollar Universe un rfrentiel de temps et en aucun cas un chancier
d'exploitation.
Dollar Universe impose la dfinition d'au moins un calendrier par noeud et par espace appel "calendrier
gnral". Dans ce cas, toutes les units de gestion prsentes sur le noeud bnficient du mme calendrier.
Afin de tenir compte au mieux des particularits de chaque entit, Dollar Universe permet de gnrer des
calendriers propres des units de gestion ou des types d'units de gestion. Pour chacun des espaces
(application, intgration, simulation, exploitation) dans lesquels une unit de gestion est prsente, un
calendrier spcifique peut tre dfini.
Afin de ne pas dupliquer, de ce fait, les calendriers autant de fois qu'il y a d'units de gestion, la gestion des
calendriers procde par exception par rapport au calendrier gnral dfini au niveau du noeud. Ainsi, les
tches seront planifies en fonction des informations contenues :
dans le calendrier spcifique de l'unit de gestion de la tche concerne,
ou, par dfaut, dans le calendrier spcifique du type de l'unit de gestion,
ou, par dfaut, dans le calendrier gnral de l'espace.

Note: toute UG sous la forme x00 (1 lettre , 2 zros et 7 espaces) est considre comme type d'UG dans les
calendriers.
L'ensemble des possibilits offertes permet d'adapter aussi finement que ncessaire les calendriers aux besoins
d'exploitation de chacun des environnements. Toutefois, il est recommand de ne pas multiplier inutilement le
nombre de calendriers dfinis, leur gestion pouvant, quand le nombre d'unit de gestion rsidant sur un noeud
est lev, devenir fastidieuse et inutile.
La planification 59
Modle de calendrier
Dollar Universe permet de crer des modles de calendriers.
A partir de ces modles de calendriers, des calendriers pourront tre gnrs pour des groupes d'units de
gestion prsentant les mmes besoins.
Seul un modle de calendrier peut donc tre distribu sur un ensemble d'units de gestion ou de types d'units
de gestion. Il devient alors le calendrier des units de gestion cibles (le type d'UG est traduit en autant d'UG
cibles).
Un modle de calendrier peut donc devenir un calendrier d'une UG spcifique mais pas un calendrier d'un type
d'UG.
Note : de mme que pour les tches, la distribution des calendriers ne peut tre effectue qu' partir de modles de
calendriers.
Gnration des jours fris

Dollar Universe permet de gnrer des calendriers avec ou sans les jours fris franais. La dfinition du
calendrier avec les jours fris franais considre les jours suivants :
1er janvier,
Lundi de pques,
1er mai,
8 mai,
Jeudi de l'ascension,
Lundi de Pentecte,
14 juillet,
15 aot,
1er novembre,
11 novembre,
25 dcembre.
La gnration des jours fris franais inclue des algorithmes complexes (calcul du jour de pques), elle n'est
pas base sur un fichier externe de dates ventuellement modifiables. Le processus ne peut donc pas tre
adapt aux jours fris d'un autre pays. Pour ce faire, il est ncessaire de gnrer un modle de calendrier sans
jour fri et de le modifier pour prendre en compte les besoins propres chaque pays. Les distributions
ultrieures de ce calendrier (modle) de base permettront d'viter la rptitivit d'une telle opration manuelle.
Etendue du calendrier
L'tendue maximum d'un calendrier est de 25 ans.
Pour l'tendue minimum, il convient de prendre en compte les exigences induites par les rgles de
planification utilises. Afin de pouvoir effectuer les calculs ncessaires (par exemple, dans le cas o un
algorithme de planification utilise une priode annuelle), le calendrier doit dbuter au moins un an avant la
date laquelle le calendrier est utilis par le calculateur et doit s'tendre sur quatre ans au moins (calcul des
deux prochaines dates de passage).
La gnration d'un calendrier doit tre conforme au schma suivant:
60 La planification
anne n-1
anne n
anne n+1
anne n+2
Date de
rfrence
Etendue minimum d'un calendrier
Note : Dollar Universe permet de crer de nouvelles annes sur un calendrier existant. Si certaines annes existent
dj, les nouvelles annes gnres annulent et remplacent les anciennes.
Type des jours

La dfinition des calendriers accepte trois types de jours :
Ouvr,
Chm,
Fri.
Les jours chms sont calculs automatiquement partir d'un masque standard de semaine. Ce masque est
obtenu en dfinissant pour chaque jour de la semaine le type associ.
Il est possible de modifier, par la suite, jour par jour, en fonction des besoins, le type de certains jours du
calendrier.
Les types de jour d'excution : "ouvr", "chm" ou "fri" peuvent tre diffrencis par les fonctions de
planification de Dollar Universe, ils jouent par consquent des rles distincts.
Impact des modifications d'un calendrier

La modification d'un calendrier est une opration dlicate dans la mesure o elle peut impacter le processus
d'exploitation.
Pour toute opration de mise jour d'un calendrier (cration, modification, suppression, transfert,
distribution,...) Dollar Universe procde une rvision systmatique et immdiate des tches d'exploitation
concernes par le calendrier vis (celles travaillant pour l'unit de gestion du calendrier ou pour des units de
gestion de mme type que celui du calendrier).
Dans le cas particulier du calendrier gnral du noeud, ce sont toutes les tches qui sont rvises.
Exemple : report d'une exploitation complte par mise jour d'un calendrier
On considre dans cet exemple un ensemble de tches planifies tous les jours ouvrs.
Certaines oprations techniques, sur le systme d'exploitation par exemple, peuvent engendrer une
indisponibilit de dure relativement longue obligeant le service d'exploitation diffrer la production d'un
jour (du vendredi au samedi, par exemple).
La fermeture du vendredi (dclaration en jour chm) et l'ouverture du samedi (dclaration en jour ouvr)
provoquera un report de l'ensemble des tches concernes par ce calendrier du vendredi au samedi.
Les rgles de planification

Dfinition
Une rgle est un algorithme permettant de traduire une priodicit souhaite de l'excution d'une tche.
Une rgle de planification, identifie par un code de huit caractres, est caractrise par :
Une priodicit : comprenant un nombre de jour, semaine ou mois,
La planification 61
Un dcalage en nombre de jours ouvrs ou calendaires partir du dbut ou de la fin de la priode

considre prcdemment,
Un masque d'autorisation pour chaque jour de la semaine suivant que celui-ci est ouvr, chm ou fri,
Un sens de report (+ ou -) permettant de dcaler la date relle d'excution dans le pass ou le futur, si
l'application de la rgle sur le calendrier dsigne un jour non autoris (fri, chm, ...).
Les rgles de planification permettent de simplifier la dfinition des caractristiques de planification des
tches. Par utilisation de ces rgles, un nombre extrmement limit de calendriers est ncessaire. Un ensemble
de rgles de planification est livr avec Dollar Universe, d'autres rgles peuvent tre dfinies en fonction de
chaque besoin.
Une rgle est affecte une (ou plusieurs) tche. Plusieurs rgles peuvent tre affectes une mme tche. Ce
processus d'affectation est une copie de la rgle au sein de la tche. La rgle copie devient indpendante de la
rgle d'origine. Ainsi une modification de la rgle ne modifie pas la planification des tches dfinie partir de
cette mme rgle. L'utilisateur peut cependant affecter manuellement la rgle aux tches.
Ce mode de gestion est retenu pour allger les oprations de manipulation et parce que les rgles voluent peu.
La distribution des rgles n'est ainsi pas ncessaire.
Une fois affectes aux tches, les rgles travaillent sur le calendrier de l'unit de gestion de la tche (si celui-ci
n'existe pas, celui du type de l'unit de gestion puis le calendrier gnral du noeud sont recherchs).
Les rgles sont dfinies, au sein d'une socit, indpendamment des espaces.
Exemples
Tous les jours ouvrs
Priode
Jour
Nombre
Dcalage
Jours
Calendaires
Sens d'analyse
+ ( partir du dbut)
Sens du report
Aucun
Autorisations
Lun
Mar
Mer
Jeu
Ven
Sam
Dim
Ouvr chm fri
ONN
ONN
ONN
ONN
ONN
ONN
ONN
Dans ce cas les informations concernant "jours ouvrs", "sens d'analyse", "sens du report" peuvent tre
modifies mais seront sans effet.
Tous les jours chms ou fris
Priode
Jour
Nombre
Dcalage
Jours
Calendaires
Sens d'analyse
+ ( partir du dbut)
Sens du report
Aucun
Autorisations
Lun
Mar
Mer
Jeu
Ven
Sam
Dim
Ouvr chm fri
NOO
NOO
NOO
NOO
NOO
NOO
NOO
Dans ce cas les informations concernant "jours ouvrs", "sens d'analyse", "sens du report" peuvent tre
modifies mais seront sans effet.
Tous les 3me jours ouvrs du mois, avec report ventuel au jour suivant
62 La planification
Priode
Jour
Nombre
Dcalage
Jours
Ouvrs
Sens d'analyse
+ ( partir du dbut)
Sens du report
+ (suivant)
Autorisations
Lun
Mar
Mer
Jeu
Ven
Sam
Dim
Ouvr chm fri
ONN
ONN
ONN
ONN
ONN
ONN
ONN
La rgle "tous les 3me jours ouvrs avant la fin du mois, avec report ventuel au jour suivant" se serait
exprime de la mme faon en modifiant seulement le sens d'analyse de "+" en "-".
Tous les mardi et quand le mardi est chm report au jour suivant
Priode
Semaine
Nombre
Dcalage
Jours
Calendaires
Sens d'analyse
+ ( partir du dbut)
Sens du report
+ (suivant)
Autorisations
Lun
Mar
Mer
Jeu
Ven
Sam
Dim
Ouvr chm fri
ONN
ONN
ONN
ONN
ONN
ONN
ONN
Cette rgle aurait galement pu s'exprimer en donnant au paramtre "a lancer les" la valeur 5 et au paramtre
"sens d'analyse" la valeur "-".
Tous les premiers mardis ouvrs de chaque mois
Priode
Mois
Nombre
Dcalage
Jours
Ouvrs
Sens d'analyse
+ ( partir du dbut)
Sens du report
+ (suivant)
Autorisations
Lun
Mar
Mer
Jeu
Ven
Sam
Dim
Ouvr chm fri
NNN
ONN
NNN
NNN
NNN
NNN
NNN
La rgle "tous les derniers mardis ouvrs de chaque mois" s'extrapole de l'exemple au "sens d'analyse" prs.
Les tches d'exploitation

Dfinition
Une tche d'exploitation correspond l'excution d'une uproc (un traitement) sur une unit de gestion (un
environnement, c'est dire, le plus souvent, des donnes).
Par extension, on appellera galement tche l'excution d'une session sur une unit de gestion.
Une tche est donc codifie par la concatnation du code de l'uproc et/ou de la session dont elle est issue et du
code de l'unit de gestion pour laquelle elle doit tre excute.
Dollar Universe distingue trois types de tches :
La planification 63
Planifie : elle bnficie d'une planification complte (rgle et/ou dates explicites) et par consquent elle
est planifie automatiquement par le calculateur.
Provoque : elle n'est pas planifie en dehors de l'expression d'une fentre de lancement, partir du
moment o elle aura t provoque (par une commande ddie ou par le biais d'une session).
Optionnelle : elle est utilise uniquement pour planifier une uproc au sein d'une session selon ses propres
rgles de planification (ex : une tche optionnelle peut tre dfinie pour qu'une uproc ne s'excute que les
vendredi, alors que la session laquelle elle appartient est journalire; en dehors du vendredi, la session
s'excute comme si l'uproc n'y figurait pas).
Il existe ainsi principalement trois possibilits pour effectuer la soumission d'une tche :
partir des diverses commandes de dclenchement fournies (cf. manuel de l'interface commande),
partir d'une fonction interactive (les lancements), permettant d'intervenir sur les travaux batch planifis
(sans modifier leur planification proprement dite),
automatiquement au travers du moteur batch, qui se substitue alors l'oprateur humain en agissant
conformment la planification prvisionnelle des tches.
Modle de tche
Pour prendre en compte des architectures rparties, possdant de nombreuses units de gestion, et par
consquent ncessitant de rpliquer une mme tche autant de fois que d'environnements d'excution
existants, Dollar Universe gre des modles de tche.
L'objet d'un modle de tche est de dfinir un paramtrage de rfrence non excutable (sur une machine
centrale, par exemple), qui sera distribu sur des units de gestion cibles.
Un modle de tche peut tre dfini pour n'importe quel type de tche : provoque, planifie, optionnelle.
Le modle de tche est transform en tche (adjonction du code de l'unit de gestion d'excution) au moment
de sa distribution vers une unit de gestion et sera donc excutable sur cette unit de gestion. Seuls les
modles de tches peuvent tre distribus.
Note : les uprocs et les sessions ne sont pas des objets excutables; ils sont indpendants de l'environnement
d'excution. C'est la raison pour laquelle ils n'acceptent pas cette notion de modle.
Diffrents types de tches

Tche planifie
Une tche planifie bnficie de toutes les facilits disponibles en matire de planification prvisionnelle dans
Dollar Universe.
Les rgles de planification appliques au calendrier de l'unit de gestion permettront d'excuter cette tche de
manire rcurrente (tous les 3me jours ouvrs de chaque mois, tous les mardis, ...).
Pour prendre en compte des besoins alatoires de soumission, il est galement possible de dfinir de manire
explicite, un ensemble de dates d'excution et de dates d'interdiction.
Tche provoque
Une tche provoque peut tre dfinie pour une uproc ou une session sur une unit de gestion ou bien pour
une uproc au sein d'une session sur une unit de gestion. Une tche provoque est soumise :
la demande,
partir d'une autre tche,
via des commandes spcifiques de Dollar Universe
64 La planification
ou via une session.
Ces tches peuvent tre soumises sur des units de gestion ventuellement diffrentes de l'unit de gestion de
la tche qui les soumet. L'ensemble de leurs paramtres d'excution sont normalement reconduits partir de
ceux de la tche provocante. Toutefois, il est possible :
de dfinir des paramtres spcifiques pour la soumission d'une tche dans un environnement donn,
de dsynchroniser la demande de soumission de la tche de son excution effective. Cette possibilit

autorise, pour des tches batch non urgentes de diffrer leur excution vers des plages horaires de moindre
charge.
Caractristiques techniques d'excution

Les tches provoques permettent de spcifier, des caractristiques techniques particulires pour une uproc au
sein d'une session.
Par dfaut, seule l'uproc en-tte de session est planifie, et les caractristiques techniques de la tche sont
automatiquement propages sur les autres uprocs de la session (principe d'hritage).
La dfinition d'une tche provoque pour une uproc au sein d'une session permet de modifier les
caractristiques techniques de la tche par les donnes de la tche provoque. Ainsi, par exemple, la priorit,
la queue d'excution ou le compte de soumission peuvent tre modifis.
Note : ces modifications sont appliques l'uproc vise et aux uprocs qui lui succdent (par principe d'hritage). Il
en va de mme du calcul de la date de traitement.
Excution diffre
La dclaration d'une tche provoque dans les fonctions de planification permet de transformer un dpart
immdiat (via une commande de dclenchement, par exemple), en une excution diffre sur une fentre de
lancement de la tche provoque (cf. "Horaires d'une tche provoque" page 69).
Tche optionnelle
Une tche optionnelle est une tche dont la planification ne suit pas les mmes rgles que celles de la session
dans son ensemble (elle ne peut donc concerner qu'une uproc au sein d'une session).
Leur caractre "optionnel" provoque au cours de l'excution de la session, l'examen de leur planification
spcifique. Ainsi, si les caractristiques de planification de la tche optionnelle ne correspondent pas celles
de la session, la tche sera purement et simplement ignore dans l'arborescence globale. Ceci permet, par
exemple, d'insrer une tche hebdomadaire dans une session quotidienne.
La planification des tches optionnelles suit les mmes rgles que celles des tches planifies.
Note : la dfinition d'une tche optionnelle doit faire rfrence la session laquelle elle appartient.
Caractristiques techniques communes

La dfinition des tches va au del de la seule planification de travaux en autorisant la dclaration de
l'ensemble de ceux-ci avec leurs caractristiques fonctionnelles et techniques d'exploitation.
Il est noter que ces caractristiques sont fonction de l'environnement d'excution (unit de gestion)
permettant d'adapter les tches d'exploitation chacun de ces environnements.
Compte utilisateur
Le compte utilisateur est le username (UID) de l'utilisateur pour lequel la tche doit tre excute. Ce
paramtre est obligatoire. L'utilisateur doit pralablement avoir t dfini dans la table des utilisateurs de
Dollar Universe.
Rappelons que Dollar Universe adapte automatiquement le compte de soumission lors des oprations de
transfert ou de distribution, par l'intermdiaire du code auteur.
La planification 65
Description de travail
Cette information n'est utilise que dans le cadre de l'environnement OS400; elle permet de spcifier la jobd
(description d'un travail). Par dfaut, elle est valorise *USER signifiant que la jobd du compte de
soumission est considre. La saisie d'une autre valeur permet ainsi d'outrepasser la jobd habituelle de ce
compte de soumission.
Queue batch
Cette information permet de spcifier la queue batch dans laquelle doit tre excute la tche. Cette queue
batch doit exister pour le noeud choisi.
Sous VMS, elle peut tre gnrique ou physique et exprime sous la forme d'un nom logique.
Sous OS400, elle correspond la notion de jobq et a la valeur *jobd par dfaut. Une autre valeur peut
bien videmment tre saisie pour spcifier une jobq diffrente de celle renseigne dans la description de
travail.
Sous UNIX ou Windows, elle n'a d'effet que dans le cas d'une utilisation conjointe de Dollar Universe et
de DQM (distributed queue management). Dans ce cas, elle peut aussi bien dsigner une file d'attente
"physique" que "gnrique".
Priorit
C'est la priorit d'ordonnancement dans la queue batch. Ce niveau de priorit peut prendre des valeurs
comprises entre 1 et 255. La valeur prise par dfaut est 100. Cette information n'est pas utilise en
environnement OS400 et n'a d'effet en environnement Windows ou UNIX que dans le cas de l'utilisation de
DQM (distributed queue management).
Note: la priorit n'a pas pour vocation de dfinir une priorit d'excution mais bien un ordre prfrentiel de
soumission lorsque les travaux sont en attente dans la queue batch.
Imprimante
Dollar Universe permet la slection de l'imprimante de sortie des rsultats d'excution de la tche. Ce code est
le nom logique sur quatre caractres de la queue d'impression ddie.
Sous OS400, Windows et UNIX cette information n'est pas utilise.
Sous VMS, cette information permet la saisie d'un nom logique (nom de variable d'environnement) sur
quatre caractres dfinissant la queue d'impression qui sera ddie au travail concern. Cette information
ne reprsente pas obligatoirement une imprimante physique. Elle peut identifier un spool d'impression.
Relance automatique (mode restart)

Le positionnement de cet indicateur signifie que la tche sera redmarre automatiquement en cas d'arrt de
fonctionnement du systme d'exploitation, dans la mesure o la gestion de files d'attente de travaux de ce
dernier le permet.
Sous OS400, cette fonction n'est pas disponible.
Sous VMS, elle correspond l'option systme /restart, permettant de reprendre automatiquement le travail
concern en cas d'arrt machine (et uniquement dans ce cas l).
Sous UNIX ou Windows, cette information est sans effet sans la prsence de DQM (distributed queue
management) conjointement Dollar Universe.
Note : il pourra s'avrer utile de prvoir dans le traitement les points de reprise requis, grce au jalonnement
propos soit par le systme d'exploitation, soit par Dollar Universe.
66 La planification
Lancement forc en fin de priode

Ds lors que la formule de lancement n'est pas vrifie (et en l'absence de condition fatale), Dollar Universe
met le lancement dans l'tat "Attente d'vnement". A la fin de la fentre de lancement, le lancement est par
dfaut mis dans l'tat "horaire dpass" de telle sorte qu'il ne participe plus l'exploitation courante. Il est
alors ncessaire d'oprer une intervention manuelle sur ce lancement pour le ractiver (en lui donnant un
nouveau "crdit" d'heure).
Le positionnement de l'indicateur "lancement forc en fin de priode", provoque en fin d'intervalle de pilotage
de la tche un lancement systmatique.
Note : cette information est dissocier de l'option "lancement sans pilotage" qu'il est possible d'utiliser dans le
cadre d'un lancement interactif ou dans les oprations de reprise.
Cet indicateur doit bien videmment tre utilis avec prcaution, surtout quand la tche considre fait
rfrence une uproc ayant des conditions de non-simultaneit.
Contrle centralis d'une tche

Le positionnement de cet indicateur permet la "remonte" des informations attaches l'excution de la tche
(au moment de son dmarrage et de sa terminaison) sur le noeud dclar comme noeud de contrle dans la
table des noeuds de Dollar Universe (cf. paragraphe "Contrle centralis" page 22).
Pour des raisons de consommations des ressources rseau, et parce que les anomalies signifies dans une trace
d'excution systme correspondent le plus souvent des problmes ponctuels ncessitant une intervention
locale, les "log" correspondants ne sont pas centraliss.
Variables d'une tche

Les variables dune tche sont choisies parmi les variables de luproc qui identifie la tche. Dans le cas dune
session :
si la tche est planifie, les variables de la tche seront choisies parmi celles de luproc entte de session,
si la tche est optionnelle, les variables de la tche seront choisies parmi celles de luproc de la tche,
si la tche est provoque, selon quelle porte sur toute la session ou seulement sur une uproc elle se
conformera lun des deux cas cits ci dessus.
Dans le cas dun lancement, si le lancement a t cr partir dune tche, ce sont les variables de la tche qui
sappliquent, si le lancement a t cr partir dune session, ce sont les variables de luproc slectionne qui
pourront tre choisies.
Planification d'une tche

La planification sous Dollar Universe procde principalement par :
planification implicite : utilisation des rgles de planification,
planification explicite : dfinition de dates explicites.
La planification explicite permet de traiter les cas de planification qui ne pourraient pas tre pris en charge par
le mcanisme de planification implicite.
La planification de la tche cumule toutes les dates : celles obtenues partir du calcul des rgles et les dates
explicites.
Affectation de rgles de planification

A chaque tche peuvent tre affectes jusqu' sept rgles de planification. Pour chaque rgle doit tre dfinie:
Une date d'application
La planification 67
C'est la date partir de laquelle le calcul de la rgle s'applique (indispensable, par exemple, pour une rgle
invoquant une priode de deux semaines : il est ncessaire de savoir quelle semaine on commence le
calcul). Une date par rgle affecte la tche est ncessaire.
La date d'application doit correspondre la date du dbut de la priode :
o
Si la priode est "semaine", la date d'application doit correspondre au lundi,
Si la priode est "mois", la date d'application doit correspondre au premier jour du mois.
Pour la tche, doit tre dfinie de faon globale :
Une date de premire planification
Elle correspond la date de mise en exploitation de la tche. Selon les paramtres de planification, le
calculateur ritrera ventuellement son calcul jusqu' trouver une date de planification suprieure cette
date de premire planification.
Note : l'affectation de rgles une tche ne suffit pas pour obtenir une planification intgre : celle-ci doit se
complter d'une saisie des horaires de lancement pour les dates de planification de la tche.
Ajout ou suppression explicite de dates

Dollar Universe permet d'associer une planification implicite des dates d'interdiction et des dates explicites
afin de stabiliser et de faciliter la mise en oeuvre des rgles de planification.
En effet, mme si la planification implicite ne peut tre utilise que dans le cas de rgles de planification
relativement stables dans le temps et si les algorithmes proposs s'adaptent aux particularits des calendriers
(utilisation du "report"), un certain nombre d'vnements peuvent, un jour donn, mettre en dfaut les
principes de planification dfinis.
Dans ce cas, le recours aux dates d'exception et aux dates explicites permet :
d'annuler les effets de la planification implicite : dfinir une date d'interdiction pour le jour invalide,
de reporter l'excution impossible la date calcule une autre date non calculable algorithmiquement :
saisis une date explicite.
Ainsi, les trois possibilits offertes (rgles, dates explicites et dates d'interdiction) permettent de disposer,
tout instant, de moyens souples et adaptables aux imprvus d'un processus de production informatique.
Dates explicites
La planification explicite constitue le moyen le plus simple de planifier une tche.
Elle permet de planifier des tches de faon absolument quelconque allant d'une planification multi-journalire
fixe et rptitive de jours en jours des planifications alatoires dans le temps.
La planification explicite consiste dfinir un ensemble d'informations comportant:
la date et heure d'excution souhaite,
une fentre de lancement possible de la tche,
la date de traitement pour laquelle la tche doit tre excute (quand l'uproc concerne t dfinie avec
une priode fonctionnelle).
Ces possibilits permettent de mettre en oeuvre des processus de planification qui se reconduisent
systmatiquement dans le temps en prenant en compte au mieux les spcificits des calendriers.
Note : dans le cas d'un lancement ponctuel, plus ou moins immdiat, on privilgiera la cration d'un lancement,
qui permet de ne pas intervenir dans le processus standard de planification.
Dates d'interdiction
68 La planification
Dans le cas o un vnement inopin viendrait perturber le cycle de planification dfini, il est possible de
dfinir des dates d'interdiction qui permettent d'invalider une excution une date donne, sans imposer de
modification des rgles de planification.
Note : une date d'interdiction ne peut servir qu' invalider une date calcule partir d'une rgle de planification.
Elle reste sans effet sur les dates explicites. Pour annuler l'effet d'une date explicite, il convient de la supprimer de
la tche.
Fentre de lancement
La fentre de lancement dfinit une plage horaire de lancement de la premire uproc de la tche, afin de tenir
compte de charges d'exploitation ventuellement diffrentes d'un jour l'autre.
Dans le cas, o la tche doit faire l'objet de plusieurs excutions journalires, il est possible de dfinir jusqu'
1500 excutions au sein d'une mme journe partir de la dfinition de plages horaires et d'une priodicit au
sein de ces plages.
Les plages horaires de lancement sont dfinies une seule fois quel que soit le nombre de rgles saisies.
Excution unique
Pour les tches qui ne doivent faire l'objet que d'une seule excution par jour, les heures de planification
peuvent tre diffrencies par type de jour dans la semaine.
Note : cette heure de dbut correspond l'heure minimale de prise en charge par le lanceur, mais elle ne
correspond pas systmatiquement la date et heure d'excution, celle-ci pouvant tre diffre en raison de
conditions non satisfaites.
L'heure de dbut de pilotage est complte par une dure (format hhh.mm) pendant laquelle on accepte
d'attendre que les conditions soient vrifies, en fonction de chaque jour de la semaine. Cet intervalle peut
aller jusqu' 999 heures et 59 minutes.
Excutions multiples
Cette fonction va permettre de saisir des heures multiples de lancement permettant de soumettre jusqu' 1500
excutions d'une mme tche au cours d'une journe. Les heures limites de lancement autorises sont calcules
par Dollar Universe en ajoutant la dure indique aux heures de lancement dfinies.
Une fonction de calcul permet de gnrer automatiquement les heures de lancement selon une priode
indique. Cette gnration automatique des heures peut tre rpte autant de fois que ncessaire, les heures
gnres s'insrant et s'ordonnant progressivement dans l'cran par ordre croissant.
Note : les horaires multiples par jour ne sont pas conus pour permettre une surveillance d'un quelconque
vnement d'ordre technique ou applicatif. Il convient dans un tel cas de confier cette tche un processus
externe, videmment moins consommateur, et qui ne perturbera pas l'automate dans son fonctionnement (utiliser
les conditions de ressources ou les ordres de dclenchement).
Horaires d'une tche provoque
Une tche provoque comporte ventuellement des horaires de lancement qui permettent de dcaler
l'excution de celle-ci (sur des plages horaires de moindre charge machine par exemple). Comme pour les
tches planifies, la fentre de lancement est calcule partir d'une heure de dbut de pilotage et d'une dure.
Note : en l'absence d'une heure de dbut, les provocations sont prises en charge ds leur demande. En l'absence
d'une dure, les provocations sont considres comme tant illimites dans le temps (en fait, le dfaut est 999h59).
Des horaires d'exclusion peuvent galement tre dfinis afin d'interdire l'excution de la tche provoque
concerne pendant une plage horaire. Cette notion est utile pour pouvoir excuter des tches batch issues de
demandes utilisateur ou des tches batch provoques trs consommatrices de ressources vers des plages
horaires de moindre utilisation des ressources machine, tout en les reconduisant automatiquement d'un jour sur
l'autre (tant que l'intervalle de pilotage n'est pas chu).
La planification 69
Date de traitement d'une tche

Tout lancement d'une tche s'accompagne du calcul ou d'une demande de date de traitement fonction de la
priode fonctionnelle de l'uproc concerne par la tche (sauf si l'uproc est sans priode fonctionnelle).
Priode fonctionnelle
Format de la date de traitement
Sans priode fonctionnelle
Sans date de traitement
Jour
Jour
Semaine
Dcade
Dcade
Quinzaine
Quinzaine
Mois
Mois
Anne
Semaine
Anne
Mois
Anne
Mois
Anne
Mois
Anne
Bimestre
Bimestre
Anne
Trimestre
Trimestre
Anne
Quadrimestre
Quadrimestre
Anne
Semestre
Semestre
Anne
Anne
Anne
La date de traitement figure dans tous les vnements d'exploitation enregistrs par Dollar Universe. Ceci
permet de conserver et de diffrencier, indpendamment des dates de planification ou d'excution, les traces
des excutions d'une tche.
Exemple : date de traitement
Une uproc de saisie comptable est mensuelle, et chaque lancement il est demand une date au format
MMAAAA.
L'uproc de clture mensuelle est mensuelle, et il est ncessaire de conserver la trace dans le fichier historique
des vnements d'exploitation des 12 excutions correctes pour pouvoir lancer l'uproc de clture annuelle de
l'exercice.
Note : la priode fonctionnelle (format de la date de traitement) est indpendante, et peut tre diffrente, de la
priodicit de planification de l'uproc concerne, mme si Dollar Universe propose en standard l'algorithmique
permettant de calculer automatiquement les dates de traitement en fonction des dates de planification.
Exemple : un traitement de bilan comptable mensuel est systmatiquement soumis deux reprises chaque
mois :
le 30 de chaque fin de mois pour extraire un premier bilan du mois coul,
le premier lundi de chaque mois pour extraire un bilan complet intgrant la "cinquime" semaine du mois
coul.
Un exemple analogue peut tre fourni sur la base d'un traitement, soumis chaque fin de semaine, et dont
l'objectif est de restituer un rcapitulatif des mouvements comptables du mois courant.
Pour prciser de manire plus fine cette date de traitement et pour permettre de diffrencier la date de
traitement de la date de planification de la tche, des paramtres supplmentaires peuvent tre dfinis. La
mthode de calcul repose sur les tapes chronologiques suivantes :
application du delta en jours, ventuellement en prenant en compte les jours ouvrs (sinon calendaires),
projection de la date obtenue dans la priode fonctionnelle correspondante,
application du delta de priodes pour obtenir la date de traitement.
Exemple : les dates de traitement

Considrons une procdure dfinie avec une priode "jour" (date de traitement au format jjmmaaaa).
On suppose galement le delta de jours gal "0".
Si l'cart de priode spcifi est "0", la date de traitement qui lui est automatiquement associe lors de sa
soumission au pilotage est la mme que sa date de planification.
70 La planification
Si l'cart de priode spcifi est "-1", la date de traitement qui lui est automatiquement associe lors de sa
soumission est celle du jour prcdant sa date de planification.
Exemple : calcul d'une date de traitement
Pour une tche btie sur une uproc mensuelle, un delta en jours calendaires de +5 associ un delta de
priode de +1 donne les calculs successifs suivants :
27 juin + 5 jours => 2 juillet
2 juillet
=> mois de juillet (par projection)
juillet + 1 priode => mois d'aot
=> 20040801
Note : le delta en jours ne fait double emploi avec le delta de priodes que dans le cas d'une priode fonctionnelle
journalire. Cette distinction sera prcieuse pour traiter des cas tels que celui mentionn dans l'exemple ci-dessous.
Exemple : diffrenciation des delta en jours et en priodes
En reprenant l'exemple du bilan comptable de priode mensuelle, soumis systmatiquement deux fois, le 30 de
chaque mois et le premier lundi du mois suivant. Il s'avre ncessaire d'oprer un delta en jours afin que ces
deux excutions "pointent" sur un mme mois.
En considrant les delta suivants : delta priode = -1 et delta jours = +2
Quelle que soit la date du premier lundi, la date de traitement obtenue pour les deux excutions sera le mois
courant :
30 juin + 2 jours => 2 juillet => juin => 20040601
lun 4 juillet + 2 jours => 6 juillet => juin => 20040601
Un rsultat similaire peut tre obtenu avec les hypothses suivantes : delta priode = +0 et delta jours = -7
Note : depuis la version 3.4, avec la possibilit d'effectuer un report au del de la priode traite en fonction des
autorisations dfinies selon le jour de la semaine, la date de traitement est calcule avant report (date calcule par la
rgle avant application du report ventuel contenu dans celle-ci).
Exemples : calculs de dates de traitement de tches planifies
On supposera que la date d'excution est le mardi 27 juin 1989 et que le calendrier du mois de juin s'tablit
de la faon suivante :
Mois
Juin (06)
Lundi
05 ouvr
12 ouvr
19 ouvr
26 ouvr
Mardi
06 ouvr
13 ouvr
20 ouvr
27 ouvr
Mercredi
07 ouvr
14 ouvr
21 ouvr
28 ouvr
Jeudi
01 ouvr
08 ouvr
15 ouvr
22 ouvr
29 ouvr
Vendredi
02 ouvr
09 ouvr
16 ouvr
23 ouvr
30 ouvr
Samedi
03 chm
10 chm
17 chm
24 chm
Dimanche
04 chm
11 chm
18 chm
25 chm
Quelques exemples de calcul...

PF de rfrence
cart de PF
cart en J.O.
date de traitement
Jour
oui
27/06/1989
Jour
non
27/06/1989
Jour
+5
oui
04/07/1989
Jour
-2
oui
23/06/1989
Jour
-2
non
Dcade
21/06/1989
Dcade
-1
11/06/1989
Dcade
+2
11/07/1989
Semaine
26/06/1989
25/06/1989
La planification 71
Semaine
-1
19/06/1989
Semaine
+1
03/07/1989
Quinzaine
16/07/1989
Quinzaine
+1
01/07/1989
Quinzaine
-1
01/06/1989
Mois
01/06/1989
Bimestre
-1
01/05/1989
Trimestre
+1
01/07/1989
Quadrimestre
+1
01/09/1989
Quadrimestre
-1
01/05/1989
Semestre
01/01/1989
Semestre
+1
01/07/1989
Anne
01/01/1989
Anne
+1
01/01/1990
Superposition de fentre de lancement

Il peut exister, pour une mme tche et pour une date donne, deux fentres de lancement caractriss par les
couples (hd1,hf1) et (hd2,hf2). Cette situation peut se produire dans les cas suivants :
deux dates explicites identiques avec des intervalles diffrents,
une rgle de planification dont le calcul donne une date figurant parmi les dates explicites,
deux rgles donnant occasionnellement, pour une mme tche, la mme date.
Dans ces cas, au moment du lancement, un arbitrage est fait en respectant la rgle suivante :
Si un intervalle contient totalement l'autre, c'est lui qui est retenu, l'autre tant purement et simplement oubli.
Dans le cas inverse, deux lancements sont prvus : celui qui a la date de dbut la plus proche garde l'intervalle
initialement prvu. L'autre voit sa date de dbut value au maximal de sa date de dbut et de la date de fin du
premier.
Exemple : impact de la superposition d'intervalles
Hd1
Hf1
Hd2
Hf2
H
Hd1
f1
Hd2
Hd1
Hf2
Hf1
Hd2
72 La planification
un seul lancement :H
- H
d1
f1
deux lancements: H
- H
et
f2
d2
deux lancements: H - H
f1
d1
Hf2
et
H - H
f2 f1
H
d2
- H
f2
Mise en production
Manipulation
Oprations de mise jour
Les oprations de mise jour d'un objet de Dollar Universe peuvent tre effectues par les options suivantes :
Crer
Un nouvel objet (uproc, session...) dans l'environnement de travail choisi : socit noeud - espace. La cration sera refuse si l'objet existe dj dans l'environnement.
Dupliquer
Un objet origine sur un objet cible. Les objets sont de mme nature mais peuvent tre
de type diffrent (modle - non modle), d'identifiant diffrent (par exemple dupliquer
l'uproc tstref/001 sur l'uproc tratbr/002) ou de versions diffrentes. La duplication sur
un objet cible dj existant sera refuse.
Modifier
Les caractristiques d'un objet. Son identifiant n'est pas accessible.
Visualiser
Les caractristiques d'un objet, sans pouvoir les modifier.
Supprimer
Un objet. L'identifiant de l'objet et ses caractristiques seront supprimes de

l'environnement de travail (y compris le CL d'une uproc s'il est interne).
La mise jour d'un objet dans un environnement donn (socit, noeud, espace) est locale cet environnement
et n'a pas d'impact sur les autres environnements. Cela signifie, par exemple, qu'une uproc supprime du
dictionnaire central n'est pas supprime des dictionnaires locaux.
D'autres oprations de mise jour sont spcifiques certains objets, elles sont dcrites dans la suite de ce
chapitre.
Verrouillage technique des objets

Lorsqu'une uproc est modifie par un utilisateur, elle devient inaccessible pour tous les autres utilisateurs, qu'il
s'agisse des utilisateurs Dollar Universe ou mme de Dollar Universe lui mme, les autres objets ne sont pas
verrouills.
Il convient donc d'tre prudent sur la mise jour d'objets faisant partie du planning du jour. En effet si un
utilisateur veut modifier une tche, si un nouveau lancement de cette tche doit tre calcul ce moment (en
fin de fentre de lancement de la tche), le nouveau lancement ne sera pas calcul tant que la tche est en
cours de modification, il le sera automatiquement ds que la modification sera termine.
Mise en production 73
Gestion des versions

Dollar Universe permet, dans l'environnement de dveloppement (espace d'application et d'intgration), de
grer des versions d'objets (uprocs et sessions) afin de faciliter la mise au point de l'automatisation des
applications.
Uprocs
Dollar Universe gre des versions d'uprocs dans les espaces d'application et d'intgration. Dans les espaces de
simulation et d'exploitation cette version est toujours nulle. Dollar Universe assure une volution conjointe du
numro de version de l'uproc et du numro de version du fichier contenant le CL associ, pour les uprocs CL
interne. Pour les autres uprocs, cette volution parallle n'est pas assure.
Version courante
La version courante d'une uproc est, parmi toutes les versions d'uproc disponibles dans un espace donn, celle
prise en compte lors de l'excution d'une session.
Note : une seule version d'uproc tant gre dans l'environnement d'exploitation, cette option ne peut tre utilise
que dans l'environnement de dveloppement.
Sessions
Les sessions, au mme titre que les uprocs, sont des objets grs par Dollar Universe. Elles suivent des rgles
de dveloppement et d'implantation sur les noeuds, de mme nature.
Ainsi :
En espaces application, intgration et simulation, les sessions sont gres par version. L'ensemble des
sessions/version est accessible depuis les espaces d'application, d'intgration ou de simulation. A ce titre,
les versions d'uproc prises en compte lors de l'excution d'une session seront les versions dfinies
explicitement comme "version courante",
En espace d'exploitation une seule version de session est disponible.
Changement d'environnement
Transfert vers un espace
Sous Dollar Universe, la description des processus d'exploitation est regroupe dans les objets suivants :
les uprocs,
les sessions,
les calendriers,
les tches.
Pour chacun de ces objets, il est possible de procder leur transfert d'un espace vers un autre. Le transfert
consiste en la duplication de l'objet d'un espace sur un autre (l'objet n'est pas supprim de l'espace origine).
Les transferts entre espaces sont autoriss selon le schma suivant :
Application -> intgration -> simulation -> exploitation.
Note : cette fonction peut tre interdite si l'espace vis n'est pas disponible sur le noeud concern (cf. paragraphe
"Habilitation aux espaces" page 23), ou si l'objet concern comporte une unit de gestion non disponible dans
74 Mise en production
l'espace cible (ce peut tre le cas des calendriers ou des tches; cf. paragraphe "Units de gestion et espaces" page
15).
Le transfert d'un objet, dj existant dans l'espace cible, a pour effet de remplacer l'objet existant par l'objet
transfr.
Pour les uprocs CL interne, le transfert de l'uproc entrane galement le transfert du fichier de commande
associ.
Conformment ce qui a t dcrit dans le paragraphe "gestion des versions" :
le transfert d'une uproc dans l'espace de simulation ou d'exploitation aura pour consquence la cration,
dans cet espace, de cette uproc avec un numro de version 000,
le transfert d'une session dans l'espace d'exploitation aura pour consquence la cration de la session, dans
l'espace d'exploitation, avec un numro de version 000.
Note : les commandes d'extraction et d'insertion ne peuvent pas tre utilises pour transfrer un objet d'un espace
un autre (cf. Manuel de l'interface commande).
Distribution vers des units de gestion

La distribution permet de reconduire les caractristiques d'un lment de paramtrage, non plus d'un espace
un autre, mais d'un site vers des units de gestion, et au travers d'elles vers d'autres sites d'exploitation (et ce
au sein d'un mme espace). Comme prcdemment, la distribution des uprocs CL interne permet la
distribution conjointe des informations descriptives de l'uproc et de son CL associ.
De la mme faon que pour le transfert, chacune des catgories d'objets de Dollar Universe peut faire l'objet
d'une distribution ainsi que les tables d'administration :
Objets :
Tables d'administration :
Uprocs
Socits
Sessions
Noeuds
Calendriers
Units de gestion
Tches
Types d'units de gestion
Classes d'incompatibilit
Dpendances des units de gestion
Ressources
Applications
Domaines
Rpertoires applications et UG
Utilisateurs
Les fonctions de distribution entranent :
l'extraction des informations descriptives de l'objet de son environnement d'origine,
son transfert vers l'environnement cible choisi,
son insertion dans les fichiers correspondants dans l'environnement cible (mme espace que celui de
dpart).
La distribution d'un objet ou d'une table d'administration consiste en la duplication de l'objet (l'objet n'est pas
supprim l'origine). La distribution d'un objet, dj existant dans l'espace cible, a pour effet de remplacer
l'objet existant par l'objet transfr.
La distribution peut s'effectuer selon :
une liste explicite d'units de gestion,
un type d'units de gestion, c'est dire sur l'ensemble des units de gestion du type indiqu.
Cible de la distribution
Toutes les tapes de la distribution sont enchanes en temps rel, que les units de gestion cibles soient
rsidentes sur le mme noeud ou sur un autre noeud du rseau.
Dans le cas d'objets dfinis indpendamment des units de gestion (c'est le cas des tables, des uprocs ou des
sessions), ce sont les noeuds qui sont viss au travers de la liste des units de gestion. Si deux units de
gestion, rsidentes sur un mme noeud, sont dsignes comme cible d'une distribution, l'objet n'est envoy
qu'une seule fois sur le noeud de destination. De mme, si parmi les units de gestion cibles, certaines sont
rsidentes sur le noeud o est effectu la distribution, alors elles sont ignores.
Distribuer un modle
Dans le cas d'objets dpendants des units de gestion (calendriers et tches), seuls ceux dfinis en tant que
modle peuvent tre distribus. Ils deviennent immdiatement oprationnels (au temps de communication et
d'installation prs) sur leurs units de gestion cibles ds la validation de la distribution. Par ailleurs, l'inverse
des objets indpendants des units de gestion, la distribution de ces objets sur des units de gestion locales
entrane la cration sur le noeud o est effectu la demande de l'objet correspondant.
Note: cette fonction peut tre interdite si les units de gestion vises ne sont pas disponibles dans l'espace
concern (cf. paragraphe "Units de gestion et espaces" page 15) ou si les noeuds viss, au travers de ces units de
gestion, ne sont pas autoriss l'espace concern (cf. paragraphe "Habilitation aux espaces" page 23).
Distribuer une table d'administration

Dollar Universe ne permet pas une distribution par "deltas" des tables, pas plus qu'une distribution
personnalise noeud par noeud. Il est recommand de distribuer les tables sur tous les noeuds ds cration ou
modification de celles-ci, afin que chacun de ces noeuds dispose d'une vue cohrente de l'environnement ainsi
dfini.
La distribution d'une table d'administration a pour effet de remplacer la totalit de la table cible par la table
origine : si des enregistrements taient prsents dans la table cible et absent dans la table origine, ils seront
dtruits dans la table cible par l'opration de distribution de la table origine.
Il existe deux exceptions cette rgle :
la table des noeuds : sa distribution ncrase plus, depuis la version 4.3, la dfinition du noeud local.
La table des utilisateurs : depuis la version 5, le contenu de la table cible est totalement effac avant
insertion, hormis l'utilisateur "root" ou "SYSTEM" ou ayant le code auteur "998". Avant cet effacement,
le contenu de la table est sauvegard dans un fichier ayant pour nom
"USERS_TABLE_<AAAAMMJJHHMNSS>" dans le rpertoire de lancement de l'changeur cible.
Note : Les fonctions de distribution ncessitent la prsence (outre des processus rseau - cf. manuel
d'administration) de l'changeur pour l'espace dans lequel est effectu la distribution. Pour la distribution des
objets dfinis au niveau de la socit et non pas au niveau des espaces (c'est le cas des tables d'administration), c'est
l'changeur de l'espace d'exploitation qui est utilis.
Un mode de fonctionnement alternatif est "Ajout". Ce mode est oprationnel lorsque la variable
d'environnement U_DISTRI_MODE est dfinie dans le contexte d'environnement de l'changeur exploitation
cible avec la valeur "A". cf. manuel d'administration.
Dans les systmes UNIX, cette variable doit tre place dans les fichiers $UXMGR/uxsetenv,
$UXMGR/uxsetenv_csh et $UXMGR/uxsetenv_ksh avec la valeur "A".
Dans les systmes VMS, le symbole global U_DISTRI_MODE doit tre prsent dans le fichier
UXEXE:U$_ANTE_ECH.COM en version 43, et UXEXE:U_ANTE_ECH.COM en version 500 et audessus avec la valeur "A".
Dans les systmes Windows, la variable doit tre incluse dans le fichier %UXEXE%\<SOCIETE>.DEF
avec la valeur "A".
Extraction / insertion de donnes

Pour permettre une dsynchronisation de l'intention de distribution et de l'installation effective du
paramtrage, des commandes d'extraction et d'insertion des objets sont disponibles dans l'interface
commandes de Dollar Universe (cf. Manuel de l'interface commande).
Le mode de fonctionnement standard de l'insertion est le mode "Ajout". Le mode de fonctionnement "Annule
et Remplace" est obtenu avec l'item "REPL" place sur la ligne de commande.
Il n'y a pas de sauvegarde automatique dans l'insertion de la table utilisateurs en mode commande.
L'opration d'extraction de la table des utilisateurs depuis une socit, puis l'insertion dans une autre socit
est dsormais oprationnelle. Aucun paramtre particulier n'est requis lors de l'insertion. La variable
d'environnement S_SOCIETE est prise en rfrence pour l'insertion.
Verrouillage fonctionnel des objets

Le transfert et la distribution d'un objet peut s'accompagner du verrouillage de cet objet dans le but de le
protger contre toute modification par un utilisateur non autoris.
Lors de la cration d'une socit, le positionnement de l'option "verrouillage des uprocs et des sessions"
permet d'effectuer ce contrle. Dans ce cas les objets sont verrouills dans leur environnement d'origine et
dans l'environnement cible du mouvement.
Pour accder en modification sur ces objets l'utilisateur doit avoir la capacit de "librer" l'uproc ou la session.
Historique des distributions

L'ensemble des mouvements effectus : transfert, distribution, insertion (uxins) ou extraction (uxext) sont
enregistrs et consultables dans le cadre des historiques de distribution.
Ces historiques ont pour objet d'acqurir une vue complte des divers paramtrages existants sur l'ensemble de
la configuration, et de pouvoir ainsi garantir la cohrence globale de ce paramtrage et, pour le moins, de
diagnostiquer trs rapidement les incohrences ventuelles. Dans l'historique, seront affiches la nature et
l'identifiant de l'objet et des informations sur le mouvement :
Nature et identifiant des objets distribus

L'identifiant est la concatnation des informations constitutives de l'objet distribu, telle que figure dans
le tableau ci-dessous :
Table
Libell
Uproc
Uproc, version
Ressource
Ressource
Session
Session, version
Calendrier
UG ou modle
Tches
Session, version, uproc, version, UG (modle)
La nature du mouvement : transfert, distribution, import ou export,
L'tat du mouvement pour l'environnement courant (celui dans lequel travaille la fonction d'interrogation).
Pendant le mouvement, ce code peut tre diffrent entre l'origine et la cible, et prendre les valeurs
suivantes :
o
Demande de mouvement en cours (D3) : ce statut apparat dans le cadre d'une distribution lorsque le
site metteur ne peut crire sur le site distant l'ordre d'acquisition.
Mouvement demand (D4) : ce statut apparat dans le cadre d'une distribution lorsque le site metteur
a russi crire l'ordre d'acquisition sur le site distant, mais que celui-ci n'a pas transmis l'accus
rception.
Mouvement en cours d'acquisition (A3) : ce statut apparat dans le cadre d'une distribution, sur le site
rcepteur, lorsque celui-ci a russi acqurir l'information souhaite. Il apparat galement dans le
cadre d'un transfert et signifie l'initialisation de cette opration.
Mouvement acquis (A4) : ce statut apparat dans le cadre d'un transfert comme d'une distribution et
tmoigne du bon droulement de l'opration concerne (pour la distribution, signifie que le site
rcepteur accus rception sur le site metteur).
Si l'tat n'atteint pas la valeur A4, il tmoigne d'un incident dans l'opration correspondante : on
s'attachera alors vrifier que le serveur d'I/O de Dollar Universe est bien dmarr dans le noeud et
l'espace cibles du transfert ou de la distribution. Dans ce dernier cas, on vrifiera que le serveur de
commandes et l'changeur sont galement dmarrs sur les deux noeuds concerns (pour les espaces viss
dans le cas de l'changeur).
Le noeud cible (respectivement origine) du mouvement,
L'espace cible (respectivement origine) du mouvement,
L'unit de gestion cible (respectivement origine) du mouvement,
La date et heure de ralisation du mouvement pour la cible (mises jour chaque changement d'tat du
mouvement, respectivement pour l'origine).
Dans le cas d'une distribution, l'historique de ces mouvements est systmatiquement mis jour sur les deux
noeuds concerns, afin d'avoir toujours, sur un noeud donn, une vue exhaustive des mouvements entrants et
sortants.
Simulation de planification
Objectifs
Sur Windows, UNIX et VMS, Dollar Universe permet de constituer des plannings d'exploitation de faon
compltement dynamiques, sans rfrence des plannings prtablis. Dans ces conditions, il peut tre
ncessaire d'obtenir une vue de synthse de la planification prvisionnelle sur une priode donne.
Ceci constitue l'objectif des fonctions de simulation de planification.
Les fonctions interactives de dfinition de la planification d'une tche permettent tout moment de simuler par
rapport au calendrier de rfrence l'effet de la planification dfinie au niveau de cette tche. Cette simulation
peut tre excute sur une priode quelconque paramtrable.
Manipulation du planning prvisionnel

Afin de faciliter la lisibilit du planning prvisionnel, des critres de choix des tches traiter, et les
conditions de visualisation du planning prvisionnel peuvent tre dfinis :
Slection des tches partir de chacun de leur composants (uprocs, sessions, units de gestion), de
manire explicite ou gnrique,
Slection des dates et heures de dbut et de fin de calcul du planning prvisionnel. Il est noter que la
date et heure de fin est exclue du calcul.
Le choix des tches observer ne peut concerner que des units de gestion rsidentes sur le noeud sur lequel
est effectue la dtermination du planning prvisionnel.
Composantes d'une session

Cette fonction permet de dvelopper ou non les sessions, i.e., d'afficher l'ensemble des tches figurant sur le
chemin normal de la session et s'excutant sur des units de gestion contenues dans la cible d'units de gestion
choisie.
Dans ce cas, le planning prendra en compte les particularits des tches de la session. Ainsi, les tches
optionnelles dont les conditions de planification ne correspondent pas aux conditions de planification de la
session ne seront pas affiches. De mme, les tches provoques diffres apparatront dcales par rapport
aux autres tches de la session. Par dfaut, le planning prvisionnel affiche les sessions sans les dvelopper.
Intervalles de pilotage
La fonction de planning prvisionnel permet de visualiser soit les intervalles de pilotage, soit les dures
d'excution moyennes des tches, soit les deux. Les temps d'excution sont issus des informations statistiques
calcules en temps rel par Dollar Universe lors de chaque excution. Par dfaut, l'affichage ne mentionne que
les intervalles de pilotage.
Units de gestion distantes

Dans les sessions peuvent tre incluses des tches concernant des units de gestion ne rsidant pas sur le
noeud sur lequel est excute la simulation. Ces tches n'apparaissent pas dans les crans proposs, leurs
informations statistiques n'tant pas disponibles sur le noeud concern. Toutefois, si ces tches s'insrent entre
des tches excutes localement le positionnement des dures d'excution tient compte de leur existence. En
effet, les informations statistiques portent la fois sur le temps d'excution de la tche et la dure sparant le
dbut d'excution de la session et le dbut d'excution d'une quelconque des tches prsente dans la session.
Ordonnancement
Le rle du moteur batch

Dollar Universe excute un ordonnancement et un lancement dynamique des travaux, bass sur des processus
acycliques ragissant en fonction des vnements qu'ils constatent en temps rel : heure, dbut ou fin d'un
travail, changement d'tat d'une ressource, mise jour des paramtres d'exploitation...
Il ne s'appuie sur aucun planning prdfini, mais interprte, en fonction des vnements d'exploitation qui
surviennent et des interventions ventuelles des exploitants, l'ensemble des informations descriptives des
travaux et les lments de planification associs. Cette interactivit totale de Dollar Universe lui confre :
de trs hautes performances (consommation de ressources minimale du fait de l'absence de processus

cycliques, soumission "juste temps" des travaux, ...),
une ractivit exceptionnelle, pour une meilleure disponibilit des applications qu'il prend en charge,
un rel confort d'utilisation, la capacit d'intervention des exploitants tant respecte en temps rel.
Le processus d'automatisation
Le fonctionnement du moteur batch de Dollar Universe est reprsent par le schma ci dessous :
Calendrier
Rgles
Oprateur
Taches
UG /
Uproc
Administrateur
Calculateur
Lancements
Attentes
vnements
locaux ou
distants
Lanceur
Excutions
Echangeur
Surveillant
Vers sites distants
Systme
d'exploitation
Fonctionnement du moteur de Dollar Universe
La planification des travaux s'appuie sur les tches qui regroupent les procdures excuter (les uprocs) sur
des environnements (les UG) suivant des rgles de planification et des calendriers.
Le moteur batch de Dollar Universe prend ensuite la main pour calculer les dates d'excution des tches et les
lancer en vrifiant les conditions d'excution (vnements dj survenus ou ressources attendues). Si la
production doit tre ralise sur une architecture distribue, il communique avec les autres machines par le
rseau.
Ordonnancement 81
Ces diffrentes tapes sont ralises par Dollar Universe au travers de diffrents processus : le calculateur, le
lanceur, le surveillant et l'changeur.
Les composants du moteur batch

Le moteur batch est constitu de trois composants principaux :
Le calculateur, dont le rle est de calculer les prochaines dates d'excution pour toutes les tches
planifies ou encore de recalculer celles-ci suite une modification du calendrier ou de la planification.
Le lanceur, remplit trois fonctions essentielles que sont : le pilotage, le lancement et la terminaison des
tches que le calculateur a dtermines comme tant excuter (ou qui ont t demandes par ailleurs commande de dclenchement, demande oprateur, ...). Il est assist du surveillant pour la dtection de
ressources systmes.
L'changeur, dont le rle est de grer les changes de donnes spcifiques Dollar Universe entre les
noeuds.
Le rle du moteur batch est d'optimiser l'utilisation des ressources machine (lancements "juste temps",
lancements pendant les plages de sous charges des matriels, les nuits ou les fins de semaine par exemple),
ventuellement hors de toute prsence humaine.
Le calculateur et le lanceur ne sont donc pas activs de faon cyclique, mais en fonction des besoins rels du
schma d'exploitation qu'ils grent. Ces dispositions rendent les fonctions d'automatisation de Dollar Universe
particulirement performantes et conomes en terme de consommation de ressources.
Par ailleurs, le calculateur, comme le lanceur, travaillent partir de la date/heure systme. Dans ces conditions
il convient d'tre particulirement vigilant aux changements de date et heure systme. Ils peuvent, s'ils ne sont
pas planifis avec rigueur en tenant compte de la production, dsorganiser les fonctions d'automatisation de la
production.
Implantation du moteur batch

Les processus du moteur batch (calculateur + lanceur) sont spcifiques chaque socit et chaque espace de
la socit.
Ils doivent systmatiquement tre dmarrs en espace d'exploitation sur toutes les machines constitutives du
systme informatique. Dans le cas d'une organisation en cluster sous VMS et OPENVMS, les processus requis
peuvent tre installs sur chacune des machines constitutives du cluster. Les fichiers utiliss par ces processus
sont, par contre, partags par tous les processus du moteur batch installs sur les machines du cluster.
Note : le calculateur et le lanceur doivent tre prsents pour un fonctionnement normal de Dollar Universe. Dans
le cas d'une automatisation au travers d'un rseau, l'changeur est galement indispensable : cela signifie qu'il faut
que les automates soient dmarrs dans l'environnement de travail : socit - noeud - espace.
On se reportera au manuel d'Administration pour de plus amples informations sur l'architecture technique
retenue pour supporter le moteur batch.
Soumission au travers du rseau

Les diffrents moteurs batch installs changent les informations utiles via une communication de type client serveur, constitue d'une fonction ddie nomme changeur (situe dans un processus distinct). Ce processus
permet de faire excuter des travaux sur des units de gestion distantes, ou de les conditionner sur des
excutions distantes sans que cela soit diffrentiable par l'application d'une exploitation uniquement locale.
Etapes d'excution d'une tche

L'excution d'une tche se droule en cinq tapes principales :
82 Ordonnancement
La planification : calcul de la prochaine date de lancement (pour les tches batch planifies),
Le lancement : examen des dates et heures, et rception des ordres de dclenchement,
Le pilotage : examen des conditions d'excution,
L'excution du CL associ,
La terminaison : excution des consignes, traitement des vnements en attente, droulement des sessions.
Soumission
manuelle
Soumission automatique
: calcul des dates de
planification
Lancement des
tches
Collecte des
vnements
Pilotage des
lancements
Rception des
vnements
attendus
ok
fatal ok
Abandon
Attente
Dpassement
heure limite
Excution
Terminaison
Cinmatique d'excution d'une tche
Ces cinq tapes sont ralises, selon le schma prcdent, chaque excution de la tche. Le franchissement
de chacune de ces tapes correspond un vnement d'exploitation enregistr par Dollar Universe.
La planification des travaux

La planification initialise le processus et dfinit les paramtres qui permettront de calculer la date d'excution
de chacune des tches concernes. Chaque date de prochaine excution d'une tche est ainsi dynamiquement
mise jour chaque modification des paramtres de planification.
Le fonctionnement du calculateur
A partir des informations de planification des tches, le calculateur met jour, en temps rel, la prochaine date
d'excution de chacune des tches. Ce calcul est effectu :
chaque fois qu'il constate, pour une tche, une date d'excution dpasse : calcul de la prochaine date
d'excution pour la tche concerne, donc en fin de fentre de lancement de la tche,
la suite de la modification d'un calendrier : nouveau calcul des prochaines dates d'excution pour
l'ensemble des tches utilisant le calendrier qui a t modifi,
chaque fois que des paramtres entrant dans le calcul des dates d'excution d'une tche sont modifis.
Dans ce cas, le nouveau calcul porte sur la tche dont les caractristiques ont t modifies.
Le calculateur planifie son rveil, aprs chaque calcul, en fonction de la plus proche date/heure de fin de
fentre de lancement de tche.
Ordonnancement 83
Enfin, le calculateur intervient sur le lanceur pour le rveiller chaque fois que, dans ses calculs, il constate
qu'une date/heure d'excution d'une tche est infrieure la prochaine date/heure prvue de rveil de celui-ci.
Le calculateur cr des lancements qui sont des objets distincts des tches (fichiers diffrents). Ce sont ces
lancements qui seront considrs par le lanceur et non les tches.
Impact des modifications d'une tche

D'une manire gnrale, toute modification (ou activation) d'une tche provoque une actualisation de celle-ci
avec la modification du lancement initialement prvu si la date et heure courante n'est pas comprise dans la
fentre de ce lancement. Dans le cas inverse, l'actualisation sera effectue la fin de la fentre de lancement.
En supposant que la modification intervient en dehors de la fentre de lancement :
Si la modification intervient uniquement sur les informations techniques d'une tche, elle se rpercutera
sur tout futur lancement de cette tche, mais celle-ci n'est pas ractualise et, par consquent le lancement
immdiatement prvu n'est pas rgnr,
Si la modification porte sur l'un des modes de planification (horaires, dates explicites, planification
implicite, dates d'exception), la tche sera recalcule (si elle n'est pas dsactive et si le calculateur est
prsent) selon sa nouvelle dfinition.
Modification d'une tche et lancement correspondant

Cas A
Le lancement existant est dans le futur par rapport la modification de la tche (lancement dans l'tat
"Attente de lancement"):
Dans ce cas, une fois la modification valide, mme si le calculateur n'est pas dmarr, le lancement (qui n'a
pas t modifi manuellement) est effac des "Lancements".
Dans ce cas, une fois averti de la modification, le calculateur tablira un nouveau lancement.
Note : Si le lancement post par le calculateur est modifi manuellement, il ne sera pas effac.
Cas B
Le Lancement existant est dans le pass par rapport la modification de la tche (lancement dans l'tat
"Attente d'vnement", "Horaire dpass" ou "Attente de lancement" - si le lanceur est arrt):
Dans ce cas, une fois la modification valide :
Cas B1 : Si le calculateur est en dehors de la fentre de lancement calcule antrieurement (avec les
valeurs prcdentes de la tche) : un nouveau lancement est calcul
Cas B2 : Si le calculateur est dans la fentre de lancement calcule antrieurement (avec les valeurs
prcdentes de la tche) le calculateur se comporte comme suit :
o
Cas B2a : Le nouveau lancement tabli est dans le futur par rapport la date et l'heure actuelle : dans
ce cas, un nouveau lancement est calcul.
Cas B2b : Le nouveau lancement tabli est dans le pass par rapport la date et l'heure actuelle : dans
ce cas, aucun lancement n'est calcul. Le calculateur sera rveill pour calculer un nouveau
lancement la fin de la nouvelle plage de lancement de la tche.
Activation - dsactivation d'une tche

Quelle que soit sa nature une tche peut tre dsactive. Une tche inactive est une tche pour laquelle le
lancement en fonction de ses dates de planification est suspendu.
84 Ordonnancement
Lors de la dsactivation (ou la ractivation) d'une tache planifie, le lancement qui avait t antrieurement
gnr par le calculateur est dsactiv (ou ractiv) s'il est dans le futur par rapport au moment de l'action et
qu'il n'a pas t modifi par un utilisateur.
Une tche dsactive demeure susceptible de participer au conditionnement d'une autre tche qui demeurera
examine dans son intgralit pouvant ainsi "bloquer" la tche conditionne. Il conviendra de "librer" (par
activation) le lancement prvu gnr ou de crer l'vnement correspondant pour simuler, si besoin est,
l'excution de la tche.
L'activation correspond une mise jour complte de la tche. A ce titre, L'activation d'une tche provoque
ne libre pas les lancements prvus dsactivs gnrs dont la date et heure de dbut de plage horaire de
soumission est antrieure la date courante.
Quand la tche sera ractive la premire excution effective n'interviendra que pour la premire date de
planification suivant la date laquelle est opre la ractivation de la tche.
Lancements d'une tche dsactive

Par dfaut, le calculateur continue de gnrer des lancement pour une tche inactive, cependant ces
lancements sont dans l'tat dsactiv. Les tches provoques et les tches optionnelles se dsactivent au mme
titre que les tches planifies. De la mme manire que pour les tches planifies, toute demande de
dclenchement apparatra sous la forme d'un lancement prvu dsactiv.
Dsactiver une tche comportant des horaires multi journaliers risque de faire grossir trs rapidement la base
des lancements prvus et est ce titre dconseill.
Pour que les lancements associs une tache dsactive n'apparaissent pas dans la fentre des lancements, il
faut positionner la variable U_WRITE_HELD'espace' a N dans les fichiers uxlnm'SOCIETE'.dat (o espace
vaut X, S, I ou A). cf. manuel d'administration.
Ordonnancement - lancement des travaux

Le lanceur
Le lanceur regroupe les quatre principales tapes d'ordonnancement - lancement que sont :
Le lancement : examen des dates et heures, et rception des ordres de dclenchement,
Le pilotage : examen des conditions d'excution,
La soumission de la "coquille batch",
La terminaison : excution des consignes, traitement des vnements en attente, droulement des sessions.
Le lanceur compare la date et l'heure systme avec la date et l'heure du prochain lancement tel qu'il a t dfini
par le calculateur, et, en cas d'galit, ralise le pilotage de ce lancement. Dans le cas contraire, le lanceur
"hibernera" jusqu' la date et heure de prochain lancement prvu. Les informations ncessaires au lanceur, lui
sont transmises par le calculateur (ou par diverses interventions manuelles).
Le lanceur examine la formule de lancement de l'uproc : les conditions sont vrifies dans l'ordre de l'criture
de la formule :
si le lanceur rencontre une condition "fatale" non rsolue : il met ce lancement dans l'tat "Refus au
pilotage" et l'abandonne,
si le lanceur rencontre une condition (non fatale) qui n'est pas rsolue, le lancement est mis dans l'tat
"attente d'vnement" (jusqu' la fin de la fentre de lancement dfinie).
Le lanceur ne ressaye pas cycliquement de soumettre le lancement au pilotage. Un processus, de type

"gestion vnementielle" s'y substitue. En effet, au moment du pilotage, les vnements non raliss,
Ordonnancement 85
interdisant la vrification de la formule de lancement de l'uproc concerne sont stocks. Ds que l'un de ces
vnements intervient, le lancement est soumis un nouveau pilotage.
Lorsque le pilotage rvle que la formule de lancement est valide, le lanceur soumet la "coquille batch" qui
prend en charge l'excution du CL (cf. paragraphe "Soumission de l'uproc" page 93).
Aprs l'excution du CL, la phase de terminaison assure l'excution des consignes de terminaison associes
l'uproc et qui dtermine quels lancements en attente d'vnements doivent tre rexamins; elle assure
galement la gestion des enchanements dfinis dans les sessions (cf. paragraphe "Terminaison des travaux"
page 93).
Limites du lanceur
Au del des limites imposes par les systmes d'exploitation eux mmes (nombre de processus, taille
mmoire, etc.), le lanceur peut grer jusqu' 10000 lancements ou excutions en parallle un instant t.
Le lancement
Un lancement peut avoir comme origine :
la gnration automatique par le calculateur pour chaque tche planifie,
une intervention sur un lancement (cration autre que par la planification, modification, suspension,
ractivation ou ordre de dclenchement, grce cette fonction interactive ou utilisation des commandes et
api fournies en standard avec Dollar Universe),
la commande de dclenchement d'une tche ou de cration d'un lancement (cf. Manuel de l'interface
commande).
Un lancement peut avoir les tats suivants :
Attente de lancement (la fentre de lancement est dans le futur),
Dsactiv (aprs suspension du lancement ou dsactivation de la tche),
Dbut (examen des conditions),
Attente d'vnement (conditionnement de l'uproc non vrifi),
Horaire dpass (la fentre de lancement est expire).
Voir paragraphe "Pilotage des lancements" page 89 pour l'enchanement de ces tats et paragraphe "Etats des
travaux" page 98 pour leur description dtaille.
Dpassement de la fentre de lancement

La fentre de lancement est la plage de temps accorde pour vrifier que l'ensemble des conditions, constituant
un pralable l'excution de la tche, sont rellement vrifies. Ainsi, un lancement prvu 19 heures avec
une fentre de lancement de deux heures pourra attendre avant son excution effective deux heures pour que
ses conditions soient satisfaites. Si, au terme de cet intervalle, une au moins des conditions n'est pas vrifie,
alors l'excution du lancement sera purement et simplement abandonne. Pour certains cas particuliers, il est
possible d'imposer l'excution du lancement au terme de cet intervalle mme si toutes les conditions ne sont
pas remplies en utilisant l'option "lancement forc".
Dans le cas d'un tat "horaire dpass", le lancement ne peut plus tre soumis. Il est alors ncessaire soit de
l'abandonner (en le supprimant), soit de lui redonner du crdit (par modification de sa fentre de lancement).
Cette fonction est utile lors d'un arrt machine trop long pour que Dollar Universe ait le temps de reprendre
l'ensemble des traitements non excuts. Dans ce cas, au redmarrage, Dollar Universe rgnre l'ensemble
des lancements qui auraient du avoir lieu et leur attribue (si la fentre de lancement est dpasse) le statut
"horaire dpass" : l'utilisateur pourra alors dcider des lancements qu'il souhaite excuter ou abandonner.
86 Ordonnancement
Oprations sur les lancements

Dollar Universe offre des fonctions d'analyse et de contrle de l'exploitation qui permettent d'intervenir sur les
lancements prvus.
Ainsi, il peut tre ncessaire :
de lancer manuellement une excution non planifie,
de modifier ou de supprimer une excution planifie,
de modifier les variables du lancement ou leurs valeurs,
de suspendre (ou de ractiver) un lancement.
Toutes ces oprations sont possibles grce aux fonctions sur les lancements. Ces oprations n'affectent pas la
planification des tches mais uniquement les occurrences de lancements de chacune d'elles.
Suspendre ou ractiver un lancement

Cette fonction permet de suspendre un lancement. Celui-ci ne peut alors plus tre lanc par Dollar Universe
jusqu' sa ractivation par la mme option. Tous les lancements (quel que soit leur "tat") peuvent tre
suspendus, l'exception de ceux qui le sont dj.
Selon l'heure de sa ractivation, le lancement peut passer dans l'tat "horaire dpass" s'il se trouve alors en
dehors de sa fentre de lancement.
Lancer une excution non planifie

Dollar Universe permet de crer manuellement de nouveaux lancements, que ceux-ci portent sur des tches
dj planifies ou non. Si la tche est dj planifie, cette nouvelle occurrence de lancement viendra s'ajouter
celle issue de la planification sans la modifier ni la suspendre.
La cration d'un lancement doit tre renseigne comme une tche. Il faut donc indiquer l'uproc, l'UG et
ventuellement la session ainsi que les informations techniques ncessaires cette excution (cf. paragraphe
suivant). Par dfaut, lors de la cration du lancement sur une tche existante, les informations techniques de
celle-ci sont reconduites.
Lors de la cration d'un lancement sur une machine distante, les dates et heures proposes par dfaut (date de
traitement, fentre de lancement) sont celles de la machine distante.
Modifier des lancements prvus

La mise jour d'un lancement permet d'en modifier tous les paramtres :
Le compte utilisateur d'excution,
Les informations techniques : imprimante, queue d'excution et priorit,
La fentre de lancement,
La fentre d'exclusion du lancement : comprise dans les limites de la fentre de lancement, elle permet
d'interdire momentanment le lancement de la tche,
La date de traitement du lancement vis,
Le lancement sans pilotage : indique si le lancement est effectu avec pilotage (examen des conditions
d'excution) ou non. Cette option est galement propose lors de la reprise d'une excution, elle diffre de
l'option dcrite ci-dessous,
Contrle centralis : rappelle si le lancement concern doit faire l'objet d'un contrle centralis, c'est dire
si son information de dbut et de fin d'excution doit tre transmise au noeud de contrle tel que dfini
dans la table des nuds (cf. paragraphe "Contrle centralis" page 22),
Relance automatique ou mode restart :

Ordonnancement 87
Sous VMS indique si le lancement concern doit faire l'objet d'une soumission avec l'option restart de
VMS, c'est dire si son excution est reprise automatique par VMS aprs une ventuelle interruption du
service de celui-ci.
Sous Windows ou UNIX, l'utilisation de DQM permet d'accder la mme fonctionnalit. Celui-ci
soumettra de nouveau les lancements en cours d'excution au moment de l'arrt machine s'ils bnficiaient
de cette option.
Modification des variables : dans le cas dun lancement cr partir dune tche, ce sont les variables de
la tche qui sappliquent, si le lancement a t cr partir dune session, ce sont les variables de luproc
slectionne qui pourront tre choisies. Dans tous les cas de figure ces variables restent modifiables tant
que le lancement na pas t pilot par lautomate.
Supprimer un lancement
La suppression d'un lancement peut porter sur un lancement issu de la planification, d'une cration d'excution
ou d'un dclenchement via la commande ddie propose par Dollar Universe. La suppression aura pour effet
la disparition du lancement, il ne sera donc pas excut par le lanceur.
La suppression dun lancement na aucun effet sur la tche dont il est issu. Le prochain lancement de cette
tche sera calcul selon les rgles habituelles, par dfaut la fin de la fentre de lancement de la tche.
Si le lancement supprim conditionnait d'autres excutions, celles ci peuvent rester bloques par l'absence
d'excution de ce lancement.
Historique des interventions

L'historique des interventions mmorise toutes les interventions effectues sur les lancements (issus de tches
planifies ou non).
Cette fonction a pour objectif de recenser les diverses interventions manuelles opres sur le processus
d'exploitation automatis. En effet, si ces interventions prsentent un intrt majeur pour agir en temps rel sur
l'exploitation, elles peuvent galement s'avrer dangereuses si elles ne sont pas utilises avec prcaution.
Les interventions sont repres par :
Le code auteur l'origine de la modification (ou de la cration) du lancement,
L'action entreprise sur l'excution :

Lancement interactif : "L",
Modification du lancement (intervalle de pilotage, informations techniques) : "M",
Excution diffre (supprime) : "D",
Suspension du lancement : "H",
Reprise du lancement : "R",
La date et l'heure de l'intervention.
Le dtail des informations techniques lies au lancement (utilisateur, queue batch, fentre de lancement, etc.)
sont galement disponibles.
La base des vnements

Le pilotage d'un lancement est bas sur la rsolution de la formule de lancement de l'uproc correspondante.
Celle-ci comporte un certain nombre de conditions dont la dtermination du caractre "satisfait" ou "non
satisfait" repose sur l'analyse des vnements survenus en exploitation.
Afin de grer une dissociation extrmement stricte des divers environnements, chaque espace dispose de sa
base d'vnements propre.
88 Ordonnancement
Cette base collecte l'ensemble des vnements correspondants aux excutions des uprocs dclars
"mmorises".
Interventions sur les vnements

Les besoins d'intervention sur les vnements sont multiples :
Lors de la premire excution d'une application ou lors de la mise en exploitation d'une application, les
conditions dfinies au niveau des uprocs peuvent faire rfrence des excutions de tches qui n'ont
encore jamais eu lieu (conditionnement d'une tche sur la bonne excution de la mme tche le jour
prcdent par exemple). Dans ce cas, il sera ncessaire de crer artificiellement l'vnement ncessaire de
faon initialiser dfinitivement le cycle d'exploitation.
Lors de processus de reprise ou lors d'intervention suite un incident, il peut tre ncessaire pour
continuer automatiquement une squence d'exploitation de modifier ou de crer des vnements
d'excution, de classes ou de ressources.
Dans ces conditions il apparat que toute intervention sur les vnements d'exploitation peut avoir une
incidence particulirement forte sur le processus d'exploitation.
Durant les phases de lancement, d'excution et de terminaison, la progression dans le temps d'un lancement
peut tre suivie par l'volution de son tat d'excution. Il est inscrit dans le fichier des vnements d'excution.
Ce fichier est utilis par le lanceur pour l'examen des conditions ou la reprise d'excution d'uprocs en cas
d'incident.
Fonctionnement rseau
Dans le cas d'un conditionnement par le rseau (l'uproc conditionnante se trouve sur un noeud diffrent de
l'uproc conditionne), la base des vnements uprocs joue un rle particulier.
Lors du pilotage de l'uproc conditionne, l'attente d'vnement (session, uproc, UG) est transmise au noeud
concern. Lorsque l'uproc conditionnante s'excute, l'vnement est cr dans sa base d'vnements locale
ainsi que dans les bases d'vnements de toutes les uprocs conditionnes en attente de cet vnement.
Les vnements inscrits dans la base d'vnements de l'uproc conditionne correspondent aux tats A (attente
excution), E (excution en cours), T (termin) et I (incident). Chaque changement d'tat est
systmatiquement transmis.
La base d'vnements de l'uproc conditionnante est rgie selon les rgles de mmorisation dfinies, par contre
la base d'vnements de l'uproc conditionne ne conservera que le dernier vnement de l'uproc
conditionnante pour la priode considre (quelles que soient les valeurs de la mmorisation de l'uproc
conditionnante).
Une consigne de terminaison ou la suppression manuelle de lvnement sur la base dvnements de luproc
conditionnante est automatiquement rpercute sur la base dvnement de luproc conditionne. Linverse
nest pas vrai.
Pilotage des lancements

Les diffrentes valeurs des tats des lancements ou des excutions sont rsums dans la figure suivante :
Ordonnancement 89
Attente lancement
Horaire
dpass
Dbut
Dsactiv
Attente
vnement
Refus
Attente excution
Excution en cours
Consignes en cours
Incident
Termin
Etats d'un job
Les valeurs des tats d'excution ont la signification suivante :
D ou "Dbut" : durant toute la phase de lancement et de vrification des conditions.
W ou "Attente vnement": la formule de lancement n'a pas pu tre valide, au moins une condition n'est
pas vrifie.
R ou "Refus" : la formule de lancement n'a pas pu tre valide, au moins une condition fatale n'a pas t
vrifie.
O ou "Horaire dpass": dpassement de la fentre de lancement, que la formule de lancement soit

vrifie ou non.
A ou "Attente excution" : en attente de l'excution d'un job ayant franchi avec succs la phase de
pilotage et place en queue d'excution.
E ou "Excution en cours" : durant toute la phase d'excution du CL.
I ou "Incident" : tat aprs une excution incidente la suite d'une opration dfectueuse dans un
programme ou dans le CL de l'uproc, qui ne permet pas de donner une fin fonctionnelle correcte
l'excution (erreur de lecture, d'criture, d'ouverture de fichier, de division par 0, d'overflow, erreur
applicative, etc ...).
F ou "Consignes en cours" : durant toute la phase de terminaison aprs une excution correcte.
T ou "Termin" : tat la fin de la phase de terminaison sans aucun incident.
D'une manire gnrale, lorsqu'une valeur d'un statut s'inscrit dans les fichiers des vnements ou du suivi
d'exploitation, elle annule la prcdente. Ces critures se font de manire automatique (cf. paragraphe "Etats
des travaux" page 98 des excutions).
Vrification des conditions

Chaque lancement est soumis au pilotage ds que l'heure de dbut de la fentre de lancement est atteinte. Le
statut du lancement est positionn "D" (dbut) pendant toute la dure du pilotage.
Le pilotage dbute par l'examen des classes d'incompatibilit. Celles peuvent tre contrles dans la base des
vnements classes. Si le rsultat de cet examen donne satisfaction, la formule de lancement est son tour
examine.
90 Ordonnancement
Si toutes les conditions ne sont pas satisfaites et que dans les conditions non satisfaites figure au moins une
condition fatale, l'excution du lancement est abandonne (passage du statut "R" refus). Si toutes les
conditions ne sont pas satisfaites (sans condition fatale), le pilotage met le lancement en "attente d'vnement"
et enregistre les vnements qui manquent pour que le pilotage puisse tre russi. Le statut du lancement est
durant toute la dure de l'attente "W" attente vnement.
A chaque fois qu'un vnement uproc ou ressource manquant survient (avant la fin de la fentre de
lancement), le lancement est soumis en vue d'un nouveau pilotage (passage du statut "D" Dbut nouveau).
Rappelons que seuls les vnements bloquants sont mmoriss chaque pilotage de telle sorte que chaque
nouveau pilotage peut faire surgir de nouveaux vnements bloquants.
Les conditions non remplies interdisant la vrification de la formule de lancement sont traites de la faon
suivante :
Si la condition porte sur l'excution d'une tche sur le mme noeud, l'vnement est enregistr. Ds que
Dollar Universe intercepte l'vnement correspondant, le lanceur procde un nouveau pilotage de la
tche,
Si la condition concerne l'excution d'une tche sur un noeud diffrent, l'changeur, provoque
l'enregistrement de la condition attendue sur le noeud concern. Quand Dollar Universe intercepte
l'vnement correspondant la condition, il transmet l'information au noeud initial qui relance un pilotage
de la tche.
Cette cinmatique de gestion des vnements attendus permet de dfinir, au niveau des uprocs, un
conditionnement indpendant de l'architecture logique ou physique.
A l'expiration de la fentre de lancement, si la formule de lancement n'est toujours pas vrifie, l'excution de
la tche sera abandonne et le lancement sera plac dans l'tat "O" horaire dpass. Il est possible de recourir
un lancement forc. Dans ce cas, expiration de la fentre de lancement, la tche sera soumise en ignorant les
conditions d'excution.
Note : le lancement forc ignore globalement la formule de lancement qu'elle soit porteuse on non de conditions
de non-simultaneit; le recours au lancement forc doit donc tre pratiqu avec prudence.
En final, si la formule de lancement est vrifie, le lanceur assure la cration du processus d'excution
(coquille batch) et soumet le CL associ dans ce processus (cf. paragraphe "Soumission de l'uproc" page 93).
Supplance du surveillant de ressources

Lorsque la formule de lancement comporte une condition de ressource (la ressource a t dfinie et la
condition de ressource a t intgre dans la formule de lancement) le lanceur vrifie sur le systme l'attribut
de la condition de ressource concerne sur le noeud local.
Si l'attribut de la ressource est trouv, il continue l'analyse de la formule.
Si l'attribut de la ressource n'est pas trouv, le lanceur charge l'automate "surveillant" de l'avertir lorsque la
ressource sera prsente sur le noeud, il mmorise par ailleurs l'attente de l'vnement ressource. A partir de cet
instant le surveillant scrute cycliquement la prsence de l'attribut de la ressource selon la frquence indique
dans la dfinition de la ressource. Le surveillant cesse son activit sur cette ressource ds qu'il constate sa
disponibilit.
La vrification de l'attribut n'est effectue que si la ressource n'est pas de type logique et si la condition
spcifie la vrification de l'attribut.
Aprs analyse de la ressource et constat de sa disponibilit, le surveillant notifie sa prsence dans la base des
vnements ressource (distinct de la base des vnements jobs), et informe le lanceur qu'il peut piloter
nouveau les uprocs en attente de cette ressource. Une seule demande est effectue au surveillant, un instant
donn, mme si plusieurs uprocs ncessitent la prsence de cette ressource.
Le lanceur reprend alors l'analyse de la formule de lancement.
Note : seules les ressources de type physique (fichier, nom logique, process) font intervenir le surveillant, pour
des ressources de type logique, le surveillant nintervient pas dans le processus de pilotage.
Ordonnancement 91
Vrification des quotas d'une condition de ressource

Si la condition de ressource est vrifie (dans le cas ou le quota demand dans la condition est infrieur au
quota disponible) l'uproc bloque le quota exprim dans la condition pendant toute la dure de son excution.
Lorsque l'uproc se termine (tat T ou I) elle libre le quota correspondant si la ressource a t dfinie "avec
libration automatique", dans le cas contraire la libration devra tre excute par une commande dans un
script (libration manuelle).
Si la condition n'est pas vrifie car le quota demand est suprieur au quota disponible, le lanceur poste une
attente de quota sur cette ressource. L'attente sera nouveau examine par le lanceur lorsqu'une uproc, en se
terminant, librera le quota correspondant ou par l'excution d'une commande.
Note : malgr la souplesse de la prsente fonction, on privilgiera, dans la mesure du possible, pour des raisons de
performances, un processus de dclenchement l'expression de conditions de ressources, ds lors que le
traitement concern doit tre dclench chaque fois que se produit l'vnement technique attendu (exemple :
soumission systmatique d'un traitement chaque arrive d'un fichier et planification d'une tche conditionne par
la prsence d'au moins une occurrence du fichier traiter).
Rservation des quotas d'une ressource et priorit d'ordonnancement

A partir de la version 4.3 de Dollar Universe, sur Windows, UNIX et VMS, une fonction (une fentre en mode
graphique et deux commandes) permet d'effectuer une rservation sur les quotas d'une ressource.
Cette rservation est ralise au titre d'une tche (session, uproc, unit de gestion) qui s'excute dans un
environnement dfini (socit, noeud, espace) pour le compte d'une date de traitement.
Elle permet :
De bloquer des quotas d'une ressource en attendant l'excution de la tche :

Lors du pilotage, le lanceur reconnat la tche qui a rserv les quotas et les lui libre pour autoriser son
excution (ce qui aura pour effet immdiat de bloquer les quotas demand par la condition, selon le
processus habituel).
Des quotas ayant t rservs par une tche, d'autres lancements se prsentant au pilotage pourront tre
mis en attente de ces quotas par le lanceur si la quantit demande n'tait plus disponible.
De dfinir des priorits d'ordonnancement entre des tches ayant effectu des rservation sur la mme
ressource :
Si deux tches ont rserv des quotas sur une mme ressource, celle qui s'excutera en premier est celle
qui aura demand le plus de quotas (quota1 ou quota2) dans sa rservation. Si ceux ci ne sont pas encore
disponibles le lanceur attendra leur libration pour faire partir la tche la plus prioritaire.
Si un lancement se prsente en n'ayant effectu aucune rservation sur cette ressource mais ayant une
condition de ressource pouvant tre rsolue par le lanceur car les quotas sont disponibles, alors le lanceur
validera la condition et autorisera l'excution du lancement (mme si d'autres tches sont en attente pour
des raisons de rservation).
Exemple : rservation de ressource

La commande :
uxrsv RES RES=PRIO_ORDO ESP=X UPR=IU_DT1 MU=S01 QT1=90 QT2=0 PDATE=${S_DATRAIT}
Rserve, pour la tche dfinie par l'uproc IU_DT1, l'unit de gestion S01 dans l'espace exploitation, pour la
date de traitement courante, la ressource de rfrence PRIO_ORDO avec un quota qt1 de 90.
Si la ressource PRIO_ORDO dispose d'un quota qt1 maximum de 100, 10 restent libres l'issue de l'excution
de la commande.
Une autre tche, n'ayant pas effectu de rservation sur cette ressource, pourra s'excuter si sa condition sur
cette ressource demande un quota infrieur 10.
Si une deuxime rservation est demande sur la ressource PRIO_ORDO par la commande suivante :
uxrsv RES RES=PRIO_ORDO ESP=X UPR=IU_DT2 MU=S01 QT1=10 QT2=0
Ces deux commandes dfinissent une priorit de pilotage par Dollar Universe, c'est la tche qui a rserv le
plus de quotas qui s'excutera en premier, dans cet exemple : celle dfinie sur l'uproc IU_DT1.
92 Ordonnancement
Soumission de l'uproc
Lorsque le lanceur a valid la phase de pilotage d'une uproc, il la soumet l'excution par l'intermdiaire de la
"coquille batch" u_batch. C'est cette "coquille batch" qui initialise l'excution de l'uproc (connexion sur le
compte de soumission) et effectue la phase de terminaison (restitution du code retour).
U_BATCH
Pr traitement
UPROC
Post traitement
Soumission de l'uproc
Le code retour de l'uproc est positionn en fonction de la valeur de la variable RESEXE dans le script de
l'uproc sous Windows ou UNIX (ou S_RESEXE sous VMS) selon la rgle suivante :
Systme
Variable
Uproc dans l'tat

Termin
Uproc dans l'tat

incident
Windows
RESEXE
#0
UNIX
RESEXE
#0
VMS
S_RESEXE
"V"
"I"
Traitements complmentaires
Sur Windows, UNIX et VMS, l'excution de l'uproc (script ou DCL) peut tre prcde par l'excution d'un
pr traitement qui sera commun pour toutes les uprocs. Si ce traitement existe, il sera excut
systmatiquement avant chaque uproc.
L'excution de ce pr traitement peut tre, par exemple, utilise pour dfinir des variables d'environnement ou
des noms logiques qui seront connus de l'uproc lors de son excution. Cela permet d'allger les CL des
dclarations communes.
De faon identique, l'excution de l'uproc peut tre suivie de l'excution du post traitement qui sera commun
pour toutes les uprocs. Si ce traitement existe, il sera excut systmatiquement aprs chaque uproc.
Le pr traitement se nomme U_ANTE_UPROC et il est plac dans le rpertoire mgr, sous VMS il doit tre
plac dans le rpertoire des excutables.
Le post traitement se nomme U_POST_UPROC et il est plac dans le rpertoire mgr, sous VMS il doit tre
plac dans le rpertoire des excutables.
Sous VMS, ces deux procdures sont livres avec l'extension "TEMPLATE" dans le rpertoire des
excutables et sont adapter en fonction des besoins.
Terminaison des travaux

C'est l'tape finale de l'excution d'une tche. Elle est assure par le lanceur.
Le lanceur est activ chaque fin d'excution du CL d'une uproc. A ce titre :
Il excute les consignes de terminaison associes l'uproc concerne,
Ordonnancement 93
Il insre l'vnement correspondant dans la base des vnements,
Il compare l'vnement qu'il traite aux vnements attendus et active ventuellement le pilotage quand il y
a correspondance entre l'vnement cr et un vnement attendu,
Il soumet ventuellement l'uproc fille de la session. Quand les soumissions doivent tre excutes sur des
noeuds diffrents du noeud sur lequel s'excute le lanceur, l'changeur excute l'ensemble des oprations
ncessaires l'activation du lanceur du ou des noeuds concerns.
Il prend en charge la remonte des vnements d'exploitation vers le site de contrle, dans le cas d'un
contrle centralis d'une exploitation multi-sites.
Il permet ainsi de boucler la chane initie par le calculateur et les fonctions de lancement et de pilotage
du mme lanceur.
Communication inter machines

Rle de l'changeur
L'changeur est le process du moteur batch de Dollar Universe qui prend en charge l'ensemble des
communications batch entre les diffrents noeuds du rseau (en soulageant le lanceur).
Il est ainsi utilis pour :
Soumettre des tches sur des units de gestion distantes,
Transmettre des attentes d'vnement (conditionnement d'une "uproc locale" sur la fin d'excution d'une
"uproc distante" par exemple),
Distribuer les diffrents objets du paramtrage de Dollar Universe,
Effectuer le transport des informations lors d'oprations de contrle centralis.
Il bnficie d'un mode de fonctionnement vnementiel (ncessitant la dclaration d'un objet DECNET sous
VMS) et a recours un cycle paramtrable pour scuriser les changes d'informations.
Les informations de production qui transitent par l'changeur sont accessibles dans la base des "Echanges
job". Les informations de distribution sont accessibles dans la base des "Echanges distribution".
Principes de fonctionnement
Le moteur batch gre les soumissions des tches par l'intermdiaire du lanceur selon le processus suivant :
Si les lancements sont dclencher sur une unit de gestion rsidant sur le mme noeud, le lanceur les
soumet au pilotage,
S'ils doivent tre dclenchs sur un noeud diffrent de celui de la tche provocante, le lanceur utilise les
changeurs du noeud origine et des noeuds cibles pour informer les lanceurs des noeuds concerns.
Lanceur
Lanceur
Echangeur
Echangeur
2
rseau
Mcanismes de l'changeur
94 Ordonnancement
Dans ce dernier cas, le lanceur local transmet l'ordre de pilotage son changeur (tape 1). Celui ci transmet la
demande l'changeur de l'unit de gestion concerne (tape 2). L'changeur distant avertit le lanceur (tape
3) qui soumet le lancement sur l'unit de gestion.
Note : dans le cas d'une soumission sur un nud distant, cela signifie que le paramtrage ncessaire doit tre
disponible sur le nud distant (uproc complte et session), il doit donc avoir t distribu vers une unit de
gestion de ce noeud.
Une condition d'enchanement d'une tche locale sur une tche distante utilise les mmes principes de
fonctionnement.
Si l'vnement attendu n'est pas trouv en local par le lanceur, il formule une demande d'attente d'vnement
l'changeur (tape 1). L'changeur local transmet la demande avec le nom de l'metteur l'changeur distant
(tape 2). Celui ci la transmet au lanceur distant (tape 3).
Si l'vnement est disponible, la rponse est immdiate (elle prend le chemin inverse), sinon le lanceur distant
poste une attente d'vnement, lorsque celle-ci sera rsolue la rponse sera transmise au lanceur metteur qui
rsoudra son attente d'vnement et inscrira celui-ci dans sa base d'vnements (afin de ne pas le chercher de
nouveau chaque fois qu'il en aura besoin).
Note : pour une description technique des processus de communication inter machines, se reporter au manuel
d'administration.
Interruptions de service
En cas d'incident machine, quatre cas de figure peuvent se prsenter au lanceur :
L'incident a lieu alors que le lancement n'a pas t effectu. Dans ce cas, Dollar Universe reprendra
automatiquement ce lancement pour un examen de validit de la fentre de lancement et un ventuel
pilotage. Si le lancement tait dj en attente, celui-ci n'est bien videmment pas considr (inutile),
L'incident survient au cours du lancement. Dans ce cas, aucune opration irrmdiable n'a t effectue, et
il suffit de reprendre le lancement et de le soumettre un nouveau pilotage (ralis automatiquement par
le moteur batch),
L'incident est contemporain de la phase de terminaison. Dans ce cas, une fonction de Dollar Universe
lanc au "boot" ou l'IPL de la machine reprend et termine les consignes de terminaison de chaque
lancement rest dans l'tat "F" consignes en cours,
L'incident a lieu en cours d'excution. Dans ce cas, Dollar Universe offre la possibilit de reprendre
automatiquement les lancements correspondants, grce un paramtrage spcifique associ chaque
tche (relance automatique sur Windows ou UNIX si DQM est utilis ou restart sur VMS).
Au moment de son dmarrage, Dollar Universe considre l'ensemble de son portefeuille de travaux en
cours et se synchronise de nouveau avec ces mmes traitements (pour attendre leur fin). S'ils ne sont plus
prsents, il les dclare "incidents". Dans ce cas, la dfinition de jalon dans le CL permet une reprise
partielle du traitement interrompu.
En cas d'incident machine, le calculateur recalcule automatiquement tous les lancements (en espace
d'exploitation) qui auraient du tre crs pendant l'interruption de service du systme d'exploitation ou de
Dollar Universe lui-mme.
Ces dispositions garantissent une parfaite scurit de fonctionnement, y compris dans le cas du seul arrt de
Dollar Universe (mme si ceci constitue une anomalie grave).
Ordonnancement 95
Suivi des excutions

Objectifs
Dollar Universe accorde une place particulirement importante au contrle et la surveillance d'exploitation,
afin de faciliter le suivi de l'exploitation, d'acclrer l'identification des incidents, leur diagnostic et les
processus de reprise correspondants. Une fonction spcifique leur est ddie.
La liste des excutions de Dollar Universe permet de visualiser dynamiquement tout ou partie (selon les
critres de slection dfinis) des travaux excuts ou en cours d'excution. Toutes les informations essentielles
sont directement accessibles :
La trace automate mise en forme par Dollar Universe, consignant les vnements attendus ainsi que les
tapes franchies par le travail. Cette trace peut intgrer des commentaires (consignes d'exploitation par
exemple) transmis depuis le script de l'uproc via l'excution d'une commande spcifique de Dollar
Universe,
Le log d'excution du travail,
Les prochains travaux soumettre, etc.
Ainsi que les principales fonctions permettant d'intervenir sur le droulement du processus d'exploitation :
Les reprises sur incident,
Le lancement interactif d'un travail non planifi,
L'affichage et la mise jour d'un vnement d'exploitation...
La liste des excutions concentre en un seul point tous les lments permettant l'exploitant d'intervenir sur le
processus d'exploitation. Une console peut tre ddie pour cette seule fonction.
Contrle centralis
Il est possible partir d'un noeud dfini comme noeud de contrle centralis (cf. paragraphe "Contrle
centralis" page 22) de visualiser les excutions locales ainsi que les excutions distantes dfinies avec
l'option "contrle centralis" (cf. paragraphe "Contrle centralis d'une tche" page 67).
Pour les tches dfinies avec l'option "contrle centralis", les vnements concernant le dbut et la fin
d'excution sont systmatiquement transmis vers le noeud de contrle centralis. Ainsi, la fonction de suivi
des excutions du noeud de contrle centralis affiche l'ensemble des excutions principales survenant sur le
rseau de machines.
Suivi de l'exploitation 97
La trace automate ou le log d'excution des jobs distants ne peux pas tre affich directement sur le nud de
contrle centralis mais sont disponibles sur le nud d'excution en cas de besoin.
Etats des travaux

Les tats des travaux affichs dans la liste des excutions sont les suivants :
Statut
Code
Signification
Termin
Excution termine normalement.
Incident
Excution termine en incident. Ce statut est normalement gnr par la procdure

elle-mme (cf. Manuel de l'interface commande chapitre "CL d'excution" pour de
plus amples informations sur les possibilits offertes de gestion de codes retour)
Consignes en
cours
Ce statut n'apparat que lors d'une terminaison correcte de la procdure et correspond

l'excution des consignes de terminaison. Quel que soit le statut final, les autres
oprations de la phase de terminaison demeurent effectues : ractivation des
vnements en attente ou demande de lancement des uprocs suivantes dans une
session.
Excution en
cours
Excution de la tche en cours
Attente
d'excution
Cet statut correspond une mise en queue batch du lancement suite un pilotage
russi (conditionnement satisfait). Cette phase du lancement est plus ou moins durable
en fonction des caractristiques techniques instantanes de la queue batch.
Dsactiv
Lancement suspendu. Ce statut peut survenir suite une intervention de ce type : dans
la fonction lancements prvus (ou grce la commande correspondante) ou dans la
prsente fonction de contrle ou la fonction associe de gestion des queues batch.
Refus
Cet abandon se produit lorsqu'une condition fatale est rencontre au moment d'un
pilotage de la tche.
Attente
d'vnement
Dans le cas o toutes les conditions, dont aucune n'est fatale, ne sont pas satisfaites, le
lancement correspondant est mis en attente. Une mme tche peut faire l'objet de
plusieurs vnements de type "attente vnement". Chacun d'entre eux correspond
une tentative de pilotage n'ayant pas abouti. En effet, ds son premier pilotage non
satisfait une tche est mise en attente de l'vnement correspondant, l'apparition de
l'vnement attendu provoquant un nouveau pilotage. Si ce nouveau pilotage met en
vidence une autre condition non satisfaite, la tche est nouveau mise en attente etc.
Horaire
dpasse
Fentre de lancement dpasse. Ce statut intervient chaque fois qu'un vnement

attendu survient trop tard ou lorsque l'une ou l'autre des fonctions calculateur et/ou
lanceur sont restes absentes trop longtemps.
Dbut
Pilotage en cours. Cette phase correspond l'examen des conditions d'excution du

lancement. Il est noter que ce statut est considr bloquant vis vis de conditions
ventuelles de non-simultanit (ou critres d'incompatibilit) d'autres traitements.
L'ordre d'enchanement des tats est dcrit au paragraphe "Pilotage des lancements" page 89.
Diagnostics de l'exploitation
Le diagnostic de l'exploitation peut tre effectu 4 niveaux :
l'tat de l'excution renseigne sur la phase de lancement ou d'excution du job ainsi que sur son rsultat
final,
les "pilotages antrieurs" prsentent l'historique des pilotages des lancements avec la trace automate
associe (cf. paragraphe "Afficher filiations ou "pilotages antrieurs"" page 99),
la "trace automate" prsente la vue dtaille de l'automate : consignes d'exploitation, vnements

attendus (cf. paragraphe "Afficher historique ou Trace automate" page 99),
98 Suivi de l'exploitation
la "trace systme" prsente le log d'excution de l'uproc, elle peut tre consulte tout moment (cf.
paragraphe "Visualiser le log ou Trace systme" page 100).
Les lments de diagnostic de Dollar Universe lui mme sont dcrits dans le manuel d'administration.
Interventions sur les excutions

Arrter une excution
Cette fonction n'est accessible que si l'tat de l'excution est "Excution en cours". Elle a pour effet d'arrter
l'excution de l'uproc au niveau systme et donc d'arrter les sous-process dpendants. L'excution prend alors
l'tat "Incident".
Reprendre une excution

Cette fonction n'est accessible que sur une excution dans l'tat "Incident".
L'uproc doit avoir t paramtre "mmorise" (cf. paragraphe "Mmorisation des vnements" page 43) pour
que cette fonction soit accessible. Il demeure possible de modifier ou de crer l'vnement considr pour le
dclarer "Incident" pour pouvoir reprendre l'excution correspondante.
Une excution peut tre reprise en diffr. Il suffit de spcifier lors de la reprise les date/heure de dbut et
date/heure de fin de priode (sauf interface caractres). Il est galement possible de modifier la valeur des
variables du job.
Afficher filiations ou "pilotages antrieurs"

Dollar Universe ne conserve dans sa fonction de suivi qu'une seule occurrence des examens successifs d'un
lancement. Ces diverses occurrences peuvent tre consultes par la fonction des "pilotages antrieurs" et/ou
dans l'historique des excutions.
Cette fonction permet de visualiser l'ensemble des pilotages dont a fait l'objet un lancement avant d'tre
excut ou abandonn ainsi que les "trace automate" correspondant chaque pilotage.
Afficher historique ou Trace automate

La trace automate de Dollar Universe se prsente sous la forme d'un cran format dans lequel figure des
messages labors par les divers composants des automates.
Cette fonction permet d'accder l'historique de l'excution de l'uproc et d'obtenir l'cran les rfrences de
l'uproc suivies de la date et l'heure de pilotage par le lanceur, la date de traitement, les variables, la date et
l'heure et le numro d'entre dans la queue batch pour excution et un message explicatif relatif l'tat de la
tche.
Chaque ligne est gnralement compose de la date (exprime selon le format de la variable U_FMT_DATE),
de l'heure (exprime selon le format HH:MM:SS) et d'un libell de message. Ces messages sont par exemple :
Lors du franchissement de chacune des phases essentielles de l'excution d'un lancement :

"DATE HEURE dbut du pilotage",
"DATE HEURE soumission en queue Batch",
"DATE HEURE dbut d'excution Batch",
"DATE HEURE dbut des consignes de terminaison",
"DATE HEURE *** FIN ANORMALE DE LA TACHE ***",
"DATE HEURE *** FIN NORMALE DE LA TACHE ***".
Pour tous les lancement issus d'une uproc ayant une priode fonctionnelle :
"date de traitement DATE"
A chaque excution d'une commande uxset dans le script de l'uproc, un commentaire appropri est
affich, par exemple :
"DATE HEURE passage au jalon n : NN",
Eventuellement les variables de l'uproc ainsi que leur valeur. VAR indique le nom de la variable, endessous est affiche sa valeur, par exemple (trois variables de type : date, numrique et texte) :
VAR : VARDATE 2002/07/01
VAR : VARNUM 123
VAR : VARTXT Last var
Durant l'accomplissement de chacune des tapes principales de la tche :

"*** Tche refuse au pilotage ***",
"*** Uproc en cours d'excution ***",
Au cours du pilotage :
o Pour une classe d'incompatibilit ouverte :
incompatibilit avec l'uproc
o Pour une condition d'enchanement non vrifie, par exemple :
Enchanement Cond. 01 Prop. 01 :
Ench. :
D_BACKUP SIEGE
Soit : session (vide dans l'exemple) uproc (D_BACKUP) UG (SIEGE)
(20040525) Absent (l'vnement identifi prcdemment est absent).
20040525
Absent
date de traitement
o Pour une condition de ressource non vrifie, par exemple :

Ressource
Cond. 01 Prop. 01 :
Ress. : D_FIL_PAY
FIL Absent
C:\temp\FilePay.txt
Absent
Soit : ressource (D_FIL_PAY) type (FIL : fichier) Absent (la ressource identifie prcdemment est
absente).
o Pour une condition de non simultanit non vrifie, par exemple :
Simultanit Cond. 01 Prop. 01 :
Simu. : SESS_NS
-0000152 UPR_NS_1 -0000442 S_SATURN
Present
Soit : session (SESS_NS) numro de session (0000152) - uproc (UPR_NS_1) numro d'uproc
(0000442) - UG (S_SATURN) Present (l'excution de la tche cite a t trouve).
Les statistiques sur l'excution de la tche :

Dure
temps elapsed
CPU
temps cpu
PGF
page faults
(sur VMS uniquement)
DIO
direct IO
BIO
bufferized IO
soit par exemple (sous Windows PGF, DIO et BIO ne sont pas renseigns):
*** TOTAL *** - Duree : 00.00:00:10.00 - CPU : 00.00:00:00.00
- PGF
: ???? - DIO : ???? - BIO : ????
Visualiser le log ou Trace systme

L'utilisateur peut consulter le log de l'excution slectionne sous diteur. La consultation peut tre ralise
tout moment, que l'excution soit en cours ou termine. Dollar Universe inscrit lui mme dans le log la sortie
standard et la sortie erreur de l'excution.
Par exemple :
C:\WINNT\system32>ECHO OFF
_!================================================
$!** PROCEDURE .. : D_LOAD_FIL
$!** VERSION .....: 000
$!** EXECUTION .. : 0000445
$!** SESSION .... : D_LOAD_BCK
$!** VERSION .... : 000
$!** EXECUTION .. : 0000151
$!** DATE TRAIT.. : 25/05/2004
_!-----------------------------------------------$!** PARAMETRES.. : AUCUN
_!-----------------------------------------------_!** VARIABLES
VARDATE
: 2002/07/01
VARNUM
: 123
VARTXT
: Last var
_!================================================
1 fichier(s) copi(s).
Ce fichier log commence systmatiquement par une entte formate par Dollar Universe qui affiche :
le nom de l'uproc, sa version et son numro d'excution,
le nom de la session, sa version et son numro d'excution,
la date de traitement,
ventuellement les paramtres reus par l'uproc,
ventuellement les variables de l'uproc,
et les sorties standard et erreur de l'excution du script.
Les fichiers logs des excutions sont situs dans le sous-rpertoire log de l'espace (accessible par les variables
UXLxx avec xx=AP, IN, SI ou EX selon l'espace).
Le nom du fichier log est standardis (cf. manuel d'administration, paragraphe "Gestion des logs").
Historiques et statistiques
Un ensemble de fonctions de Dollar Universe sont ddies l'historique des vnements d'exploitation. Ces
fonctions permettent :
de disposer d'un journal des interventions effectues sur les "lancements" : historique des interventions,
d'avoir un historique complet de l'exploitation tout en autorisant la purge de la liste des excutions au jour
le jour : historique des excutions,
de bnficier des informations indispensables lies la consommation des ressources par l'ensemble des
traitements : statistiques,
de connatre, tout instant, l'ensemble des oprations de transfert, de distribution ou d'insertion effectues
sur le paramtrage de Dollar Universe et d'avoir ainsi une vue globale des divers paramtrages mis en
exploitation : historique des distributions.
Historique des excutions

La liste des excutions permet de suivre les diffrentes tapes de l'excution d'une tche. Les vnements
correspondants peuvent tre purgs ds que ncessaire, la liste des excutions ne constitue pas un historique
des excutions.
Les vnements mmoriss sont utiliss pour vrifier la formule de lancement de chaque uproc. Pour des
raisons d'exploitation, ces vnements peuvent eux-mmes tre dtruits manuellement ou automatiquement
via les consignes de terminaison des uprocs.
Dollar Universe gre donc un troisime niveau d'historique dans lequel aucune purge manuelle ou alatoire
n'est possible, autre qu'une purge systmatique base sur une priode de rtention dfinie, de manire globale,
au niveau de Dollar Universe.
Note : toutes les tentatives de lancement effectues par Dollar Universe sont consignes dans cet historique. Ainsi,
si un mme lancement a t pilot trois fois (suite l'arrive d'vnements attendus), celui-ci apparatra trois fois
avec trois numros d'uproc diffrents mais un mme numro de lancement.
Informations disponibles
Les excutions sont repres par l'uproc, session, l'UG et par le numro d'excution. Les informations
contenues dans cet historique permettent de connatre :
Le compte de soumission de la tche, ou le demandeur du lancement (dans le cas d'une intervention sur
un lancement),
Le mode de lancement de la tche. Il peut prendre trois valeurs :

"P" comme planifie,
"L" comme lancement interactif,
"R" comme reprise,
Les dates et heures de dbut et de fin d'excution,
Le code tat final de l'excution,
Le dtail des informations techniques lies la tche (queue batch, fentre de lancement, etc.),
Les valeurs des variables,
La trace construite par Dollar Universe lors de l'excution de la tche.
Statistiques
Dollar Universe mmorise pour chaque excution des travaux, la consommation des ressources essentielles
(CPU, I/O directes et bufferises, mmoire, temps elapsed, ...en fonction du systme d'exploitation) et la dure
d'excution sur les cent dernires excutions et en calcule les valeurs mdianes.
Cette mthode de calcul permet d'obtenir des valeurs correspondant 50% des excutions. Elle permet
galement de limiter l'impact de cas exceptionnels, non significatifs, sur les valeurs calcules. L'ensemble de
ces informations peuvent tre visualises sous forme graphique. Pour effectuer des simulations de temps
d'excution prcises, elles peuvent tre mises jour (limination de "points aberrants", cration de valeur
estime pour de nouveaux travaux jamais excuts).
Les jobs dont la dure est infrieure 1 seconde (temps elapsed ou temps CPU) apparaissent dans les
statistiques comme ayant une dure de 1 seconde.
Les fonctions de modification ne sont utilises que dans des cas ou l'on souhaite intervenir sur les valeurs
statistiques de certaines tches afin de modifier le comportement d'autres fonctions de Dollar Universe et
notamment le suivi graphique d'exploitation. Seule la fonction "histogramme" ne rpond pas cette rgle dans
la mesure o cette fonction permet de visualiser, sous forme graphique, l'volution dans le temps de la
consommation de ressources des tches.
La fonction de cration est ncessaire pour initialiser l'ensemble des paramtres grs pour une tche
nouvelle.
La fonction de modification permet d'altrer partiellement l'ensemble des donnes disponibles pour une
tche donne.
La fonction de suppression permet de dtruire compltement une tche des statistiques, la fonction
d'annulation permettant d'initialiser les valeurs statistiques d'une tche.
Oprations de purge
Base des vnements
La base des vnements est alimente par les excutions des uprocs qui ont t dclares mmorises. Suivant
les paramtres de mmorisation indiqus lors de la dfinition de l'uproc (cf. paragraphe "Mmorisation des
vnements" page 43), une ou toutes ses excutions seront conserves sur le nombre de priodes indiqu.
Cette base servant rsoudre le conditionnement des autres uprocs, il convient d'tre prudent sur sa purge.
Une purge automatique peut tre ralise par l'utilisation des consignes de terminaison (cf. paragraphe
"Consignes de terminaison" page 54). Elles ont pour fonction de purger les vnements indiqus la fin de
l'excution de l'uproc.
Une purge manuelle peut galement tre pratique, en slectionnant les vnements et en les supprimant de la
base.
Suivi des excutions

La purge de la liste des excutions est ralise manuellement. Cela signifie que toutes les occurrences
slectionnes seront purges et donc disparatront de la fentre de suivi. Si plusieurs excutions de la mme
procdure sont purges, elles seront toutes supprimes : la purge ne conserve pas la dernire excution. La
purge du suivi d'exploitation n'a aucune incidence sur le droulement de l'exploitation. Elle ne peut empcher
que la reprise d'une excution qui aurait t purge.
Les excutions restent prsentes dans l'historique des excutions et, si l'uproc a t dclare "mmorise", dans
la base des vnements.
Lexcution de luproc IU_PUR permet de supprimer de la liste des excutions les enregistrements voulus
(plusieurs variables permettent d'affiner la slection). Se rfrer au manuel d'administration pour son
utilisation.
Le lanceur peut effectuer cette purge, des variables d'environnement doivent tre dfinies. Se rfrer au
manuel d'administration.
La liste des excutions peut galement tre purg par lintermdiaire dune commande de purge. Se rfrer au
manuel de l'interface commande pour son utilisation.
Historiques
La purge des historiques est effectue par l'uproc IU_PUR. Cette procdure doit tre planifie selon une
priodicit au maximum gale un mois. Elle supprimera des fichiers historiques tous les traitements dont la
date de validit est dpasse.
Depuis la version 4.3 de Dollar Universe, la purge des excutions ne conserve plus dans le fichier historique la
dernire excution des procdures, quelles que soient leur date. La planification et l'excution de cette uproc
doit tre ralise pour chaque espace de la socit.
Se rfrer au manuel d'administration pour plus de dtails.
Fichiers log
Plusieurs fichiers log sont gnrs par Dollar Universe :
Le log gnral de Dollar Universe dclar lors de l'installation (sauf sur OS400),
Les logs de fonctionnement des process,
Le log d'excution de chaque procdure.
La purge de ces fichiers log n'est pas ralise automatiquement par Dollar Universe, elle est la charge de
l'administrateur qui peut ainsi prendre en compte ses propres contraintes d'exploitation.
Se rfrer au manuel d'administration pour plus de dtails.
Release notes
Release notes Dollar Universe v5.0 SPRE0025

Utilisateurs
Prsentation des nouvelles fonctionnalits du contrle d'accs, voir paragraphe "Le contrle d'accs" page 7.
Refonte de la prsentation des utilisateurs : voir paragraphe "Les utilisateurs" page 27.
Description dtaille des nouvelles fonctionnalits du contrle d'accs, voir paragraphe "Le contrle d'accs"
page 27 :
"Le contrle d'accs aux serveurs - les proxies" page 27,
"Le contrle d'accs aux donnes et aux fonctions fichier SECURITY" page 29.
Description des fonctions de personnalisation des interfaces : voir paragraphe "La personnalisation des
interfaces" page 29.
Paramtrage
Utilisation des chemins UNC dans les ressources: voir paragraphe "Codification" page 34.
Description de l'environnement logique d'excution de l'uproc : voir paragraphe "Paramtres d'excution" page
38.
Mise en production
Nouvelles rgles de distribution de la table des utilisateurs et mode "Ajout" : voir paragraphe "Distribuer une
table d'administration" page 76.
Dtails sur l'extraction et l'insertion de la table des utilisateurs, voir paragraphe "Extraction / insertion de
donnes" page 77.
Ordonnancement
Dtail du comportement des automates lors :
de la modification d'une tche : voir paragraphe "Impact des modifications d'une tche" page 84,
de l'activation / dsactivation d'une tche : voir paragraphe "Activation - dsactivation d'une tche" page 84.
Release notes 105
Heures de lancement sur une machine distante : voir paragraphe "Lancer une excution non planifie" page
87.
Uniformisation des libells des tats des lancements et des excutions dans tout le produit.
Dtail des informations obtenues dans la trace automate : voir paragraphe "Afficher historique ou Trace
automate" page 99.
Dtail des informations obtenues dans la trace systme : voir paragraphe "Visualiser le log ou Trace systme"
page 100.
Nouvelles fonctionnalits de purge : voir paragraphe "Oprations de purge" page 103.
Release notes Dollar Universe v5.1

Nouvelle variable dans 'environnement de l'uproc : S_FORCEFINPER, voir paragraphe "Paramtres
d'excution" page 38.
Les limites du lanceur ont t dtailles au paragraphe "Limites du lanceur" page 86.
106 Release notes
Glossaire
Attente vnement
Etat d'un lancement situ dans sa fentre de lancement dont la formule de lancement n'a pas t entirement
rsolue.
Calculateur
Le calculateur est un automate spcifique un espace. Il procde, de manire vnementielle, au calcul de la
prochaine date de planification de chacune des tches et ractualise cette planification chaque fois que leur
fentre de lancement est chue ou lors d'une modification de la tche ou du calendrier de rattachement.
Calendrier
Dfinit les types des jours : ouvrs, chms et fris sur une tendue d'annes pour une unit de gestion, un
type d'unit de gestion ou par dfaut pour l'espace (c'est le calendrier gnral, il ne porte pas de nom).
Le calendrier sert de rfrence l'automate calculateur pour le calcul de la planification des tches.
Date 1re planification

Correspond une date de mise en exploitation. Selon les paramtres de planification, le calculateur ritrera
ventuellement son calcul jusqu' trouver une date de planification suprieure cette date de premire
planification pour gnrer le premier lancement de cette tche.
Date d'application
Date partir de laquelle le calcul de la rgle s'applique (indispensable, par exemple, pour une rgle invoquant
une priode de deux semaines : il est ncessaire de savoir partir de quelle semaine on commence le calcul).
La date d'application doit correspondre une date de dbut de la priode dfinie pour la rgle. Par exemple
pour une rgle de priode "semaine", la date d'application doit correspondre un lundi.
Date de traitement
Date qualifiant la priode pour laquelle l'uproc travaille. La date de traitement peut tre distincte de la date de
planification du traitement (ex : pour une planification au 3 fvrier, la date de traitement peut tre
automatiquement calcule, via un algorithme dfini par le client, comme tant le mois prcdent, c'est dire le
1er janvier).
La date de traitement est utilisable dans le script de l'uproc dans une variable ou dans les conditionnements
entre uprocs.
Glossaire 107
Echangeur
L'changeur est un automate spcifique un espace. Il intervient dans les communications rseau au sein
d'une socit de Dollar Universe pour effectuer des oprations de distribution du paramtrage, de transmission
d'vnements rseau ou d'ordres de soumission rseau.
Espace
Environnement de travail au sein d'une socit.
Quatre espaces sont proposs et nomms : application, intgration, simulation et exploitation. L'espace
d'exploitation est le seul dmarrer obligatoirement, les autres sont facultatifs.
Les espaces sont des environnements tanches d'exploitation mais qui bnficient de fonctions interactives de
transfert de paramtrage (au sein d'une mme socit).
Formule de lancement
Equation boolenne rassemblant les conditions ncessaires l'excution d'une uproc. Cette formule peut
contenir tous les types de conditions : enchanement, non simultanit ou ressource relies par les oprateurs
boolens et, ou et pas. Elle peut contenir jusqu' 99 conditions et 9 niveaux de parenthses.
L'ordre de la formule de lancement dtermine l'ordre de pilotage par l'automate lanceur.
Horaire dpasse
Etat d'un lancement dont le pilotage par le lanceur n'a pas pu aboutir une soumission pendant la fentre de
lancement qui lui tait dfinie.
Incident
Etat d'une excution qui s'est anormalement termine, soit par positionnement applicatif de la variable de
sortie du script (cf. Etat termin), soit par une sortie brutale de l'excution du script.
Lancement
Un lancement est une occurrence de calcul d'une tche. Il peut tre le rsultat de la planification par le
calculateur ou d'une demande explicite de cration par un oprateur, ou d'une provocation (par le droulement
d'une session ou par une commande).
Lanceur
Le lanceur est un automate spcifique un espace. Il procde, de manire vnementielle, l'ordonnancement
des lancements. Il travaille principalement avec la date et heure du prochain lancement, laquelle il se rveille
et effectue les oprations de pilotage et de soumission des traitements.
Il est galement rveill par des vnements attachs la fin d'excution des traitements pour effectuer de
nouveaux pilotages.
Noeud
Appellation logique (limite 10 caractres) reprsentant une machine physique.
Le fichier uxsrsrv.sck du rpertoire mgr de la socit fournit la correspondance entre le nom de noeud (au
sens de Dollar Universe) et le nom physique de la machine (au sens du systme d'exploitation).
Priodicit du traitement, au sens de l'applicatif (ex : un bilan comptable est mensuel) ventuellement distincte
de la priodicit de planification du traitement. C'est la priode fonctionnelle qui dfinit le format de la date de
traitement (journalier, hebdomadaire, mensuel).
108 Glossaire
Pilotage
Examen par l'automate lanceur des conditions d'excution d'une uproc et mise en attente ventuelle du
lancement si les conditions ne sont pas satisfaites.
Lors du pilotage l'tat du lancement est "dbut", si les conditions ne sont pas rsolues l'tat du lancement
devient "attente vnement", si les conditions sont rsolues le lanceur procde la soumission du traitement.
Rgle
Algorithme priodique (jour, semaine ou mois) permettant de calculer des dates de planification d'une tche.
Les rgles travaillent sur le calendrier de l'unit de gestion pour laquelle s'excute la tche concerne (si celuici n'existe pas, celui du type de l'unit de gestion puis le calendrier gnral du noeud sont recherchs).
Ressource
Une ressource permet, via un identifiant logique, de dcrire une ressource systme (un fichier par exemple)
que l'on souhaite surveiller pour conditionner l'excution d'une uproc.
Par extension une ressource peut galement tre logique (ou virtuelle) elle n'a plus de ralit physique mais est
alors gre par des notions d'exclusivit ou d'attribution de quotas (par rapport un maximum).
Session
La session est un ensemble homogne d'uprocs (ex : mme planification). Elle permet de dcrire un ordre de
soumission des uprocs et de dfinir des processus dgrads en cas d'incident d'excution d'une uproc.
Socit
La socit reprsente une installation de Dollar Universe et par consquent un environnement de travail (de
donnes) pour l'automatisation d'une production. La socit est un environnement tanche d'exploitation qui
ne peut communiquer qu'au travers de commandes d'import/export de son paramtrage.
Soumission
Dans le cas o la formule de lancement d'une uproc est rsolue le lanceur soumet l'excution du traitement au
gestionnaire de queues batch ou en son absence au systme d'exploitation.
Surveillant
Le surveillant est le seul automate a tre commun tous les espaces sur un noeud. Sa fonction est de prendre
en charge la surveillance des ressources la demande du lanceur, lorsque celui ci examine une uproc dont la
condition de ressource (physique) n'est pas satisfaite. Le processus de surveillance est alors cyclique, selon
une priode dfinie pour chaque ressource.
Tche
Caractristiques techniques et de planification d'excution d'une uproc ou d'une session sur une unit de
gestion. Trois types de tches peuvent tre dfinis :
Tche planifie : priodiquement ou par l'intermdiaire de dates explicites de planification,
Tche optionnelle : pour faire une exception dans la planification priodique d'une session,
Tche provoque : pour tre dclenche " la demande" ou pour faire une exception dans les
caractristiques techniques d'une tche planifie (dans une session).
C'est partir de la dfinition d'une tche que le calculateur gnre un lancement.
Termin
Etat d'une excution correctement termine. Cet tat est obtenu par :
Glossaire 109
"set RESEXE=0" dans le script de l'uproc sous Windows,
"exit 0" du script de l'uproc sous UNIX,
"S_RESEXE==V" dans le DCL sous VMS.
Tout autre tat de sortie du script de l'uproc donne lieu un tat incident de son excution.
Unit de gestion
Environnement logique de travail des applicatifs. Une ou plusieurs units de gestion peuvent tre dfinies sur
un mme noeud. Les units de gestion sont regroupes par types (reprsents par la premire lettre de l'unit
de gestion). La manipulation des types d'UG permet de paramtrer des traitements de manire gnrique (par
ex. "toutes les UG du type A"). De cette manire, le paramtrage devient indpendant de la configuration
physique de l'architecture.
Uproc
Objet qui permet de dfinir, autour du fichier de commandes (script, DCL, CL, .bat), toutes les conditions
applicatives ncessaires l'excution du traitement (enchanements inter sessions, attente de fichiers,
paramtres, date de traitement...) l'exception de ses caractristiques techniques et temporelles d'excution.
110 Glossaire
rpartie 8
scurit de fonctionnement 7
Index
B
Bureau
personnaliser 31
$
$U
architecture 7
architecture cooprative 8
architecture rpartie 8
client-serveur 8
contrle d'accs 7
contrle de l'exploitation 2
description des travaux 3
description d'une chane de travaux 3
distribution et transfert du paramtrage 9
environnement 11
gestion centralise 9
gestion du batch 2
interfaces 9
mise en production 6
objectifs 1
oprations de modifications 73
ordonnancement 5
planification 4
prsentation gnrale 2
scurit 6
simulation 6
statistiques 6
utilisation des queues batch 2
verrouillage technique 73
A
Affecter
une transaction de $U 29
Algorithme de planification
exemples 62
Application
dfinition de l'espace 14
dfinition et utilisation 24
table des rpertoires 24
Architecture
cooprative 8
Calendrier
distribuer un modle 76
distribuer vers une UG 75
historique de distribution 77
prsentation 4
transfert vers un espace 74
Cible
de la distribution 76
CL
description 37
gestion par version pour une uproc CL interne 74
utilisation des commandes 38
Classe
exemple 35
vrification lors du pilotage 53
Client-serveur
principes 8
Code auteur
dfinition 27
utilisation 31
Codification
des uprocs 37
du type d'UG et des UG 15
Commandes
dans le CL 38
Compte de soumission
dfinition 31
Compte rendu d'excution
insrer un commentaire partir du CL 38
Condition
dfinition 44
participation la formule de lancement 53
utilisation des uprocs mmorises 43
Condition fatale
prise en compte dans la formule de lancement 53
Contrle centralis
dfinition du noeud de contrle 22
objectifs 97
Contrle d'accs
principes 7
Contrle de l'exploitation
objectifs 5
D
Date de traitement
Index 111
utiliser dans les conditions de non simultanit 51

utiliser dans les conditions de ressource 52
utiliser dans les conditions d'enchanement 49
Dclencher une uproc
partir d'un CL 38
tche provoque 64
Dfinition
application et domaine 24
calendrier 59
CL interne ou externe d'une uproc 37
code auteur 27
compte de soumission 31
condition 44
condition de non simultanit 51
condition de ressource 52
condition d'enchanement 49
dpendances des units de gestion 16
espaces 14
fentre de lancement 69
noeud de contrle centralis 22
noeud matre 22
noeud, noeud logique, noeud physique 21
pilotage d'une tche 36
profil utilisateur 27, 30
rgle de planification 61
ressource 33
socit 13
socit, espace, UG 11
traitement informatique hirarchis (TIH) 16
type d'UG 15
unit de gestion 14
uproc mmorise 43
version courante d'une uproc 74
Dpendance des UG voir TIH
Dsaffecter
une transaction de $U 29
Distribution
cible 76
d'un modle 76
d'une uproc CL interne 37
tat 77
historique 77
impact sur le noeud de contrle centralis 22
principes 9, 75
table 76
utiliser le type d'UG 15
verrouillage des objets 77
Domaine
Droits d'accs
utilisation du profile 29
Dure d'excution
dans le planning prvisionnel 79
112 Index
E
Editeur
dfinition dans la table socit 13
Enchaner les uprocs voir session voir condition
d'enchanement
Environnement
compte de soumission 31
prsentation 11
restitution des chemins d'accs grs dans les tables
24
structuration 11
Espace
concept d'environnement 11
dfinition 14
distribuer un objet au sein d'un espace 75
gestion par version des sessions 74
gestion par version des uprocs 74
habilitation des noeuds 23
transfert d'objet vers un espace 74
utilisation de l'unit de gestion 15
utiliser dans la codification d'une ressource 34
Etats
de la distribution ou du transfert 77
EXE
valorisation 24
Excuter une tche
rle du pilotage 44
Excution force
en fin d'intervalle de pilotage 44
Exemple
classe d'incompatibilit 35
conditions d'enchanement 49
UG, type d'UG, TIH, dpendances d'UG 17
uproc mmorise 43
Explicite
planification 59
planification d'une tche 67
Exploitation
Externe
CL d'une uproc 37
F
Fentre de lancement
dfinition 69
d'une tche 69
excution unique 69
excutions multiples 69
superposition de plages 72
superpositions 72
tche provoque 69
FIC
valorisation 25
Formule de lancement
conseils d'optimisation 53
limites 53
H
Historique
distribution et transfert 77
Horaires de lancement
intervalle de pilotage 69
I
Implicite
exemples de planification 62
planification 59
planification d'une tche 67
Intgration
Interface
contrle des droits d'accs 29
Interfaces
de $U 9
Interne
CL d'une uproc 37
Intervalle de pilotage
dans le planning prvisionnel 79
J
Jour de planification 61
M
Manipuler des fichiers
commandes dans le CL 38
Mmorisation
caractristiques 43
dfinition 43
Mise en production
principes 6
Modle
distribuer 76
Modifier
organisation des menus de $U 29
une rgle de planification - impact sur les tches 61
N
Noeud
calendrier 59
chemin d'accs aux donnes d'une UG 25
chemin d'accs aux rpertoires d'une application 24
habilitation aux espaces 23
rpertoires 24
Noeud de contrle centralis
dfinition 22
Noeud matre
dclaration dans la table socit 13
dfinition 22
O
Objet
distribuer 75
transfrer 74
Ordonnancement
objectifs 5
P
Personnaliser $U
menus utilisateur 29
recommandations 30
restrictions 30
rle des profils 30
Pilotage
conditions d'analyse de la formule de lancement 53
dfinition 36
impact de la notion de successeur 44
principes 85
rle de la formule de lancement 53
rle des vnements d'excution 44
Planification
exemples de rgles 62
explicite ou implicite 59
objectifs 4
prsentation 2, 4
Planning prvisionnel
affichage des composantes d'une session 79
intervalle de pilotage 79
manipulation 78
simulation de planification 78
tches excutes sur un noeud distant 79
Profil
dfinition des droits 29
Profil utilisateur
dfinition 27
dfinition, rle et utilisation 30
personnaliser 31
Purge
vnements 54
R
Rgle de planification
dfinition et rle 61
Index 113
exemples 62
prsentation 4
Rpertoire
accs aux donnes d'une UG 25
accs aux objets d'une application 24
du CL associ une uproc 37
noeud 24
socit 13
UG ou application restituer dans le CL 24, 38
Report de planification 61
Ressource
identifiant, nature et quotas 33
S
Scurit
objectifs 6
Session
gestion des versions en fonction des espaces 74
prsentation 3
utiliser le type d'UG pour distribuer 15
visualisation dans le planning prvisionnel 79
Simulation voir Planning prvisionnel
prsentation 6
Socit
dfinition 13
diteur, verrouillage d'objets, noeud matre, rpertoire
13
indpendance des socits 13
utiliser dans la codification d'une ressource 34
Statistiques
objectifs 102
prsentation 6
utilisation par le planning prvisionnel 79
Statut
de la distribution ou du transfert 77
Statut d'excution
utiliser dans les consignes de terminaison 54
Structuration
chemin d'accs aux donnes d'une UG 25
chemin d'accs aux objets d'une application 24
T
Table des rpertoires
applications 24
restituer dans le CL 24
UG 25
114 Index
Tables
dpendance des UG 16
des utilisateurs 27
distribuer 76
socit 13
Tche
distribuer un modle 76
superposition de fentre de lancement 72
Tche optionnelle
Tche provoque
TIH
dfinition 16
exemples 17
formalisme et utilisation 16
utiliser dans le CL 38
Trace automate
insrer un commentaire partir du CL 38
Traitement informatique hirarchis voir TIH
Transaction
dfinition 29
menus utilisateur 29
rle 31
Transfert
d'une uproc CL interne 37
historique 77
principes 9, 74
verrouillage des objets 77
Type d'UG
calendrier 59
exemples 17
restriction de distribution du calendrier 60
rle, dfinition, codification 15
U
Unit de gestion
calendrier 59
codification 15
dfinition 14
dfinition du type d'UG 15
distribuer des objets 75
et les espaces 15
exemples 17
implication dans le TIH 16
objectifs 8
table des rpertoires 25
utilisation 15
utiliser les dpendances dans le TIH. 16

Univers
utilisation de l'unit de gestion 15
Uproc
cinmatique d'criture 37
CL interne ou externe 37
codification 37
conditions d'excution 44
dfinir la version courante 74
gestion des versions en fonction des espaces 74
mmorisation 43
prsentation 3
rptition dans une session 55
restitution dans le CL des chemins d'accs grs dans
les tables 24
utilisation des successeurs dans le pilotage 44
Username voir Utilisateur
Utilisateur
code auteur 27, 31
profil 27
rle des profils 30
transactions d'un profil 31
Utilisateurs
V
Verrouillage
dclaration dans la table socit 13
fonctionnel des objets 77
fonctionnel des objets (session) 74
technique des objets 73
Version
du CL pour les uprocs CL interne 37
gestion en fonction des espaces (session) 74
gestion en fonction des espaces (uproc) 74
Version courante d'une uproc 74
Index 115
Email : support@orsyp.com
Site WEB : http://www.orsyp.com

Dollar Uni

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

Dollar Uni

Transféré par

Droits d'auteur :

Formats disponibles

Dollar Universe v5.

Dollar Universe Solutions pour Windows, Unix et VMS

le manuel interface Motif,

le manuel interface commandes,

le manuel Global Control,

le manuel Business Views,

le manuel Web control,

tous les textes et titres des entres et crans du logiciel.

Unit de Gestion ou UG.

Dollar Universe v5.1 Manuel de rfrence

Table des matires

Objectifs fonctionnels ................................................................................................................ 1

Les concepts d'environnement

Dollar Universe v5.1 Manuel de rfrence

Personnalisation de l'interface caractres ..................................................................29

Les ressources ..........................................................................................................................33

Les calendriers .........................................................................................................................59

Dollar Universe v5.1 Manuel de rfrence

Verrouillage technique des objets.............................................................................. 73

Le rle du moteur batch ........................................................................................................... 81

Suivi des excutions ................................................................................................................ 97

Dollar Universe v5.1 Manuel de rfrence

Release notes Dollar Universe v5.0 SPRE0025.....................................................................105

Dollar Universe v5.1 Manuel de rfrence

Etapes de vie d'une application informatique

Dollar Universe v5.1 Manuel de rfrence

Planification et ordonnancement des travaux

Gestion des files d'attente de travaux

Dollar Universe v5.1 Manuel de rfrence

La description des travaux

des conditions de non simultanit de travaux entre eux,

des conditions de disponibilit de ressources.

un compte utilisateur de soumission,

une date fonctionnelle (date pour laquelle est excut un travail),

un tat du traitement attendu,

une unit de gestion ou un groupe d'units de gestion d'excution.

Description d'une chane de travaux

Dollar Universe v5.1 Manuel de rfrence

facilite la maintenance des processus d'exploitation,

encourage et simplifie la mise en oeuvre de traitements dgrads ou de reprise, en cas d'incident.

Elles contribuent ainsi la qualit de l'exploitation et facilitent ses volutions.

des rfrentiels de temps constitus de calendriers civils,

un ensemble de priodicits d'excution nommes rgles de planification, prdfinies ou dfinissables en

sur une priode maximale de 25 ans,

avec positionnement automatique de jours chms paramtrable (option),

avec positionnement automatique des jours fris franais (option).

Les rgles de planification

un cycle de base, savoir un nombre quelconque de jours, semaines ou mois,

un nombre de jours depuis le dbut ou avant la fin du cycle de base,

la liste des jours de la semaine autoriss pour l'excution,

tous les jours ouvrs,

tous les premiers mardis ouvrs du mois,

tous les 87 jours...

La planification des travaux

Dollar Universe v5.1 Manuel de rfrence

La planification implicite consiste, aprs analyse du cycle d'excution du travail concern :

dfinir d'ventuelles interdictions d'excution (jusqu' 52 dates).

Ordonnancement et lancement des travaux

de trs hautes performances (consommation de ressources minimale du fait de l'absence de processus

une souplesse et une ractivit exceptionnelle,

Le contrle et la surveillance d'exploitation

le log d'excution du travail,

les prochains travaux soumettre, ...