Dollar-Universe-Reference Guide PDF

Dollar Universe v5.
6
Reference user's guide
Dollar Universe for Windows and Unix
EMEA HEADQUARTERS AMERICAS HEADQUARTERS
Tour Franklin 54 Middlesex Turnpike

92042 Bedford, MA
Paris La Défense Cedex 01730
France USA
+33 [0] 1 47 73 12 12 +1 [781] 276 4600
info@orsyp.com info_usa@orsyp.com
www.orsyp.com www.orsyp.com
July 31, 2009
© Copyright 2009. All rights reserved.
ORSYP, its logo, Dollar Universe, UniJob and UniViewer are registered trademarks of ORSYP
S.A.S.
All other trademarks in this document are the property of their respective owners. Specifications are
subject to change without notice.
Contents
1. Introduction 1
1.1 Functional objectives....................................................................................1
1.1.1 Scheduling and sequencing ..............................................................2
1.1.2 Batch queues....................................................................................2
1.1.3 Job monitoring ..................................................................................2
1.2 Overview......................................................................................................2
1.2.1 Job description .................................................................................3
1.2.2 Scheduling........................................................................................4
1.2.3 Job sequencing and launching..........................................................5
1.2.4 Operations monitoring.......................................................................6
1.2.5 Execution statistics ...........................................................................6
1.2.6 Simulation.........................................................................................6
1.2.7 Security of operations .......................................................................7
1.2.8 Distributed client-server operations ...................................................8
1.2.9 Interfaces with Dollar Universe........................................................10
2. Environmental concepts 11
2.1 Introduction ................................................................................................11
2.1.1 Environmental concepts features ....................................................11
2.1.2 Presentation ...................................................................................11
2.2 Companies.................................................................................................12
2.2.1 Independence of Companies ..........................................................13
2.2.2 Additional characteristics of Companies ..........................................13
2.3 Areas .........................................................................................................14
2.4 Management Units .....................................................................................14
2.4.1 Definition ........................................................................................14
2.4.2 Management Unit types ..................................................................17
2.4.3 Hierarchical data processing ...........................................................18
2.4.4 Implementation of Management Units .............................................21
2.5 Nodes ........................................................................................................25
Dollar Universe v5.6 Reference user's guide Contents • iii

2.5.1 Definition........................................................................................ 25
2.5.2 Central or local administration ........................................................ 26
2.5.3 Additional characteristics of the node ............................................. 27
2.6 Declaring the applications environment...................................................... 28
2.6.1 Applications and domains............................................................... 28
2.6.2 Application or MU directories.......................................................... 28
3. Users 30
3.1 Definition ................................................................................................... 30
3.2 Access control ........................................................................................... 30
3.2.1 Server access control - the proxies................................................. 30
3.2.2 Access control to data and functions – the SECURITY file.............. 32
3.3 Customization of interfaces........................................................................ 32
3.3.1 Dollar Universe Console customization........................................... 33
3.4 Submission accounts................................................................................. 33
3.4.1 Definition........................................................................................ 33
3.4.2 Using the author code .................................................................... 33
4. Parameters 35
4.1 Resources ................................................................................................. 35
4.1.1 Definition........................................................................................ 35
4.1.2 Codification .................................................................................... 36
4.2 Incompatibility classes ............................................................................... 37
4.2.1 Purpose ......................................................................................... 37
4.2.2 Using incompatibility classes .......................................................... 37
4.3 Uprocs....................................................................................................... 38
4.3.1 Definition........................................................................................ 38
4.3.2 Command type Uprocs................................................................... 39
4.3.3 Procedures or programs (DCL, shell, CL, .bat) ............................... 41
4.3.4 Completion status of the Uproc ...................................................... 45
4.3.5 Auto-Retry...................................................................................... 45
4.3.6 Variables........................................................................................ 46
4.3.7 Functional period and processing date ........................................... 47
4.3.8 Event memorization ....................................................................... 49
4.3.9 Successors .................................................................................... 50
4.3.10 E-mail notification......................................................................... 50
iv • Contents Dollar Universe v5.6 Reference user's guide

4.4 Execution prerequisites ..............................................................................51
4.4.1 General features of conditions ........................................................51
4.4.2 Additional characteristics ................................................................55
4.4.3 Types of conditions.........................................................................56
4.4.4 The launch formula .........................................................................60
4.4.5 Completion instructions...................................................................61
4.5 Sessions ....................................................................................................62
4.5.1 Definition ........................................................................................62
4.5.2 Normal and error processing paths .................................................64
4.5.3 Execution environment ...................................................................65
4.5.4 Carry-over of Uproc variables’ values..............................................65
4.5.5 Storage limits..................................................................................66
5. Scheduling 67
5.1 Calendars...................................................................................................67
5.1.1 Calendar application environment ...................................................67
5.1.2 Calendar model ..............................................................................68
5.1.3 Generation of holidays ....................................................................68
5.1.4 Calendar range...............................................................................68
5.1.5 Types of day...................................................................................69
5.1.6 Impact of modifications on a calendar .............................................69
5.2 Scheduling rules.........................................................................................70
5.2.1 Definition ........................................................................................70
5.2.2 Examples of Rules..........................................................................71
5.3 Tasks .........................................................................................................73
5.3.1 Definition ........................................................................................73
5.3.2 Task model.....................................................................................74
5.3.3 Types of task ..................................................................................74
5.3.4 Common technical characteristics...................................................76
5.3.5 Task scheduling..............................................................................78
6. Refining the operations process 87

6.1 Manipulation...............................................................................................87
6.1.1 Updating.........................................................................................87
6.1.2 Technical locking of objects ............................................................87
6.2 Version management .................................................................................87
Dollar Universe v5.6 Reference user's guide Contents • v

6.2.1 Uprocs ........................................................................................... 88
6.2.2 Sessions ........................................................................................ 88
6.3 Changing environment............................................................................... 88
6.3.1 Transfer to an Area ........................................................................ 88
6.3.2 Distribution to Management Units................................................... 89
6.3.3 Importing and exporting data.......................................................... 91
6.3.4 Functional locking of objects........................................................... 91
6.3.5 Distribution history.......................................................................... 91
6.4 Simulation of scheduling ............................................................................ 92
6.4.1 Objectives...................................................................................... 93
6.4.2 Workload forecasting...................................................................... 93
7. The operations process 95

7.1 Role of the batch engine ............................................................................ 95
7.1.1 The automation process................................................................. 95
7.1.2 Components of the batch engine.................................................... 96
7.1.3 Location of the batch engine........................................................... 96
7.1.4 Submission across the network ...................................................... 96
7.1.5 Execution phases of a task............................................................. 97
7.2 Job scheduling........................................................................................... 97
7.2.1 Operation of the calculator ............................................................. 98
7.2.2 Impact of modifying a task.............................................................. 98
7.2.3 Enabling - disabling of a task.......................................................... 99
7.3 Sequencing and launching....................................................................... 100
7.3.1 The launcher................................................................................ 100
7.3.2 The launch................................................................................... 101
7.3.3 Operations on launches ............................................................... 102
7.3.4 The Job events file....................................................................... 104
7.3.5 Condition checking....................................................................... 105
7.3.6 Uproc submission......................................................................... 109
7.3.7 Job completion............................................................................. 110
7.4 Inter-machine communications ................................................................ 111
7.4.1 Role of the exchanger .................................................................. 111
7.4.2 Operating principles ..................................................................... 111
7.5 System failures........................................................................................ 112
vi • Contents Dollar Universe v5.6 Reference user's guide

8. Operations monitoring 114
8.1 Executions monitoring ..............................................................................114
8.1.1 Purpose ........................................................................................114
8.1.2 Central monitoring ........................................................................114
8.1.3 Job status .....................................................................................115
8.1.4 Production diagnostics..................................................................115
8.1.5 Authorized interventions................................................................116
8.2 History files and statistics .........................................................................120
8.2.1 Execution history ..........................................................................120
8.2.2 Statistics.......................................................................................121
8.3 Purging ....................................................................................................122
8.3.1 Operating events file.....................................................................122
8.3.2 Executions monitoring...................................................................122
8.3.3 History files...................................................................................122
8.3.4 Log files........................................................................................123
9. Glossary 124
10. Index 129
Dollar Universe v5.6 Reference user's guide Contents • vii

Figures
Figure 1: Stages in the life cycle of a computer application ........................................1
Figure 2: The environmental concepts of Dollar Universe ........................................12
Figure 3: Objects logical layout depending on environment concepts ......................12
Figure 4: Distribution of MU dependencies within physical configuration..................22
Figure 5: Use of MU to represent technical objects..................................................25
Figure 6: Use of the master node ............................................................................26
Figure 7: Illustration of the notions of master node and central monitor node ...........27
Figure 8: Authorization of nodes to Areas................................................................27
Figure 9: Calendar units proposed for different functional periods............................55
Figure 10: Structure of Session ...............................................................................63
Figure 11: Minimum range of a calendar .................................................................69
Figure 12: Dollar Universe batch engine functions...................................................95
Figure 13: Task execution diagram .........................................................................97
Figure 14: Execution status of a job ......................................................................105
Figure 15: Uproc submission.................................................................................109
Figure 16: Exchanger mechanisms .......................................................................112
Dollar Universe v5.6 Reference user's guide Figures • ix

1. Introduction
1.1 Functional objectives

The main objectives of Dollar Universe are firstly to reduce the constraints weighing upon the
technical organization in charge of managing computer operations, secondly to ensure optimum
reliability in the operations cycle. As a means towards these objectives, Dollar Universe offers:
• Functions covering the essential part of the central operations process, through which it allows,
at any given time, precise supervision and overall control of operational coherence.
• Automation of all batch operations, removing the need for human presence during the daily
execution of the operations cycle and allowing automatic management of recovery processing
sequences when incidents are encountered.
• A structured applications environment adaptable to the norms and standards of each site.
• Increased stability and flexibility of the operations process regarding changes in both the
physical configuration and the applications environment. The possibilities offered by Dollar
Universe reduce the number and scope of maintenance operations and increase the resulting
quality of the operations process.
The following figure illustrates chronologically the main stages in the life cycle of a computer
application.
Procedures
management
Implementation Remote
distribution
Batch
scheduling
Batch
submission
Operations Output
monitoring management
Figure 1: Stages in the life cycle of a computer application
Dollar Universe proposes a series of functions for managing each of the themes presented in the
above figure. The managers, the supervision, the editions and output management functions
represent modules that are independent from the automation module discussed in this Reference
user's guide.
The interfaces (Motif, Windows, command …) are explained in specific manuals.
Dollar Universe v5.6 Reference user's guide Introduction • 1

1.1.1 Scheduling and sequencing
Batch procedures are scheduled using calendars; these are generated semi-automatically, one for
each logical entity managed.
Scheduling can be performed procedure by procedure, or alternatively, defined for a group of
procedures. Dollar Universe provides procedure sequencing models called Sessions. In addition to
their specific advantages, Sessions afford the possibility of defining a single schedule for a group of
procedures.
Execution dates can be expressed by specifying the desired dates and times of execution (explicit
scheduling) or by defining algorithms used for automatically deducing the intended dates (implicit
scheduling).
To avoid possible redefinition of these algorithms, they can be stored in "scheduling rules"
managed individually by Dollar Universe.
Finally, for exceptions to the algorithm without alteration of the algorithm, exception dates can be
defined. Each of these dates allows the invalidation of a date calculated by application of a rule, or
the forcing of another.
1.1.2 Batch queues

Dollar Universe exploits the ability of operating systems to manage batch queues.
In UNIX and Windows, where this function is not supported by the system, this part of the process
can be provided by an additional Dollar Universe module: DQM (distributed queue management).
This module provides a technical organization of the production process, above and beyond the
functional organization provided by Dollar Universe, while dissociating the management of
associated constraints.
1.1.3 Job monitoring

Dollar Universe proposes a group of functions that allow dynamic tracking and intervention in the
operations process.
Built around a screen displaying current processes, the job monitoring function represents a
veritable work station, allowing the operator to monitor all his jobs without ever losing sight of the
overall operations scenario.
1.2 Overview
Dollar Universe aims to offer users a global automation solution, irrespective of the type of
operations being undertaken.
Within Dollar Universe, two essential notions can be distinguished:
• the Company,
2 • Introduction Dollar Universe v5.6 Reference user's guide

• the Management Unit.
The notion of Company means that, in a given computing environment, a single copy of Dollar
Universe can manage the operations of several distinct Companies independently.
Thanks to its access control functions and its technical architecture, Dollar Universe allows totally
hermetic separation of their operations.
Within the Company, Dollar Universe can handle distinct environments where several different
operations scenarios will be run in parallel, as might be the case with a Company using the same
applications on different data. These environments are called Management Units.
Dollar Universe can manage several thousand Management Units.
1.2.1 Job description
1.2.1.1 Elementary job description

The description of a job rests essentially on:
• Identification of the procedure: command, script (.bat, shell…) or any other specific function,
• Definition of its technical characteristics
• Conditions required for its execution.
Dollar Universe distinguishes three main types of conditions:
• Dependency condition, representing the dependence of one job on another.
• Condition of mutual non-simultaneity of jobs.
• Condition of resource availability.
For each of these conditions, Dollar Universe allows the association of criteria such as:
• A user submission account.
• A functional date (date for which the job was run).
• The expected status.
• The Management Unit or group of Management Units on which the job ran.
These conditions (up to 99 for a given procedure) can be combined in a Boolean expression
associating the constraints using the logical operators: and, or, =, not =, ( and ).
The use of free syntax in this expression, and the rich parameter-setting possibilities, means that
the functional logic governing execution of the various jobs can be precisely transcribed. This
makes it easy to run normal processing scenarios (i.e. Sequences respecting the normal
processing path), as well as incident situations (degraded processing paths or recovery).
The procedure associated with its execution conditions is called "Uproc".

1.2.1.2 Description of a job stream
From a more macroscopic viewpoint, Dollar Universe offers the notion of "job stream", referred to
as a Session, for procedures presenting homogeneous operations constraints (same scheduling
conditions, for example).
The Session allows jobs to be ordered in a tree structure, whereby each job is told which jobs
follow it in both normal and abnormal operating circumstances. The sequences so-defined within a
Session do not substitute for the dependencies defined at the individual job level, but rather
supplement them.
It is therefore possible to define (see "Elementary job description" on page 3) the associated
functional conditions for each job and, via the Session, superimpose on these the execution
sequence required by the operator. In so doing operations imperatives (time constraints,
optimization of resource consumption etc.) can be integrated without altering the expression of the
functional conditions.
Thanks to these job description features, Dollar Universe:
• Facilitates maintenance of operations processes.
• Assists with and simplifies the implementation of degraded processing paths or recovery, in
event of error conditions.
Such features thereby contribute to the quality of operations, and make change management
easier.
1.2.2 Scheduling
Scheduling applies indifferently to individual jobs or Sessions (groups of jobs).
It rests on prior definition of the following objects:
• A series of time reference bases created using civil calendars.
• A series of execution frequencies called scheduling rules, either predefined or definable,
depending on requirements.
1.2.2.1 Calendars
Each Management Unit may have its own calendar.
Functions for automatically generating calendars are proposed as follows:
• For a maximum period of 25 years.
• With automatic positioning of configurable work days (option).
• With automatic positioning of standard holidays (option).
In addition to this generation function, the type (workday, closing day, holiday) of any day in a
calendar can always be modified.
The work involved with calendar definition or maintenance is practically zero.

1.2.2.2 Scheduling rules
The most common scheduling rules are supplied as a standard feature of Dollar Universe.
It is still possible to define specific scheduling rules to meet particular cases.
A scheduling rule is:
• A base cycle, that is, a number of days, weeks or months.
• A number of days from the start or before the end of the base cycle.
• The list of days of the week authorized for execution.
• An offset direction from the execution date, whereby, if the date obtained by applying the rule
to the calendar is not a workday, this date will be shifted to the first workday preceding or
following the targeted date.
A scheduling rule can translate execution frequencies of the type:
• Every working day.
• The first working Tuesday in each month.
• Every 87 days etc.
1.2.2.3 Job scheduling

Dollar Universe proposes two main scheduling methods, which can be used together if required, for
handling recurrent and/or random runs:
Implicit scheduling of the analysis of the execution cycle of the job in question consists in:
• Associating from one to seven scheduling rules, to obtain the desired final schedule.
• Defining the job execution time (such as a particular time for a particular day of the week, or up
to 1500 launches per day, etc.), and a waiting period for the conditions to be met. After this
interval, the execution will be abandoned or forced (option).
• Defining of exclusion dates.
Explicit scheduling consists in listing the dates and launch windows, one by one.
In the field of scheduling, Dollar Universe provides a natural solution capable of meeting the
majority of foreseeable cases. By offering combined features such as: automatic generation of
calendars; the possibility of mixing normal submission frequencies; processing of random cases via
explicit schedules and exception dates, Dollar Universe limits the amount of maintenance required
by the operations schedule, while preserving the user's freedom of intervention.
1.2.3 Job sequencing and launching

Dollar Universe provides dynamic sequencing and launch control for each job, based on a cyclical
process that react in accordance with events detected in real time (date/time, end or start of job,
change resource availability, updating of operations parameters etc.).
Dollar Universe uses no permanent, predefined plan, but interprets, in accordance with the actual
operations events occurring (and any interventions by the operators) all descriptive information
concerning the various jobs, and their associated scheduling data.

Thanks to this fully interactive approach, Dollar Universe means:
• Very high performance (minimal resource consumption due to the absence of a cyclical
process, and "just-in-time" job submissions).
• Exceptional flexibility and reactivity.
• Genuine user comfort, since the operator retains all freedom for real-time interventions.
1.2.4 Operations monitoring

Dollar Universe affords particular attention to the tracking and supervision of operations with the
sole aim of facilitating job monitoring, accelerating the identification and diagnosis of incidents, and
permitting the necessary recovery procedures. There is a dedicated job monitoring function.
Organized around a control screen, the job monitoring function allows dynamic display (audible
alarm, automatic screen refresh) of all or part of the finished or current job runs. The job monitor
features fine selection criteria, allowing the operators to focus on the most strategic jobs.
All essential data is directly accessible from the job monitor:
• The history trace formatted by Dollar Universe, recording the steps performed by the job and, in
the case of jobs in an event wait state, the expected events. The history trace can contain
comments or operator instructions transmitted from the command interpreter via a specific
Dollar Universe command.
• The job execution log.
• The following launch window of all scheduled jobs,
As well as the main functions for intervening in the operations process:
• Recovery after incident.
• Interactive launching of unscheduled jobs.
• Updating of operations events.
The job monitor provides the operator with a single point from which to make all necessary
interventions on the current operations process.
1.2.5 Execution statistics

For each job run, Dollar Universe memorizes the consumption of essential resources (CPU,
elapsed time), over the last hundred executions, and calculates the mean values.
All collected data can be displayed interactively in graphical form.
In order to give precise simulations of execution times, it can be updated (removal of deviations,
creation of estimated values for new jobs that have never run).
1.2.6 Simulation
Dollar Universe offers simulation functions of a single job schedule.

The interactive task scheduling function enables the simulation of a given task, using a reference
calendar, over a selected period of time.
1.2.7 Security of operations

Security of operations is one of the main guiding factors of Dollar Universe.
It will be approached under three headings:
• Security through managed implementation of job parameters.
• Security through control of access to Dollar Universe functions.
• Security through the technical architecture of Dollar Universe.
1.2.7.1 Implementing applications

For each Company, Dollar Universe manages four Areas which, for no significant increase in
workload, permits the progressive refinement of operations processes.
These Areas can be dedicated, depending on requirements, to acceptance of applications, user
training, integration tests, simulation of operations, or operations proper.
All Dollar Universe functions include an option allowing interactive passage from one Area to
another.
Within each Area, a given job may have different parameter settings corresponding to each step of
its technical or functional cycle. As a standard feature, Dollar Universe offers an interactive function
allowing parameter settings to be debugged in one Area, then moved by transfer to another Area
(transfer from the integration Area to the simulation Area, for example).
Each interactive transfer of Dollar Universe objects is logged, an operation which essentially
memorizes:
• The job in question.
• The operator.
• The source and target Areas.
• The date and time of the operation.
The databases thus created can be interrogated interactively. Through the use of detailed requests
(multi-criteria selections such as date, job in question, operator etc.), they allow retrospective
constitution of the development path of the parameter settings present in the production Area, for
example.
The transfer history aims to facilitate the analysis of disparities between an expected parameters
and the actual parameter setting.
1.2.7.2 Access control

Before any connection takes place, each user must be identified by Dollar Universe in order to be
allocated with a user profile.
For each user profile, it is possible to customize strict rights of use of Dollar Universe interfaces.

• For the MOTIF, Windows or Command interfaces, authorized or prohibited actions are defined
in the SECURITY file (see the administrator's guide).
• For the Windows interface: it is possible to define a standard desktop for each profile and a
specific user desktop (see the Dollar Universe Console user's guide).
This access control, coupled with proxies definition functions (connection authorization given by a
server to clients) allows the functional scope of Dollar Universe to be tailored to individual needs.
1.2.7.3 Architecture
Several aspects of Dollar Universe's architecture contribute to more secure operations.
The content of each user/Dollar Universe exchange is memorized. So, whatever the circumstances
(system crash, for example), on his following connection to Dollar Universe, the user will take up
the dialogue at the same point. This approach is used to ensure that all tasks performed during
operational parameter settings always complete correctly.
In identical circumstances (system crash) the basic processes are designed to never lose track of
running jobs (provided the operating system itself never does).
Finally, to avoid altering the performances of one Area due to overloading another, there are
separate permanent processes for each active Area.
The design and nature of Dollar Universe functions combine to facilitate methodical operations
management within strictly delimited environments. Thanks to the customization options, it is
possible to offer each user a tool precisely tailored to his individual tasks.
Such factors, coupled with a structured and rigorous technical architecture, bring greater clarity to
the overall operations process, while increasing the degree of operator control.
1.2.8 Distributed client-server operations

Dollar Universe uses standard protocols, such as DECNET and TCP/IP to provide client-server
communications between the different Dollar Universe modules on a network.
Dollar Universe enables automation of job sequences spread across several machines, monitoring
and condition checks from a central point, increased reliability, and optimization of multi-site
operations processes.
1.2.8.1 Distributed operations

The Management Unit is Dollar Universe's major contribution to the management of distributed
operations.
A Management Unit can reside on any node on the network, provided the node is identified in the
descriptive information of the Management Unit. A Management Unit can use a reference time
different from that of the application server.
In addition, Dollar Universe qualifies Management Units through notions such as:
• Management Unit type (factory, depot, sales office, country) differentiating each Management
Unit by its essential criterion in relation to the operations process,
• Relationships ("dependency") between Management Units.

Within this framework, each Dollar Universe function referring to the notion of Management Unit
(expression of conditions in the job descriptions, definition of jobs dependent on a job in a Session
etc., is able to interpret expressions of the type:
• Management Units of type X.
• Management Units dependent on the current Management Unit.
• Management Units of type X dependent on the current Management Unit.
Each Dollar Universe function can be set up according to the logical operational organization. Only
at the time of submission does Dollar Universe translate the logical references into the physical
reality of the network using the descriptive data of the Management Units.
In this way, Dollar Universe allows the description of flexible processes able to adapt to
configuration changes.
Imagining an operations process that consists in running a job for all the sales offices within a
Company, most of the changes can be implemented without modifying the basic operations
parameter settings. For example:
• To add a new sales office: create a new Management Unit with the type "sales office". The
Session within which the submission is executed remains unchanged (job "A" submits job "B"
for all sales offices),
• To concentrate two sales offices on a given machine: update the node for the Management
Unit in question (the Session remains unchanged).
Management Units' descriptive data is memorized in a database; Dollar Universe provides the
necessary tools for remote distribution to all nodes in question.
1.2.8.2 Co-operative management of distributed operations

The expression of conditions in the job descriptions can use logical expressions targeting the
Management Units.
In this way, it becomes possible to synchronize jobs running on Management Units residing on
different nodes:
"job A will not run on Management Unit X unless Job b has been correctly executed on
Management Units of type Z".
In this case, without the need to dispatch applications pseudo-files, Dollar Universe implements
truly co-operative multi-machine management. It triggers requests towards the nodes of residence
of Management Units of the type in question, to determine if the condition is actually met. As soon
as the expected event occurs, the requesting machine will be automatically informed.
These functions are event-driven (the request is not issued cyclically). They are implemented in a
specific communication function that guarantees the security of transmissions and the reception of
requests, even in the event of a temporary break in the network.
1.2.8.3 Central monitoring

To limit the load on the network, and ensure processing of only that data which is strictly required
for operations monitoring, each job contains a flag that indicates if it will be centrally monitored or
not.

The monitoring of operations on strategic tasks for the Management Units in question will be shifted
to the node defined as central monitoring node. The operations monitoring function allows the
dynamic display not only of the jobs in the local Management Units, but also the essential jobs in
the centrally monitored remote Management Units.
Monitoring of distributed operations can be extended to include definition of the operations
parameters for the remote sites.
To this end, Dollar Universe includes the notion of a parameter template, known as a "model". A
model is an inactive parameter setting which only becomes operational after distribution to a target
Management Unit.
The notion of model makes it possible to manage parameter settings for all distributed operations
from a single node.
It should also be noted that all Dollar Universe interactive functions allow the parameter settings of
another node to be displayed, without logging in to the node in question.
1.2.8.4 Remote parameter distribution

In the same way as the transfer between Areas, each element of the Dollar Universe operations
parameters can be interactively distributed to all Management Units in the architecture.
Each distribution operation is logged, providing a history database, which also can be consulted
interactively.
Dollar Universe offers the potential to process all forms of local or distributed operations, with local
or centralized management. In this respect, Dollar Universe affords significant advantages when
migrating from one mode to another.
The flexibility and independence of the processes, as compared to the physical reality of the
configuration, leads to increased operations stability, ensuring reduced maintenance and optimum
reliability.
1.2.9 Interfaces with Dollar Universe

To allow access to its various functions, Dollar Universe provides the following interfaces:
• Graphical interface (X/MOTIF, Windows, Java),
• Command mode interface,
• Web services interface.
Furthermore, Dollar Universe provides standard interfaces to external functions such as:
• Alarm management,
• Backup packages,
• Web applications,
• ERP,
• ...

2. Environmental concepts
2.1 Introduction
2.1.1 Environmental concepts features

The features defining the environment and general administration of Dollar Universe, presented in
this section, lay the foundations for structuring, planning and organizing any automation project.
• The "Environmental concepts" chapter, describes the proposed general architecture, and the
underlying concepts making up this architecture, in particular:
o The concepts in the structuring of the environment, and their mode of administration.
o The concepts pertaining to the automation of operations, as well as relevant information of
a functional nature.
• The "Declaring the applications environment" chapter introduces the administration associated
with the applications, for a pre-requisite for automating applications procedures.
It also introduces the administration of tables, allowing declaration of the applications
environment, and use of this same declaration for the internal requirements of Dollar Universe.
• The "Users" chapter introduces the different interpretations of "user" within Dollar Universe,
defining:
o How they are managed.
o The access rights to the various transactions of Dollar Universe.
2.1.2 Presentation
Dollar Universe manages several concepts meant to lend logical structure to the working
environment.
Three main organizational levels of data can be distinguished.
• Company,
• Area,
• Management Unit (MU).
The above concepts are illustrated in the following figure:
Dollar Universe v5.6 Reference user's guide Environmental concepts • 11

Company A
Company B
Application area
Integration area
Simulation area
Production area
MU1 MU2 MU3
Figure 2: The environmental concepts of Dollar Universe
The Company represents the highest level in the environment concept. Each Company
corresponds to a new installation of the product. It is possible to install a given Company on several
nodes, or several Companies on a given node.
Companies are sealed working environments that can communicate only through import/export of
parameters.
A Company is divided into four distinct Areas: Applications, Integration, Simulation and Production.
Areas are also sealed operations environments which benefit, within a given Company, from
interactive transfer of parameters. Certain Areas also accept the definition of object versions (Uproc
and Session).
The following diagram shows the main objects managed by Dollar Universe, as well as their logical
layout depending on the different environment concepts proposed.
§ Executables and configuration utilities
COMPANY § Administration and authorization files
§ Specific files not managed by area
Development universe Production universe
Application Integration Simulation Production

area area area area
§ uprocs § uprocs § uprocs § uprocs
§ data § data § data § data
§ logs § logs § logs § logs
Figure 3: Objects logical layout depending on environment concepts
The notions of Area are not managed on an individual basis. The Dollar Universe tables will only be
able to differentiate via the definition of the access paths to applications' objects and to data
specific to each Management Unit.
Finally, the entire logical environment is independent of the physical organization of the computer
systems and, consequently, exists on each node (machine) in the network.
Moreover, since the co-operative architecture of Dollar Universe imposes no particular constraints
on the organization of the operators responsible for administering and monitoring operations (the
"master" or "slave" concept is non-existent in Dollar Universe), it is through the nodes themselves
that the individual organization of each context can be translated.
2.2 Companies
12 • Environmental concepts Dollar Universe v5.6 Reference user's guide

The Company is the highest level of environment managed by Dollar Universe. One Company
must be defined at the time of Dollar universe installation. In many cases it will be the only
Company in the information system, but all other notions defined in Dollar Universe take it as their
reference.
This concept ensures a strict partitioning of data. It ensures the hermetic structure of several
Companies (in the judicial sense of the term) on a single computer system.
2.2.1 Independence of Companies

Setting up Companies consists in creating totally separate environments.
Companies have their own specific tools (batch motor per Company, for example), which feature in
independent operations. In the case where such a strict dissociation is not necessary, the notion of
Management Unit will allow the running of parallel operations.
If several Companies share a computer system, the various Dollar Universe functions will be able
to work in the same way for each Company, without any interference in individual operations or
sharing of data.
2.2.2 Additional characteristics of Companies

Each Company authorizes the declaration of information of general interest such as:
• The type of editor used
On UNIX, the type of editor used is defined in the environment file uxsetenv (cf. administrator's
guide).
• Locking of objects
This information allows defining whether, during transfer or distribution operations, Uprocs and
Sessions need to be accessible or not for modification.
• Master node
This information indicates the Company's master node.
Refer to the heading "Nodes" in this chapter for more information regarding the meaning of the
notion of master node, and the related operating precautions.
• Company directory
This information declares the physical location (directory name) of a Company's various files
(Company administration tables, scheduling rules, authorization files etc.) for the node in
question.
Note: There is a dual definition for this directory, in order to ensure compatibility with previous
versions of Dollar Universe, which recognized a Company's file locations in terms of universes
(groups of paired Areas); it therefore requires the same declaration in the two directories proposed
for a given Company. Since a given Company can be installed differently on each node, it is wise to
avoid distributing this table.

2.3 Areas
In order to allow gradual testing of applications under development or maintenance in conditions
that simulate production conditions as closely as possible, Dollar Universe offers four working
environments known as "Areas":
• Application Area,
• Integration Area,
• Simulation Area,
• Production Area.
The application and integration Areas are environments dedicated to the development of
operations procedures. The simulation and production Areas are reserved for computer production.
Dollar Universe manages, for certain Areas, versions of Uprocs and Sessions (see section "Version
management" on page 87).
The same Dollar Universe functions are available in all Areas. Changing Areas is easily
accomplished by transferring objects from one Area to another.
The types of objects managed at the Area level are the following:
• Parameters: Uprocs, Sessions, calendars, tasks,
• Monitoring: launches, executions, events, history files etc.
The following objects are managed at the Company rather than the Area level:
• Administration: all tables,
• Parameters: rules, resources, incompatibility classes.
2.4 Management Units
2.4.1 Definition
The Management Unit represents a logical working environment. It is present throughout all Dollar
Universe functions, where it plays a key role.
A Management Unit systematically points to a node, so that the mere fact of allocating a procedure
to a Management Unit is sufficient to designate the physical environment in which the job in
question will be run. The notion of node becomes transparent in the daily use of Dollar Universe
functions, in favor of the notion of Management Unit.
A configuration, be it centralized or distributed, is seen as a single machine on which resides a set
of Management Units.
Main features of a Management Unit:
• For a given physical environment, facilitates the coexistence of parallel processing of identical
applications respecting different operating constraints (data environments, applications…).

• Forms the central element in the notion of distributed data-processing. The MU allows the
simulation of distributed data processing architecture on a centralized architecture. Thus, the
MU facilitates changes of architecture for computer solutions (centralized architecture to
distributed architecture or vice versa), and renders operations methods unaffected by such
changes;
• Cannot be defined on several nodes. Nevertheless, a node can support several MUs.
2.4.1.1 Use
Computer operations require a permanent dual perspective regarding a Company's data
processing organization:
• On the one hand, the logical view as seen in the applications.
• On the other hand, the physical view of the computer assets, as dictated by operations.
In Dollar Universe, technical operations processes may be built on the logical notions making up
the Management Units, delaying the translation of logical parameters into physical data until final
execution of the data processes.
This interpretation is made dynamically, acting on the descriptive information of the Management
Units contained in the administration tables of Dollar Universe. This flexibility gives operations
processes unparalleled stability, thus optimum reliability.
The following example illustrates these features.
Processing streams can apply to several Management Units: take, for example, the consolidation
of commercial statistics of sales offices at the regional office level:
If the consolidation operation has to submit operations to run on each sales office environment, or
copy files localized in each of the office environments in question, a change in the organization of
the offices (such as progressive increase in workload on an application, or switching of an office to
a new machine etc.), could have problematic repercussions.
In most cases, procedures will have to be modified to take into account the new context. However,
Dollar Universe avoids repetitive maintenance operations on the existing processes. The only
intervention will consist in updating the administration table designed to create a new Management
Unit or modify the technical characteristics of an existing Management Unit.
To offer a complete solution, Dollar Universe makes it possible to define hierarchical relationships
between Management Units. These relationships could be established, for example, between a
regional office and every sales office. This type of relationship is known in Dollar Universe as
"Hierarchical Data Processing", or HDP.
2.4.1.2 Management Units and Areas

Management Units are present in each Area, unless an explicit restriction is expressed during the
MU definition (restriction to the development Area only, for example).
In this way, the environment and parameters of the operating procedure can remain the same from
development up to the implementation phase.

2.4.1.3 Management Unit reference time
A time offset specific to a Management Unit can be defined in regards to the system clock on the
Management Unit’s node of residence. The offset time will be used whenever a job is scheduled to
run on the particular Management Unit.
For example:
If a job is scheduled to run at midday on each of the Management Units below, the system
scheduled time will be as follows:
MU M_LONDON M_BOSTON M_PARIS
M.U. offset 0 -5 +1
System schedule time 12h 17h 11h
If a job is scheduled to run at midnight the system schedule times will be:
MU M_LONDON M_BOSTON M_PARIS
M.U. offset 0 -5 +1
System schedule time 00h 05h 23h (d-1)
The offset value is displayed in all lists: Management Units, Tasks, Launches, Executions,
Execution history, Graphical job monitor, Business View monitor, Forecast workload.
The display mode may be chosen by the user.
• In the graphical interfaces, the display mode can be altered from the “Display/Reference time”
menu option. Initial value is defined by the environment variable U_TREF (system time by
default).
• In the command line interface, the display mode can be altered using the switches ASTIME or
MUTIME. If these switches are absent, the display mode will be set according to the value of
the variable U_TREF.
The variable U_TREF is described in the paragraph "Job parameters" on page 42.
By default, a Management Unit uses the system time on its node of residence.
2.4.1.4 Time zones and MU offsets

The system clock is frequently set at system initialization to the local time zone. In this case,
changes from Standard Time (winter) to Daylight Saving Time (summer) are handled automatically
in respect of local rules.
Initially two types of architecture are considered:
• Distributed: Processing power is installed near the users and the system clock reflects local
time.
• Centralized: Remote users from different time zones connect to a central server.
Distributed Architecture and local time
Dollar Universe uses the system clock to schedule new launches and is perfectly adapted to a
distributed architecture. Each system is equipped with its own scheduling engines which rely on the
local system clock. Jobs are therefore naturally scheduled in local time. All monitoring information
is displayed in local time wherever the monitor is situated.
Centralized architecture

However Dollar Universe may also be used to schedule jobs on a central server on behalf of users
in different time zones.
Natively the person creating a scheduled task for the Boston Management Unit, for example, on a
system set to GMT (Greenwich Mean Time) would have to manually integrate the 5 hour difference
(e.g. for a job to run at midday EST (Eastern Seaboard Time), it should be scheduled to run at 5pm
GMT.
Monitoring on such a system would be equally confusing, operators having to constantly make
mental conversions from GMT to local time.
MU offsets were integrated into Dollar Universe v5.3 to alleviate this headache. The 5 hour
difference between EST and GMT is created in the BOSTON Management Unit. All jobs scheduled
on the BOSTON MU will be scheduled in EST. The operator can then set his display to show
system time (ASTIME) or MUTIME as required.
Note that the MU Offset will have to be adjusted twice a year to reflect the switches between
Standard Time and Daylight Saving Time.
Distributed architecture but synchronized time
Suppose now that in a distributed architecture, all servers are synchronized on GMT. The
immediate consequence would be similar to the problems on a central server. Time differences
would need to be manually integrated into Task scheduling. Operators would have to constantly
convert GMT to local time.
In this case two solutions are available:
1. MU Offsets can be used as for the central server (MU Offsets need to be changed twice a year
for DST changes).
2. The TZ environment variable can be used to align system time in the Dollar Universe
environment to the local time zone. Set the TZ variable in the Dollar Universe logical
environment uxsetenv.
The advantage of using TZ is that switches between standard time and daylight saving time
can be handled automatically by the system.
The potential danger of this solution is that if a submission account does not have the same TZ
value defined in its .profile, timestamps may become incoherent.
The use of the TZ environment variable and MU offsets is mutually exclusive.
2.4.2 Management Unit types

Management Units may be grouped into types ("factory" type, "office" type etc.). The advantage of
this type of classification is that objects (sales offices, for example), can be identified without having
to be named individually. This generic addressing feature can be used:
• In job triggering commands within a processing stream.
• In defining conditions (dependency, non-simultaneity, file presence etc.).
• In formatting specific Dollar Universe commands.
• In distributing operations parameters to each individual environment.

The MU "type" is an important element in management of the environment, and the essential
element at the root of hierarchical data processing (HDP). It is an integral part of the Management
Unit code, which it functionally characterizes.
A Management Unit is coded as follows:
• First character: represents the MU type; this is the character used for HDP management;
• Following characters: additional identification.
Dollar Universe imposes no particular constraints on the coding of these Management Units. It is,
however, often useful to define, for each node, a technical Management Unit containing general-
interest functions.
Note: It may be useful to reserve a particular type ("N", for example) to designate Management
Units present in a single version at a given node. The presence of these Management Units and a
dedicated Management Unit type will facilitate the distribution of tables and other objects existing in
a single version on a given node, irrespective of either the number of Management Units or Areas
present (for example, Uprocs or Sessions). In this way, defining a Management Unit target to
facilitate distributions for these types of objects would thus be limited to "N" (meaning "all
Management Units of type "N"").
2.4.3 Hierarchical data processing

Hierarchical relationships between Management Units may be defined, under a technique known
as "hierarchical data processing" or HDP using an HDP-specific symbol; processing streams can
be described without prejudging the name(s) or the quantity of Management Units in question.
This guarantees the stability of the parameters for operations undertaken within Dollar Universe,
irrespective of any changes to the hardware configuration used (creation or concentration of sites),
or the data organization (creation or suppression of sales offices, for example).
2.4.3.1 Convention
These generic expressions allow implementation of the information contained in the Management
Unit types, and in the Management Unit dependencies, to be combined. Some examples of the
associated convention may be given:
• {XY} designates "all type 'X' MU dependent on the type 'Y' MU on which the current MU
depends".
• {X } designates "all type 'X' MU dependent on the current MU".
• { Y} means "all MU of type 'Y' on which depend the MU Where the expression took place".
• { } designates the current MU.
These generic expressions can be used to:
• Express conditions pre-requisite to running a procedure.
• Trigger procedures from within another procedure.
They enable the correlation between execution of a Uproc on a Management Unit, and the
execution of a Uproc on a sub-set of management-units. The generic expression is interpreted

dynamically. Conditions using these expressions automatically take into account the creation,
deletion or modification of Management Units.
Assuming a Management Unit hierarchy as follows:
The different conventions are implemented as follows:

{XY}This convention allows a "son" to see all "cousins":
A02 "sees" X11 and X12

A01 "sees" X01, X02, X11 and X12
• {X }
This convention allows a "father" to see all "sons" (but not "nephews"):
Y01 "sees" X01 and X02

Y02 "sees" X11 and X12
• { Y}
This convention allows a "son" to see his "father"
X01 "sees" "Y01"

A02 "sees" Y02
A01 "sees" Y01 and Y02
2.4.3.2 Roll-Out
If you create an HDP, it is recommended you have:
• an identical definition of the HDP used on every related node,
• an identical definition of the Session used on every related node,
• an identical definition of the Uprocs used on every related node,

• an identical definition of the users used (author codes only) on every related node.
To do this, it is advisable to distribute the following to all nodes to which the Management Units are
linked:
• The node table.
• The Management Unit table.
• The Management Unit type table.
• The Management Unit dependencies table.
• The Uprocs concerned.
• The Sessions concerned.
The User table does not need to be distributed, but on each node, a user must exist with the same
author code as the code defined in the submission account for the task (scheduled, provoked or
optional…).
2.4.3.3 False dependencies

A dependency is correct if the Management Units exist for this dependency. A dependency is false
if a Management Unit is missing (if a Management Unit is deleted, the corresponding dependency
is not).
When a HDP is applied, Dollar Universe checks false dependencies on this HDP. If a dependency
is false, a line is added to the general log of Dollar Universe:
<MISSING_MU> is missing for the dependency relation <MU> -
<DEPENDENT_MU>
Case of the Session
When a HDP is defined in a Session, a launch is created on all Management Units targeted by the
HDP.
• On the Management Units targeted by a false dependency, the launch is created with the
status Aborted and the line below is added to the execution’s history trace:
Management Unit <UG> <label> Unknown
Case of a Uproc dependency condition
• If all the MUs targeted are necessary: if there is a false dependency amongst the
dependencies targeted by the HDP, the launch is aborted and the line below is added to the
execution’s history trace :
No MU for this level
• If a single Management Unit is enough: the Management Unit targeted by the false
dependency is ignored, the Uproc will wait for a Uproc conditioned on other MUs.
• If an HDP does not return a Management Unit, the condition is false and the launch is aborted.
Case of the completion instruction
The Management Units targeted by false dependencies are ignored.
Case of non-simultaneity conditions

• A Uproc executing on a Management Unit checks the condition if the Management Unit is
targeted by the HDP.
• If a HDP returns no Management Unit, the condition is true.
Case of the resource condition
• If all MUs targeted are necessary: if there is a false dependency, the launch is aborted.
• If a single Management Unit is enough: the Management Unit targeted by the false
dependency is ignored, the Uproc will wait for the resource on other MUs.
• If a HDP does not return a Management Unit, the condition is false and the launch is aborted.
2.4.4 Implementation of Management Units

To help in understanding this logical representation of the environment, and demonstrate the power
of the Management Unit concept, certain operating examples are given below.
The following examples are provided to demonstrate the extent of possibilities where the
Management Unit concept can be used. Furthermore, the MU will be systematically used in the
replication of operations.
2.4.4.1 In the case of a manufacturing Company

Assuming a Company built around a sales organization comprising regional offices under the
control of a head office, with the regional offices themselves controlling factories and sales offices.
The immediate definition of Management Units for this organization would consist in creating as
many MU as there were entities (head office, regional offices, branch offices and factories).
Each entity of a given type will in all likelihood employ identical, or at least similar, data
applications. This similitude may be translated by attributing a common MU Type to the
corresponding Management Units.
The following Management Units could be created:
• Head office: C01,
• Regional offices: R01 and R06,
• Factories: U07, U16 and U34
• Offices: A01, A02, A11, A12 and A13.
Certain types of processing, such as consolidations, for example, can be used to highlight the
functional dependency between these entities.
Consolidation of daily production information is done directly by head office, while sales statistics
are initially aggregated at the regional level then at central level. The following diagram gives an
example of such functional dependency:

Functional links between MUs
This functional dependency can be translated into straight relationships of dependency between
the Management Units. The latter are thus organized in a form of network.
Depending on the availability of the hardware assets, this network can be supported by a greater or
lesser number of nodes, as illustrated below:
Figure 4: Distribution of MU dependencies within physical configuration
It should be borne in mind that all processes are described from the Management Unit
dependencies; the individual MU remains independent of the physical configuration.
2.4.4.2 Example 1: how to use the MU Type in the distribution process

Distribution of the "sales statistics" application to offices
The sales statistics application is developed at the Paris site.
Its automation is carried out at the same site, then distributed to the offices who are most
concerned by this application.
In parallel with distribution of the application, procedures defined within Dollar Universe will be
distributed to all Management Units of type 'A'.
The offices affected by this distribution are: A01, A02, A11, A12 and A13.
Thanks to this generic process, no office will be left out, and Dollar Universe will automatically
ensure distribution to the sites in question.
2.4.4.3 Example 2: how to use {X } convention in a triggering process

Setting off office jobs after decision by the region
Following distribution of the sales statistics application and automated procedures within Dollar
Universe, a processing stream is built as illustrated below.

This uses the HDP "{A }" convention meaning that the statistics job will be provoked on all
dependent offices of the region in question.
By this hierarchical method, when the "Regional_OK" is given for one of the regions, the statistics
job will be provoked on all offices (MU of type a) dependent on that region.
For example, if the "Regional_OK" is activated on region R01, statistics job will be provoked on
offices A01, A02 and A11.
The processing stream thus formed remains independent of the region of execution, the number of
offices or their links with such or such a region.
2.4.4.4 Example 3: how to use the {XY} convention in a synchronization

process
Synchronizing statistics jobs with stock updates
The statistics job, mentioned in the previous example, can run only if the daily stock update has
been processed on each factory (MU type = U) of the same region.
In which case, the statistics job will carry a dependency condition to translate this synchronization.
This condition, using the HDP Convention "{UR}", means that the statistics job will wait until stock
update processing has been correctly performed on all the factories dependent on the region to
which that office belongs.
For example, in order for the statistics job to run on office A02, the stock process must have run
correctly for factories U07 and U16. The same naturally applies for offices A01 and A11.
Synchronization of the resulting operations remains independent of the region of execution, the
number of factories their links to such and such a region.
2.4.4.5 Example 4: how to use the { Y} convention within a

synchronization process
Synchronizing the statistics jobs with the logical stock situation
The same statistics job, presented above, will also run only if each sales office of the region has
declared the day's undelivered orders, this obviously influences the real state of inventory.
It will therefore carry a dependency condition to translate this synchronization.
The condition, using the HDP Convention "{ R}", means the statistics job will wait until order entry
processing has been correctly performed for all offices dependent on the current region.
For example, in order for the statistics job to run on office A02, order processing must have run
correctly for offices A01, A02 and A11. The same naturally applies for offices A01 and A11

Synchronization of the resulting operations remains independent of the region of execution, or the
number of offices.
2.4.4.6 Example 5: how to reverse MU dependencies in a

synchronization process
Synchronization of the statistics job with price-book processing
Finally, the statistics job presented above will run only if the product price book has been delivered
by the head office to each region (bearing in mind that the said price book may differ for each
region).
It therefore carries a dependency condition whereby the price book processing (retrieval of price
book files generated at the central site) must have completed successfully for the region to which
the office in question belongs.
This condition, using the HDP Convention "{R }", means the statistics job will wait until the price
book processing has completed correctly for the region to which that office belongs.
This convention implies the definition of a dependency (inverted in relation to the dependency
defined previously), between each office and its associated region, as illustrated in the diagram
hereafter (upward-pointing arrows"):
Thus, for example, in order for the statistics job to run on office A02, the price book processing
must have completed correctly for region R01.
Synchronization of the resulting operations remains independent of the region of execution.
2.4.4.7 Documentation generating application

This example concerns a batch application designed to generate multi-lingual documentation for
various types of high-tech equipment.
This application brings together a number of procedures using parameters to indicate the type of
equipment in question and the language in which the documentation has to be generated as
parameters.
Thus the same processing stream will be executed for a set of Management Units based directly on
the equipment type/language combination.
This arrangement limits the number of processes to be defined in Dollar Universe, since the
Management Units do much replacement (a given operation will run as many times as there are

Management Units). The Management Unit is interpreted at the moment the procedure is executed;
the Management Unit code has only to be translated into type of equipment and language code.
Where certain jobs are common to all languages for example, a hierarchy could be set up between
the different Management Units defined, to translate the need for synchronization of the various
procedures in question.
2.4.4.8 A permutation processing application

This example considers a batch application designed to receive a very large number of files from
various clients (such as mail orders, for example).
The application requires special technical optimization of the disk resources consumed.
Considering the great number of files received each day, the aim is to distribute these to each disk
of the receiving machine in order to balance the i/o of each disk during processing of the files.
During handling of these files by the application, the latter will perform a given operation as many
times as there are disks.
In this example, Management Units will be used to declare each of these disks and have the
procedures run as many times as there are Management Units of the "disk" type.
Figure 5: Use of MU to represent technical objects
Apart from reducing the number of objects needing to be defined within Dollar Universe, this
representation has the advantage of not requiring any special parameters to be set when the
increasing quantity of data received makes it necessary to add a new disk to the configuration.
2.5 Nodes
2.5.1 Definition
Dollar Universe is designed to automate distributed operations it lends itself naturally to cluster and
network architectures.
The node in the Dollar Universe sense has the same meaning as in the computing sense,
designating a machine in a network.
As mentioned previously, the notion of node is in fact hidden (in Dollar Universe parameters)
behind the Management Unit to provide the greatest degree of flexibility in the operations process.
The node only intervenes during the actual processing on a machine.
Furthermore, Dollar Universe proposes, for all versions operating with TCP/IP, the possibly of
designating nodes logically; a file provides the correspondence between the logical node used by

Dollar Universe, and the name of the physical machine as recognized by TCPI/IP (see the
administrator's guide).
2.5.2 Central or local administration
2.5.2.1 Master node

Even if Dollar Universe benefits from a co-operative architecture and authorizes at the same time
either local or central administration, it nevertheless allows management of its administration tables
to be limited to a single focal point thanks to the notion of master node.
This arrangement is in many cases desirable based on the importance of the information contained
in the administration tables (description of the physical and logical environments).
Each node therefore recognizes a master node, which during installation of the Company is defined
as being the authorized node to modify its own administration tables.
If the Companies table points to a master node different from the current node, local update of the
administration tables will be impossible. They will have to be updated from another node, and then
distributed.
Note: The notion of master node is independent of the notion of central monitoring node.
The following diagram illustrates the notion of master node:

Node1 Node2
ADMINISTRATION ADMINISTRATION
company table company table
Master = Node1 Distribution Master = Node1
Update Consultation
Node3
ADMINISTRATION
company table
Master = Node5
Figure 6: Use of the master node
Note: As indicated in the above diagram, the notion of master node serves only to prevent local
modification of the administration tables, and in no case indicates any dependency in terms of
management of the platform for example, node 2 recognizes node 1 as its master node but can in
all cases be supplied (by distribution) from another node.
2.5.2.2 Central monitoring

Dollar Universe allows operations to be distributed over a large set of nodes; consequently a
central monitoring feature is provided to enable the control of certain tasks from a central node in
the architecture.
The central monitoring option can be set individually for each task (the default value is supplied in a
logical variable - see section "Context provided by Dollar Universe" on page 42) in order to supply
the central node with the necessary information for overall operations monitoring.

One of the node definition options allows it to be declared as the central node for operations
monitoring.
So for each node, it is possible to declare a central monitor node which will receive status of
execution of all tasks declared with the central monitoring flag.
Furthermore, it should be noted that only one node can be declared as central monitor node (in the
node table), so that distribution of the node table to a set of other nodes will result in recognition by
all the said nodes of a single central monitor node (possibly distinct from the master node).
The following example illustrates this notion of central monitor node and the impact of the notion of
master node.
Node1 Node2
Master = Node1 Node table Master = Node1
node table distribution node table
Central M. = Node2 Central M. = Node2
Node8 Node3
Master = Node8 Master = Node5
node table node table
Central M. = Node9 Central M. = Node2
Figure 7: Illustration of the notions of master node and central monitor node
2.5.3 Additional characteristics of the node
2.5.3.1 Authorization by Area

Authorization to the development universe (application and integration Areas) and the production
universe (simulation and production) is determined in the node table.
In this way, access can be limited to certain Areas on, a given machine.
Note: In order to avoid disparities between parameters, it is recommended to locate the

development environment for the operations processes to a single development node, and
distribute Dollar Universe objects from this node only.
The following diagram illustrates this type of organization:

Development node Production node
Production
Development
Distribution
of
Transfer parameters
Production Production
Production node
Figure 8: Authorization of nodes to Areas

Note: This organization is valid for all operations of definition and modification of parameters, that
is, update, transfer and distribution.
2.5.3.2 Directories
Since Dollar Universe does not know beforehand the architecture of the target node, this
information gives direct access to the target node's data and executables.
2.6 Declaring the applications environment
2.6.1 Applications and domains

Computer applications are generally reduced into sub-sets. The functional domain and the
application are two distinguishing criteria proposed by Dollar Universe.
• A domain is defined by a code and a label.
• An application is defined by a code, a label and the domain to which it belongs. Several
applications can belong to the same domain.
The application and the domain are used by Dollar Universe for analysis and structure of all the
managed Uprocs.
The definition of the Uproc is effectively linked to the application (and therefore a domain), see
section "Uprocs" on page 38.
2.6.2 Application or MU directories

The notions of Areas and Management Units make it possible to define a logical organization for
the computing environment. Each of these notions can be optionally associated with the physical
structuring of the overall environment, defined within the framework of the administration tables.
This physical organization is designed to allow meshing of the disk space using access paths to the
directories where the main computing objects and data reside.
Since Dollar Universe does not impose any particular constraints on this feature, it allows the
individual norms and standards of each customer to be taken into account.
Each application program directory can thus be defined:
• In VMS, by specifying either a disk name (four-character code) and a directory name, or a
global logical name,
• In OS400, by typing the name of the library in question.
• In UNIX or Windows, by directly typing the name and the access path to the directory in
question.
The values of the access paths to the application program directories are restored, in environment
variables (UNIX and Windows), variables (AS400), or symbols (VMS and OPENVMS) during
execution of the Uprocs, see section "Context provided by Dollar Universe" on page 42.

Note: The environment definition is of course optional, save for Dollar Universe, which locates its
own data and executable programs through these tables.
2.6.2.1 Application directories

Dollar Universe can manage access paths to the programs (or other assimilated objects) of
applications in terms of node, universe or application.
Unlike data, for which it is possible to distinguish access paths Area by Area, Dollar Universe
manages program directories only in terms of universe (production or development).
Furthermore, this declaration is independent of the Management Units resident on the node in
question, since the objects are independent of the data on which they operate, and consequently,
common to the Management Units with which they serve.
The corresponding table can be defined centrally and then distributed to each of the nodes,
needing knowledge of the application environment described.
2.6.2.2 MU directories
For the same reason as the programs, Dollar Universe provides, each of the Area / Management
Unit / application set (the node is implicit, the Management Unit being resident on a single node),
the ability to declare an access path to the application-specific data for the Management Unit in
question.
The corresponding table can also be defined centrally and distributed to each of the nodes
requiring knowledge of the application environment thus described.

3. Users
3.1 Definition
Dollar Universe distinguishes two main types of user:
• The users of Dollar Universe interfaces (command, Motif, Java and Windows),
• The submission accounts used for running batch operations.
Note: A given user can have both functions.
Users are identified by their profile. Profiles control access to Dollar Universe functions and data
(see section "Access control to data and functions – the SECURITY file" on page 32).
Defining user profiles makes it also possible to organize individual work stations in Dollar Universe
to suit actual user requirements (see section "Customization of interfaces" on page 32).
Prior to logging in, each user must be known to Dollar Universe. This identification is managed by a
user record in the "user table" which in turn points to a user profile and an "author code".
The author code is a trigram (signature) that characterizes a username. It serves as a reference to
identify the submission account to use for running a task in Dollar Universe (see paragraph
"Submission accounts" on page 33).
3.2 Access control

Besides system access rights (see administrator's guide), Dollar Universe proposes two types of
access control for its functions and data:
• Proxy definition permits global access control to a server for each of its client.
• The definition, for a given node, of the authorized actions authorized or forbidden in the
command, MOTIF, Java, and Windows (Dollar Universe Console) interfaces.
3.2.1 Server access control - the proxies

On UNIX and Windows, the implementation of security protocol based on the proxies permits
access to a data site to be authorized or prohibited.
A Dollar Universe user is identified by a given system user (group or domain – system user name)
connected to a machine. This association "system user/Dollar Universe user" is called the proxy.
30 • Users Dollar Universe v5.6 Reference user's guide

The proxies are defined locally on the server that carries out the control of the application that
initiated the connection, which can be:
W32 for Windows system users,
UNX for UNIX system users,
VMS for VMS system users,
AS4 for AS400 system users,
MPE for MPE system users,
WEB for Internet users accessing from Dollar Universe Web Control,
DOC for Publisher users,
REP for Reporter users.
These commands (see administrator's guide) permits the definition and modification of the proxy
binary files used by the Dollar Universe IO server. These commands are stand alone and do not
need the IO server to be started to work.
Example of proxy file defined for the Company 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>
3.2.1.1 Users not referenced in Dollar Universe

If the Dollar Universe proxies are activated, a user not referenced in the Dollar Universe proxy
management cannot open the Dollar Universe interface.
A user not referenced in the administration tables of the Dollar Universe Company cannot open the
Dollar Universe interface.
3.2.1.2 Declaration of a proxy user on a server

Variables must be defined in the environment file and point to the proxy file (See the administrator's
guide for details). This file is then loaded by the IO server at startup.
If the environment variable doesn’t exist, the server will not manage the proxies and will authorize
access from all clients.
If the variable is defined but the proxy file doesn’t exist, it is automatically created and no clients
can connect to the server before at least one entry is defined in the proxy files.
3.2.1.3 Proxy management commands

These commands permit proxy file management. They are detailed in the administrator's guide.
Dollar Universe v5.6 Reference user's guide Users • 31

Command Description
lstproxy Lists the contents of the proxy definition file.
setproxy Adds or modifies the definition of an entry in the proxy file.
delproxy Deletes a record in the proxy file.
getproxy Verifies the coherence of the proxy file.
loadproxy_io Notifies the IO server of a modification to the proxy file.
3.2.2 Access control to data and functions – the SECURITY file

For the command and graphical interfaces, Dollar Universe provides access control to its functions
and data according to the Area.
Access control is dependent on the user profiles definition (associated with a user when it’s defined
in the user table) and the rights associated with these profiles. Specific rights can also be defined
for particular users.
These controls are described in the file which is composed of: the headers, the controls, the key
words for the operations and for the objects (see administrator's guide for the usage description of
this file).
Access to actions is tied directly to the specification of the action (e.g. display, create, update, etc.).
The action is authorized or denied for specified objects.
Objects are protected either by their type (e.g. Uproc, Task, Engine), or for the subset of a type
(e.g. Uproc=U*, restrains the specified action to all Uprocs beginning with U).
For each object there are a certain number of keys which may carry restrictions.
The controls are different according to the profiles. The profile PROFADM has access to all objects
and all actions.
3.3 Customization of interfaces

These functions are available in the Windows interface.
The Java, Motif and Command interfaces do not allow changes to the vocabulary or the
organization of the interface.
The aim of this function is to allow the creation of customized menus for the Windows interface
tailored to the requirements of each organization.
It defines:
• The standard desktop for a profile.
• The user’s default desktop.
The wording of folders can be modified, adding to the degree of customization attained.

3.3.1 Dollar Universe Console customization
Customization of the Dollar Universe Windows interface rests both on the definition of a standard
Desktop for a profile and a user Desktop.
A standard desktop is defined by default for each profile created by Dollar Universe at installation:
PROFADM (administrator), PROFDEV (developer) and PROFEXP (operator).
A user having the administrator profile (PROFADM) can create and modify desktops associated to
this profile (a profile = a standard desktop). It can also give users of a profile the possibility to
create their own user desktop, which would be specific to each user.
The manipulation of desktops is described in the Dollar Universe Console user's guide.
3.4 Submission accounts
3.4.1 Definition
Each of the two user populations can form a submission account, conditional on the following
restrictions:
• Development-users can only be used as a submission account in the development universe.
• Production-users can only be used as a submission account in the productions universe.
On the other hand, a "mixed" user (i.e. Developer as well as Production) can be used as a
submission account in all Areas.
The Administrator user account for the Company (by default <COMPANY>a) must be defined
during installation as the submission account for all Areas.
3.4.2 Using the author code

The author code is a trigram (signature) characterizing the user. It consists of three capital
characters: from 0 to 9 and from A to Z (from version 5.3).
One such code must be present for every user account. It serves as a reference identifying the
account to use when running tasks in Dollar Universe.
All jobs scheduled within Dollar Universe, even if attributable to a user (development or production)
only memorize the author code, to ensure that automatic conversion can be performed between
submission accounts during implementation. This occurs during the transfer phases (automatic
translation of a development-user into a production-user with the same author code), and also in
the distribution phases (for example, automatic translation of an end-user for a given node into
another end-user on another node). The following example illustrates the advantages:
Example: A task is planned in the applications Area and is associated with an account whose
username is "cpttest". The author code for this account is "A01".
The task in question is distributed to a remote Management Unit.
On the node supporting the Management Unit in question, the account "cpttest" is not defined, but
another account with the username "accnt" and an author code "A01" exists.
Dollar Universe v5.6 Reference user's guide Users • 33

When it is time to run the task in question, the author code will ensure that the account "accnt" is
linked to it.
The above example shows that it is not necessary to standardize accounts for all the nodes
affected by a Dollar Universe operation. It is simply necessary to link the reference formed by the
author code, to existing accounts.
The author code therefore contributes to the portability of tasks defined in Dollar Universe, from the
development environment to the production environment.

4. Parameters
4.1 Resources
In Windows and UNIX, the resource enables, using a logical identifier, the description of a system
resource or a logical one (virtual) which should be scanned in order to condition the running of
operations procedures.
4.1.1 Definition
A resource is identified by a reference:
• The reference is a logical identifier allowing the Uproc to adapt to its executing environment. In
the event of a change of node (or even of operating system), the Uproc description will adapt to
take account of any related special features.
• Resource references are defined globally for a given node, irrespective of the Area.
A resource is defined by its nature:
FIL: file UNIX, Windows
LOG: logical UNIX, Windows
SAP_JOB: SAP job UNIX, Windows
SAP_EVENT: SAP event UNIX, Windows
JMS: Java message service UNIX, Windows
The usage of the different types of resources depends on whether the correct Dollar Universe
licenses have been installed or not (please refer to the Licenses paragraph in the Administrator's
guide).
A resource is identified by:
• Its name: Physical name of the resource to supervise, in the sense of the operating system.
• Its location: Name of storage object (for example, the directory name for a file).
The resource "location" is exclusively used for resource categories "FIL".
Note: This location may refer to resources not resident on the resource analysis node, provided
that it is allowed by the primitives of the operating system used (corresponding to the defined
category and attribute).
If a resource is defined as "exclusive", it may not be shared by another conditioned Uproc.

Otherwise, quotas may be defined to manage resource sharing between Uprocs (see section
"Resource condition" on page 59 for the quota mechanisms):
Dollar Universe v5.6 Reference user's guide Parameters • 35

Quota 1 Maximum value of the resource's quota 1, which may be between 0 (default) and 9999.
Quota 2 Maximum value of the resource's quota 2, which may be between 0 (default) and 9999.
Finally, a resource is examined according to a specific frequency (by the supervisor: see section
"Substitution of the resource supervisor" on page 107).
4.1.2 Codification
The resource name may be encoded with certain functional elements proposed by Dollar Universe.
The following expressions can be inserted into a resource name.
This coding is usable only for the resource natures "LOG" and "FIL". They can be inserted at any
point in the name.
• "!UG!": The Management Unit code can be inserted into the name; this is the code obtained
from data defined by "Management Unit control" on the resource condition. If interpretation of
this data points to several Management Units, the generic resource name created by insertion
of this expression will correspond to the same number of resource names as there were
Management Units designated.
Caution: Even if the Management Units targeted by the condition are not resident on the
examined node, the corresponding resources will be searched locally (unless the location
refers to a remote resource).
• "!DTRAIT!": The processing date can be inserted into the resource name; this is the date
expressed in the "Processing date control" of the resource condition (format: YYYYMMDD).
• "!SOC!" Allows the name of the current Company to be inserted during examination of the
resource condition.
• "!ESP!" Allows insertion of the current Area code (A, I, S or X) into the resource identifier during
examination of the resource condition.
On UNIX or Windows systems, for a "FIL" resource, the name of the file may contain a wildcard (*)
anywhere in its name. The wildcard may not be used, however, in the location of the file. Neither
are the characters " ? " or " [ ] " accepted by the scheduler.
On Windows, for a file resource type, the UNC paths are managed (starting from Dollar Universe
version 5). In order for file detection on UNC paths to work, the launcher and supervisor must have
the rights to access the UNC path. Due to this fact, the Windows services associated with the
engines must be started in the name of a user possessing these rights (authentication rights for the
Windows domain and the access rights to the file).
Note: On VMS and OPENVMS, in order to ensure that the operations process remains as
independent as possible of the environmental organization, it is advisable to use logical names to
define the location (access path) of a file rather than its name. In general terms, adding variables
into resource names and locations will depend on the "dynamic" character of the parameters
proposed (that is, which can change over time): therefore "static" concepts ("!UG!", "!SOC!" And
"!ESP!") Will be used for the location, while "dynamic" concepts ("!DTRAIT!") will be employed in
the resource name.
Example: reception and consolidation of files from shops

The Uproc employed for consolidating files from the shops has a resource condition based on its
reference, defined as follows:
Type FIL
36 • Parameters Dollar Universe v5.6 Reference user's guide

Attribute exist
Name comm_t!DTRAIT!g.dat
Location rep_!ESP!!UG!
The "MU control" associated with this condition is a HDP convention of type "{S }" (all shops
depending on head office, such as "S01" and "S02", for example).
The "Processing date control" associated with this condition will use identical processing date to
the processing date of the considered Uproc (same day, for example).
When launching the Uproc for 21 December 2004, Dollar Universe translates the symbols "!UG!"
And "!DTRAIT!" By their values as obtained in the "MU Check" and the "Processing date control".
If the launch takes place in the production Area, the files to supervise will be:
REP_XM01: COMM_T20041221G.DAT
REP_XM02: COMM_T20041221G.DAT
Where REP_XM01 and REP_XM02 will be logical names describing the directories for storing the
COMM_T20041221G.DAT files.
If the option "all necessary" was selected for the "MU control", the two files must be present in order
for the condition to be satisfied.
4.2 Incompatibility classes
4.2.1 Purpose
Non-simultaneity conditions make it possible to define extremely refined processing exclusions.
Nevertheless, they are not symmetrical. In fact, when two Uprocs should not be executed
simultaneously (i.e. are incompatible), the non-simultaneity condition must be present in the
description of each Uproc.
This constraint can be problematic in the case where whole applications must be considered as
being incompatible, therefore, globally non-simultaneous.
On Windows and UNIX, incompatibility classes are a simple and effective solution to this kind of
problem.
4.2.2 Using incompatibility classes

Associating a Uproc with a class allows the definition of "incompatible execution" processes,
conditioned by the following rules:
• A Uproc can belong to one (and only one) class (declared in the Uprocs "general information").
• A Uproc may be defined as being incompatible with one or n classes.
The rules for examining these incompatibilities are the following:
• Examination is performed locally,
• For each Uproc launched (assuming that its incompatibility constraints have been satisfied),
Dollar Universe memorizes:
o Its membership class (references of the "membership" type),

o Other classes with which it is incompatible (references of the "incompatibility" type).
• When launching any Uproc, Dollar Universe ensures:
o That its membership class is not already memorized among the classes referenced in the
"incompatibilities" type,
o That the classes with which it is incompatible are not already memorized as classes
referenced in the "membership" type.
Therefore a given Uproc cannot be run simultaneously with another Uproc from a class with which
it is declared incompatible. Similarly, no Uproc can be run simultaneously with another if it has
been declared as incompatible with the other's membership class.
Note: Incompatibility classes are examined locally by the launcher: this examination applies only to
those Uprocs running for the Management Units residing on the examining node.
Incompatibilities described by means of classes are systematically examined before condition

checking (examining operating conditions) on the Uproc in question. In this respect, the notion of
class does not figure in the launch formula.
Example: Uproc classes
A good example of the use of incompatibility class is backup processing, where it is preferable not
to have any other type of processing running concurrently.
All backup Uprocs will be declared as belonging to a class, with which all the other Uprocs will be
defined as "incompatible".
4.3 Uprocs
4.3.1 Definition
The Uproc (Universe procedure) is comprised of:
• A set of characteristics and logical conditions which define the functionality of the procedure
(known as "launching" the Uproc). This information is defined in the Uproc by:
• A command, a file containing commands (known as CL: Command Language) or by a specific
pre-formatted function (without CL) such as: Manager for FT, Manager for SAP Solutions,
Manager for JMS, Manager for Java, etc.
• So-called "completion" instructions whose purpose is to define the "post-processing" performed
for updates, or for purging history files, or for preparing the dependent job stream.
The resulting Uproc is a standalone object whose constituent parts are not dissociable from a
Dollar Universe perspective.
The Uproc is defined for an application (itself dependent on a domain). It has parameters
(Information and Severity) that can change during execution, enabling filtering in the job monitoring.
The Uprocs are submitted by the scheduler to a batch queue to await execution (or submitted to
the system in the background, under UNIX or Windows, in the absence of Dollar Universe
Distributed Queue Manager).

The scheduler analyses the Uproc execution result depending on certain rules (see paragraphs
"Completion status of the Uproc" on page 45 and "Job status" on page 110) and sets its final
status. Depending on the completion status, an e-mail can be sent (see paragraph "E-mail
notification" on page 50).
4.3.1.1 Working Environments

The Uproc creation and management functions are available in each Area managed by Dollar
Universe. Uprocs are instantly executable on the node and within the Area in which they are
created.
If it is necessary to run a Uproc in another Area, a prior transfer of the Uproc will be required. If it is
necessary to run a Uproc on a Management Unit residing on a node other than its development
node, a distribution will be required.
4.3.1.2 Uproc types

Dollar Universe supports several different types of Uprocs:
• The "CMD" type enables the user to define a system command to be executed directly in the
Dollar Universe interface, without needing a script. These Uprocs are described in paragraph
"Command type Uprocs" on page 39.
• The types "internal CL" or "external CL" represent a file extension .bat in Windows, a shell
script in UNIX, a procedure .com in DCL using VMS, or a program in CL in OS400 (CL, DCS
and shells are detailed further within this documentation in the General Vocabulary section,
under "CL" meaning "Command Language"). These Uprocs are described in the paragraph
"Procedures or programs (DCL, shell, CL, .bat)" on page 41.
• The types "SAP_IPACK", "SAP_CHAIN" and "SAP_XBP2" represent the submission Uprocs
for SAP jobs. They are documented in "Dollar Universe Manager for SAP Solutions – User
Manual".
• The types "FTP_GET" and "FTP_PUT" represent retrospectively the Uprocs used to receive
and to send FTP files. They are documented in "Dollar Universe Manager for File Transfer –
User Manual".
• The type "JMS" represents the Uprocs designated to send JMS messages. This type is
documented in "Dollar Universe Manager for Java – User Manual".
• The type "EJB" represents the Uprocs to invoke EJB (Enterprise JavaBeans). This type is
documented in "Dollar Universe Manager for Java – Getting Started".
The usage of the different types of Uprocs depends on whether the correct Dollar Universe licenses
have been installed or not (please refer to the Licenses paragraph in the Administrator's guide).
4.3.2 Command type Uprocs

The CMD type Uproc enables the user to execute a single system command. The following
information must be specified:
• The command to be executed.
• The path to the command.

• The arguments of the command.
• The execution directory of the command. By default, this is the home directory of the
submission account for which the Uproc is executed.
The first three items of information appear together on the command line that is submitted directly
by the Launcher. The execution directory is specified separately.
Note: If the command line does not contain the complete path to the command, the Launcher will
look for it in the PATH variable (under Windows and UNIX).
4.3.2.1 Description of the command

The command to be executed depends on the operating system and can thus vary from one
system to another.
Under Windows or UNIX, the command can be a system command, a binary or a script with the
required execution rights. For example:
netstat
/home/user/myScript
cp –p file1 file2
The command line must respect the syntax of the operating system on which the Uproc is
submitted.
On Windows, "CMD /C" must precede a shell command. For example: CMD /C dir
The launcher does not make any checks: it replaces the variables by their values (if any, see
paragraph below "Use of variables in the command line" page 40) and submits the command to the
operating system. It does not check the syntax of the arguments.
4.3.2.2 Use of variables in the command line

Variables can be used in the path to the command and/or in the arguments.
The variables used can be:
• System or user environment variables known at the time of execution (environment of the
submission account that executes the Uproc),
• Variables of the Uproc.
The syntax is independent of the interface used (Windows, Java, Dollar Universe commands):
• The variable name must be enclosed in "!" characters, for example:
!VARIABLE!
• The command line may include variable and invariable parts, for example: if !DATE! is
"20060725" at execution time, FILE_!DATE! will be replaced by: FILE_20060725.
• If the variable is not defined, the label of the variable !VARIABLE! remains unchanged.
• If the variable is defined but empty, it is replaced by an empty string. For example: if !DATE!="",
FILE_!DATE! will be replaced by: FILE_.

• The syntax !VARIABLE:n:p! can be used to extract (from the value of the variable) "p"
characters starting from position "n". The first position is 0.
"p" is optional. If it is not specified, this means "up to the end of the value of the variable".
For example, if DATE=20060725:
o !DATE:0:4! returns 2006,
o !DATE:4:2! returns 07,
o !DATE:6! returns 25,
o !DATE:i! (if i > 7) will be replaced by a null string.
4.3.2.3 Execution of the command

Return code management for Uprocs of the type CMD has changed in version 5.6. To continue
with the previous system, the variable U_UPRCOMMAND_OLDMODE can be set in the Company
environment file uxsetenv, see the Administration Manual for more detail.
The launcher submits the command to the operating system.

By default the Uproc completion status is determined by the return code of the command (or script).
Advanced management of Uproc completion statu scan be applied if necessary (see paragraph
Completion status of the Uproc).
The execution log of a CMD type Uproc uses the standard presentation of Dollar Universe. It
contains:
• The command line with its arguments. The variables (if any) are evaluated before writing to the
log,
• The standard output and the error output,
• The return code of the command.
4.3.3 Procedures or programs (DCL, shell, CL, .bat)

Two Uproc types are used for managing the command language file associated with the Uproc:
CL_INT for files managed by Dollar Universe and CL_EXT for files managed outside of Dollar
Universe.
4.3.3.1 External CL Uproc

The decision to manage the command language externally to Dollar Universe (CL_EXT type)
entails identifying the file containing the corresponding command language instructions. This
parameter is a filename whose writing conventions comply with those of the operating system in
question. Any access path can be used to this file (but it naturally must exist on the node where the
Uproc will run). The access path may be explicitly declared or logically using a local variable
declared:
On Windows:
• In the uxsetenv file located in the Company's mgr directory,

• In the <COMPANY>.def and UNIVERSE.def files located in the Company's exec directory.
On UNIX: in the 3 uxsetenv files (uxsetenv, uxsetenv_csh, uxsetenv_ksh) located in the Company's
mgr directory.
4.3.3.2 Internal CL Uproc

For Uprocs with internal CL (CL_INT type):
• The file containing the command language is created with the name and the version number of
the Uproc (UPROC_NAME.VERSION). It is stored in a Dollar Universe directory (directory
containing the Uprocs for the Area: UXPxx) declared during installation. See the Installation
user's guide.
• Dollar Universe ensures parallel evolution in the Uproc version number and the version number
of the CL File for internal Uprocs. For external Uprocs, this parallel evolution feature is not
ensured.
• In all transfer, distribution and extraction operations, Dollar Universe ensures the transport of
the Uproc with its internal CL file.
4.3.3.3 Writing procedures

The interactive Uproc-writing functions proposed by Dollar Universe use the standard editor of the
operating system in question.
• On UNIX, a local environment variable (see the administrator's guide) can be used to specify a
text editor for both read-only and write operations. By default, the vi editor is used on UNIX.
• On VMS, there is a choice between the edt and tpu editors. It is one of the Company's
characteristics.
Within the command language, Dollar Universe authorizes insertion of specific commands allowing
communication with the applications; this applies for functions such as:
• Inserting execution checkpoints or steps in the CL.
• Triggering a Uproc on behalf of a number of Management Units.
• Restoring, as dedicated variables, the names of the directories containing the data-processing
objects of each application managed by Dollar Universe. Within the CL associated with the
Uproc, the corresponding command avoids the explicit reference to data that may differ
depending on the execution context (i.e. Area, Management Units).
• Transmitting messages towards the history trace for the Uprocs managed by Dollar Universe,
etc.
The Dollar Universe commands which may be inserted into the CL are described in the Command
interface user's Guide.
4.3.3.4 Job parameters

In Dollar Universe, parameters are transmitted in various ways as presented below. The specific
commands are detailed in the Dollar Universe Command interface user's guide.
Context provided by Dollar Universe

During start-up, Dollar Universe provides a set of environment variables, or logical names that can
be used for writing the procedure. These variables are the same regardless of the operating system
in question, but have a distinct prefix in each case (such as "S_" in UNIX or Windows).
This logical environment is available in the preprocessing procedure: U_ANTE_UPROC, in the
Uproc script and in the post processing procedure: U_POST_UPROC (See paragraph "Additional
processing" on page 109).
Name Function Format
EXE Application directory.
FIC MU directory.
LO*GOUT Housekeeping procedure executed at the end of the work
Session.
S_APPLI Uproc host application. 2 char
S_CODAUTEUR Author code of the submission account. 3 char [0.9] [A,Z]
S_CODNOEUD Dollar Universe node name that corresponds to the node or 10 char
S_NOEUD the cluster alias.
S_NODE
S_NODENAME Dollar Universe node name. 10 char
S_CODSESS Session name. 10 char
S_CODUG Code of the current Management Unit. 10 char
S_DATRAIT Processing date of the running Uproc. YYYYMMDD
S_DATRAIT_E
S_DATRAIT_X Processing date in the format U_FMT_DATE.
S_DATRAIT_A Processing date. YYMMDD
S_DOMAINE Domain to which the Uproc is attached. 1 char
S_ESPEXE Current Area code. X, S, I or A
S_LOGINPLUS Indicator allowing several logins under the same user name,
sacrifices memorization of context in the character interface.
S_LOGINSTD Reserved for ORSYP developers.
S_NUMJALON Step number used for job recovery. 2 num char
S_NUMPROC Order number of current Uproc. 7 num char
S_NUMSESS Order number of the Session. 7 num char
S_NUMVERSESS Version number of the Session. 3 num char
S_NUMLANC Launch number. 7 num char
unix_status On UNIX, exit returned by the U_ANTE_UPROC procedure.
S_P1 to S_P30 Parameters sent to the Uproc by an uxordre or uxset parm
command.
S_SIBATCHNP Number of parameters passed (from 0 to 30). 0 to 30
S_PID Process ID.
S_PROCEXE Name of current Uproc. 10 char
S_REP_EXEC Directory address for UNIVERSE executables.
S_REPRISE Recovery flag. O or N
S_CODREPRISE
S_RESEXE On VMS, Uproc standard return code (see section "Uproc
submission" on page 109).

Name Function Format
RESEXE On Windows and UNIX, Uproc standard return code.
S_SBPROC Technical parameters for Uproc launch.
S_SIGSOC Company code.
S_SOCIETE
S_T Memorization of $STATUS at Uproc completion.
S_U_LANGUE Current language. EN or FR
S_U_RETCOMM Return code specific to UNIVERSE special batch commands.
S_USERNAME User submission account.
S_VEREXE Version number of current Uproc. 3 num car
U_CDJ_DISABLE Disable Graphical Job Monitor flag. Y or N
U_FMT_DATE Entry and display format for the date, a combination of YYYY
(year), MM (month), DD (day of the month) and potentially a
separator such as /: or -.
S_VERIFY Memorization of verify mode.
U_LOGIN_SET Login flag to avoid looping.
S_EXECFORCE Indicates submission bypassing the condition check. Y or N
S_FORCEFINPER Indicates forced launch at the end of launch window Y or N
S_STAT_AVG On Windows and UNIX: average elapsed time for a job. To
activate the value of S_STAT_AVG, set the variable
U_GET_STAT_AVG to Y in the Dollar Universe environment.
U_TREF U_TREF set to "MUTIME" indicates that the time displayed is 6 car
that of the Management Unit.
U_TREF set to "ASTIME" means that the time displayed is
the system time.
Transmission of additional parameters to a procedure

Over and above the stated execution context (see above), the need for transmission of parameters
should be dissociated from the question of whether the related processes are periodic or not;
periodic processes (automatic submission without human presence) naturally require no particular
parameter settings except in cases where:
• Parameters are passed from one procedure to another.
• Automatic feeding of default parameter settings, insofar as the CL systematically requires
parameters during submission, will systematically need to receive parameters).
Dollar Universe satisfies these requirements as follows:
• Within a given Session, two procedures can exchange up to 30 parameters of 256 characters
each (see Command Interface user's guide for details concerning writing of the CL).
• By allowing the handling of purely application parameters (called variables) attached to the
Uprocs with a mechanism for assigning values which is set out in the next paragraph.
Finally, for non-periodic processes, Dollar Universe offers a specific command (uxordre) for
provoking batch Uprocs that accepts parameters of the following capacities. Refer to the Command
Interface user's guide.

4.3.4 Completion status of the Uproc
The completion status of the Uproc is set by default according to the general rules described in the
paragraph "Job status" on page 110. It can be changed by an additional definition in the Uproc.
To attribute the status Completed or Aborted, the user can choose one of the following methods:
• Simple analysis of the value of the Uproc’s return code using:
o One of the operators: equal (default), greater than, less than, not equal,
o A positive or negative integer.
By default: status "Completed" if "Return code" = 0
Another example: status "Completed" if "Return code" > 16
• Extended return code: the status is set to Completed or Aborted if the return code
corresponds to one of the indicated values/
o A simple value. Format: * or a positive or negative integer.
Example: -2
o A range of positive or negative integers. format : [min,max].
Example: [-10,10] : from -10 to 10 inclusive.
o Values calculated from a multiple: Format N/m
Example: */3: all multiples of 3 (including negatives).
o Values calculated within a range using a specific multiple (m): format [min.max]/m
Example: [1,10]/4 : 4 and 8.
Each of the values or ranges must be separated by a colon. The whole list should not exceed
64 characters. For example:
-2;[-10,10];*/3;[1,10]/4
• searching for a character string in the Uproc log or a specified file:
o Free text of 128 characters maximum,
o Log or full file name with 258 characters maximum.
For example: search for the character string "normal completion" in the file
"c:\temp\teststatus.txt".
If the option "Auto-Retry" was selected in the Uproc parameters, the completion status of the Uproc
will be examined at the end of every run as described above, but will not be displayed until the end
of the last retry. See paragraph Auto-Retry.
4.3.5 Auto-Retry
The Uproc can be set to be automatically re-run in case of an aborted completion, The user defines
the number of retry attempts and the delay between reties.
• If the Uproc completes successfully, the auto-retry feature will be turned off and final status will
be “Completed”.

• If the Uproc continues to fail up to the maximum number of retries, the final status will be
“Aborted”.
The “running” status is maintained during the retry cycle until the final status has been determined.
Uproc conditions are checked to validate only the first execution; they are not re-evaluated for each
retry.
If the Uproc is in a Session, the Session will only be able to continue once the final status has been
determined.
If the Uproc conditions other Uproc executions, the conditions will only be satisfied once the final
status is clear (HDP included).
Each retry generates traces in the History Trace (paragraph Display history trace) and in the
Uproc’s job log. (paragraph Display log).
4.3.6 Variables
This Dollar Universe function enables variables to be defined and inserted. This can be done in
command mode or via the graphical interface and during the development phase for operational
objects as well as during production.
Thus, the objective is to allow manual or semi-automatic preparation of the batch operation.
4.3.6.1 General principles

Thus, Dollar Universe enables:
• Names and types of variables to be defined and default values (which can be subsequently
modified) assigned to them at the time of Uproc definition.
• To transmit variable values between Uprocs in a Session (by executing a specific Dollar
Universe command uxset var in the Uproc script, see the Command Interface user's guide).
The Uproc variables identifying the Task are automatically assigned to the Task. Their values can
then be changed for this schedule.
The Task variables are automatically assigned to the Launch when it is created. The user can
change their values in the Launch.
The user can also change their values on resumption of an execution if a value needs to be
changed at this stage.
The value of a variable can also be modified when the task is triggered, or when the launch is
created in command mode, or when the CL is executed.
4.3.6.2 Characteristics
Variables are defined in Uprocs. They are given names. And they have the following
characteristics:
• Maximum number of variables: 80.
• Length of the variable’s name: up to 20 characters.
• Types of variable: date, numeric or text.

• A variable’s value: a maximum of 255 characters for text, 12 for a numeric variable (positive or
negative).
Values are assigned to these variables, by a commands mechanism within the Session, in Uprocs
at the time of their definition, in tasks, launches or an execution restart.
4.3.6.3 Assigning values

The variables can be used directly in the Uproc’s CL. A variable’s value at the time of execution is:
• At the time of execution within a Session, the value can be carried over via execution of a
command in the Uproc’s CL (uxset var command, see the Command Interface user's guide).
• In the event of an execution recovery, the value is that indicated at the time of the recovery.
• Or, the value is that allocated to the launch.
• Or, the value is that allocated to the task.
• Or, the value is the default value of the variable shown at the time of its definition in the Uproc
(the value on the local node where the Uproc is executed).
4.3.7 Functional period and processing date
4.3.7.1 Definitions
Dollar Universe carries out operations in their order of occurrence; it does not recognize the notion
of operating date. Instead, it recognizes applications periods for which operations are run.
The functional period allows the dating of data processed during a Uproc run.
In this way, all Uproc launches are accompanied by the automatic calculation of (or request for) a
processing date (unless the Uproc has no functional period). This date depends directly on the
Uprocs functional period (unless the Uproc is defined without a functional period).
Accepted values for the functional period are:
None 2 weeks 4 months
Day Month 6 months
Week 2 months Year
10 days 3 months
The processing date is expressed as day, month and year, irrespective of the functional period. If
one element of the processing date is not needed, it will not be requested, and will automatically
assume the value of the starting date of the period that is selected.
This date serves as a reference model to automatically calculate all the other dates encountered
during the condition check, execution of the CL, or completion.
If the Uprocs functional period is:
• Day: The requested period is a complete date: day month year.
• Week: The requested period is the week number (from 1 to 53) in the year (NNYYYY), or the
corresponding date (day month year, which is inevitably a Monday).

• Ten days: The requested period is first the month and the year, then the number of the ten-day
period (1, 2 or 3), the corresponding processing dates being the first, the eleven and the twenty
first of the month.
• Month: The requested period is the month and the year (MMYY) and the processing date is
automatically the first of the month.
• Twice a month: The requested period is first the month and the year, then the fortnight (1 or 2);
the corresponding processing date is the first and the sixteen of the month.
• Three months: The requested period is the number of the quarter (1, 2, 3 or 4) and the year.
The corresponding processing date is the first day of the quarter.
4.3.7.2 Use
The processing date figures in the events recorded by Dollar Universe. This date allows the
conservation and differentiation of execution traces of a task (complementary to the schedule and
execution dates).
The processing date is available within the CL, as a reserved variable (see section "Job
parameters" on page 42), to allow, for example, the correct accounting period to be inserted in the
report, independently of the execution date.
The processing date will be used in the synchronization of procedures (such as, Uproc to run only if
it ran correctly the previous month, or if another Uproc ran correctly for the same month etc.).
Example: processing dates
An accounts entry Uproc is monthly; each time it is launched, the requested period is a date with
the format MMYYYY.
The month-end Uproc is monthly, and traces of the last 12 runs must be kept in the operating
events in order for the year-end Uproc to be able to run.
Note: The functional period is independent on the scheduling period for the Uproc in question, even
if Dollar Universe routinely offers algorithms for automatic calculation of processing dates based on
the schedule dates (see "Processing date of a task" on page 84).
Example: A monthly accounting-statement procedure is systematically submitted twice a month:

On the 30th of each month (month-end), to extract an initial statement of the past month.
On the first Monday of each month to extract a complete statement integrating the "fifth" week of
the past month.
A similar example might entail an operation, submitted each weekend, to give the summary of
accounts movements of the current month.
The "application" nature of the functional period imposes a certain number of usage considerations
in any synchronizing or triggering of Uprocs. Refer to the description of the "Processing date
control" on page 54 for details concerning their operational limits.
It is possible to alter the functional period allocated to a Uproc (as of the version 4.1 on Windows
and UNIX).

4.3.8 Event memorization
4.3.8.1 Purpose
With Dollar Universe, computing production benefits from guaranteed coherence due to the total
control that Dollar Universe exercises over each event in the data operations cycle.
A certain number of these events are important and their presence may condition the execution of
certain other Uprocs. However, the majority are of no more than informative interest.
To avoid overloading the history files, Dollar Universe maintains a specific events file that records
all Uprocs declared as memorized. Dollar Universe examines this file in order to evaluate the
execution conditions of each Uproc.
A non-memorized Uproc can never be quoted in the reference conditions used by another Uproc.
The operating events database is maintained by means of this memorization, or by use of
completion instructions. This file is different from the job monitor and execution history.
4.3.8.2 Characteristics
Memorization is defined by means of several parameters:
• Memorization: yes or no
This flag indicates whether the execution of a Uproc will be memorized or not. Memorizing a
Uproc execution corresponds in Dollar Universe to create an event.
If any conditions must be defined on a Uproc, it must necessarily be memorized. On the other
hand, "non-memorization" limits the size of the Dollar Universe operating events base (for
performance and clarity issues).
• Memorization per processing date
Used only when the Uproc must be memorized; this information indicates one or more events
need to be kept for the same processing date (date obtained by applying the functional period
to the execution date).
Selecting "one" implies destroying the last-known event for the processing date in question, as
soon as a new execution is started for the same processing date.
This automatic purge feature is completed by the "number of dates" parameter.
Note: This function can replace the "Completion instructions" on page 61. It does not allow,
however, such fine event management, and therefore cannot replace it systematically.
• Memorization for n processing dates

This information defines the duration (i.e. a multiple of the Uprocs functional period) for which a
Uproc execution events will be retained within the operating events base.
Example: Memorized and non-memorized Uproc
A Uproc designed to update a permanent customer file may be non-memorized because it is
unlikely, in functional terms, to condition the execution of another Uproc.
A Uproc that participates in the month-end accounts closure will certainly be memorized, because
its correct execution over 12 consecutive months will condition launching of the year-end closure
Uproc.

4.3.9 Successors
The launcher is an events-driven process; starting and ending of the conditioning Uproc causes the
launcher to re-examine any Uprocs which are conditioned (and inhibited) by this Uproc.
By default, the new examination is performed randomly. The aim of successors is to define a
preferential order for examining the Uprocs waiting for the completion of the conditioning Uproc.
4.3.9.1 Purpose
At the end of each Uproc run, Dollar Universe (the launcher) examines the list of jobs with Uprocs
waiting. In each case, a new launch will be performed.
The Uproc launch is performed in random order.
The notion of successor is the definition of a dependency for examination of Uprocs waiting for
events, thus giving a particular Uproc higher priority for launch after the execution of the Uproc in
question.
4.3.9.2 Special features

The proposed function observes the following rules:
• Successors are processed irrespective of the end-of-job status of the conditioning Uproc
(completed or Aborted).
• Successors are examined in the order in which they were entered.
• The only successors processed are those in event wait on the Uproc in question.
• Successors are identified by Uproc names only, the other necessary information (Management
Unit, Session, user, processing date) being directly provided by the execution conditions of the
related Uproc.
• Uprocs awaiting an event on the related Uproc but not designated as successors, are
submitted to condition checking according to the normal examination conditions of dollar
universe.
4.3.10 E-mail notification

E-mail notification can be sent (configurable in the Uproc) by the IO server when the launch of the
Uproc finishes with the status "Refused" or "Time overrun" or when execution of the Uproc finishes
with the status "Completed" or "Aborted".
The e-mail (in SMTP format) includes:
• The sender: configurable and defined once only for all e-mails sent from this Dollar Universe
node,
• The recipient(s): these can be aliases or lists known to the mail server,
• The subject: this is formatted by Dollar Universe. It takes the form:
"Dollar Universe: <status> <Session> <Uproc> <MU> <Launch number>
<Execution number of the Uproc> <Area>"

• The text of the e-mail consists of:
o Execution information (information and severity).
o The launch or execution history trace.
• The execution log can be attached to the e-mail (configurable).
A global configuration on the node defines:
• Whether e-mails can be sent.
• The sender’s e-mail address.
• The server and port number used.
The language used is that of Dollar Universe. The History Trace indicates that an e-mail has been
sent. A log file records the e-mails sent from the node.
4.4 Execution prerequisites

Uproc conditioning means describing its functional dependency on other Uprocs or resources.
Note: It is not necessary to translate the operators technical constraints (degraded processing
paths, forced serialization of operations, insertion of technical processes such as backups etc.) In
the elementary conditioning process, since the structure provided by Dollar Universe at the Session
level is specifically designed to handle this requirement.
Dollar Universe provides three types of conditions, with the possibility of combining these into a
launch formula interpreted at each launch attempt.
References to processing dates, Management Units and Sessions can be integrated into the
conditions. The events expected by each condition can then be identified with great precision.
Note: All operations events (absence, launch, execution or incident on a Uproc) are stored by
Dollar Universe as events (if the Uproc is memorized). It is these events that are used for
determining if the condition is satisfied or not.
The Uprocs execution conditions are systematically examined whether this Uproc runs within a
Session or not (except in the case of "Forced run at end of window" on page 77). The Session is
only a sequencing model, external to the Uproc.
Available types of conditions are:
• Non-simultaneity (incompatibility),
• Dependency,
• Resource.
4.4.1 General features of conditions

In Dollar Universe, the expression of conditions is based on:
• The identification of the event (execution of the conditioning Uproc),

• The logical formulation of the condition.
The aim of this paragraph is to describe the common features of the conditions. These general
criteria are also valid when expressing completion instructions.
The three main criteria enabling the identification of an event are described below.
4.4.1.1 Session control

The Session check function applies to the "non-simultaneity" and "dependency" conditions, as well
as to completion instructions. It enables the determination of which Sessions Dollar Universe must
search in order to locate possible executions of the target Uproc, either to evaluate the said
conditions, or cancel the corresponding event (for the completion instructions).
The options are as follows:
• Same Session and same execution
This option limits the search for conditioning events (or events to delete) to the same execution
of the Session containing the conditioned Uproc (same Session execution number). In this way,
if the Session runs a second time (possibly at the same time) or if the target Uproc runs on
behalf of another Session, the corresponding execution events will not be considered in the
search.
Note: This option is useful for fine event management, when using completion instructions and a
given Session is to be submitted several times this option will avoid confusion between individual
runs (which frequently arises in demonstrations).
• Same Session and all runs

This option extends the preceding option of searching for conditioning events (or events to
delete), to all occurrences of the Session in which the conditioned Uproc is found. Unlike the
preceding definition, previous occurrences of the Session can be taken into account by this
option.
• Name of Session
This option allows precise determination of the Session where conditioning events will be
searched (or deleted). All executions of this Session will be considered.
Note: This option is noticeably less used, since it provides the least degree of open-ended ness.
• Any Session
Default value. This option is the most general, allowing searching in all Sessions or in no
Session at all (as for separately scheduled Uproc).
Note: This mode of operation should be preferred in all cases, since conditioning of Uprocs
(translating the applications logic) is normally independent on the operations constraints handled by
the Session.

4.4.1.2 Management Unit control
The MU check can be used in conditions of "incompatibility", "dependency" and "resource" (for
certain types where the file name or address contain the variable: !UG!), as well as to completion
instructions. It directs the search towards events associated with a specific management-unit.
The options are as follows:
• Management-unit type
This option directs the search for conditioning events (or events to delete) to all Management
Units of a given type.
Note: This option does not analyze the dependencies between MU, and it is preferable to restrict its
use to certain specific cases (technical processing, for example). It will often be ignored in favor of
the HDP technique described below.
• Management Unit
This option searches for conditioning events (or events to delete); limited to a specific
Management Unit.
Note: This option serves to process very specific cases. It will be ignored in favor of the HDP, more
open-ended.
• Dependent units: HDP

This option extends the search for conditioning events (or events to delete) to all Management
Units linked to execution of the Management Unit containing the conditioned Uproc (per the
HDP convention).
Refer to the section entitled "Hierarchical data processing" on page 18 for more information on
the use of HDP convention.
The following examples illustrate possible use of these conventions:
• "{ }" limits the search for conditioning events (or events to delete), to the Management Unit on
which the conditioned Uproc is executed. Therefore if the conditioning Uproc runs on another
Management Unit, the corresponding execution events will not be considered in the search.
Note: This option is the default taken by Dollar Universe during creation of a condition or an
instruction.
• "{A }" limits the search for conditioning events (or events to delete), to all the Management
Units of type "A" dependent on the current Management Unit.
This configuration is often preferred over the two preceding ones (MU type or MU based on it’s
scalability, as illustrated by the following two examples:
Example: 1. Use of the { } convention
An accounts processing stream runs each month within a given Company, according to execution
conditions expressed in the "{ }" convention.
Following a readjustment of activity or acquisition, the Company divides into two distinct entities,
each entity's accounts being processed separately.
The only task required is to create a second Management Unit and duplicate the workload
schedule, in order for the jobs to run coherently on the second entity, independently of the first.
Example: 2. Use of the {A } convention

The updates on a commercial database are consolidated each month for each region of a
Company, according to execution conditions expressed in convention "{A }".
Up until now, operations have been based on two regions, incorporation of new offices simply
requiring the declaration of the corresponding Management Unit, and its dependency to one of the
two regions.
Following a large increase in the number of offices, a new region is created. The only task required
is to declare the corresponding Management Unit, and duplicate the operations schedule for the
new region, by deleting, if necessary, the dependency of certain offices to one of the original
regions, and creating their dependency on the new region.
• All are necessary

This option complements those given above, by allowing the operator to indicate whether for
the condition to be valid events must be found for all target Management Units, or if any one of
them suffices.
Given the frequency of the "yes" option, this parameter is taken as the default when creating a
condition.
Note: Since this information has no meaning when considering completion instructions and
incompatibility conditions, it is not proposed in the corresponding windows. In both cases, the
events are considered for all Management Units designated.
4.4.1.3 Processing date control

The functional period (and consequently, the processing date associated with each execution) is
used with the "dependency" and "resources" type conditions (for certain resource categories), and
for completion instructions.
Referring to the processing date of the conditioned Uproc, the functional period determines the
processing date for which Dollar Universe must seek possible executions of the Uproc or the
targeted resource, via the conditions or the completion instruction.
The processing date control is therefore performed on a comparison between the processing date
of the Uproc or the conditioning resource, and the processing date of the conditioned Uproc; this
enables the dissociation of the relationship between the processing date and the processing date
sought for the Uproc or the conditioning resource at the time of launch.
Since Dollar Universe version 4.1, a Uproc’s functional period can be modified. Dollar Universe
undertakes the resolution of concerned conditioning.
If the conditioning Uproc has a smaller functional period than the conditioned Uproc the condition
check must remain coherent. To this end the operand "Any" is used.
Example: use of the processing date control
Uproc "A", which generates an annual statement of accounts, can run only if Uproc "B", which
generates the monthly balance, ran correctly.
Uproc "A" is declared with a annual period,
Uproc "B" is declared with a monthly period.
Uproc "A" comprises a condition stipulating that Uproc "b" must have run correctly
In practice, at each expected execution of Uproc "A", Dollar Universe will translate its processing
date (for example, 1995) into a processing date for Uproc "B" (01/xx/95), according to
the formula used ("any month, same year").

Note: Similarly, incompatibility conditions are expressed simply by declaring whether this
incompatibility takes account of the respective processing dates or not (same or any)
The calendar units available for evaluating processing dates or processing-date differences vary
with the reference functional period of the Uproc in question; the reference is systematically
proposed, as well as the year (greatest unit). If "month" is greater than the reference functional
period, it also is proposed (except for the week, for obvious reasons of non-compatibility between
these two units).
The following table summarizes the calendar units proposed, according to the Uprocs functional
period:
Calendar units
F.P. D W 10D 2W M 2M 3M 4M 6M Y
None
Day * * *
Week * *
10 days * * *
2 weeks * * *
Month * *
2 months * *
3 months * *
4 months * *
6 months * *
Year *
Figure 9: Calendar units proposed for different functional periods
Note: If the conditioning Uproc has "none" for the functional period (corresponding, therefore, to an
infinite period), the processing date control feature will not be effective.
So, the definition of a dependency of a Uproc with functional period on a Uproc without a functional
period will default to a check on any processing date rather than same processing date (version 4.1
onwards).
4.4.2 Additional characteristics
4.4.2.1 User account

The user id can also be used by conditions of the type "dependency" and "non-simultaneity", and
for completion instructions.
This tells Dollar Universe to limit its search for target events in Uproc conditions or the completion
instruction, to those corresponding to executions run under a particular user id.
The option is either any user account (by default), or the same user account as the submission
account to which the conditioned Uproc belongs.

4.4.2.2 Fatal condition
When one of the conditions in the launch formula is defined as "fatal", non-verification of this
condition after it is encountered during launching will prevent any new launches to be attempted for
the operation in question.
Otherwise, when a Uproc is ready to be submitted (scheduled time and date reached) and one or
more non-fatal conditions are not satisfied, the Uproc is set to await the unperformed events. When
all expected events have occurred, provided the launch window is still valid, the Uproc is
automatically "relaunched".
In some cases, it is known in advance that a condition not satisfied at one point will remain so long
enough for there to be no point in putting its associated Uproc in a wait state. This is the purpose of
the fatal character associated with a condition.
The corresponding launch will be seen as Refused in the executions list.
Example: Use of "fatal" characteristic with a dependency condition
A "finished-product stock management" process is automated using Dollar Universe. It requires a
Uproc called "order entry" for the sales-office MU 'S, and a Uproc called "enter goods requests" for
the factory MU 'S.
It will therefore contain dependency conditions to translate this logic.
For simplicity, it is assumed that order entry or goods requests are the only operations requiring
updated stocks.
It could be very useful for these dependency conditions to be fatal, in that if the data entry Uprocs
are interactive, and if the batch engine runs at night, their absence at a given moment from the
historical events file for this date will not change during the night (unless data-entry can also take
place at night...).
In this way, the automation process will not redundantly manage the Uproc in a wait state, and the
other Uprocs depending on this Uprocs running (or not running) can be submitted earlier.
Example: Use of the fatal character on an incompatibility condition
Assuming that in the course of the day several users have used an order entry Uproc which
triggers a batch Uproc to process the orders of the day. When the batch engine starts up (it is
assumed that the batch engine is started only after a certain time of day), it will try to run the order-
processing Uproc as many times as the order-entry Uproc activated. It is clear, in this case, that a
single execution of this Uproc is sufficient. The declaration of a fatal incompatibility condition of the
batch Uproc with itself will limit the number of runs to 1.
4.4.3 Types of conditions
4.4.3.1 Dependency condition

Dependency conditions make it possible to link functionally dependent Uprocs, whether they run on
the same or different nodes.
The purpose of this function is to search the memorized operating events for those conditioning
execution of the Uproc being launched.
This group of conditions allows linking two Uprocs, and conditioning the execution of one Uproc
(conditioned Uproc) on execution (or non-execution) of another Uproc (conditioning Uproc). The
conditioning and conditioned Uprocs may be one and the same.

These conditions can be configured using criteria discussed previously:
• The Management Unit(s) for which the conditioning Uproc was run (see "Management Unit
control" on page 53).
• The Session where the conditioning Uproc was executed (see "Session control" on page 52).
• A specific processing date (see "Processing date control" on page 54).
• The user account running the task concerning the conditioning Uproc (which may also be that
running the task in question).
• Other characteristics: Fatal or not, expected or excluded.
In addition, a dependency condition will refer to the status of the conditioning Uproc in the events
file. Possible statuses are:
• Completed.
• Aborted.
• Absent.
Note: The "absent" option means that the Uproc is neither running nor completed (either correctly
or abnormally) nor waiting to run, but it does not signify that the Uproc is not scheduled. It may
even have already been activated, and waiting for an event.
Therefore the dependency conditions are based on the notions of processing date, user account
and Management Unit, obtaining the information they require in the operating events file.
A non-memorized Uproc cannot act as conditioning Uproc in a dependency condition.
Similarly, in order for date-comparisons to make sense, Uprocs quoted as references must have a
functional period compatible with that of the Uproc containing the dependency condition.
Example: Dependency conditions
The accounts month-end Uproc will not run, for a given month, unless the previous month's
occurrence completed correctly and if the preceding annual closing exercise is correctly
completed..
One of the solutions for expressing this logic consists in using dependency conditions. In this case,
two conditions must be used because the logical translation of the process described above implies
presence of an AND operand.
Condition 01
Sequencing of the month-end accounts Uproc with itself for the preceding month
Processing dates: "month-1",
AND Condition 02
Dependency with the Uproc of the preceding annual closing exercise
Processing date: same year
The launch formula is, therefore:
=C01 and =C02
Example: Prohibiting calls to applications
Once in operation, an application may sometimes have to be interrupted temporarily (due to
applications problems, overloading of computing resources necessitating the limiting of available
applications etc.).
This example gives a simple way of rapidly inhibiting an application. The only requirement is to
develop, in each application, a special Uproc on which all the other Uprocs in the application
depend. This Uproc is then allocated to each MU using the application in question. The inhibitor
can be used only by the operators, when necessary.

Once the Uproc is memorized, the event associated with it remains in the events file after
execution. Two options are offered concerning its completion: Normal (Completed status) or not
(Aborted status).
In each Uproc in the application, the following dependency condition is created on the inhibitor:
Condition nn
Target Uproc: inhibitor
Status required: "Aborted"
Condition: "excluded"
In this way, if there is no trace of the inhibitor on the events file because it has never been run, or if
there is one with "Completed" status, condition nn is satisfied and will not prevent the job-run.
If on the other hand, an article is encountered at "Aborted" status (obtained voluntarily for
inhibiting), condition nn is not satisfied and execution will be impossible.
To return the application to service, the only requirement is to activate the inhibitor again by
selecting the option corresponding to the Completed status: this updates the events file by
replacing events coded with the inhibiting "Aborted" status.
4.4.3.2 Non simultaneity condition

This group of conditions enables the definition of a set of Uprocs which must not be executed
simultaneously with the Uproc being launched. The verification centers on the local operating
events database at the launch time of the conditioned Uproc (an incompatibility condition may not
be declared with a Uproc which runs on a remote machine). The job statuses concerned by an
incompatibility condition translate execution of the latter (or its potential for execution):
• Started (condition checking).
• Pending (in batch queue).
• Running.
• Completion in progress.
Each condition is expressed according to the previously discussed features:
• The Management Unit(s) where the conditioning Uproc was run (see "Management Unit
control" on page 53).
• The Session where the conditioning Uproc is run (see "Session control" on page 52).
• A specific processing date (or not) (see "Processing date control" on page 54).
• The user account running the task concerning the conditioning Uproc (which may also be that
running the task in question).
• Other characteristics: Fatal or not, expected or excluded.
The incompatibility conditions are necessary in each case requiring:
• Non-simultaneous execution of Uprocs using the same files for updates.
• Limiting of two competing resource-intensive Uprocs.
Note: It may be useful for a Uproc to contain an incompatibility condition with itself. This will avoid,
for example, a strategic Uproc being launched twice by accident.
Important: Incompatibility conditions are not reflexive and must be entered in the two Uprocs which
must not run simultaneously.

Example: Non-simultaneity conditions
A Uproc covering end-of-month invoice processing, using permanent files such as customer files or
VAT Rate files cannot simultaneously accept the Uprocs which update the said permanent files.
Therefore all the Uprocs will have incompatibility conditions such as:
All invoice-processing operations will exclude the possibility of updates,
Conversely, all updates will prevent start-up of invoice processing.
4.4.3.3 Resource condition

This step enables the declaration of an execution pre-requisite for the Uproc, based on the
availability or the status of system or logical resources.
Each condition is expressed according to the characteristics stated above:
• The Management Unit for which the resource was defined (see "Management Unit control" on
page 53).
This notion is only valid if the !UG! Variable is embedded in the name or localization of the
resource.
• A processing date (see "Processing date control" on page 54). As stated above, this notion is
only valid if the !DTRAIT! Variable is embedded in the name or localization of the resource.
If the Uproc has no functional period, the processing date !DTRAIT! will translate to 000000.
• Whether the condition is fatal or not, expected or excluded.
Certain characteristics are specific to resource conditions:
• A permanent resource avoids the resource attribute check. A resource by default is considered
"to check" and its attributes are systematically verified.
Note: The function examining resource conditions is pointed at local resources (unless it uses the
UNC file name).
• Attribute: The available attributes depend on the type of resource. For a File type resource, the
attributes are as follows:
Attribute Description Operator Parameter

EXIST Check file exists. None None
SIZE Check file size. All size
DATEUNCHANGE Check stability and date of file >= duration : DDD,HH,MM
SIZEUNCHANGE Check stability and size of file >= duration: DDD,HH,MM
• An exclusive resource means that only one Uproc conditioned by a particular resource can run
at a given moment. Other Uprocs conditioned by the same resource will have to wait until the
resource is made available. The notion of exclusivity may be attached to the resource itself or
to the resource condition, in which case it will be valid only for the definition of this particular
condition.
• For the condition check to succeed, both quotas required by the condition should be available.
If either of the quotas is superior to the quota available at the time of launching, the Uproc will
be forced to wait because of "insufficient quota".

If the resource contains one or more of the following variable elements !SOC!, !MU! (or !UG!) or
!DTRAIT!, verification of the quotas will take into account the value of any variable elements
during the condition check.
If the resource contains none of the variable elements !SOC!, !MU! (or !UG!) or !DTRAIT!,
values provided for these elements in the resource condition will not be taken into account.
The definition of resource conditions may include, for certain resource types information of an
applicative nature (for example, filename integrating dates comparable to the processing date, HDP
Expressions, or reference to an MU).
Resource conditions participate in the elaboration of the launch formula, and can be defined in
much the same way as dependency conditions (with the same characteristics, apart from the
status).
Note: It should be noted that, with the exception of quota definitions, a resource condition
expresses the availability or the presence of a resource in a given state at launch time. Since Dollar
Universe does not reserve resources (except for defined quotas or exclusive resources); it may be
that the status or availability of certain resources in certain operating circumstances change after
verification by Dollar Universe. If the stability of the resource status or its availability is a pre-
requisite for execution of the Uproc, the user must take the required technical precautions.
4.4.4 The launch formula
4.4.4.1 Purpose
The launch formula is an expression containing dependency, resource and incompatibility
conditions, linked by a set of operands (AND, OR, =, #).
The logic translated by this expression is analyzed during condition checking of the Uproc. The
analysis depends principally on the examination of the events base.
Submission of the Uproc depends on verification or non-verification of this expression. The logical
value of the launch formula ("true" or "false") determines whether it is possible to run the CL
associated with the Uproc.
If impossible, the non-verify condition is displayed in the history trace.
Note: The Uproc incompatibility classes do not play a part in the expression launch formula. Any
resulting job incompatibilities are checked before the logical expression translated by the launch
formula.
4.4.4.2 Optimization of the launch formula

The exploitation of the launch formula by the launcher is initially optimized by a purely logical
analysis of the expression of the formula, which determines whether each condition is principal or
not. A condition is qualified as principal if its non-verification entails non-verification of the entire
formula.
This is typically the case for conditions not included between parentheses and preceded by an
AND.

As a second step, the launcher determines the satisfied or unsatisfied character of each condition
in relation to memorized events. Conditions are examined according to their order in the formula.
When a condition is principal, and the logical value deduced is different from that sought, (satisfied
for # CNN and not satisfied for =CNN), the analysis is not continued, and the launch is refused.
Using this process therefore requires a few operating hints:
• The most improbable conditions to satisfy should be placed at the head of the launch formula,
in order to get the best from the analysis.
• Place conditions of a fatal character at the start of the formula, insofar as possible. The launch
formula analysis will thus be restricted to the maximum if the fatal condition is not satisfied.
• If one of the fatal conditions is not verified, even if it is not principal, the engine is informed and
the fatal character can block the following launches.
If the organization of the formula does not include this precaution, any premature glitch (before
analysis of the fatal conditions) will prevent detection of a possibly not-satisfied fatal condition,
resulting in unnecessary launch attempts.
Note: When a Uproc is launched, Dollar Universe memorizes any event inhibiting Uproc launch.
Any intervention from the job monitor on other events will be ineffectual. Furthermore, each new
launch will systematically examine all conditions afresh (those satisfied beforehand may no longer
be), so that any modifications are processed in real time (except for HDP Analysis).
4.4.4.3 Launch formula limits

The launch formula is limited to 99 conditions, regardless the type of condition.
4.4.5 Completion instructions
4.4.5.1 Purpose
The completion instructions of a Uproc are performed when the job run ends correctly (Completed
status).
They allow "purges" required on the operating events database to be identified, that is, previously
memorized Uproc executions for deletion; these may have completed correctly (Completed status)
or abnormally (Aborted status).
The use of completion instructions can be explained by:
• Application requirements.
• Requirement to limit the volume of memorized events.
In a perfect context, all Uprocs memorized by Dollar Universe would have at least one other Uproc
responsible for deleting their successive runs from the operating events database.
Note: As for dependency conditions (whose instructions constitute the counterpart), the functional
period (processing date format) of the Uproc to purge must be the equal or greater than that of the
Uproc to which the instruction belongs ("month" greater than "ten-day period" greater than "day"
etc.).

The use of completion instructions is not compulsory, since the memorization of the Uproc enables
automatic management of memorized events. Nevertheless, completion instructions facilitate
intervention on events in very specific cases (destruction of a particular event, for example).
Example: Completion instructions
A batch application can run only if the interactive application has been "shut down".
A shutdown Uproc is, therefore defined, with the characteristic "memorized". This will condition all
batch runs of this application.
A start-up Uproc is also defined, containing a completion instruction to delete the event (job run)
associated with the shutdown Uproc.
When the application is started, the memory record for the shutdown Uproc will be deleted, and no
more batch processing can be submitted.
Note: Completion instruction's impact is limited to the node on which they are performed. If the
condition is local, the completion instruction purges the event from the local base.
4.4.5.2 Network operations

If the condition is networked, the event will be recorded both in the local database (that of the
conditioned Uproc) and in the remote database (that of the conditioning Uproc). If a completion
instruction is performed on the local node, the remote event will remain.
However, if a completion instruction (or event deletion) is performed on the remote node (where the
conditioning Uproc resides), then all events on the local bases (for conditioned Uprocs) will be
purged as per the instruction.
General rule:
Any modification of the event on a remote node (creation, update, deletion or purge by a
completion instruction) is transmitted to all nodes having issued a request on the event in question.
The correspondence is then checked locally between the status requested and the status received,
to determine:
• Whether to launch the conditioned Uproc.
• Whether to purge the event.
4.5 Sessions
4.5.1 Definition
A Session is a tree structure comprising Uprocs that are homogeneous not necessarily from the
functional viewpoint (they may contain Uprocs from several applications or different domains), but
in terms of their operations constraints.
A Session is sequencing model external to the execution conditions of the Uprocs it contains. The
Session predefines an order in which the Uprocs are launched, knowing that at each phase, Dollar
Universe will systematically check the execution conditions of the Uprocs that the Session is
launching.
The Session offers a certain number of advantages, in particular:

• Scheduling, over which the Session exerts a simplifying role, since the schedule of the Session
itself suffices to sequence all the constituent Uprocs automatically. Nevertheless, if required,
one or more Uprocs in the Session can be allocated a specific schedule.
• Maintenance of the order of submission of the procedures: Sessions are defined totally
externally to Uprocs, therefore in the event of changes in the sequence structure; there is no
need to intervene in the command language or the parameter settings of the related Uprocs.
This translates into fewer interventions Uprocs, thereby increasing reliability.
• Job monitoring: The concept of Session is present in all job-monitoring functions; it focuses
actions on groups of Uprocs that application logic (through the Dollar Universe notion of
application) cannot completely translate.
Example: Content of a Session
A Company runs an accounts-payable job stream every week.
Supplier cheques are issued by a specific application which formats and prints the cheques.
From the operations viewpoint, the function is completed only if the cheques are effectively issued.
A Session could therefore be created to unify these two related applications.
4.5.1.1 Session coding

A Session is identified by a freely defined code on ten alphanumeric characters.
4.5.1.2 Structure of Sessions

The relationships between the operations implemented in Sessions are illustrated below:
T1 Level n
OK KO
T2 T3 T4 T5 level n+1
T6 T7 T5 Level n+2
T8
Figure 10: Structure of Session
A Session begins always with only one Uproc called the Session header.
These relationships make it possible to define hierarchical relationships of the parent-child type.
The Uproc at level n will be parent to the Uprocs at level n+1, known as child Uprocs. Individual
Uprocs dependent on a given parent at a given level are referred to as peer Uprocs. The Session
thus allows complex processing tree structures to be defined.
A given Uproc can appear several times in the tree structure, at different levels, or at the same
level.
The relationships thus defined express organizational and operational sequencing requirements,
and in no case replace the functional relationships translating the logical conditions defined at
Uproc level. It is possible that part of the structure of a Session is already partially translated into
such conditions, more particularly into dependency conditions. The fact of superimposing these two
types of relationships is of no consequence.

Note: In no case should the dependency conditions be cancelled within the Uprocs simply because
they will be translated in the tree structure defined by the Session. The existence of Sessions is
justified, among other factors, by the need to dissociate operations constraints (represented by the
Session tree structure) from the applications and logical constraints defined at the Uproc level.
Operations constraints (incompatible execution of two resource-heavy operations, for example)
may evolve independently of applicative constraints. For maximum simplicity and reliability of
maintenance operations, it is therefore important to avoid mixing these two types of constraints.
4.5.1.3 Scheduling features

The Uprocs in a Session inherit the schedule, the technical characteristics (submission account or
job queue, for example) and the functional characteristics (processing date, for example) of the
Session-header Uproc (i.e. The one at the top of the tree structure). Nevertheless, for cases where
it is desirable to modify these characteristics on a related Uproc, a "provoked" (or "optional") task
must be created, mentioning the name and the version of the Session concerned, the name and
the version of the target Uproc and the Management Unit of the initial task.
Specific characteristics can then be allocated, as follows:
• Declaring a provoked task, for example, allows the execution of the task to be deferred to a
specified launch window, or inhibiting this job during certain periods. (the tasks in the Session
depending on the specified launch window will be deferred to the same degree),
• When an optional task is declared, special scheduling conditions different from those of the
Session may be attributed. In this case, the Session will run normally, except for the optional
task, if the latter were not scheduled for execution on the day and time in question. In this case,
non-performance will be interpreted as normal completion, and the Session will continue along
the normal path associated with the non-executed task.
These new characteristics will be carried over into the following Uprocs in the Session. In the case
of an optional task, the characteristics will be carried over whether or not the optional task is
executed.
Note: The Session can also be used for handling operations constraints, thereby dissociating this
type of constraint from the applicative constraints processed as part of the conditioning function.
The Session does not replace the execution conditions of the Uprocs. Therefore, despite the order
of submission imposed by the Session, Dollar Universe performs condition checking (verifying
launch formula) on each Uproc to be submitted as part of a Session.
4.5.2 Normal and error processing paths

A Session is a group of Uprocs arranged into a tree structure.
Depending on the execution status, the Session allows different paths to be distinguished within the
defined tree structure: the normal path, when the Uproc ends in the completed status or the error
path if the Uproc ends in the aborted status.
These features of a Session are useful when system failures occur, as they provide for degraded
processing sequences instead of an outright break in the job stream.

4.5.3 Execution environment
The execution Management Unit of the Session is normally determined at the task’s creation or
during a launch where the combination of "Session – header Uproc – Management Unit’ are
defined. The Management Unit is inherited such as the execution environment for the next Uprocs
in the Session.
It is now possible, for each Uproc in the Session (except the header), to specify the execution
Management Unit, by selecting:
• The Management Unit code, or
• A type of Management Unit, or
• An expression of the hierarchical data processing (HDP) type.
The HDP uses the dependency declared between Management Units. It is used within Sessions
and conditions to define a "target" set of Management Units in the job triggering or synchronizing
commands. Refer to section "Hierarchical data processing" on page 18 for more information on the
use of HDP.
The following example illustrates the possibilities offered by HDP.
Example: Use of HDP in defining Sessions
Assuming an organization centered on a head office, with regional and local offices.
The offices are grouped by region into regional divisions.
When running a Uproc on a Management Unit of type "r" (regional), the expression" {a}" means all
Management Units of type "a" (= offices) depending on the regional division.
This possibility for "generically" designating Uprocs for management-unit targets allows the creation
of general processes that can adapt automatically to modifications in the logical architecture of the
environment.
For example, the adding of another "OFFICE" MU will be transparent in a Session configured to
submit a given process from a regional office to all its dependent offices.
Note: By default, the type of HDP convention retained will be "{ }", allowing execution of all Uprocs
in a Session on behalf of a given Management Unit.
If the execution Management Unit has been explicitly selected at the Uproc level of a Session, all of
the Uproc children inherit this new execution Management Unit (or this set of Management Units).
4.5.4 Carry-over of Uproc variables’ values

Carry-over of the values of Uproc variables within a Session is not automatic. By default, if nothing
is done, the value of the variable is not carried over and the engine applies the rules for assigning
values by default.
The carry-over of the execution value to a child Uproc can be requested by executing the command
uxset var in the CL of the Uproc or in its post-processing, U_POST_UPROC. Three kinds of carry-
over of execution values can be requested:
• A complete carry-over of the value of all the variables in the parent Uproc.
• Carry-over of only those values of the father Uproc variables recognized by the son Uproc, in
other words the intersection between the list of received variables and those of the son Uproc.

• By explicitly mentioning the variables to be carried over, together with their values.
Cf. the Command Interface user's guide for the syntax to be used for this command.
4.5.5 Storage limits

The total number of Uprocs managed in a Session is 140. Up to 20 Uprocs can be declared at each
level of the tree structure (for normal completions), with another 20 Uprocs declared as "ab-ends"
(abnormal completion of the so-called parent Uproc).
Note: If a given Uproc can occur several times in a given Session, each occurrence decrements the
total number of available operations in the Session by 1 (from the total of 140).

5. Scheduling
Job scheduling constitutes the entry point of automated operations, and therefore one of its major
functions.
Based on pre-defined calendars and scheduling rules (pre-defined calculation algorithms); job
scheduling enables the automatic calculation (by the batch engine) of scheduling dates and times
for the various tasks in hand.
Note: Determining a scheduling date and time does not mean systematically that the task will be
run at the start of (or even during) the launch window period (= interval between the starting and
finishing dates), since effective execution is determined by the conditions attached to the related
Uproc.
5.1 Calendars
5.1.1 Calendar application environment

In Dollar Universe, calendars serve as a time reference base and in no case an operations
schedule.
Dollar Universe imposes the definition of at least one calendar per node and per Area called
"General calendar". In this case, all the Management Units present at this node will refer to the
same calendar.
To cater for the special needs of each entity, calendars can be generated specifically for
Management Units or types of Management Units. A specific calendar can be defined for each
Area (application, integration, simulation and production), in which a Management Unit is present.
To avoid having to duplicate calendars for each Management Unit, the calendar function is
managed by a search list in this way; tasks will be scheduled depending on the information
contained in:
• The specific Management Unit calendar for the related task.
• Or, if not, in the specific calendar of the MU type.
• Or, if not, in the general calendar of the Area.
Note: All MU’s in the form X00 (one letter, two zeros, and seven spaces) are considered as MU
type in the calendars.
The available options ensure that calendars can be adapted as finely as required for the
operational needs of each environment. Nevertheless, it is recommended to avoid unnecessary
creation of calendars, since they may become difficult and tedious to manage if the Management
Units at a node become numerous.
Dollar Universe v5.6 Reference user's guide Scheduling • 67

5.1.2 Calendar model
Calendar models can be created. From these models, calendars can be generated for groups of
Management Units with similar needs.
Only a calendar model can be distributed to a group of Management Unites or to Management Unit
types. They then become calendars of the target Management Unit (the MU type is transformed to
as many targets MU’s that are selected).
The model calendar can therefore become a calendar for a specific MU but not a calendar of an
MU type.
Note: As for tasks, distribution can only take place from calendar models.
5.1.3 Generation of holidays

Calendars can be generated with or without standard French public holidays. The standard French
public holidays are:
• 1st January.
• Easter Monday.
• 1st May.
• 8th May.
• Ascension day.
• Whit Monday.
• 14th July.
• 15th August.
• 1st November.
• 11th November.
• 25th December.
Calendar generation includes complex algorithms (such as calculating Easter), and is not based on
an external file comprising possibly modifiable dates. The process cannot, therefore, be adapted to
holidays for another country. This would require generating a template calendar with no holidays,
then modifying it to take account of the internal requirements of that country. Later distributions of
this baseline template calendar will remove the need for the repetition required by these manual
operations.
5.1.4 Calendar range

A calendar's maximum range is limited to 25 years.
For the minimum range, allowance should be made for the requirements imposed by the
scheduling rules used. To ensure the necessary calculations (for example, a scheduling algorithm
using an annual period), the calendar must start at least one year before the date at which the
68 • Scheduling Dollar Universe v5.6 Reference user's guide

calendar will be used by the calculator, and be extended for four years at least (to allow calculation
of the next two processing dates).
A calendar must be generated as illustrated in the following diagram:
year n-1 year n year n+1 year n+2
Reference
date
Figure 11: Minimum range of a calendar
Note: Dollar Universe allows the creation of additional years on an existing calendar. If some years
exist already, the newly generated years cancel and replace the earlier ones.
5.1.5 Types of day

The definition of calendars accepts three types of days:
• Workday.
• Closing day.
• Holiday.
Closing days are positioned automatically, from a standard "week" mask, comprising each day of
the week and its associated type.
The type for certain days of the calendar can then be modified day by day, as required.
The scheduling functions of Dollar Universe differentiate between workdays, closing days and
public holidays, enabling them to fulfill separate purposes.
5.1.6 Impact of modifications on a calendar

Modifying a calendar is a delicate operation, given that it can have great impact on the operations
processes.
For all update operations on a calendar (creation, modification, delete, transfer, distribution etc.)
Dollar Universe immediately and systematically updates the related scheduled tasks affected by
this calendar (i.e. those tasks operating on behalf of the Management Unit linked with this calendar
or Management Units with the same type as the calendar).
The general calendar for the node is a special case, with all tasks being updated.
Example: Shifting of a group of operations by updating a calendar
In this example, we assume that several tasks are scheduled each working day.
Certain technical operations, on the operating system for example, can result in relatively long
down-time, forcing the operations department to defer production for a day (Friday to Saturday, for
example).
Closing down on a Friday (declaration as a closing day) and opening on a Saturday (declared as
working day) will result in the shifting of all related tasks by this calendar, from Friday to Saturday.

5.2 Scheduling rules
5.2.1 Definition
A rule is an algorithm which translates the required execution periodicity of a task.
A scheduling rule, identified by an eight-character code (alphanumeric and the characters "+" and
"-"), is characterized by:
• A periodicity comprised of a number of days, weeks or months.
• A position - the number of days (working or calendar) from start or the end of the period.
• Authorizations (see paragraph "Rule authorizations").
o for the days of the week,
o for the days of the month,
o for the months of the year.
• An offset direction (next or previous), to move the scheduled date backwards or forwards, if
application of the rule on the calendar designates an unauthorized day (by one of the three
authorization masks).
Scheduling rules mean of simplifying the definition of scheduling characteristics for tasks. Using
these rules, a very limited number of calendars is necessary. A set of scheduling rules is delivered
with Dollar Universe; this means that new rules can be added as desired.
A rule is assigned to one (or multiple) tasks. Multiple rules can be assigned to the same task. The
allocation process copies the rule to the task, which becomes independent on the original rule. So
modifying the rule does not modify the job schedule defined using this same rule. The user can
nonetheless manually assign the rule to tasks.
This mode of management is used in order to reduce manipulation, and because the rules do not
evolve. Distribution of rules is not therefore necessary.
Once allocated to the tasks, the rules are applied to the calendar belonging to the Management
Unit of the task (if there is no calendar, the one belonging to the MU Type, or the general calendar
of the node is sought).
The rules are defined, inside a Company, independently of the Areas.
5.2.1.1 Rule authorizations

Three authorization masks make it possible to determine whether the day proposed by the
algorithm is authorized or not.
For a day to be authorized, it must be passed by all three masks. A day will not be authorized if it is
failed by any one of the three masks.
If the day calculated by the algorithm is authorized, the day calculated effectively becomes the
task’s scheduled date.
If the day is not authorized:
• If an offset is defined, this will be applied to find the next (or previous) authorized day.

• If no offset is defined, the day calculated is abandoned for this period of the task. The next
calculation of the rule will be made for the following period.
Days of the week
The "Days of the week" mask determines: for each day (Monday to Sunday), depending whether
the day is a working day, closing day or public holiday in the task’s reference calendar , whether
the day is authorized or not.
Days of the month
The "Days of the month" mask determines: for each day (from 1 to 31), counting from the beginning
or end of the month, whether the day is authorized or not.
Months of the year
The "Months of the year" mask defines: for each month (from January to December), whether the
month is authorized or not.
5.2.2 Examples of Rules

The examples described below can be expressed in several ways. We have described the
simplest.
Each working day
Period 1 Day
Shift 1 Working Day
From Beginning
Offset None
Days of the week Mon Tues Wed Thur Fri Sat Sun
Work Closed Holiday YNN YNN YNN YNN YNN YNN YNN
Days of the month All
Months of the year All
In this case, "From" and "offset" may be modified, but will have no effect. In the "Days of the week"
mask, Saturdays and Sundays are authorized if the task’s reference calendar defines them as
working days.
All closing days or holidays
Period 1 Day
Shift 1 Calendar Day
From Beginning
Offset None
Work Closed Holiday NYY NYY NYY NYY NYY NYY NYY
In this case, "From" and "offset" may be modified, but will have no effect.
Each third working day of the month
Period 1 Month

Shift 3 Working Days
From Beginning
Offset None
The rule "third day of the month and a working day" is expressed differently:
Period 1 Month
Shift 3 Calendar Days
From Beginning
Offset Next
Each Tuesday; if Tuesday is a closing day or a holiday, offset to next working day
Period 1 Week
Shift 2 Calendar Days
From Beginning
Offset next
Each first working Tuesday in each month

Period 1 Month
Shift 1 Working Day
From Beginning
Offset next
Work Closed Holiday NNN YNN NNN NNN NNN NNN NNN
The rule "every last working Tuesday in each month" is expressed in the same way by replacing
"From: Beginning" by "From: End".
From the 1st to the 5th of each month
Period 1 Day
Shift 1 Calendar Day
From Beginning

Offset None
Work closed holiday YYY YYY YYY YYY YYY YYY YYY
Days of the month 1, 2, 3, 4, 5
All days are considered, whether working days, closing days or public holidays. A restriction can be
applied, if necessary, in the "Days of the week" mask.
Last but one working day of the week except in August
Period 1 Week
Shift 2 Working Days
From End
Offset None
Work closed holiday YNN YNN YNN YNN YNN YNN YNN
Months of the year January, February, March, April, May, June, July,
September, October, November, December
5.3 Tasks
5.3.1 Definition
A scheduled task corresponds to running of a Uproc (the procedure) on behalf of a Management
Unit (an environment, most often data).
By extension, a task also designates running a Session on behalf of a Management Unit.
A task is identified by concatenating the code of the Uproc and/or the Session from which it comes,
and the code of the Management Unit for which it will run.
Dollar Universe distinguishes four types of task:
• Scheduled: this task has a complete schedule (rules and/or explicit dates), and consequently is
scheduled automatically by the calculator. It may be triggered by a dedicated command.
• Provoked: this task has no schedule other than the expression of specific launch windows. It
will be triggered via the dedicated command or as part of a Session.
• Optional: this task is used only to schedule a Uproc within a Session, according to its own
scheduling rules (for example: A task can be defined for a Uproc that must run only on Fridays,
whereas the Session to which it belongs is daily; apart from Friday, the Session runs as if the
Uproc did not exist).
• Cyclical: it is scheduled with a repetition interval expressed in days, hours and minutes. It has
no rule or explicit date.

A task can be submitted in three main ways:
• Through the various triggering commands provided (see the Command Interface user's guide),
• Through an interactive function (the launches), allowing job submission in scheduled batches
(without altering their actual scheduling); scheduled batch jobs can be modified;
• Automatically, through the batch engine; which in this case replace the human operator by
acting in conformity with the forecast task workload.
5.3.2 Task model

To take into account distributed architectures composed of numerous Management Units, and
requiring duplication of a given task for each operations environment, Dollar Universe proposes the
task model.
The purpose of the model is to allow non-executable reference parameter settings to be defined
(on a central computer, for example), for distribution to the target Management Units.
A task model can be defined for any type of task: provoked, scheduled, optional or cyclical.
The task model is transformed into a task (linked to its executing Management Unit) upon
distribution to a Management Unit, and will therefore be executable on this Management Unit. Only
task models can be distributed.
Note: Uprocs and Sessions are not executable objects, being independent on the executing
environment.: For this reason they do not need the notion of model.
5.3.3 Types of task
5.3.3.1 Scheduled task

A Scheduled task benefits from all the facilities available in Dollar Universe in terms of workload
forecasting.
Scheduling rules are applied to the calendar of the Management Unit, allowing this task to be run
recurrently (for example, every third working day of month, every Tuesday etc.). In order to handle
random submission requirements, it is also possible to explicitly define a set operating dates,
exclusion dates and exclusion windows.
A scheduled task can be provoked by a specific command (uxordre).
5.3.3.2 Provoked task

A provoked task can be defined:
• for a Uproc or Session on a Management Unit
• as well as for a Uproc inside a Session on a Management Unit.
A provoked task is submitted:
• On demand.

• From another task.
• Through specific Dollar Universe commands.
• Through a Session.
These tasks may be submitted on Management Units other than that of the provoking task. Their
job parameters are normally recalculated from those in the provoking task. Nevertheless, it is
possible:
• To define specific parameters for submission of a task in a given environment,
• To desynchronize the task submission request from its effective execution. This option allows
non-urgent batch tasks to be deferred to a less busy time period.
Technical execution characteristics
Provoked tasks allow the special technical characteristics of a Uproc to be specified within a
Session.
By default, only the Session-header Uproc is scheduled, and the technical characteristics of the
task are automatically circulated to the other Uprocs in the Session (inheritance principle).
The definition of a provoked task for a Uproc inside a Session permits the modification of the
technical characteristics of the task by imposing the provoked tasks own data. It is therefore
possible, for example, to modify specific priority, job queue or submission account.
Note: These specifications apply to the target Uproc and to the other Uprocs succeeding it (by the
inheritance principle). The same applies for calculation of the processing date.
Deferred execution
The declaration of a provoked task in the scheduling functions means that an immediate start (via a
triggering command, for example), can be transformed into a deferred execution in the launch
window defined for this particular task. See section "Schedules of provoked tasks" on page 81.
5.3.3.3 Optional task

An optional task is a task with a schedule that does not exactly follow the same rules as the rest of
the Session; therefore, it only applies to Uproc contained in a Session.
During execution of the Session, this "optional" character generates an examination of their specific
scheduling rules. In this way, if the scheduling characteristics of the optional task do not correspond
to those of the Session, the task will be ignored outright in the overall tree structure. This allows, for
example, a weekly task to be inserted in a daily Session.
Scheduling of optional tasks follows the same rules as those for scheduled tasks.
Note: An optional task must refer to the Session to which it belongs.
When defining an optional task, for a Uproc within a Session, the technical characteristics of the
task can be modified. For example, the priority, the execution queue, or the submission account
can all be changed.
N.B. These modifications will apply to the selected Uproc, and to any subsequent Uprocs which
follow it (in accordance with the hierarchical principles). This is also true for the calculation of the
processing date.

5.3.3.4 Cyclical task
A cyclical task can relate to a single Uproc or to a Session. It is scheduled by a number of days,
hours and minutes from a calculation start date and time.
It has no scheduling rule or explicit date. On the other hand, the user can define exclusion dates or
windows.
5.3.4 Common technical characteristics

The notion of tasks goes beyond the sole scheduling of jobs, by allowing all jobs to be declared
with the technical and functional characteristics required for their execution.
It should also be noted that these characteristics depend on the execution context (Management
Unit), meaning that tasks can adapt specifically to each MU.
5.3.4.1 User account

The user account is the username (UID) of the user for which the task will be run. This parameter is
compulsory. The username must have been previously defined in the users table of Dollar
Universe.
It should be remembered that Dollar Universe automatically adapts the user account during transfer
or distribution of tasks, via the author code.
5.3.4.2 Job description

The job description ("JOBD") is used only with the os400 environment. By default, it is
parameterized for *user, meaning that the JOBD of the submission account will be used. Entering
another value will override the usual JOBD of the submission account.
5.3.4.3 Batch queue

This information specifies in which batch queue the task must be run. This batch queue must exist
for the selected node.
• In VMS, it can be generic or physical, and expressed in the form of a logical name.
• In OS400, it corresponds to the notion of JOBQ and has the value *JOBD by default. Another
value can be entered to specify a different JOBD from the one entered in the job description.
• In UNIX or Windows, it is only effective in the case of joint use of Dollar Universe and DQM
(distributed queue management). In this case, it can designate a "physical" as well as a
"generic" job queue.
5.3.4.4 Priority
The priority of the task represents its "scheduling level" in the job queue in question. The priority
level can be set between 1 and 255. The default value is 100. This information is not used in the

OS400 environment and will only have an effect on Windows or UNIX when DQM (distributed
queue management) is used.
Note: The priority is not intended to control priority operating, but rather defines a preferential order
of submission when jobs are pending in the batch queue.
5.3.4.5 Printer
Dollar Universe allows selection of a printer for outputting the results of task executions. This code
is the logical name (four characters) of the dedicated print queue.
• In OS400, Windows and UNIX, this information is not used.
• In VMS, this information enables a four-character logical name to be entered to define the print
queue reserved for this job. This field does not necessarily represent a physical printer; it could
point to a print SPOOL.
5.3.4.6 Automatic restart mode

Setting this indicator means that the task will be automatically restarted after a system failure,
insofar as management of the job queues allows.
• In OS400, this function is not available.
• In VMS, it corresponds to the system /restart option, allowing the job to be restarted
automatically in the event of a system failure (and only in this case).
• In UNIX or Windows, the information serves no purpose unless DQM (Distributed Queue
Management) is being used jointly with Dollar Universe.
Tip: It may prove useful to allow for recovery points in the CL, using OS checkpoints or the steps
proposed by Dollar Universe.
5.3.4.7 Forced run at end of window

If the launch formula is not satisfied, (and provided unsatisfied fatal conditions are absent), Dollar
Universe puts the corresponding launch to the "Event wait" status. At the end of the launch window,
the launch is set by default to the "Time overrun" status, removing it from the current operations
stream. A manual intervention is necessary to reactivate it, by prolonging the launch window.
Setting the "forced run at end of period" indicator results in systematic submission of tasks with
unsatisfied conditions at the end of the launch window..
Note: This information must not be confused with the "bypass condition check" option, which can
be used with an interactive launch or in recovery operations.
This indicator must obviously be used with care, especially when the considered task refers to a
Uproc having declared incompatibilities.

5.3.4.8 Central monitoring of a task
Positioning this flag means that information concerning execution of the task (during start-up and
finishing) is uploaded to the node declared as central monitor node in the Dollar Universe nodes
table. See section "Central monitoring" on page 26.
For reasons related to network-resource consumption, and because of the anomalies encountered
in execution logs most often arise through specific problems requiring local intervention, the
corresponding "logs" are not uploaded to the central monitor.
5.3.4.9 Execution history

By default details of all Uproc executions are recorded in the execution history.
It is however possible to disable recording of such details for the Uprocs of a Task.
In this case the traces of the Uprocs of a Task will no longer appear in the execution history (and
history trace) once the Uprocs have finished running.
5.3.4.10 Variables of a task

Task variables are selected from among those available for the Uproc in the Task identification. In
the case of a Session:
• If the task is scheduled or cyclical, task variables are those of the Session header Uproc.
• If the Task is optional, variables are those of the specific Uproc.
• Provoked tasks will conform to one of the two cases above, depending on whether the Task
applies to a whole Session, or a single Uproc within a Session.
In the case of Future Launches:
• if the Launch was created from a Task, the task variables are assigned to the launch,
• if not, the variables of the selected Uproc are assigned to the launch.
5.3.5 Task scheduling

In Dollar Universe, scheduling essentially comprises:
• Implicit scheduling: use of scheduling rules or a cycle. The scheduled dates are calculated
automatically by the calculator.
• Explicit scheduling: definition of explicit dates by the user.
Explicit scheduling allows the processing of scheduling cases that cannot be dealt with
automatically by the implicit scheduling mechanism.
Tasks are scheduled by the accumulation of all dates: those obtained by the calculation of the rules
and the explicit dates.

5.3.5.1 Allocation of scheduling rules
Each task can accumulate up to seven different scheduling rules. Each rule must have:
• An application date
This is the date as of which the rule is calculated (indispensable, for example, for a rule with a
period of two weeks: it must be clear from which week the calculation begins). There must be
an application date per rule allocated to a task.
The application date must correspond to the period's starting date:
o If the period is "week", the application date must be a Monday.
o If the period is "month", the application date must be the first of a month.
More generally, the task itself requires:
• First schedule date.
This corresponds to the date on which the task is available for operations. Depending on the
scheduling parameters, the calculator will possibly reiterate its calculation until it finds a
scheduling date greater than the first schedule date.
Note: The allocation of rules to a task is not sufficient to produce an integral schedule: the latter
must be completed with a launch timetable for the scheduled dates of the task.
5.3.5.2 Cycle
A cycle must be defined to schedule a cyclical task.
The cycle is expressed in days (from 0 to 365 days), in hours (from 0 to 23 hours) and in minutes
(from 0 to 59 minutes).
A start date (in the general format defined by the environment variable U_FMT_DATE) enables the
next scheduled date to be calculated according to the defined cycle.
5.3.5.3 Explicit dates, exclusion dates and exclusion windows

Dollar Universe offers explicit dates, exclusion dates and exclusion windows associated with
implicit scheduling, to stabilize and facilitate the implementation of scheduling rules.
Effectively, while implicit scheduling can be used only in the case of scheduling rules remaining
relatively stable over time, and if the proposed algorithms can adapt to the particularities of the
calendars (such as use of "offsets"), a certain number of events may, on a particular day, disable
the scheduling principle.
In which case, the use of exclusion dates, exclusion windows and explicit dates makes it possible
to:
• Cancel the effects of implicit scheduling:
o by an exclusion date: inhibit a future launch calculation for a particular day,
o by an exclusion window: define a period (date and time) during which scheduling will be
invalid.
• Define a schedule non-algorithmically calculable date: entering an explicit date.

Apart from covering all imaginable cases, these four possibilities (rules, explicit dates, exclusion
dates and exclusion windows) provide an adaptable and flexible means able of accommodating
any unforeseen problems arising in the computer production process.
Explicit dates
Explicit scheduling is the simplest way of scheduling a task.
Tasks may be scheduled in absolutely any manner, from a permanent and repetitive multiple daily
schedule, to random scheduling over time.
Explicit scheduling consists in defining a set of information comprising:
• The required execution date and time.
• The launch window of the task.
• The processing date for which the task must run (when the related Uproc has been defined
with a functional period).
These possibilities allow the implementing of exceptional scheduling processes
Note: In the case of one-off launches, which take place more or less immediately, the launch
creation will be preferred, since it avoids interference in the standard scheduling process.
Exclusion dates
In cases where a sudden event might disturb the definitive scheduling cycle, exclusion dates can
be defined, making it possible to invalidate an execution at a given date, without modifying the
scheduling rules.
Note: An exclusion date can serve only to invalidate a date calculated from a scheduling rule. It has
no effect on any explicit dates. To cancel the effect of an explicit date, the related date should be
deleted from the task definition.
Exclusion window
The exclusion window is an extension of the exclusion date. The user can define a period during
which the task cannot be scheduled by the scheduling rules, by indicating start and end dates/times
of the window.
Note: Similarly to the exclusion date, the exclusion window can only be used to invalidate a date
calculated from a scheduling rule; it will have no effect on explicit dates.
5.3.5.4 Launch window and scheduling time

The launch timetable option defines a window to launch the first Uproc of the task:
• from the resolution of its launch formula,
• to allow for the particular operations load, which may vary day by day.
Launch windows are defined once and for all, irrespective of the number of implicit rules entered.
Single job run
For tasks that must run once a day only, the scheduling times can be different for each type of day
of the week.

Note: This starting time corresponds to the "earliest" possible execution time ensured by the
launcher, but does not correspond systematically to the execution date and time, which may be
deferred if the conditions are not satisfied.
The beginning of the launch window duration is completed by a duration (HHH.MM format) which is
the time the launcher will keep the launch active pending satisfaction of its conditions. This interval
may attain 999 hours and 59 minutes.
Multiple executions
This function allows entering multiple launch times, making it possible to submit up to 150
executions for a given task in the course a day. The launch time limit is calculated by Dollar
Universe by adding the indicated duration to the beginning of the launch window.
The launch timetable is generated automatically for the specified period. This automatic generation
feature can be repeated as many times as necessary, the generated times appearing gradually on
the screen in ascending order.
Note: this multiple daily launch function is not designed for supervising technical or applications
events.
Auto-relaunch
A scheduled task can be set for “automatic re-launch”.. Within a user determined window, the task
can be re-launched as soon as it finishes (completed or aborted) or after a programmable delay.
The number of re-launches can be limited by the user. In the case of a Session, the Launcher waits
for all branches of a Session to finish (completed or aborted) before processing the re-launch.
Timing of a cyclical task
A cyclical task is defined by a period (in days, hours and minutes) and by a calculation start date.
The next scheduled date/time will thus be calculated as a function of the previously calculated
date/time. The launch time can therefore not be fixed.
The launch window of the task, on the other hand, is defined at the same time as the cycle. The
duration of the launch window is thus always fixed.
Schedules of provoked tasks
A provoked task:
• can be taken into account immediately after its launch,
• or can be deferred to a launch window (from … for…). Its launch window cannot end later than
23:59.
An exclusion window can also be defined so as to inhibit execution of the related provoked task for
certain part of the day. The upper limit of this exclusion window must be higher than the lower limit
and cannot be later than 23:59.
Example of launch window and exclusion window of a provoked task.
The provoked task has a launch window: from 11:00 for 12h (i.e. until 23:00).
If the task is provoked before 11:00, it will wait for launch until 11:00 and will then be started.
If the task is provoked after 23:00, it will wait for launch until the next day at 11:00 and will then be
started.
1st case: an exclusion window is defined from 18:00 to 20:00.
If the task is provoked between 11:00 and 17:59 or between 20:00 and 23:00, it will be started
immediately.

If the task is provoked between 18:00 and 20:00, it will wait for launch until 20:00 and will then be
started.
2nd case: an exclusion window is defined from 18:00 to 23:00.
If the task is provoked between 11:00 and 17:59, it will be started immediately.
If the task is provoked between 18:00 and 23:00, it will wait for launch until 23:00, then be assigned
the "time overrun" status at 23:00.
If the task goes to "Event wait" status, if it is unable to start before the end of its launch window, its
status is changed to "time overrun" at the end of its launch window, in this example, at 23:00.
This notion is useful in that it allows user-requested batch tasks, or very resource-heavy batch
tasks, run in lightly loaded periods.
5.3.5.5 Types of launch

For a given task and a given date, there may be two launch windows characterized by the pairs
(Hb1, He1) and (Hb2, He2). This situation can arise in the following cases:
• Two identical explicit dates with different windows.
• A scheduling rule, which gives a date included in the explicit dates.
• Two rules occasionally giving the same dates for a given task.,
• a task scheduled for multiple launches with overlapping launch windows,
• a cyclical task with overlapping launch windows
• …
Depending on the task’s launch type, the number of launches and their launch times will be
different.
Serial Launches
This is the default launch type; it corresponds to the operation of Dollar Universe up to version 5.2.
The next launch of the task is calculated at the end of each launch window.
If one period totally contains the other, the "including" period is retained, the "included" period being
purely and simply forgotten. If this is not the case, two distinct launches are scheduled. The one
with the earliest starting time maintains its original window; the other has its start time adjusted to
the end of the previous window, while keeping the same finishing time.
Example: impact of the superposition of the launch windows

Launch 1
Launch 2
Hb1 Hb2 He2 He1
Launch 1
Launch 2
Hb1 Hb2 He1 He2
Launch 1
Launch 2
Hb1 He1 Hb2 He2
Launch 1 is submitted at time Hb1. The end of its launch window is He1.
1st case: Launch 2 of this task is ignored.
2nd case: Launch 2 of this task is only calculated and submitted after He1.
3rd case: Launch 2 of this task is calculated at time He1 and submitted from Hb2.
Parallel launches
This new launch type permits several launches of the same task in parallel. The calculator
calculates the next launch of a Task at the start of the launch window of the previous launch.
Exception: if two rules give the same date, a single launch is calculated.
Example: impact of the superposition of the launch windows

Launch 1
Launcht 2
Hb1 Hb2 He2 He1
Launch 1
Launch 2
Hb1 Hb2 He1 He2
Launch 1
Launch 2
Hb1 He1 Hb2 He2
Launch 1 is submitted at time Hb1. The end of its launch window is He1.
In the three examples above, Launch 2 of this task is calculated at time Hb1 and is submitted at
time Hb2.

Refer to paragraph "Impact of modifying a task" on page 98 for the calculation of Launches when a
Task is modified.
5.3.5.6 Processing date of a task

Each time a task is launched, it is accompanied by calculation of (or a request for) a processing
date which depends on the functional period of the related Uproc for this task (unless the Uproc
has no functional period).
Functional period Format of processing date
No functional period No processing date
Day Day Month Year
Week Week Year
10 days 10 days Month Year
2 weeks 2 weeks Month Year
Month Month Year
2 months 2 Months Year
3 months Quarter Year
Year Year
The processing date occurs in all operations events recorded in the Dollar Universe files. This
makes it possible to conserve and distinguish the job traces of a task independently of the
scheduling or execution dates.
Example: processing date
An accounts entry Uproc is monthly; at each launch, the requested period is a date with the format
MMYYYY.
The month-end closing Uproc is also monthly, and must conserve the trace (in the operating events
file) of 12 correct executions to enable the year-end Uproc to run.
The functional period (format of the processing date) is independent, and can differ from the
scheduling period of the related Uproc, even if Dollar Universe routinely proposes the algorithms
necessary for automatically calculating the processing dates based on the scheduling dates.
Example: a monthly accounting-statement procedure is run twice a month:
On the 30th of each month (month-end), to extract an initial statement of the past month,
On the first Monday of each month, to extract a complete statement integrating the "fifth "week of
the past month.
A similar example might entail an operation, submitted each end-of-week, to give a summary of
movements for the current month.
In order to specify this processing date more finely and allow the possibility of differentiating the
processing date from the task scheduling date, additional parameters may be defined. The
calculation method is based on the following chronological phases:
• Applying the difference in days, if necessary taking account of working days (otherwise
calendar days).
• Projection of the date obtained in the corresponding functional period.

• Applying the difference between the periods, in order to obtain the processing date.
Example: processing dates
Consider a procedure defined with a period of "day" (processing date in DDMMYYYY format).
It is assumed also that the day difference is "0".
If the specified period shift is "0", the processing date automatically associated with it at launching
is the same as its scheduling date.
If the specified period shift is "-1", the processing date automatically associated with it is the day
preceding the scheduled date.
Example: calculation of a processing date
For a task constructed on a monthly Uproc, a difference in calendar days of +5 associated with a
period shift of +1 gives the following successive calculations:
June + 5 days => 2 July
July => month of July (by projection)
July + 1 period => month of august
=> 20040801
The difference in days is not a simple repetition of the period difference, except for the "daily"
functional period. This is a valuable distinction when processing cases such as that shown in the
following example:
Example: distinguishing between differences expressed in days and in periods
Returning to the example of the monthly accounting statement that is systematically submitted
twice (on 30th of each month and on first Monday of following month). The difference must be
expressed in days in order for these two executions to "point" to a given month.
Considering the following differences:
Period difference = -1
Day difference = +2
Irrespective of the date of the first Monday, the processing date obtained for the two executions will
be the current month:
June + 2 days => 2 July => June => 20040601
Mon. 4 July + 2 days => 6 July => June => 20040601
A similar result can be obtained with the following hypotheses:
period difference = +0
day period = -7
Since version 3.4, which introduced the possibility of offsetting a task beyond the period handled
(depending on the authorizations defined for the day of the week), the processing date has been
calculated before the offset (date calculated by the rule before applying the possible offset
contained in the rule).
Examples: calculations of processing dates for scheduled tasks
The execution date is taken as Tuesday 27 June 1989, with the calendar for the month of June
configured as follows:
Month June (06)
Monday 05 work 12 work 19 work 26 work
Tuesday 06 work 13 work 20 work 27 work
Wednesday 07 work 14 work 21 work 28 work
Thursday 01 work 08 work 15 work 22 work 29 work
Friday 02 work 09 work 16 work 23 work 30 work
Saturday 03 closed 10 closed 17 closed 24 closed

Sunday 04 closed 11 v 18 closed 25 closed
Some calculation examples:

Reference Delta of FP Work days Processing date
FP
Day 0 yes 27/06/1989
Day 0 no 27/06/1989
Day +5 yes 04/07/1989
Day -2 yes 23/06/1989
Day -2 no 25/06/1989
10 days 0 21/06/1989
10 days -1 11/06/1989
10 days +2 11/07/1989
Week 0 26/06/1989
Week -1 19/06/1989
Week +1 03/07/1989
2 weeks 0 16/07/1989
2 weeks +1 01/07/1989
2 weeks -1 01/06/1989
Month 0 01/06/1989
2 months -1 01/05/1989
Quarter +1 01/07/1989
4 months +1 01/09/1989
4 months -1 01/05/1989
6 months 0 01/01/1989
6 months +1 01/07/1989
Year 0 01/01/1989
Year +1 01/01/1990

6. Refining the operations process
6.1 Manipulation
6.1.1 Updating
Dollar Universe objects are managed with the following options:
Create A new object (Uproc, Session etc.) In the selected working environment: Company -
node - Area. Creation will be refused if the object already exists in the environment.
Duplicate A source object to a target object. The objects will be of the same kind, but can have
different types (model, non-model), with different identifiers (for example duplicate
Uproc"tstref/001"onto Uproc tratbr/002), or different versions. Duplication on an already
existing target object will be refused.
Update The characteristics of an object. Its identifier is not accessible.
Display The characteristics of an object, without being able to modify them.
Delete An object. Its identifier and characteristics will be cancelled from the working
environment (including the CL Procedure file if the Uproc is internal).
Updating an object in a given environment (Company, node, Area) is specific to this environment
and has no impact on the object in other environments. This means, for example, that a Uproc
cancelled from the central repository is not cancelled in the local node.
Other update operations are specific to certain objects; these are described later in this chapter.
6.1.2 Technical locking of objects

When a Uproc is being updated by a user, it becomes inaccessible to all other users and to Dollar
Universe itself. The other objects are not locked.
There is a need for caution, therefore, when updating objects belonging to the day’s schedule. If,
for example, a user wants to modify a task and if a new launch of this task should be calculated at
this time (at the end of the launch window) the new launch will not be scheduled until the task has
been updated, but it should be automatically calculated once the modification of the task is
completed.
6.2 Version management
Dollar Universe v5.6 Reference user's guide Refining the operations process • 87
In the development environment (application and integration Areas), Dollar Universe manages
object versions (Uprocs and Sessions) to facilitate the tuning of the operations process.
6.2.1 Uprocs
Dollar Universe manages Uproc versions in the application and integration Areas. In the simulation
and production Areas, the version is always null. Dollar Universe ensures parallel changes between
the version number of an internal Uproc and the version number of the associated CL file. Parallel
management of version numbers does not apply to external Uprocs.
Current version
The current version of a Uproc is the one which, of those Uproc versions available in a given Area,
is processed during execution of a Session.
Note: Since only one version of a Uproc is possible in the production universe, this option can be
used only in the development universe.
6.2.2 Sessions
As for Uprocs, Sessions are Dollar Universe objects which follow similar rules for development and
implementation.
Therefore:
• In the application, integration and simulation Areas, Sessions are managed by version. The
entire Session/version group is accessible from the application or integration Areas. In this
respect, Uproc versions processed during a Session will be versions defined explicitly as the
"current version".
• In the production Area only one version of a Session is available.
6.3 Changing environment
6.3.1 Transfer to an Area

In Dollar Universe, the description of operations processes is assembled within the following
objects:
• Uprocs.
• Sessions.
• Calendars.
• Tasks.
For these objects it is possible to transfer each one from one Area to another. The transfer consists
in duplicating an object from one Area to another (the object is not cancelled in the source Area).
88 • Refining the operations process Dollar Universe v5.6 Reference user's guide
Transfers between Areas are authorized in the following sequence:
Application -> Integration -> Simulation -> Production.
Note: This function may be prohibited if the target Area is not available on the node in question
(see section "Authorization by Area" on page 27) or if the object in question comprises a
Management Unit that is unavailable in the target Area (this may occur with calendars or tasks -
see section "Management Units and Areas" on page 15).
Transfer of an object already existing in the target Area causes the existing object to be replaced
by the transferred object.
For Uprocs with internal CL, transferring the Uproc will also entail transferring the associated
command-language file.
In line with the procedure described in the paragraph entitled "version management":
• Transfer of a Uproc to the simulation or production Area will result in the creation, of the Uproc
with a version number of 000 in the target Area.
• Transferring a Session to the production Area will result in creation of the Session with a
version number of 000 in the production Area.
Note: the extraction and insertion commands cannot be used to transfer an object from an Area to
another (see the Command Interface user's guide).
6.3.2 Distribution to Management Units

Distribution allows the transmission of certain parameters, not between one Area and another, but
from one machine to a set of Management Units, and through them, to other operations machines
(within the same Area). As before, the distribution of Uprocs with internal CL means the parallel
distribution of descriptive information relating to the Uproc along with its associated CL.
As for the transfer, each object category within Dollar Universe can be sent for distribution including
the administration tables:
Administration tables Objects
Companies Uprocs
Nodes Sessions
Management Units Calendars
Management Unit types Tasks
Management Unit dependencies Incompatibility classes
Applications Resources
Domains
Application and MU directories
Users
Distribution functions entail:

• Extraction of descriptive information concerning the object and its source environment.
• Transfer to the destination environment.
• Insertion in the corresponding files in the destination environment (same Area as source).
Distribution of an object or an administration table consists in duplicating the object (the source
object is not deleted). If the object already exists in the target Area, it will simply be replaced by the
newly distributed object.
Objects can be distributed to:
• An explicit list of Management Units.
• A Management Unit type, meaning, all the Management Units of the indicated type.
6.3.2.1 Target of the distribution

All of the phases presented above run in real time, whether the target Management Units reside on
the same node or on another node in the network.
In the case of objects defined independently of the operations environment, (i.e. the Management
Units - this covers tables, Uprocs or Sessions), only the nodes are targeted through the
Management Unit list. If two Management Units resident on the same node are designated as
targets for a distribution, the object is sent only once to the destination node. Similarly, if the
targeted Management Units are resident on the node where the distribution is performed, the
distribution will be ignored.
6.3.2.2 Distribute a model

In the case of objects that depend on the operations environment (i.e. calendars and tasks), only
those defined as models can be distributed. They will become immediately operational for their
target Management Units as soon as the distribution is validated (allowing a delay for transmission
and installation). Unlike environment independent objects, distribution of model objects to local
Management Units will result in their creation on the local node.
Note: This function may be excluded if the target Management Units are not valid for the Area in
question (see section "Management Units and Areas" on page 15), or if the targeted nodes,
through these Management Units, are not authorized for the Area in question, see section
"Authorization by Area" on page 27.
6.3.2.3 Distribute an administration table

Dollar Universe does not allow "delta" distribution of tables (i.e. Differences only), in addition to
customized distribution node by node. It is recommended that a table be distributed to all nodes as
soon as it is created or modified, so that every node has a coherent view of the environment thus
defined.
The effect of distributing an administration table is to replace the entire target table by the original
table: if there were records in the target table which are not in the original table, these will be
destroyed by the distribution of the original table.
There are two exceptions to this rule:
• The nodes table: since version 4.3 its distribution no longer overwrites the local node definition.
• The user table: since version 5, the contents of the target table is completely deleted before
insertion, except for the "root" or "SYSTEM" user or any user having the author code "998".
Before the deletion, the contents of the table are saved in a file with the format
"USERS_TABLE_<AAAAMMJJHHMNSS>" in the directory where the exchanger is launched.
Note: The distribution of Area level objects requires the presence (in addition to network processes
- see the administrator's guide) of the exchanger for the Area in which the distribution is performed.
When distribution concerns objects at Company level (as is the case with the administration
tables), the exchanger of the production Area is used.
An alternate function is "Addition". This is operational when the U_DISTRI_MODE environment

variable is set in the production exchanger engine’s environment with the "A" value (Please refer to
the Administrator's guide for details).
• For UNIX systems, this variable should be defined in the $UXMGR/uxsetenv,
$UXMGR/uxsetenv_csh as well as $UXMGR/uxsetenv_ksh files with the "A" value
• For Windows systems, the variable should be declared in the %UXEXE%\<SOCIETE>.DEF file
with the "A" value.
6.3.3 Importing and exporting data

To allow desynchronization of the decision to distribute and the effective insertion of parameters,
export and import commands are available in the Dollar Universe command interface (see the
Command Interface user's guide).
The standard operation mode for the insertion is the "Addition" mode. The "Cancel and Replace"
function is provided with the "REPL" argument at the command line.
There is no automated backup when inserting the users table in command mode.
The extraction of the users table from a Company followed by the insertion in another Company is
now operational. No particular argument is required for the insertion. The S_SOCIETE variable is
the reference for the insertion.
6.3.4 Functional locking of objects

Transfer or distribution can optionally lock an object for protection against all modification by non-
authorized users.
This option is enabled during creation of a Company, by setting the "lock Uprocs and Sessions"
option. Objects will then be locked both in the source and the destination environment of the move.
To access these objects for modification, the user must be cleared to activate the "unlock" option
on the Uproc or the Session.
6.3.5 Distribution history

All possible actions: transfer, distribution, insertion (uxins) or extraction (uxext) functions are logged
and displayed in the distribution history.
These history files are designed to give a global view of the various parameters existing throughout
the configuration and the ability to detect potential incoherence rapidly which facilitates overall
parameter management. The history file will display the type and identifier of the object and
information concerning the actions:
• Type and identifier of objects distributed
The identifier is a concatenation of data concerning the distributed object, as illustrated in the
following table:
Table Label
Uproc Uproc, version
Resource Resource
Session Session, version
Calendar MU, (model)
Tasks Session, version, Uproc, version, MU, (model)
• Type of transmission: transfer, distribution or acquisition,

• The status of the transmission for the current environment (i.e. that containing the interrogation
function). During the action, this code can differ between the source and the target, and can
take the following values:
o Transmission request in progress (D3), this status is returned for a distribution when the
sending site cannot write the acquisition order to the remote site.
o Transmission requested (D4), this status is returned for a distribution when the sending site
has succeeded in writing the acquisition order to the remote site, but the latter has not
returned an acknowledgement.
o Transmission acquisition in progress (A3), this status is returned at the receiving site of a
distribution, when the site has been successful in acquiring the required information. It is
also obtained for a transfer, where it signifies the initialization of the transfer.
o Transmission acquired (A4), this status is returned for both a transfer and a distribution; it
indicates correct completion of the operation in question (for a distribution, means that the
receiving site has acknowledged to sending site).
If the status does not reach value A4, it means there is a problem with the corresponding
operation: it is then necessary to check that the Dollar Universe I/O server is properly running
on the node and in the target Area addressed by the transfer or the distribution. In this last
case, a check is necessary to see if the command server and the exchanger are also running
on the two nodes in question (for the targeted Areas, in the case of the exchanger).
• The target node (and source respectively) of the operation.
• The target Area (and source respectively) of the operation.
• The target Management Unit (and source respectively) of the operation.
• The date and time of the operation (for the target) (updated at each change of status during the
operation, respectively for the source).
In the case of a distribution, the history file of the move is systematically updated on the two nodes
in question, so that a given node always has a clear view of incoming and outgoing moves.
6.4 Simulation of scheduling
6.4.1 Objectives
On Windows and UNIX, production schedules are dynamically maintained by Dollar Universe,
without use of predefined plans. In such circumstances, it may be necessary to obtain a summary
view of the projected job schedule over a given period.
The above tasks are performed by the forecast workload functions.
The interactive functions for defining and scheduling a task allow a simulation to be performed at
any given time in relation to the reference calendar, and viewing the effect of the schedule on this
particular task. This simulation can be executed over any configurable period.
6.4.2 Workload forecasting

To enhance the readability of the workload forecasts, tasks to be processed can be selected,
together with their display conditions:
• Task may be selected according to individual components (Uprocs, Sessions or Management
Units), either generically or explicitly.
• The starting and ending date and time of the forecast workload.
• It should be noted that the finishing date and time are excluded from the forecast calculation.
Observable tasks will be limited to Management Units residing on the local node.
6.4.2.1 Session components

Sessions may be displayed generally or in detail, that is to say all component tasks on the
processing path running on the selected Management Units.
The forecast will take into account the particularities of those component tasks. In which case,
optional tasks whose scheduling conditions do not correspond to those of the Session will not be
displayed. Similarly, deferred provoked tasks will appear offset in relation to the other tasks of the
Session. By default, the forecast workload displays Sessions without displaying the detail of their
component Uprocs.
6.4.2.2 Launch windows

The forecast workload option can display either the task's launch windows or average elapsed time
or both. Job times are based on statistical information calculated in real time by Dollar Universe at
each job run. By default, the display includes launch windows only.
6.4.2.3 Remote Management Units

Sessions can include tasks running on remote Management Units. These tasks do not appear in
the forecast, since their statistical information is not available on the local node. However, if these
tasks are inserted between locally executed tasks, the calculator will take account of their
existence, since the statistical information operates on both the elapsed time for each task, and the
interval between the start of the Session and the starting time of each task in the Session.
7. The operations process
7.1 Role of the batch engine

Dollar Universe provides dynamic sequencing and launch control of job, based on acyclical
processes that react to events in real time: time, job start-up or completion, change of resource
status, parameter update etc.
Dollar Universe does not make use on a predefined operations plan, but rather interprets sets of
descriptive information concerning the various jobs and their associated scheduling data, taking
into account events as they occur, including any operator interventions. Thanks to this highly
interactive approach, Dollar Universe brings:
• High performance (minimal resource consumption, due to the absence of a cyclical process,
and "just-in-time" job submissions).
• Exceptional flexibility and reactivity.
• Genuine user comfort, since the operator retains all freedom for real-time interventions.
7.1.1 The automation process

The working of the Dollar Universe batch engine is represented by the following diagram:
Calendars Rules
Operator
Tasks Launches
Uprocs / Calculator Launcher Executions
MU
Awaiting
Exchanger Supervisor
Local or
remote
events Operating
Administrator To remote sites system
Figure 12: Dollar Universe batch engine functions
Job scheduling is built upon tasks, which are procedures (Uprocs) or groups of procedures
(Sessions) to be run in an environment (MU), according to scheduling rules and calendars.
The Dollar Universe batch engine then calculates the task's next execution date, then, at the
appropriate time, launches the task by verifying the execution prerequisites (existing events or
expected resources). If the production environment is distributed, the batch engine communicates
with the other machines, via the network.
Dollar Universe v5.6 Reference user's guide The operations process • 95

These various phases are performed by Dollar Universe through a series of different processes
known as the calculator, the launcher, the supervisor and the exchanger.
7.1.2 Components of the batch engine

The batch engine comprises three main components:
• The calculator, whose role is to calculate the following execution dates for all scheduled tasks
or recalculate those dates following modification of the calendar or the task.
• The launcher, which provides three essential functions, namely: condition checking, submission
and completion of those tasks that the calculator has determined as being "ready to launch" (or
that have been requested by user or operator trigger commands). It is assisted by the
supervisor in the detection of system resources.
• The exchanger, which manages Dollar Universe specific data exchanges between nodes.
The role of the batch engine is to optimize resource usage ("just in time" launches, launches at low-
load periods, such as night or weekends), potentially without any operator needing to be present.
The calculator and the launcher therefore do not function cyclically, but in direct reaction to the
requirements of the production which they manage. Dollar Universe's automation functions are
particularly efficient in terms of resource consumption.
Furthermore, the calculator, like the launcher, works on the basis of the system date and time.
Special care is required when changing the system date and time, since any changes not planned
with rigor and with the production load in mind may well disorganize the automated production
functions.
7.1.3 Location of the batch engine

The batch engines (calculator + launcher) are specific to each Company and to each Area within a
Company.
There must be a batch engine available in the production Area on all machines comprising the data
processing system. For organizations using cluster architecture (in VMS and open VMS), the
required process may be present on each machine in the cluster. The files used by these
processes are, on the other hand, shared by all batch processes installed on the cluster machines.
Note: The calculator and the launcher must be present for normal operation of Dollar Universe.
Where automation is applied across the network, the exchanger is also indispensable: this means
that the batch engines must be started in the working environment (Company-node-Area).
Refer to the Administrator's guide for more ample information on the technical architecture
supporting the batch engine.
7.1.4 Submission across the network

The different batch engines installed exchange necessary information via a client-server connection
comprised of a dedicated function called the exchanger (located in a distinct process). This process
96 • The operations process Dollar Universe v5.6 Reference user's guide

allows jobs to be executed on remote Management Units, or to condition them on remote job runs
without this being apparent to an application running locally.
7.1.5 Execution phases of a task

Execution of a task comprises five main phases:
• Scheduling: calculation of the next launch date (for scheduled batch tasks).
• Launch: examination of dates and times, and receipt of triggering commands.
• Condition checking: verification of the conditions in the launch formula.
• Execution of the associated CL. Procedure.
• Completion: execution of instructions; processing of event waits, provocation of Sessions.
Manual Automatic submission :

submission calculating of execution
dates
Launching Event
of tasks collection
Condition checking Reception of

of launches expected events
ok fatal ok Wait
Time limit
Abandon overrun
Execution
Completion
Figure 13: Task execution diagram
The five phases shown in the above diagram are performed each time a task is executed. Passage
from one phase to another constitutes an operation event which is recorded by Dollar Universe.
7.2 Job scheduling

The scheduling function initializes the process and defines the parameters used for calculating the
execution date of each task in question. Each "next execution date" for a task is thus dynamically
updated every time the scheduling parameters are modified.

7.2.1 Operation of the calculator
The calculator maintains the next execution date for each task in real time. This calculation is
performed in the following conditions:
• Each time the calculator detects an outdated execution date for a task: calculation of next
execution date for the task in question, so at the end of the launch window (for Tasks launched
serially) or at the start of the tasks launch window (for Tasks launched "in parallel").
• Following calendar update: next launch dates of all tasks dependent on the modified calendar
are recalculated.
• Each time the task's scheduling parameters are updated. In this case, only the updated task's
next launch date is recalculated.
After each calculation, the calculator programs itself to wake up at the end of the next launch
window (for Tasks launched serially) or at the start of the launch window of the Task (for Tasks
launched "in parallel").
Finally, the calculator resets the launcher's alarm if the task's launch window precedes its current
wake up time.
The calculator generates launches, which are objects distinct from tasks (different files). It is the
launches that will be considered by the launcher, and not the tasks themselves.
7.2.2 Impact of modifying a task

In general terms, all modification (or activation) of a task results in the recalculation and update of
the initial expected launch, on condition that the current system date and time is not within the initial
launch window, in which case the recalculation will be performed when the end of the launch
window is reached (for Tasks launched serially) or at the start of the launch window of the Task (for
Tasks launched "in parallel").
Assuming that the update takes place outside the initial launch window:
• If the update concerns only the task's technical information, it will affect all future launches of
this task without recalculation of the next launch, consequently any existing expected launch is
not regenerated.
• If the update concerns at least one of the scheduling modes (implicit scheduling rules, explicit
dates, exclusion dates and exclusion windows), the task will be reprocessed (if it is not disabled
and the calculator is present) to reflect the new definition.
7.2.2.1 Update of a task and its corresponding launch

Case A
The existing launch is scheduled in the future compared to the task update (the status of the launch
is "Launch Wait"):
In this case once the update is validated and even if the calculator is not started, the launch (that
has not been manually updated) is deleted from the "Launches".
In this case, once notified of the update, the calculator will establish a new launch

Note: If the launch posted by the calculator is manually updated, it will not be erased.
Case B
The existing launch is in the past compared to the task update (the status of the launch is "Event
Wait", "Time Overrun" or "Launch Wait" – if the Launcher is stopped that is):
In this case once the update is validated:
• Case B1: If the calculator is inside the previously calculated launch window (with the previous
values of the task): a new launch is scheduled.
• Case B2: If the calculator is outside the previously calculated launch window (with the previous
values of the task): The calculator goes this way:
o Case B2a: The new calculated launch is in the future compared to the actual date and
time: In this case a new launch is scheduled.
o Case B2b: The new calculated launch is in the past compared to the actual date and time:
In this case no launch is calculated. The calculator will be woken up to schedule a new
launch at the end of the new task’s launch window.
7.2.3 Enabling - disabling of a task

Irrespective of its category, a task can be disabled. An inactive task is a task for which scheduled
launches are suspended.
As a scheduled task is disabled (or enabled) the launch that had previously been calculated is
disabled (or enabled) if it is in the future compared to the time of the action and if it has not been
manually updated.
A disabled task can still play a role in the conditioning of another task that will undergo complete
evaluation, thus being able to "inhibit" the conditioned task. It will be necessary to "free" (by
enabling) the generated expected launch, or create the corresponding event, to simulate, if need
be, execution of the task.
Enabling corresponds to a complete update of the task. In this respect, activating a provoked task
does not free generated expected launches with launch windows having submission start dates
and times earlier than the current date.
When the task is enabled, the first effective execution will occur for the next launch following the
date on which the task was re-enabled.
7.2.3.1 Launches of disabled tasks

By default, the calculator continues to generate launches for disabled tasks, however these
launches are generated with a disabled status. Provoked tasks and optional tasks are disabled in
the same way as scheduled tasks. Similarly to scheduled tasks, processing requests will appear as
disabled expected launches.
Disabling tasks which have multiple daily launches may result in a rapidly expanding expected
launches file and should consequently be avoided.
In order for the launches of a disabled tasks not to be displayed in the launches window, the
U_WRITE_HELD<AREA> variable should be set to "N" in the uxlnm<COMPANY>.dat file (where
AREA is X, S, I or A). Please refer to the Administrator's guide for details.

7.3 Sequencing and launching
7.3.1 The launcher

The launcher contains the main sequencing and launch phases, namely:
3. Launch: examination of dates and times, and receipt of triggering commands.
The launcher compares the system date and time with the date and time of the next launch as
defined by the calculator; in the event of equality, it performs condition checking for this launch.
In the opposite case, the launcher will hibernate until the date and time of the next expected
launch. The data required for the launcher are transmitted by the calculator (or by various
manual operations).
4. Checking for outages (see section Outage checks).
At the start of the launch window (before the condition check), the Launcher checks for the
presence of outage windows falling within the expected duration of the Uproc. The foreseen
duration is calculated from the Uproc’s execution statistics.
If it is likely that the Uproc will not be finished before the start of the outage, the Launcher will
postpone the Uproc until the end of the outage, the duration of its launch window being set to
the remainder of the launch window at the time of the modification. If another outage is
detected, the Launcher will recalculate until it finds a valid launch window for the task.
5. Condition checking: examination of execution conditions (see section Condition checks).
The launcher checks the Uproc’s launch formula: the conditions are checked in the order they
appear in the formula:
o If the launcher encounters a "fatal" condition that is not met: the launch status is changed
into "Launch Refused ".
o If the launched encounters a (non fatal) condition that is not met, the launch status is
changed into "Event Wait’ (until the end of the launch window).
The launcher does not cyclically retry to submit the launch for condition checking. This is taken
care of by an event-driven management process. Indeed, at the moment of condition checking,
expected events inhibiting the satisfaction of the launch formula for the Uproc in question are
stored. As soon as one of these events has occurred, the launch will be resubmitted for repeat
condition checking.
6. The submission of the "batch envelope" (see section Uproc submission).
When the launch formula is validated, the launcher submits the "batch envelope" which
executes the actual CL procedure (see section "Uproc submission" on page 109).
7. Completion: execution of instructions, processing of events on hold, execution of Sessions.
After execution of the CL, the completion phase ensures execution of the completion
instructions associated with the Uproc and determines which launches awaiting events require
re-examination; it also insures management of sequences defined in the Sessions (see section
"Job completion" on page 110).
7.3.1.1 Launcher limits
The launcher can manage up to 10.000 launches and executions at any given time if no limits are
imposed by the Operating System (number of processes and memory capacity).
7.3.2 The launch

A launch can originate from:
• The automatic generation by the calculator for each scheduled task.
• Intervention on an expected launch (creation other than by the scheduling, modification,
suspension, re-activation or triggering command, using the interactive function or commands
provided in the standard Dollar Universe release).
• The task triggering or a launch creating commands (see the Command Interface user's guide).
A launch can have the following statuses:
• Launch wait (the launch window is in the future).
• Started (condition checking).
• Event wait (condition not satisfied).
• Time overrun (launch window overdue).
Note: the Disabled status (after deactivation of the launch or of the task), is not a status in the
Dollar Universe sense, since the launch retains its initial status, even when deactivated. However,
the Dollar Universe interfaces allow a selection to be made according to the launch status (launch
wait, started, event wait or Time overrun) and/or according to its characteristic: enabled or disabled.
See section "Condition checking" on page 105 about the statuses workflow and section "Job
status" on page 115 for a detailed description
7.3.2.1 Launch window overdue

The launch window is a period of time granted to ensure that all the conditions considered as pre-
requisites to execution of the task are effectively satisfied. So a launch expected for 07:00 PM, with
a launch window of two hours may wait up to two hours for its conditions to be satisfied. If after this
interval at least one of the conditions is not satisfied, execution of this launch will discard. For some
special cases, it is possible to impose execution of the launch at the end of this interval, even if all
of the conditions are not met using the "forced run" option.
In the event of a "Time overrun" status, the launch can no longer be submitted. It must therefore be
either abandoned (by cancellation), or have its time credit increased (by extending the launch
window).
This function is very useful in the event of a system halt that is too long for Dollar Universe to be
able to restart all non executed jobs. In this case, when it restarts, Dollar Universe regenerates all
launches that should have occurred (but solely in the production Area), and, if the launch window is
overdue, attributes them the "time overrun" status: the user will then be able to decide which
launches are to be executed or abandoned.
7.3.3 Operations on launches
Dollar Universe comprises functions for operations analysis and job monitoring to intervene on
expected launches.
In this case, it may be necessary to:
• Manually start an unscheduled job.
• Modify or delete a scheduled execution.
• Modify the variables of the launch or their values.
• Hold (or release) the execution of a launch.
All these operations are possible through the "launches" functions. These operations do not
allocate the actual task but solely the occurrences of the launches for each task.
7.3.3.1 Suspending or reactivating a launch

This function allows all launches of a launch to be suspended. The task can then no longer be
started by Dollar Universe, until it has been released using the same option. All launches
(irrespective of their "status") can be suspended, except for these that are already in suspended
status.
Depending on the time of its reactivation, if the launch is outside its launch window, it can pass into
"Time overrun" status.
7.3.3.2 Starting an unscheduled job

Dollar Universe allows new launches to be created manually, whether these apply to already
scheduled tasks or not. If the task is already scheduled, the new launch occurrence will be added
to the one produced by the scheduling function, without modifying or suspending it.
Creation of a launch is entered much like a task; the Uproc, the MU and perhaps the Session must
be given, plus the technical information necessary for the execution (see the following paragraph).
If the scheduled task exists, its technical information will by default be proposed.
Scheduling information is defined as follows:
• When a launch is created for a provoked task, the default values launch duration and exclusion
windows are those of the task definition.
• When a launch is created on a scheduled task, the values used for launch duration and
exclusion windows are those specified in the launch GUI, the exclusion dates and times are not
taken into account.
• When a launch is created for a non-scheduled Session or Uproc the launch duration and
exclusion windows values are specified in the launch GUI.
As a launch is created on a remote host, the default time and date (processing date, launch
window) are the ones on the remote host.
7.3.3.3 Updating expected launches
Updating a launch allows some or all parameters to be modified:
• The launch user's account.
• Technical information: printer, batch queue, and priority.
• The job's launch window.
• The launch exclusion window: comprised between the same limits as the launch window, this
allows momentarily inhibiting the launch.
• The processing date of the launch in question.
• Bypass condition check: indicates if the launch is performed with condition.
• Checking (examination of execution conditions) or not. This option is also proposed during job
recovery, it is different from the option described below.
• Central monitoring: notes whether the launch in question must be submitted for central job
monitoring, that is, whether its start- and end-of-execution information needs to be transferred
to the monitor node as defined in the node table (see section "Central monitoring" on page 26).
• Automatic relaunch or restart mode:
On VMS, indicates if the launch in question is to be submitted with the VMS restart option, that
is, whether it can be automatically restarted by VMS after a system failure.
On Windows or UNIX, the joint use of Dollar Universe and DQM allows access to the same
functionality. This will resubmit those launches that were in progress at the time of the system
failure, provided this option has been selected.
• Modification of variables: In the case of a launch created from a task, it is the variables of the
task which apply. If not, it is the variables of the Uproc in question which will be selected. In any
event, these variables can be modified as long as the conditions of the launch have not been
checked by the engine.
7.3.3.4 Canceling a launch

A launch cancellation can involve launches created by a scheduled task, a new job creation, or
triggered from the Dollar Universe interactive command. Cancellation results in the disappearance
of the launch, which in turn is not executed by the launcher.
Deleting a launch has no effect on the task it originates from. The next launch of this task will be
calculated according to the rules stated above, by default at the end of the task’s launch window.
If the cancelled launch conditioned other job runs, the latter may remain blocked due to the
absence of this launch.
7.3.3.5 Intervention history

The intervention history stores all the interventions on the launches (scheduled task or not)
The purpose of this function is to record the various manual interventions performed on the
automated production process. While such interventions are a major advantage to act in real time
on the production, they can nevertheless cause damage if not used with care.
Interventions are marked by:
• The author code at the source of the modification (or creation) of the launch.
• Type of action performed on the job:
• Interactive launch: "L".
• Launch modification (launch window, technical information): "M".
• Deferred execution (cancelled): "D".
• Launch held: "H".
• Launch released: "R".
• The date and time of the intervention.
The detailed record of the technical information associated with the launch (user, batch queue,
launch window etc.) is also accessible.
7.3.4 The Job events file

Condition checking of a launch is based on the resolution of the launch formula for the
corresponding Uproc. This Uproc contains a certain number of conditions which are deemed either
"satisfied" or "unsatisfied", according to analysis of the events occurred during operations.
To ensure strict environmental separation, each Area has its own current events file.
This base stores every event corresponding to all runs of Uprocs declared "memorized".
7.3.4.1 Modify events

There are several reasons for wanting to modify events:
• When configuring a job or an application, the conditions defined at the Uproc level may refer to
tasks that have never run (such as conditioning a task on correct execution of the same task
the previous day, for example). In this case, it will be necessary to create the required event
artificially in order to definitively initialize the production cycle.
• During a recovery process or during an intervention following a system failure, it may be
necessary to modify or create operations, class or resource events in order to automatically
continue a production sequence.
In these conditions it should be clear that any intervention on production events can have a
particularly heavy impact on the production process.
During the launch, execution and completion phases, the progression over time of a launch may be
determined by the changes in its execution status. This is recorded in the current job events file,
which is used by the launcher for condition checking or recovery of Uprocs.
7.3.4.2 Network operations

When conditions are used across the network (i.e. the conditioning Uproc is on a different node to
the conditioned Uproc), the events database plays a special role.
When the conditioned Uproc is launched, the event request (Session, Uproc, MU.) is transmitted to
the concerned node. When the conditioning Uproc run, the event is created in the local event
database and is uploaded to the databases of all the conditioned Uprocs which are waiting for this
event.
The event statuses, for the conditioned Uprocs, are A (condition check accepted, execution
pending), E (execution in progress), T (normal successful completion) or I (abnormal end of job).
Each change of status is uploaded systematically.
The records in the events database corresponding to the conditioning Uproc is managed according
to the rules of memorization defined in the Uproc’s general information. However, the events
database of the conditioned Uprocs, only stores the last event for the period in question (whatever
the memorization parameters of the conditioning Uproc).
The deletion of an event from the conditioning Uproc’s events database is automatically carried
forward to the events base of the conditioned Uproc. The reverse does not apply.
7.3.5 Condition checking

The different status for launches and executions are summarized in the following figure:
Launch wait
Started Disabled
Time Event Refused

overrun wait
Pending
Executing
Completion in
progress Aborted
Completed
Figure 14: Execution status of a job
The values of the execution status have the following meaning:

• D or "Started": launch condition checking phase.
• W or "Event wait ": the launch formula could not be validated, meaning at least one condition is
not met.
• R or "Refused": the launch formula could not be validated, meaning at least one fatal condition
is not met
• O or "Time Overrun": the launch window is over, independent of the result of the condition
check
• A or "Pending": pending execution of a job, having successfully negotiated the condition
checking phase the job is submitted to the batch queue.
• E or "Running": throughout execution of the CL.
• I or "Aborted": status after a crashed execution due to defective operation of a program or the
Uproc CL., preventing the correct functional end of job (such as error reading, writing or
opening a file; divide by 0; overflow; application error etc.).
• F or "Completion in progress": throughout the completion phase after a correct job run.
• T or "Completed": status at the end of the completion phase without incident.
In general terms, when the value of a status is entered in the current events files or the job monitor
events file, it cancels the previous record. These operations are automatic (see section "Job status"
on page 115 of the executions).
7.3.5.1 Outage checks

An outage can be used to stop all or part of production for a specific period of time:By submitting no
jobs during the window and
• By postponing jobs that would be likely (according to their mean execution duration) to run
during the window.
If however jobs that should statistically have finished before the outage continue running into the
outage, they will not be cancelled by the Launcher.
If no execution statistics exist for a job, the Launcher will use default duration of 10 minutes. A
variable in the company’s environment file allows the default value to be altered (see the
Administration Manual - environment files).
Outages can be applied globally to the specified node, or limited to Management Units of a Type on
the specified node or limited to a Management Unit on the specified node. The window is defined
by a start date/time and an end date/time.
At the start of the launch window (before the condition check), the Launcher checks for the
presence of an outage during the expected execution of the Uproc, calculated from past execution
statistics.
The search for an outage is carried out in the following order:
• For the specific Management Unit,
• For the specific Management Unit Type,
• Globally for the Area.
If it is likely that the Uproc will not be finished before the start of outage, the Launcher will postpone
the Uproc until the end of the outage, the duration of its launch window being set to the remainder
of the launch window at the time of the modification. If another outage is detected, the Launcher will
recalculate until it finds a valid launch window for the task.
If the Launcher postpones a launch of a task with multiple daily launches, the Calculator will only
generate new launches of this task after the end of the outage. Launches that should have run
during the outage will not appear.
Deletion of an outage has no effect on launches that have already been postponed.
Outages are purged by the Dollar Universe purge feature (see Administration Manual).
Time changes do not affect the outage since these are based on start and stop dates and times.
Postponed launches are set to the Launch Wait status.
7.3.5.2 Condition checks
Each launch is submitted to condition checking as soon as the start of the launch window is
reached. The launch status is set to "D "(started) for the whole duration of the condition checking
phase.
Condition checking begins by examination of any incompatibility classes. These may be managed
in the class events database. If the examination result is satisfactory, the launch formula is itself
examined.
If all conditions are not satisfied and among the unsatisfied conditions there is at least one fatal
condition, execution of the launch is abandoned (status "R" - refused). If not all the conditions are
satisfied without any fatal condition, the condition checking function puts the launch on hold and
records those missing events which prevented the success of the condition check. Throughout this
time, the launch status is at "W - "event wait".
Each time a missing Uproc or resource event occurs (before the end of the launch window), the
launch is re-submitted for condition checking (returns to status "D" Started). It should be noted that
only inhibiting events are memorized at each condition check so that each new condition check can
bring up any new inhibiting event.
Unmet conditions inhibiting verification of the launch formula are processed as follows:
• If the condition concerns execution of a task on the same node, the event is recorded. As soon
as Dollar Universe intercepts the corresponding event, the launcher will renew the condition
check on this task,
• If the condition concerns a task on another node, the exchanger process will trigger the
recording of the expected condition on the node in question. When Dollar Universe intercepts
the event corresponding to the condition, it will transmit the information to the initial node, which
will rerun a condition check on the task.
This method of managing expected events provides, at the Uproc level, conditioning that is
totally independent of the organization or the layout of the environments within the
configuration.
Upon expiry of the launch window and if the launch formula is still not satisfied, execution of this
task will be abandoned and the launch status will become "Time overrun". There is always the
possibility, of performing a forced run. In this case, upon expiry of this launch window, the task will
be submitted, with the execution conditions being ignored.
Note: a forced run ignores the launch formula outright, whether the latter contains incompatibility
conditions or not. Use of the forced run therefore requires prudence.
Finally, if the launch formula is verified, the launcher ensures creation of the execution process (the
batch envelope), and submits the CL. associated with this process (see section "Uproc submission"
on page 109).
7.3.5.3 Substitution of the resource supervisor

When the launch formula contains a resource condition (the resource having been defined and the
resource condition having been integrated into the launch formula), the launcher looks for this
resource attribute on the system.
If the resource attribute is found, the launcher continues to analyze the formula.
If the resource attribute is not found, the launcher requests the supervisor to warn it when the
resource is present at the node; it also memorizes the fact that it is waiting for a resource event.
From this point, the supervisor will cyclically scan for presence of the resource using the period
indicated in the resource definition. The supervision of the resource in question will cease as soon
as it is deemed available.
A resource attribute will only be checked if the resource is not logical and if the condition
specifically requires verification of its attributes.
After the resource has been analyzed and deemed available, the supervisor notifies its presence in
the resource events database (distinct from the expected events base) and informs the launcher
that it can check the Uprocs waiting for this resource. Only one request is communicated to the
supervisor concerning a given resource, even if the resource is common to several Uprocs.
The launcher then renews analysis of the launch formula.
Note: only the physical resources (file, logical name…) make the supervisor intervene, for logical
resources, the supervisor does not intervene in the condition checking operations.
7.3.5.4 Verification of resource condition quotas

If the condition is satisfied, (i.e. If the required quota is inferior to the available quota), the Uproc
reserves the quota, expressed in the condition, for the duration of its execution. If the resource was
defined with automatic unlocking, the reserved quota will made available upon Uproc completion
(status T or I), if not a specific script command will have to be run to free up the reserved quota
(manual liberation).
If the condition is not satisfied, because the requested quota is superior to the available quota, the
launcher positions a quota wait on the resource in question. When the corresponding quota is
increased, either by another Uprocs completion or by the specific command, the launcher will once
again examine the resource attributes pertaining to the waiting Uproc.
Note: for performance reasons, whenever possible, it is generally better to use the provocation
commands in preference to resource conditions. For example, when a task should run at every
occurrence of a given technical event, i.e. arrival of a file.
7.3.5.5 Reserving resource quotas and scheduling priorities

Starting from Dollar Universe version 4.3, on Windows and UNIX, a function (a window in graphical
mode and two commands) enables reservations to be made on quotas of a resource.
This reservation is carried out by virtue of a task (Session, Uproc, Management Unit) executed in a
defined environment (Company, node, Area) on behalf of a processing date.
This enables:
• Blocking of resource quotas while a task is awaiting execution:
During condition checking the launcher will recognize the task which has reserved the quotas
and will release them to it to authorize its execution. The immediate effect of this will be to
block the quotas requested by the condition according to the usual process.
Once quotas have been reserved by a task, any other launches presented for condition
checking will wait until the requested quotas are made available by the launcher. Definition of
scheduling priorities between tasks having made reservations on the same resource:
If two tasks have reserved quotas on the same resource, the first to be executed will be the one
having more quotas (quota1 or quota2) in its reservation. If these are not yet available the
launcher will await their release to run the task with the higher priority.
If a task is presented for launch without having made any reservation on this resource but
having a resource condition capable of being resolved by the launcher because the quotas are
available, then the launcher will validate the condition and authorize the execution of the launch
(even if other tasks are waiting for reasons of reservation).
Example: reserving resources
The command:
uxrsv RES RES=PRIO_ORDO ESP=X UPR=IU_DT1 MU=S01 QT1=90 QT2=0
PDATE=${S_DATRAIT}
reserves for the task defined by Uproc iu_dt1, Management Unit s01in the production Area, for the
current processing date, the resource with the reference PRIO_ORDO with a quota qt 1 of 90.
If the resource PRIO_ORDO has available to it a quota qt 1 of a maximum of 100, 10 remain free at
the outcome of the execution of the command.
Another task, not having made any reservation on this resource, can be run if its condition on this
resource requires a quota of 10 or less.
If a second reservation on the resource PRIO_ORDO is requested by the following command:
uxrsv RES RES=PRIO_ORDO ESP=X UPR=IU_DT2 MU=S01 QT1=10 QT2=0.
These two commands define a condition checking priority by Dollar Universe. The task which has
reserved more quotas will be executed first, in this case the one defined on Uproc IU_DT1.
7.3.6 Uproc submission

When the Launcher has validated the condition-checking phase of a Uproc, it submits the Uproc by
executing the "batch envelope" u_batch. It is this "batch envelope" which initializes the execution of
the Uproc (with reference to a submission account) and executes the completion instructions
(issuing of the return code).
U_BATCH
Pre-processing
UPROC
Post-processing
Figure 15: Uproc submission
7.3.6.1 Additional processing

On Windows, UNIX and VMS, the execution of a Uproc may be preceded by the execution of a pre-
processing which will be common to all Uprocs. If this procedure exists it will be run systematically
before each and every Uproc.
The execution of the pre-processing may be used, for example, to define local environment
variable or logical names which will be known to the Uproc during execution. This avoids having to
integrate common code in the CL.
In the same way, the Uproc execution may be followed by a post-processing, which if it exists will
be run systematically for each Uproc. It will be common to all Uprocs.
Pre-processing is called U_ANTE_UPROC (U_ANTE_UPROC.bat on Windows) and is located in
the mgr directory.
Post-processing is called U_POST_UPROC (U_POST_UPROC.bat on Windows) and is located in
the mgr directory.
7.3.6.2 Job status

By default, the Uproc’s return code is set following the rule below:
System Variable Completed status Aborted status

Windows RESEXE 0 #0
UNIX Return code of script 0 #0
When defining the Uproc (see paragraph "Completion status of the Uproc" on page 45), the user
can also configure another method of positioning the termination status of the Uproc:
• by a comparative on the real value of the return code of the Uproc,
• according to the presence of a character string in the log of the Uproc or in another file,
• after having reiterated the Uproc execution (see section Auto-Retry).
This analysis is carried out by the Launcher on completion of the execution after recovering the
script’s return code or the value of the corresponding variable.
If the execution is interrupted, the job status is always set to Aborted.
If the file cannot be analyzed (file not found, insufficient rights…), the job status is set to Aborted
and a specific message is placed in the log.
If the launcher has updated the completion status of the execution, one of the following lines is
added to the log of the Uproc:
“TEXT” found in job log job status set to COMPLETED/ABORTED
“TEXT” found in FILE job status set to COMPLETED/ABORTED
Return code is VALUE job status set to COMPLETED/ABORTED
Unable to open the job log job status set to ABORTED
Unable to open FILE job status set to ABORTED
7.3.7 Job completion

This represents the final phase in execution of a task. It is provided by the launcher.
The launcher is enabled at the end of execution of each Uproc's CL, providing the following
functions:
• Executes the completion instructions for the Uproc in question,
• Inserts the corresponding event in the events file,
• Compares the event that it processes against the expected events, and re-enables (if required)
condition checking when there is a correspondence between the created event and an
expected event,
• Submits (if necessary) the "child Uproc" depending of the Session. When the submissions have
to be made to nodes other than the node running the launcher, the Exchanger will execute all
operations required for activating the launcher on the node(s) in question,
• Uploads operations events towards the central monitor node, where central job monitoring is
being used for a multi-site production environment,
• Therefore completes the circle initiated by the calculator and the launch and condition checking
functions of the same launcher.
7.4 Inter-machine communications
7.4.1 Role of the exchanger

The exchanger is a process in the Dollar Universe batch engine that handles all batch
communications between the different nodes of the network (relieving the launchers).
The functions provided by the exchanger are:
• Submission of tasks for remote Management Units.
• Transmission of event wait states (conditioning a "local task" on the end of execution of a
"remote task", for example).
• Distribution of objects forming the Dollar Universe parameter settings.
• Uploading of information for the central job monitoring function.
The exchanger operates on an event-driven basis (requiring declaration of a DECNET object in
VMS) and has a configurable cycle to ensure the security of data transfers.
The production information going through the exchanger is available in the "Job exchange"
database. The distribution information is available in the "Distribution exchange" database.
7.4.2 Operating principles

The batch engine manages task submissions via the launcher, in the following way:
• If the launches are to be triggered on a Management Unit, the launcher submits them for
condition checking.
• If they are to be triggered on a remote node, the launcher will use the exchangers of the source
and target nodes to inform the launchers at the nodes in question.
Launcher Launcher
1 3
Exchanger Exchanger
2
network
Figure 16: Exchanger mechanisms
In the latter case, the local launcher transmits the condition checking command to its exchanger
(phase 1). The latter transmits the request to the exchanger of the Management Units in question
(phase 2). The remote exchanger warns the launcher (phase 3), which submits the launch on the
Management Unit.
Note: In the case of a remote submission this means that the required configuration objects should
be available on the remote node (complete Uproc and Session), the objects should be distributed
to a MU of this remote node.
A dependency or incompatibility condition belonging to a local task on a remote task uses the same
operating principles.
If the expected event is not found locally by the launcher, it formulates a request for an event wait
to the exchanger (phase 1). The local exchanger transmits the request, together with the name of
the sender, to the remote exchanger (phase 2). The latter transmits it to the remote launcher
(phase 3).
If the event is available, the reply is immediate; otherwise the remote launcher posts an event wait;
when the latter occurs, the reply will be transmitted to the original launcher, which will resolve its
own event wait and record it in its current events file (to avoid searching for it each time it is
needed).
Note: For a technical description of the inter-machines communication operations, reports to the
administrator's guide.
7.5 System failures

In the event of a system failure, four situations can arise to the launcher:
• The system failure occurs before the launch has been performed. In this case, Dollar Universe
will automatically re-examine the validity of this launch window and possible condition
checking. If the launch was already on hold, it will not be considered (no point).
• The system failure occurs in the course of launch. In this case, no irremediable operation has
been performed, and it will simply resume the launch and submit it to repeat condition checking
(performed automatically by the batch engine).
• The system crashes simultaneous with the completion phase. In this case, a Dollar Universe
function started during the boot or with the computer IPL resumes and ends the completion
instructions for each launch remaining at the "F" status (Completion in progress).
• The system failure takes place during the execution. In this case, Dollar Universe offers the
possibility of automatically restarting the corresponding launches, using specific parameter
settings associated with each task (automatic restart on Windows or UNIX if DQM is used).
At start-up, Dollar Universe will consider its entire portfolio and will synchronize with these
same processing operations (in order to await their completion), or will declare them as
"incidents" if they are no longer present. In addition, Dollar Universe authorizes insertion of
recovery steps in the CL, enabling partial recovery of interrupted processes.
In the case of a system’s incident, the calculator reschedules automatically all the launches (in the
production Area) that should have been created during the interruption of service of the system or
of Dollar Universe.
These features are a natural guarantee towards security of operations, including, a crash of Dollar
Universe itself (even if this represents a very serious problem).
8. Operations monitoring
8.1 Executions monitoring
8.1.1 Purpose
Dollar Universe attributes a particularly important role to the tracking and supervision of operations,
in order to facilitate job monitoring, accelerate the identification of incidents, and permit the
necessary diagnosis and recovery procedures. There is a transaction dedicated entirely to job
monitoring.
The executions list provides dynamic display of all or part (according to the selection criteria
defined) of the finished or current job runs.
All essential data is directly accessible:
• The history trace formatted by Dollar Universe, recording the expected events and the phases
performed by the job. This trace can receive comments (operator instructions for example)
transmitted from the Uproc script via a specific Dollar Universe command.
• The job execution log.
• The next jobs to run, etc.
As well as the main functions allowing for intervening on the operations process:
• Recovery after incident.
• Interactive launching of unscheduled jobs.
• Displaying and updating of operations events.
The Executions list provides the operator with a single point from which to make all necessary
interventions on the operations process.
A console can be dedicated to this function alone.
8.1.2 Central monitoring

It is possible from a node defined as the central monitoring node (see section "Central monitoring"
on page 26) to display the local executions but also remote executions defined with central job
monitoring flag (see section "Central monitoring of a task" on page 78).
For the tasked defined with the "central monitoring "option, the events concerning the start and end
of execution are systematically transmitted to the central monitoring node. In this way, the
execution monitoring function active at the central monitoring node displays all major events
occurring on all computers in the network.
114 • Operations monitoring Dollar Universe v5.6 Reference user's guide

The history trace and job log of remote jobs cannot be directly displayed on the central monitoring
node but are available on the execution node should the need arise.
8.1.3 Job status

The job statuses displayed in the execution list are the following:
Status Code Meaning
Completed T Normal successful completion of a Uproc.
Aborted I Abnormal end-of-job. This status is normally generated by the procedure
itself (see the Command Interface user's guide chapter entitled "execution
CL" for more information regarding the possibilities for managing return
codes)
Completion in F This status appears only during correct completion of the procedure, and
progress corresponds to execution of the completion instructions. Irrespective of the
final status, the other completion-phase operations are performed:
reactivating of events on hold, request for launch of following Uprocs in a
Session
Running E Execution of job in progress
Pending A This status corresponds to submission of the job in a batch queue,
following a successful condition check. The duration of this phase of the
launch can vary with the technical characteristics of the batch queue at
any one moment.
Disabled H Launch on hold. This status can occur following an intervention of this
type: in the expected launches function (or after the corresponding
command), in the job monitor, or the associated batch queue management
function.
Refused R This abandon occurs when a fatal condition is not satisfied during the
launch's condition check.
Event wait W If one or more non fatal conditions are not satisfied (but not fatal), an event
wait is posted. A given launch can be put into an event wait several times.
Each of them corresponds to an unsuccessful condition check. After the
first unsatisfied condition check, the launcher is set to await the
corresponding event. Occurrence of the expected event results in a new
condition check. If this new condition check brings up another unsatisfied
condition, the launch is again put into an event wait.
Time overrun O Launch window overrun. This status occurs each time that an expected
event does not occur during the valid launch window or when one or other
of the calculator or launcher functions has been absent for too long.
Started D Condition check in progress. This phase corresponds to examination of
the execution conditions of the launch. It should be noted that this status is
considered as inhibiting in relation to any non-simultaneity conditions (or
incompatibility criteria) from other jobs.
The statuses workflow is described in the section "Condition checking" on page 105.
8.1.4 Production diagnostics

The production diagnostic can be done at four levels:
Dollar Universe v5.6 Reference user's guide Operations monitoring • 115

• The state of the execution gives information about the launch phase or on the execution of a
job as well as on its final result.
• The "previous launches" present the history of the launches condition checks with the
associated history trace (see section "Display previous launches" on page 116).
• The "history trace" displays a detailed view of the engine: production instructions, event wait,
etc…(see section "Display history trace" on page 116).
• The "job log" presents the Uproc’s job log, it can be accessed at anytime (see section "Display
log" on page 118).
The Dollar Universe diagnostic tools are described in the Administrator's guide.
8.1.5 Authorized interventions
8.1.5.1 Kill a job

This function can only be accessed if the execution status is "Running". It has the effect of stopping
the execution of the Uproc at the level of the system thereby stopping all dependent sub-
processes. The execution then takes on the status "Aborted".
8.1.5.2 Recover job

This function is accessible only if the execution ended with the "Aborted" status.
The Uproc must have been configured as memorized (see section "Event memorization" on page
49) in order for this function to be accessible. It remains possible to modify or to create the
considered event, in order to give it "Aborted" status and so be able to restart the execution.
An execution can be relaunched with a delay. As you relaunch you can specify the date and time of
the beginning and the end of the period. It is also possible to update the job variables.
8.1.5.3 Display previous launches

Dollar Universe only keeps track in its monitoring function of a single occurrence of the multiple
condition checks of a launch. These diverse occurrences can be accessed via the "previous
launches" and/or in the history trace of the executions.
This option displays all condition checks concerning a launch before being executed or abandoned
as well as the "history traces" corresponding to each launch or condition check.
8.1.5.4 Display history trace

The Dollar Universe history trace is presented in the form of a formatted screen in which messages
are displayed by the various components of the engine processes.
This function allows access to the job's execution history, and to display the job's descriptive labels
along with date and time of condition checking by the launcher, the processing date, the variables,
the date, time and number of the entry on the batch queue and an explanatory message
concerning the state of the task.

For tasks where history recording has been disabled the user can access the history trace during
the launch and execution of the Uproc, but this is no longer available once the Uproc has finished
executing.
Every line is usually made of the date (with the U_FMT_DATE format), the time (format:
HH:MM:SS) and of a text message. These messages are for example:
• At any a major execution phase:
DATE TIME Start condition check
DATE TIME Submitted in batch queue
DATE TIME Batch Starting
DATE TIME Start Completion Instructions
DATE TIME *** TASK ENDED ABNORMALLY ***
DATE TIME *** NORMAL TASK COMPLETION ***
• For all the launches that are based on a Uproc with a functional period
Processing date DATE
• For every execution of a uxset command in the Uproc script, an appropriate comment is
displayed such as:
DATE TIME Pass Step N: NN
• Possibly the Uproc variables as well as their values. VAR indicates the name of the variable
and below its value is displayed, for example (three types of variables ; date, numeric and text):
VAR: VARDATE
2002/07/01
VAR: VARNUM
123
VAR: VARTXT
Last var
• As the major steps of the task are in progress:

*** Task launch refused ***
*** Uproc running ***
• During the condition check
o For an opened incompatibility class:
Incompatible with Uproc …
o For a dependency condition that is not met, for example:
Dependency Cond. 01 Prop. 01:
Dep.: - D_BACKUP - SIEGE 20040525 Missing
Let: Session (empty in the above example) – Uproc (D_BACKUP) – MU (SIEGE) processing
date (20040525) Missing (the identified event is missing)
o For a resource condition that is not met, for example:
Resource Cond. 01 Prop. 01:
Res.: D_FIL_PAY FIL Absent
C:\temp\FilePay.txt Absent

Let: resource (D_FIL_PAY) – type (FIL: file) – Absent (the previously identified resource is
missing).
o For a non-simultaneity condition that is not met, for example:
simultaneity Cond. 01 Prop. 01:
Simu.: SESS_NS -0000152 UPR_NS_1 -0000442 S_SATURN Present
Let: Session (SESS_NS) – Session number (0000152) - Uproc (UPR_NS_1) –Uproc number
(0000442) - MU (S_SATURN) Present (The execution of the mentioned task has been found).
• During the automatic retry of the task:
"DATE HEURE relaunch execution – retry no [n]"
• The task execution statistics:
Duree Elapsed time
CPU CPU time
PGF page faults (on VMS
only)
DIO direct IO (on VMS
only)
BIO buffered IO (on VMS
only)
Let for example (on Windows – the information for PGF, DIO and BIO are not available)
*** TOTAL *** - Duree: 00.00:00:10.00 - CPU: 00.00:00:00.00
- PGF : ???? - DIO: ???? - BIO: ????
• Sending an e-mail:
Date/Time NOTIFICATION_EMAIL REQUEST OK - <Status>
Recipient1;Recipient2;...
Or
Date/Heure NOTIFICATION_EMAIL REQUEST ERROR - <Status>
Recipient1;Recipient2;...
8.1.5.5 Display log

The user can consult the job's execution log via a text editor. Querying can be performed at any
given time, regardless whether the execution is in progress or has completed. Dollar Universe
redirects itself the job's STDOUT and STDERR to the execution log file.
For example:
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 file(s) copied.
The log file always starts with a Dollar Universe formatted header displaying;
• The Uproc’s name, version and execution number,
• The Session’s name, version and execution number,
• The processing date,
• Possibly the received parameters,
• Possibly the received variables,
• The standard and error output of the script execution or the specific function.
In the case of an automatic retry the following lines are inserted in the job log:
_!================================================
_! ** DATE HH:MM:SS relaunch execution - retry [n] - [UPROC]/[VER] [Exec No [MU]
_!================================================
The execution log files are located in the Area log sub-directory (accessible via the UXLww where
ww=AP, IN, SI or EX depending on the Area).
The name of the log file follows a standard format (please refer to the administrator's guide, "Log
Management " paragraph).
8.1.5.6 Customizable actions

Customizable actions can be created by the user:
• in the Graphical Job Monitor,
• when creating a Business View.
An action is defined by
• a unique identifier,
• a label chosen by the user, which appears in the menu when job monitoring,
• its description,
• in some cases: an icon,
• a command in which variables can appear, such as:
Variable Description
S_COMPANY Name of the Dollar Universe Company.
S_NODE Node of the selected job.
S_ESPEXE Area code.
S_NUMPROC Execution number of the Uproc.
S_NUMSESS Execution number of the Session.

S_NUMLANC Execution number of the Launch.
S_CODSESS Code of the Session.
S_PROCEXE Code of the Uproc.
S_CODUG Execution Management Unit.
S_NBRECORD Number of the record chosen from the list.
• an execution directory (the name of which can contain the variables listed above),
• a trace file (the name of which can contain the variables listed above).
The actions defined can be used in the menu that will be shown:
• in the Graphical Job Monitor,
• to supervise and control the Business View in Monitor mode,
• in Web Console.
The actions are saved on the selected node. The node on which they are saved can be chosen in
the Graphical Job Monitor. The actions are loaded when the corresponding tool is started,
depending on the connected nodes.
8.2 History files and statistics

Dollar Universe comprises a series of functions dedicated to maintaining histories of operations
events. These functions provide access to:
• A journal listing interventions performed on the "launches" (see paragraph entitled "Intervention
history" on page 103);
• A complete execution history, which allows daily purging of the executions list (see "Execution
history" on page 120);
• Information concerning resource consumption by all jobs (see "Statistics" on page 121);
• Instantaneous view of all transfer, distribution or insertion operations performed on Dollar
Universe objects, giving the global situation of the parameter settings in force at any one
moment (see paragraph entitled "Distribution history" on page 91).
8.2.1 Execution history

The execution list makes it possible to follow the different phases in the execution of a task. Since
events may be purged at any time, the execution list cannot guarantee a complete history of
executions.
The memorized events are used to verify the launch formula of each Uproc. For operations
reasons, these events can themselves be destroyed manually or automatically from the Uproc
completion instructions.
Dollar Universe therefore manages a third level of history in which no random or manual purging is
possible, other than a systematic purge based over a defined retention period.

Note: All launch attempts performed by Dollar Universe are recorded in this history file. If a given
launch has been through condition checking three times (following the arrival of expected events),
the launch will appear three times, with three different Uproc numbers but with the same launch
number.
For tasks where history recording has been disabled, neither the various launch attempts of the
task, nor the final status are permanently saved to the execution history.
8.2.1.1 Available information

Executions are marked by: Uproc, Session, MU and by the execution number. The information
contained in the execution history therefore can identify:
• The task submission account or the party requesting the launch (in the event of an intervention
on an expected launch).
• The launch mode of the task: this can have three values:
• "P" for schedule.
• "L" for interactive launch.
• "R" for relaunch.
• Dates and times of start and end of execution.
• The final status code of the execution.
• Breakdown of the technical information linked to the task (batch queue, launch window etc.).
• The values of the variables.
• The history trace formatted by Dollar Universe during execution of the task.
8.2.2 Statistics
For each job run, Dollar Universe memorizes the consumption of essential resources (CPU, direct
and buffered I/O, memory, elapsed time etc. depending on the operating system), the elapsed time
of the last hundred job runs and calculates the median values.
This method of calculation provides values corresponding to 50% of job runs. It also limits the
impact of exceptional, insignificant results on the values calculated. All this data can be displayed in
graphical form. To allow precise execution-time simulations, they can be updated (removal of
"rogue values", creation of estimated values for new jobs that has not been executed).
For the jobs whose execution lasts less than a second (elapsed time or CPU time) the displayed
time in the statistics will be rounded up to 1 second.
Update functions are used only where an intervention is required on the statistical values of certain
tasks in order to modify the behavior of other Dollar Universe functions, particularly the graphical
job monitor. Only the "histogram" function does not respect this rule, since it consists of a graphical
display showing changes in task-resource consumption over time.
• The creation function is necessary for initializing all the parameters managed for a new task.
• The modification function allows partial alteration of all available data for a given task.

• The deletion function allows complete destruction of a task in the statistics, while the
cancellation function serves for initializing the statistical values of a task.
8.3 Purging
8.3.1 Operating events file

The operating events file is fed by the execution of Uprocs that have been declared as memorized.
Depending on the memorization parameters declared during definition of the Uproc see section
"Event memorization" on page 49), one or all of its execution runs will be archived over the number
of periods indicated. Since this file serves for conditioning other Uprocs, purging it must be handled
with care.
An automatic purge can be performed using completion instructions (see section "Completion
instructions" on page 61). These are meant to purge certain events at the end of a Uprocs
execution.
A manual purge can also be performed, by selecting events then deleting them from the file.
8.3.2 Executions monitoring

The executions list records are purged manually. This means that all occurrences selected will be
purged and therefore will disappear from the job monitor screen. If several executions of the same
procedure are purged, they will all be cancelled. The purge does not keep the last execution.
Purging the job monitor has no effect on the normal execution of the job; it can only prevent the re-
start of an execution which has been purged.
Executions purged from the executions list will remain present in the execution history and, if they
are memorized, in the events file.
The "on the fly" purge carried out by the IO server, enables deletion from the job monitor of any
remaining records (multiple variables allow a finer selection). Please refer to the administrator's
guide to learn how to use it.
The executions list can equally be purged by means of a purge command. See the Command
Interface user's guide for details of its use.
8.3.3 History files

History files are purged "on the fly" by the IO server. It will purge the execution history of any
operation whose retention period has expired.
Since the 4.3 version of Dollar Universe, when purging job runs, the execution history file do not
retains the last execution of any given procedure, irrespective of its date. This Uproc must be
scheduled and executed for each Area of the Company.
Refer to the administrator's guide for more details.

8.3.4 Log files
Dollar Universe generates several log files:
• The Dollar Universe general log declared during installation (except for OS400).
• Engine process logs (declared when configuring the Company).
• The execution log for each procedure.
These log files are not purged automatically by Dollar Universe, but left to the system administrator,
who can manage those files based on his operations constraints.
Refer to the administrator's guide for more details.

9. Glossary
9.1.1.1.1 1st scheduling date
Corresponds to a startup date. According to the scheduling parameters, the calculator may
reiterate its calculation until a scheduling date greater than the first scheduling date is found to
generate the first launch of this task.
9.1.1.1.2 Aborted
Status of an execution which ended abnormally, either via the application positioning of the script
exit value (see completed status), or via a sudden exit from execution.
9.1.1.1.3 Application date

Date beginning with which the calculation of the rule applies (indispensable, for example, for a rule
invoking a two week period: the week with which the calculation begins must be known).
The application date must correspond to a period start date defined for the rule. For example for a
"week" period rule, the application date must be a Monday.
9.1.1.1.4 Area
Work environment within a Company.
Four Areas are proposed and named: Application, Integration, Simulation and Production. The
production Area is the only one that must be started up. The others are optional.
The Areas are sealed, secured operating environments but featuring interactive configuration
transfer functions (within the same Company).
9.1.1.1.5 Calculator
The calculator is an engine specific to an Area. On an occurrence basis, it calculates the next
scheduling date for each of the tasks and updates this schedule each time their planned launch
window has expired or in the event of a task or attached calendar change.
9.1.1.1.6 Calendar
Defines the types of days: working, not worked, and holidays over a range of years for a
Management Unit, the types of Management Unit or by default the Area (this is the general
calendar, it is unnamed).
The calendar is used by the calculator engine as a reference to calculate the scheduling of tasks.
9.1.1.1.7 Company
The Company represents a Dollar Universe installation and consequently a work (data)
environment for the automation of production. The Company is a secured operating environment
that can only communicate through its configuration import/export commands.
124 • Glossary Dollar Universe v5.6 Reference user's guide

9.1.1.1.8 Completed
Status of a properly completed execution. This status is obtained by:
• "set RESEXE=0" in the Uproc script under Windows,
• "exit 0" from the Uproc script under UNIX,
• "S_RESEXE==V" in the DCL under VMS.
Any other Uproc script exit status yields an aborted execution status.
9.1.1.1.9 Condition check

Examination by the launcher engine of the Uproc execution conditions and possibly putting the
launch on standby if the conditions are not met.
During a condition check, the status of the launch is "Started", if the conditions are not solved the
status of the launch becomes "event wait", if the conditions are solved, the launcher proceeds with
processing submission.
9.1.1.1.10 Event wait

Status of a launch in its launch window whose launch formula has not been entirely solved.
9.1.1.1.11 Exchanger
The exchanger is an engine specific to an Area. It is used in network communications within a
Dollar Universe Company to perform configuration distribution, network event transmission or
network submission order operations.
9.1.1.1.12 Functional period

Processing frequency in the application sense (e.g. a balance sheet is monthly) possibly distinct
from the processing scheduling frequency. The functional period defines the format of the
processing date (daily, weekly, monthly etc.).
9.1.1.1.13 Launch
A launch is an occurrence of the calculation of a task. It may be the result of the scheduling by the
calculator or of an explicit creation request by an operator, or of an invocation (via Session
progress or a command).
9.1.1.1.14 Launch formula

Boolean equation uniting the conditions necessary for the execution of a Uproc. This formula may
contain all the types of conditions: chaining, non-simultaneity or resource linked by the Boolean
operators AND, OR and NOT. It may contain up to 99 conditions and 9 levels of parentheses.
The order of the launch formula determines the order of the condition check by the Launcher
engine.
9.1.1.1.15 Launcher
The launcher is an engine specific to an Area. It schedules launches on the basis of events. It
works mainly with the date and time of the next launch, at which time it reactivates itself and
performs the condition check and processing submission operations.
Dollar Universe v5.6 Reference user's guide Glossary • 125

It is also reactivated by events attached at the end of processing execution to run new condition
checks.
9.1.1.1.16 Management Unit

Logical work environment of the application tools. One or more Management Units can be defined
on the same node. The Management Units are grouped per type (represented by the first letter of
the Management Unit). The handling of MU types allows the processing to be configured
generically (for example "all type A MUs"). Configuration thus becomes independent of the physical
configuration of the architecture.
9.1.1.1.17 Node
Logical name representing a physical machine.
The uxsrsrv.sck file of the mgr directory of the Company provides the correspondence between
the node name (in the Dollar Universe sense) and the physical name of the machine (in the
operating system sense). See the administrator's guide for more details.
9.1.1.1.18 Time overrun

Status of a launch whose condition check by the launcher was unable to result in a submission
during the launch window defined for it.
9.1.1.1.19 Processing date

Date qualifying the period for which the Uproc works. The processing date may be different from
the processing scheduling date (e.g.: for scheduling on February 3, the processing date may be
calculated automatically via an algorithm defined by the customer as being the preceding month,
that is January 1st).
The processing date is usable in the Uproc script in a variable or in conditioning between Uprocs.
9.1.1.1.20 Resource
A resource is used to describe, via a logical identifier, a system resource (a file for example) which
is to be supervised to condition the execution of a Uproc.
By extension a resource may also be logical (or virtual). It has no physical reality but is managed by
notions of exclusivity or quota assignment (with respect to a maximum).
9.1.1.1.21 Rule
Periodic algorithm (day, week or month) allowing the scheduling dates of a task to be calculated.
The rules work on the Management Unit calendar for which the concerned task is executed (if it
does not exist, the calendar of the type of Management Unit and the general calendar of the node
are sought).
9.1.1.1.22 Session
A Session is a homogenous set of Uprocs (e.g.: same scheduling). It is used to describe a Uproc
submission order and to define downgraded processes in the event of a Uproc execution incident.
126 • Glossary Dollar Universe v5.6 Reference user's guide

9.1.1.1.23 Submission
If a Uproc launch formula is solved, the launcher submits the execution of the processing to the
batch queue manager or in its absence to the operating system.
9.1.1.1.24 Supervisor
The supervisor is the only engine common to all the Areas on a node. Its function is to supervise
the resources on launcher request when it examines a Uproc whose (physical) resource condition
is not met. The supervision process is cyclical, according to a period defined for each resource.
9.1.1.1.25 Task
Technical and execution scheduling characteristics of a Uproc or a Session on a Management Unit.
Three types of tasks can be defined:
• Scheduled task: periodically or via the explicit dates,
• Optional task: to set up an exception in a Session periodic scheduling,
• Provoked task: to be triggered "on request" or to set up an exception in the technical
characteristics of a scheduled task (in a Session).
The calculator generates a launch on the basis of the definition of a task.
9.1.1.1.26 Uproc
Object used to define, around a specific function (command file: script, DCL, CL, .bat, command or
other function), all the application conditions necessary to the execution of the processing (inter-
Session chaining, file standby, parameters, processing date etc.) except for the technical and
temporal execution conditions.
Dollar Universe v5.6 Reference user's guide Glossary • 127

Area
definition 11, 14
distribute an object within an area 89
location of batch engine 96
management by version of session 88
10. Index management by version of Uproc 88
node authorization 27
transfer of an object to an area 88
use in resource identifiers 36
$ use of the management unit 15
$U Author code
access control 7 definition 30
architecture 8 use 33
batch management 2 Automatic restart
batch queues 2 defining for a task 77
central monitoring 9 Auto-Retry
client-server 8 display history trace 116
co-operative architecture 9 display the log in the job monitor 118
description of a job stream 4
distributed architecture 8 B
environment 11
features 2 Batch engine
Implementation 7 components 96
interfaces 10 consequences of a system failure 112
job description 3 execution phases 97
job monitoring 2 functional architecture 95
modification operations 87 job completion 110
objectives 1 location of components 96
parameters distribution and transfer 10 role 95
scheduling 4 role of the supervisor in resource conditions checking
security 7 107
sequencing 5 submission and conditioning of tasks across network
simulation 6 111
statistics 6 working principles of the calculator 98
technical locking on objects 87 working principles of the exchanger 111
working principles of the launcher 100
Batch envelope
A additional processing 109
Access control role 109
principles 7
Access path C
restoration in the CL 28
Access rights Calculator
use of the profile 32 impact of modifications of a task 98
Add years in a calendar 68 role 96
Application working principles 98
definition and use 28 Calendar
definition of the area 14 distribute a model 90
directories table 29 distribution history 91
Architecture distribution to MU 89
co-operative 9 impact of modification on tasks 69
distributed 8 impact of update on task schedule 98
secure operations 8 minimum range 68
model 68 using the notion of session 52
presentation 4 using the user account 55
principles of generation 68 Condition
purpose 67 definition 51
transfer to an area 88 dependency see dependency condition
type of days 69 fatal - definition 56
Central monitoring fatal - processing in the launch formula 60
completion role 110 general characteristics 51
defining in a task 78 network operation 62
definition of the central monitor node 26 non simultaneity see non simultaneity condition
purpose 114 resource see resource condition
role of the exchanger 111 role of conditions in the launch formula 60
updating at launch 103 use of memorized Uprocs 49
CL using the notion of MU 53
definition 38 using the notion of processing date 54
description 41 using the notion of session 52
insert a message in the history trace 116 using the user account 55
use of commands 42 Condition check
version management of internal Uprocs 88 across network 111
Class bypass condition check of a launch 103
example 37 consequences of a system failure 112
purpose 37 examination of incompatibility classes 37
use 37 forced run 101
verifying at launch 60 network operations 104
Client-server operations 107
principles 8 principles 100
Coding priority 108
MU and MU type 17 role of the exchanger 111
of tasks 73 Condition of non-simultaneity
sessions 63 differences between incompatibility classes and non-
Command simultaneity conditions 37
$U specific commands 116 Condition of resource
use in the CL 42 operating principle 107
Command file see CL Create years in a calendar 68
Company Current version of an Uproc 88
definition 11, 13 Customize $U
editor, object locking, master node, directory 13 user menus 32
independence of companies 13 Cycle
location of batch engine 96 of a task 79
use in resource identifiers 36 Cyclical task
Completion definition 76
role 110
Completion instructions D
completion role 110
consequences of a system failure 112 Date
definition 38 exception date 80
general characteristics 51 explicit 79, 80
network operation 62 first schedule date of a task 79
purge events 122 of application of a rule 79
purpose 61 Day of scheduling 70
purpose and operations 61 Days in a calendar 69
using the notion of MU 53 Deferring launch
using the notion of processing date 54 execution of a provoked task 81
130 • Index Dollar Universe v5.6 Reference user's guide

use of provoked task 75 Uproc parent, child or per in a session 63
Definition uproc type 39
application and domain 28 user account 76
areas 14 user profile 30
author code 30 variables 46
automatic restart of a task 77 Dependencies
batch engine 95 examples 21
batch queue of a task 76 Dependency condition
calendar 67 purpose and definition 56
calendar model 68 Desktop
calendar range 68 customize 33
calendar type of days 69 Diagnostic
central monitor node 26 log file 115
central monitoring in a task 78 Directory
company 13 access path to applications objects 29
company, area, MU 11 access path to MU objects 29
completion instructions 38 access path to objects 28
condition 51 company 13
current version of an Uproc 88 company on a node 28
cyclical task 76 MU or application – restore in the CL 42
dependency condition 56 of a CL associated to an Uproc 41
fatal condition 56 Disable
forced launch at end of window of a task 77 a task 99
hierarchical data processing (HDP) 18 Display history trace
internal CL or external CL file 41 in the job monitor 116
JOBD (job description) 76 Display previous launches
launch window 80 in the job monitor 116
launching a task 38 Distribute
management unit 14 a model 90
master node 26 a table 90
memorized Uproc 49 Distribution
MU dependencies 18 calendar model 68
MU Type 17 history 91
node, logical node, physical node 25 node - impact on central monitoring 26
non simultaneity condition 58 object locking 91
normal or error processing path of a session 64 principles 10, 89
optional task 75 role of the exchanger 111
print queue of a task 77 status 91
priority of a task 76 task model 74
processing date 84 to a local MU 90
provoked task 74 Uproc with internal CL 41
resource 35 using MU Type 17
resource condition 59 Domain
resource reference 35 definition and use 28
scheduled task 74
scheduling rule 70 E
session 62
session header 63 Editor
submission account 33 definition in the company table 13
successor 50 to write the CL 42
task 73 Elapsed time
task model 74 of execution in forecast workload 93
Uproc 38 Enable
a task 99 Execution environment of a session
Environment using HDP or the MU 65
presentation 11 Execution report
restoration of access paths stored in the tables 28 history trace 116
structure 11 insert a message from the CL 42
submission account 33 log file 118
submission accounts 33 Execution status
Event use in completion instructions 61
completion role 110 use in dependency conditions 56
creation by the batch engine 97 Executions
description of the event file 104 purge 122
list of status values 115 Explicit
memorized Uproc 49 add or cancel dates 79
network operations 104 scheduling 67
purge by completion instructions 61 scheduling a task 78
purge in the events file 122 External
using 104 Uproc CL file 41
Example
completion instructions 61 F
dependency conditions 56
fatal condition 56 Failure
incompatibility class 37 consequences of system failure 112
memorized Uproc 49 Fatal condition
modify a calendar 69 definition 56
MU, MU type, dependencies, HDP 21 processing in the launch formula 60
non simultaneity conditions 58 FIC
processing date 84 value 29
resource 36 File manipulation
scheduling rule 71 use commands in the CL 42
use of HDP in a session 65 Forced launch
use of HDP in conditions 53 bypass condition check 103
Exception of scheduling within a session 64 defining in a task 77
Exchanger Forecast workload
role 96, 111 display the session components 93
submission and conditioning across network 111 launch window 93
Exclusion manipulation 93
window 80 simulation of schedule 93
Exclusivity tasks executed on a remote node 93
use in resource conditions 59 Functional period
EXE calculation of the processing date 84
value 29 definition 47
Execution use 48
batch envelope 109 use in conditions and completion instructions 54
consequences of system failure 112 use in dependency condition 56
display history trace 116 use in non simultaneity condition 58
display previous launches 116
history file 120 H
kill 116
list of status 115 HDP
possible values of status 105 convention and use 18
recover 116 definition 18
Execution examples 21
status 110 use in a session 65

use in CL 42 display in the job monitor 118
use in condition and completion instructions 53 display previous launches 116
use in dependency conditions 56 kill an execution 116
use in non simultaneity conditions 58 purpose 114
use in resource conditions 59 recover a job 116
Header JOBD
first Uproc of a session 63 defining 76
scheduling a session 64
Hierarchical data processing see HDP K
History file
available information 121 Kill
distribution and transfer 91 an execution 116
executions 120
interventions on launches 103 L
overview 120
purge 122 Launch
History trace canceling 103
display in the job monitor 116 checking for outage 106
insert a message from the CL 42 condition check 107
conditions of analysis of launch formula 60
definition 38
I extension of launch window 101
Implementation holding or releasing 102
principles 7 impact of a fatal condition 56
Implicit impact of the notion of successor 50
allocating of rules to a task 79 interventions on launches history 103
examples of scheduling 71 list of status 101
scheduling 67 manual launch of a task 102
scheduling a task 78 operations 102
scheduling rule 70 origin of launch 101
Incompatibility see Class possible launch modes 73
Information possible values of status 105
set in the uproc 38 processing of Uproc successors 50
Inheritance purpose of execution events 51
MU of execution within a session 65 purpose of the launch formula 60
of technical characteristics of the task within a session updating 103
64 Launch formula
of technical characteristics –provoked task 75 example with dependency conditions 56
Integration example with non simultaneity conditions 58
definition of the area 14 limits 61
Interface optimization hints 60
access rights control 32 purpose 60
Interfaces Launch window
of $U 10 cyclical task 81
Internal definition 80
Uproc CL file 41 extension 101
in forecast workload 93
multiple executions 81
J
of a provoked task 81
Job log single job run 80
display the log in the job monitor 118 superimposing launch windows 82
Job monitor updating at launch 103
display history trace 116 Launcher
role 96 Monitoring see Job monitoring
working principles 100 MU
Limits directories table 29
maximum number of conditions in a launch formula MU check
61 principles 53
maximum number of Uprocs in a session 66 MU dependencies see HDP
Linking two Uprocs see session, see dependency MU type
condition calendar 67
Locking distribution restriction of calendar 68
declaration in the company table 13 examples 21
functional on objects 91 role, definition and coding 17
technical on objects 87
Log file N
diagnostic tool 115
display in the job monitor 118 Nature
purge 123 of resource 35
Network
location batch engine 96
M
Node
Management unit access path to applications directories 29
and the areas 15 access path to MU directories 29
calendar 67 area authorization 27
coding 17 calendar 67
definition 11, 14 central monitoring 26
definition of MU Type 17 company directory 28
distribute objects 89 definition and use 25
examples 21 master 26
involvement in HDP 18 Non-simultaneity
MU Type definition 17 differences between incompatibility classes and non-
objectives 8 simultaneity conditions 37
scheduling environment of a task 73 purpose and definition of the condition 58
time reference 16 use the incompatibility classes 37
use 15 Normal or error paths in a session 64
use in condition and completion instructions 53 Number of executions per period
use in dependency conditions 56 memorized Uproc 49
use in non simultaneity conditions 58 Number of functional periods
use in resource conditions 59 memorized Uproc 49
use in resource identifiers 36
using dependencies in the HDP 18 O
using for defining the execution environment of a
session 65 Object
Master node distribute 89
declaration in the company table 13 transfer principles 88
definition 26 Offset of scheduling 70
Memorization Operating date
characteristics 49 use of functional period 47
definition 49 Operations monitoring
Model objectives 6
distribute 90 Optional task
of calendar 68 definition 75
of task 74 display in the forecast workload 93
Modify Order the examination of Uprocs waiting an event 50
organization of $U menus 32 Outage

principles 106 R
Range
P minimum for a calendar 68
Parameters Recover
transmission to Uprocs 42 an execution 116
Path Report
normal or error in a session 64 history trace 116
Period of scheduling 70 of execution - display in the job monitor 118
Previous launches Reservation
display in the job monitor 116 of a logical resource 108
Print queue Resource
defining in a task 77 coding with MU Code, processing date, company or
Priority area 36
defining in a task 76 definition and use 35
Processing date distribution history 91
definition 47 identifier, nature and quotas 35
purpose and definition 84 reservation of a logical resource 108
updating at launch 103 restriction on use of variables 36
use 48 Resource condition
use in conditions and completion instructions 54 operating principle 107
use in dependency condition 56 purpose and definition 59
use in non simultaneity condition 58 Resource reference see Resource
use in resource condition 59 Restart mode
use in resource identifiers 36 updating at launch 103
Processing date check Robot process see Batch engine
principles 54 Rules
Production presentation 5
definition of the area 14 Running a task
Profile purpose of launch 51
definition 30
rights definition 32 S
Provoked task
deferring launch 75 Scheduled task
definition 74 definition 74
display in the forecast workload 93 Scheduling
inheritance of technical characteristics 75 calculator operations 98
Public holidays in a calendar 68 consequences of a system failure 112
Purge definition 73
events 61, 122 effective scheduling date 79
events in the job completion 110 examples of rules 71
executions 122 exception of the optional task within a session 75
histories 122 explicit 79
log files 123 explicit or implicit 67
with completion instructions 61 generation principles of calendar 68
impact of updating calendars 69
implicit
Q application date for a rule 79
Queue batch implicit or explicit 78
defining in a task 76 inheritance within a session 64
Quotas launch window 80
definition and use 35 objectives 4
use in resource condition 59 presentation 2, 5
purpose of the calendar 67 use in dependency conditions 56
scheduling rules 70 use in non simultaneity conditions 58
Scheduling rule Steps
examples 71 define in the CL 42
presentation 5 Stop
purpose and definition 70 an execution 116
Security Structure
objectives 7 access path to applications directories 29
use of the profile 32 access path to MU directories 29
Sequencing Submission
objectives 5 across network 111
Sequencing Uprocs role of the exchanger 111
using sessions 64 Submission account
Session definition 33
coding 63 Successor
definition 62 definition 50
definition of paths 64 processing by the launcher 50
display in the forecast workload 93 purpose 50
distribution history 91 Supervisor
distribution to MU 89 purpose for resource conditions 107
first run 104 Suspend
inheritance of scheduling of header 64 temporary the task execution 99
management of versions by area 88 System failure
maximum number of Uprocs 66 effect on executions 112
presentation 4 extension of launch window 101
scheduling 73
structure 63 T
transfer to an area 88
use in condition and completion instructions 52 Tables
use in dependency condition 56 applications directories 29
use in non simultaneity condition 58 company 13
using HDP or the MU 65 distribute 90
using MU Type to distribute 17 distribution history 91
variables 65 management unit 14
Session check MU dependencies 18
principles 52 MU directories 29
Session header user accounts 30
scheduling 64 using MU type to distribute 17
Severity Target
set in the uproc 38 of the distribution 90
Simulation see Forecast workload Target of a condition
definition of the area 14 MU check 53
presentation 6 processing date check 54
Statistics session check 52
presentation 6 user account 55
purpose 121 Task
use by forecast workload 93 application date of a scheduling rule 79
Status canceling a launch 103
of executions 115 cycle 79
of launches 101 defining JOBD 76
of the distribution or transfer 91 defining the automatic restart 77
possible values for a launch or an execution 105 defining the batch queue 76
result of execution 110 defining the central monitoring 78

defining the print queue 77 Updating
defining the priority 76 variables values in a task 78
definition 73 Uproc
distribute a model 90 completion instructions 61
distribution history 91 define the variables 46
distribution to MU 89 definition 38
enable/disable - impacts 99 definition of the current version 88
execution phases 97 dependency condition 56
explicit scheduling 79 distribution history 91
extension of launch window 101 distribution to MU 89
first run 104 execution conditions 51
first schedule date 79 functional period 47
forced launch at end of window 77 general characteristics of conditions and completion
forced run 101 instructions 51
holding or releasing the launch of a task 102 impact of successors on launch 50
implicit or explicit scheduling 78 insert a message in the execution report 116
inheritance within a session 64 internal or external CL 41
interventions on launches history 103 launch formula 60
launch window 80 management of versions in relation to areas 88
list of execution status values 115 maximum number in a session 66
list of status of launches 101 memorization 49
manual launch 102 non simultaneity condition 58
model 74 parent, child or peer in a session 63
optional 75 presentation 3
origin of launch 101 purpose of incompatibility class 37
processing date 84 purpose of the processing date 84
provoked 74 repetition in a session 63
schedule 74 resource condition 59
scheduling rules 70 restoration in the CL of access paths stored in the
superimposing launch windows 82 tables 28
transfer to an area 88 scheduling 73
updating the launch 103 transfer to an area 88
updating the variables values 78 transmitting parameters in the CL 42
user account 76 using fatal conditions 56
Time using MU Type to distribute 17
in the management unit 16 using the classes 37
Transfer write the CL 42
history 91 Uproc type
object locking 91 definition 39
principles 10, 88 User
Uproc with internal CL 41 author code 30, 33
Trigger a Uproc profile 30
from the CL 42 submission account 33
Type of days in a calendar 69 use in dependency conditions 56
Type of resource 35 use in non simultaneity conditions 58
User account
U defining 76
use in conditions and completion instructions 55
Universe User profile
use of the management unit 15 customization 33
Update Username see User
of a calendar - impact on tasks 69 Users
scheduling rule - impact on scheduled tasks 70 use of the profile 32
V
Variables
declaration and modification 46
defining in the session 65
definition 46
in the Uprocs - characteristics 46
in the Uprocs - value 47
restriction on use in a resource 36
update in a task 78
updating at launch 103
Version
management by area (session) 88
management in relation to areas (Uproc) 88
of CL for Uproc with internal CL 41
W
Window
exclusion 80

Email: support@orsyp.com
WEB site: http://www.orsyp.com
User Forum: http://www.orsypforum.com

Dollar-Universe-Reference Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dollar-Universe-Reference Guide PDF

Uploaded by

Copyright:

Available Formats

Dollar Universe v5.

EMEA HEADQUARTERS AMERICAS HEADQUARTERS

Tour Franklin 54 Middlesex Turnpike

+33 [0] 1 47 73 12 12 +1 [781] 276 4600

© Copyright 2009. All rights reserved.

Dollar Universe v5.6 Reference user's guide Contents • iii

iv • Contents Dollar Universe v5.6 Reference user's guide

6. Refining the operations process 87

Dollar Universe v5.6 Reference user's guide Contents • v

7. The operations process 95

vi • Contents Dollar Universe v5.6 Reference user's guide

10. Index 129

Dollar Universe v5.6 Reference user's guide Contents • vii

Dollar Universe v5.6 Reference user's guide Figures • ix

1.1 Functional objectives

Figure 1: Stages in the life cycle of a computer application

Dollar Universe v5.6 Reference user's guide Introduction • 1

1.1.2 Batch queues

1.1.3 Job monitoring

2 • Introduction Dollar Universe v5.6 Reference user's guide

1.2.1 Job description

1.2.1.1 Elementary job description

Dollar Universe v5.6 Reference user's guide Introduction • 3

4 • Introduction Dollar Universe v5.6 Reference user's guide

1.2.2.3 Job scheduling

1.2.3 Job sequencing and launching

Dollar Universe v5.6 Reference user's guide Introduction • 5

1.2.4 Operations monitoring

1.2.5 Execution statistics

6 • Introduction Dollar Universe v5.6 Reference user's guide

1.2.7 Security of operations

1.2.7.1 Implementing applications

1.2.7.2 Access control

Dollar Universe v5.6 Reference user's guide Introduction • 7

1.2.8 Distributed client-server operations

1.2.8.1 Distributed operations

8 • Introduction Dollar Universe v5.6 Reference user's guide

1.2.8.2 Co-operative management of distributed operations

1.2.8.3 Central monitoring

Dollar Universe v5.6 Reference user's guide Introduction • 9

1.2.8.4 Remote parameter distribution

1.2.9 Interfaces with Dollar Universe

10 • Introduction Dollar Universe v5.6 Reference user's guide

2.1.1 Environmental concepts features

Dollar Universe v5.6 Reference user's guide Environmental concepts • 11

MU1 MU2 MU3

Figure 2: The environmental concepts of Dollar Universe

Development universe Production universe

Application Integration Simulation Production

Figure 3: Objects logical layout depending on environment concepts

12 • Environmental concepts Dollar Universe v5.6 Reference user's guide

2.2.1 Independence of Companies

2.2.2 Additional characteristics of Companies

Dollar Universe v5.6 Reference user's guide Environmental concepts • 13

2.4 Management Units

14 • Environmental concepts Dollar Universe v5.6 Reference user's guide

2.4.1.2 Management Units and Areas

Dollar Universe v5.6 Reference user's guide Environmental concepts • 15

2.4.1.4 Time zones and MU offsets

16 • Environmental concepts Dollar Universe v5.6 Reference user's guide

The use of the TZ environment variable and MU offsets is mutually exclusive.

2.4.2 Management Unit types

Dollar Universe v5.6 Reference user's guide Environmental concepts • 17