84094282 dollar universe reference manual ingles

Reference manual

DOLLAR UNIVERSE version 5for Windows, UNIX and VMS

version 1.1

06-19-2001

COPYRIGHT

Copyright ORSYP

The following components of DOLLAR UNIVERSE are protected by Copyright:

q Installation manual,

q Getting started,

q Administration manual,

q Reference manual,

q Motif interface manual,

q Windows interface manual,

q Commands manual,

q API manual,

q All texts and titles used in data input, and all software screens.

DOLLAR UNIVERSE, UNIVER$E GP and UNIVER$E DQM are registered trade marks of ORSYP.

The following terms are the property of ORSYP:

q Management Units, or M.U.

q Uproc.

IBM , AS/400 , OS/400 are registered trademarks of International Business Machines Corporation.

DEC , VMS , OpenVMS and OSF/1 are registered trademarks of Compaq Corporation.

Windows is a registered trademark of Microsoft Corporation.

PATROL™ is a registered trademark of BMC software.

SAP/R3 is a registered trademark of SAP.

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Reference manual • 3

Table of contents

Introduction 7Functional objectives...................................................................................................... 7

Scheduling and sequencing ............................................................................... 8Batch queues .................................................................................................... 8Job monitoring ................................................................................................. 8

Overview ....................................................................................................................... 8Job description ................................................................................................. 9Scheduling ....................................................................................................... 9Job sequencing and launching......................................................................... 11Operations monitoring .................................................................................... 11Execution statistics ......................................................................................... 11Simulation...................................................................................................... 12Security of operations ..................................................................................... 12Distributed client-server operations................................................................. 13Interfaces........................................................................................................ 15

Sequence of operations................................................................................................. 16Administration................................................................................................ 16Scheduling jobs .............................................................................................. 16Operations control .......................................................................................... 17

Environmental concepts 19Introduction ................................................................................................................. 19

Environmental concepts features..................................................................... 19Presentation.................................................................................................... 19

Companies ................................................................................................................... 21Definition....................................................................................................... 21Independence of companies ............................................................................ 21Additional characteristics of companies .......................................................... 21

Areas ........................................................................................................................... 22Management units ........................................................................................................ 22

Definition....................................................................................................... 22Management unit types ................................................................................... 24Hierarchical data processing ........................................................................... 24Implementation of management units.............................................................. 25

Nodes........................................................................................................................... 29Definition....................................................................................................... 29Central or local administration ........................................................................ 30Additional characteristics of the node.............................................................. 31

Declaring the applications environment ........................................................................ 32Applications and domains............................................................................... 32Application or MU directories......................................................................... 32

Users 35


4 • Reference manual

General ........................................................................................................................ 35Recognised users ............................................................................................ 35The author code.............................................................................................. 35

Development users....................................................................................................... 35Transactions of the character interface ............................................................ 36User profiles................................................................................................... 37Customization of profiles................................................................................ 37

Submission accounts .................................................................................................... 38Definition....................................................................................................... 38Using the author code ..................................................................................... 38

Parameters 41Resources..................................................................................................................... 41

Definition....................................................................................................... 41Codification ................................................................................................... 42

Incompatibility classes ................................................................................................. 43Purpose .......................................................................................................... 43Using incompatibility classes.......................................................................... 43

Uprocs ......................................................................................................................... 44Definition....................................................................................................... 44Procedures or programs (DCL, shell, CL, .bat) ................................................ 45Variables........................................................................................................ 47Functional period and processing date............................................................. 48Event memorisation........................................................................................ 50Successors...................................................................................................... 51

Execution prerequisites ................................................................................................ 51General features of conditions......................................................................... 52Additional characteristics................................................................................ 55Types of conditions ........................................................................................ 57The launch formula ........................................................................................ 61Completion instructions.................................................................................. 62

Sessions ....................................................................................................................... 63Definition....................................................................................................... 63Normal and abnormal processing paths ........................................................... 65Execution environment................................................................................... 65Carry-over of Uproc variables’ values............................................................. 65Storage limits ................................................................................................. 66

Scheduling 67Automation of batch tasks............................................................................... 67

Calendars..................................................................................................................... 67Calendar application environment................................................................... 67Calendar model .............................................................................................. 68Generation of holidays.................................................................................... 68Calendar range ............................................................................................... 68Types of day................................................................................................... 69Impact of modifications on a calendar............................................................. 69

Scheduling rules........................................................................................................... 70Definition....................................................................................................... 70Examples ....................................................................................................... 70

Tasks ........................................................................................................................... 71Definition....................................................................................................... 71Task model..................................................................................................... 72Types of task .................................................................................................. 72


Reference manual • 5

Common technical characteristics ................................................................... 74Task scheduling.............................................................................................. 75

Refining the operations process 81Manipulation................................................................................................................ 81

Updating ........................................................................................................ 81Technical locking of objects............................................................................ 81

Version management.................................................................................................... 82Uprocs............................................................................................................ 82Sessions.......................................................................................................... 82

Changing environment ................................................................................................. 82Transfer to an area .......................................................................................... 82Distribution to management units.................................................................... 83Importing and exporting data .......................................................................... 84Functional locking of objects .......................................................................... 84Distribution logging........................................................................................ 85

Simulation of scheduled tasks....................................................................................... 85Objectives ...................................................................................................... 86Workload forecasting...................................................................................... 86

Workload simulation .................................................................................................... 87Objectives ...................................................................................................... 87Simulation of forecast workloads .................................................................... 87

The operations process 89Role of the batch engine ............................................................................................... 89

The automation process .................................................................................. 89Components of the batch engine ..................................................................... 90Location of the batch engine ........................................................................... 90Submission across the network ....................................................................... 90Execution phases of a task .............................................................................. 91

Job scheduling ............................................................................................................. 91Operation of the calculator.............................................................................. 91Impact of modifying a task ............................................................................. 92Enabling - disabling of a task .......................................................................... 92

Sequencing and launching ............................................................................................ 92The launcher................................................................................................... 92The launch...................................................................................................... 93Operations on launches ................................................................................... 94Condition checking......................................................................................... 96Uproc submission ........................................................................................... 99Job completion ............................................................................................. 100

Inter-machine communications................................................................................... 101Role of the exchanger ................................................................................... 101Operating principles ..................................................................................... 101

System failures........................................................................................................... 102

The operations monitoring 103Job monitoring ........................................................................................................... 103

Purpose ........................................................................................................ 103Central monitoring........................................................................................ 103Job status...................................................................................................... 104Diagnostics................................................................................................... 105Authorised interventions............................................................................... 105Management of job queues............................................................................ 106


6 • Reference manual

History files and statistics........................................................................................... 107Execution history.......................................................................................... 107Statistics....................................................................................................... 108

Purging ...................................................................................................................... 108Operating events file..................................................................................... 108Job monitoring ............................................................................................. 108History files.................................................................................................. 109Log files ....................................................................................................... 109

Glossary 111

Index 115

ORSYP Addresses 123


Reference manual Introduction • 7

Introduction

Functional objectivesDOLLAR UNIVERSE is designed to meet several objectives, the main ones being to reduce the constraintsweighing upon the technical organisation in charge of managing computer operations, and the quest foroptimum reliability in the operations cycle. As a means towards these objectives, DOLLAR UNIVERSEoffers :

q Functions covering the essential part of the central operations process, through which it allows, at anygiven time, precise supervision and overall control of operations coherence,

q Automation of all batch operations, removing the need for human presence during the daily execution ofthe operations cycle and allowing automatic management of recovery processing sequences whenincidents are encountered,

q A structured applications environment adaptable to the norms and standards of each site,

q Increased stability and flexibility of the operations process regarding changes in both the physicalconfiguration and the applications environment. The possibilities offered by DOLLAR UNIVERSEreduce the number and scope of maintenance operations and increase the resulting quality of theoperations process.

The following figure illustrates chronologically the main stages in the life cycle of a computer application.

Remotedistribution

Proceduresmanagement

Implementation

Batchscheduling

Batchsubmission

Operationsmonitoring

Outputmanagement

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 abovefigure. The remote distribution and output management functions represent two modules that are independentfrom the automation module discussed in this reference manual.


8 • Introduction Reference manual

Scheduling and sequencingBatch procedures are scheduled using a series of calendars; these are generated semi-automatically, one foreach 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 specificadvantages, 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" managedindividually 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 ofanother.

Batch queuesDOLLAR UNIVERSE exploits, insofar as possible, 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 beprovided by an additional DOLLAR UNIVERSE product: DQM (distributed queue management).

This module provides a technical organisation of the production process, above and beyond the functionalorganisation provided by DOLLAR UNIVERSE, while dissociating the management of associated constraints.

Job monitoringDOLLAR UNIVERSE proposes a group of functions that allow dynamic tracking and intervention in theoperations process.

Built around a screen displaying current processes, the job monitoring function itself represents a veritablework station, allowing the operator to monitor all his jobs without ever losing sight of the overall operationsscenario.

OverviewDOLLAR UNIVERSE aims to offer users a global automation solution, irrespective of the type of operationsbeing undertaken.

Within DOLLAR UNIVERSE, two essential notions can be distinguished:

q The company,

q The management unit.

The notion of company means that, in a given computing environment, a single copy of DOLLARUNIVERSE can manage the operations of several distinct companies independently.

Thanks to its access control functions and its technical architecture, DOLLAR UNIVERSE allows totallyhermetic separation of their operations.

Within the company, DOLLAR UNIVERSE can handle distinct environments where several differentoperations scenarios will be run in parallel, as might be the case with a company using the same applicationson different data. These environments are called management units.

DOLLAR UNIVERSE can manage several thousand management units.



Job description

Elementary job descriptionThe description of a job rests essentially on identification of the procedure (DCL, CL, shell… ), definition ofits technical characteristics, and the conditions required for its execution.

DOLLAR UNIVERSE distinguishes three main types of conditions:

q Sequence conditions, representing the dependence of one job on another,

q Conditions of mutual non-simultaneity of jobs,

q Conditions of resource availability.

For each of these conditions, DOLLAR UNIVERSE allows the associating of criteria such as:

q A user submission account,

q A functional date (date for which the job was run),

q The awaited status,

q The management unit or group of management units for which the job ran.

These conditions (up to 99 for a given procedure) can be combined in an expression associating the constraintsusing the logical operators: and, or, =, not =, ( and ).

The use of free syntax in this expression, and the rich parameter-setting possibilities, means that the functionallogic governing execution of the various jobs can be precisely transcribed. This makes it easy to run normalprocessing scenarios (i.e. Sequences respecting the normal processing path), as well as incident situations(degraded processing paths or recovery).

Description of a job streamFrom a more macroscopic viewpoint, DOLLAR UNIVERSE offers the notion of "job stream", referred to as asession, for procedures presenting homogeneous operations constraints (same scheduling conditions, forexample).

The session allows jobs to be ordered in a tree structure, whereby each job is told which jobs follow it in bothnormal and abnormal operating circumstances. The sequences so-defined within a session do not substitute forthe dependencies defined at the individual job level, but rather supplement them.

It is therefore possible to define (see "Elementary job description") the associated functional conditions foreach job and, via the session, superimpose on these the execution sequence required by the operator. In sodoing operations imperatives (time constraints, optimisation of resource consumption etc.) Can be integratedwithout altering the expression of the functional conditions.

Thanks to these job description features, DOLLAR UNIVERSE:

q Facilitates maintenance of operations processes,

q Assists with and simplifies the implementation of degraded processing paths or recovery, in event of errorconditions.

Such features thereby contribute to the quality of operations, and make change management easier.

SchedulingScheduling applies indifferently to individual jobs or sessions (groups of jobs).

It rests on prior definition of the following objects:

q A series of time reference bases created using civil calendars,



q A series of execution frequencies called scheduling rules, either predefined or definable, depending onrequirements.

CalendarsEach management unit may have its own calendar.

Functions for automatically generating calendars are proposed as follows:

q For a maximum period of 25 years,

q With automatic positioning of parametered work days (option),

q With automatic positioning of standard holidays (option).

In addition to this generation function, the status (workday, closing day, holiday) of any day in a calendar canalways be modified.

The work involved with calendar definition or maintenance is practically zero.

Scheduling rulesThe 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:

q A base cycle, that is, a number of days, weeks or months,

q A base cycle start date,

q A number of days from the start or before the end of the base cycle,

q The list of days of the week authorised for execution,

q An offset direction from the execution date, whereby, if the date obtained by applying the rule to thecalendar is not a workday, this date will be shifted to the first workday preceding or following the targeteddate.

A scheduling rule can translate execution frequencies of the type:

q Every working day,

q The first working Tuesday in each month,

q Every 87 days etc.

Job schedulingDOLLAR UNIVERSE proposes two main scheduling methods, which can be used together if required, forhandling recurrent and/or random runs:

Implicit scheduling of the analysis of the execution cycle of the job in question, consists in:

q Associating from one to seven scheduling rules, to obtain the desired final schedule,

q Defining the job execution time (such as a particular time for a particular day of the week, or up to 150launches per day, etc.), And a waiting period for the conditions to be met. After this interval, theexecution will be abandoned or forced (option),

q Defining up to 52 exclusion dates.

Explicit scheduling consists in listing the dates and launch windows (up to 26 dates), one by one.

In the field of scheduling, DOLLAR UNIVERSE provides a natural solution capable of meeting the majorityof foreseeable cases. By offering combined features such as: automatic generation of calendars; the possibilityof 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, whilepreserving the user's freedom of intervention.

Job sequencing and launchingDOLLAR UNIVERSE provides dynamic sequencing and launch control for each job, based on acyclicalprocesses that react in accordance with events detected in real time (date/time, end or start of job, changeresource availability, updating of operations parameters etc.).

It uses no permanent, predefined plan, but rather interprets, in accordance with the actual operations eventsoccurring (and any interventions by the operators) all descriptive information concerning the various jobs, andtheir associated scheduling data.

Thanks to this fully interactive approach, DOLLAR UNIVERSE means:

q Very high performance (minimal resource consumption due to the absence of a cyclical process, and"just-in-time" job submissions),

q Exceptional flexibility and reactivity,

q Genuine user comfort, since the operator retains all freedom for real-time interventions

Operations monitoringDOLLAR UNIVERSE affords particular attention to the tracking and supervision of operations with the soleaim of facilitating job monitoring, accelerating the identification and diagnosis of incidents, and permitting thenecessary recovery procedures. There is a dedicated job monitoring function.

Organised 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 fineselection criteria, allowing the operators to focus on the most strategic jobs.

All essential data is directly accessible from the job monitor:

q The history trace formatted by DOLLAR UNIVERSE, recording the steps performed by the job and, inthe case of jobs in an event wait state, the expected events. The history trace can contain comments oroperator instructions transmitted from the command interpreter via a specific DOLLAR UNIVERSEcommand,

q The job execution log,

q The following launch window of all scheduled jobs,

As well as the main functions for intervening in the operations process:

q Recovery after incident,

q Interactive launching of unscheduled jobs,

q Updating of operations events.

The job monitor provides the operator with a single point from which to make all necessary interventions onthe current operations process.

Execution statisticsFor each job run, DOLLAR UNIVERSE memorises the consumption of essential resources (CPU, direct andbuffered I/O, memory, 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 ofestimated values for new jobs that have never run).

SimulationDOLLAR UNIVERSE offers several simulation functions, notably :

q Simulation of a single job schedule,

q Simulated execution of a projected workload.

Simulate a scheduleThe interactive task scheduling function enables the simulation of a given task, using a reference calendar,over a selected period of time.

Simulate workloadUsing all available data, DOLLAR UNIVERSE can format an operations schedule, for a given duration andstarting at any date (even in the past).

Execution of this schedule can be simulated interactively. This function allows:

q Displaying the sequence of operations,

q Positioning the precise instant at which execution of each job will start in time, and determining theestimated duration (use of statistical information),

q Modifying the end of job status (by default, "ok"), in order to display the degraded-processing or recoverypath.

Along with the history traces formatted by DOLLAR UNIVERSE, and the job logs, all this data leads to anoverall vision of the behaviour of operations jobs. All the necessary tools are provided to promote rapid andcomplete analysis of job behaviour and performance levels.

Security of operationsSecurity of operations is one of the guiding factors behind the design and development of DOLLARUNIVERSE.

It will be approached under three distinct headings:

q Security through managed implementation of job parameters,

q Security through control of access to DOLLAR UNIVERSE functions,

q Security through the technical architecture of DOLLAR UNIVERSE.

Implementing applicationsFor each company, DOLLAR UNIVERSE manages four areas which, for no significant increase in workload,admits 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 technicalor functional cycle. As a standard feature, DOLLAR UNIVERSE offers an interactive function allowingparameter settings to be debugged in one area, then moved by transfer to another area (transfer from theintegration area to the simulation area, for example).



Each interactive transfer of DOLLAR UNIVERSE objects is logged, an operation which essentiallymemorises:

q The job in question,

q The operator,

q The source and target areas,

q 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 thedevelopment 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 actualparameter setting.

Access controlBefore any connection takes place, each user must be identified by DOLLAR UNIVERSE principally to allowthe allocation of a user profile.

For each user profile, it is possible to customise strict rights of use of DOLLAR UNIVERSE. Access to eachtransaction and, within each transaction, the use of each option or function key may be individually authorisedor inhibited.

The resulting access control, coupled with menu definition functions (modifying the order of presentation oftransactions in relation to the standard DOLLAR UNIVERSE menus) allows the functional scope ofDOLLAR UNIVERSE to be tailored to individual needs.

In addition, the secure dissemination of information of general interest (such as giving read-only access to thejob monitor to certain developers or users, for example) facilitates communications between the data-centerpersonnel and the other actors in the process.

ArchitectureSeveral aspects of DOLLAR UNIVERSE's architecture contribute to more secure operations.

The content of each user/DOLLAR UNIVERSE exchange is memorised. So, whatever the circumstances(system crash, for example), on his following connection to DOLLAR UNIVERSE, the user will take up thedialogue at the same point. This approach is used to ensure that all tasks performed during operationalparameter settings always complete correctly.

In identical circumstances (system crash) the basic processes are designed never to lose track of running jobs(provided the operating system itself never does).

Finally, to avoid altering the performances of one area due to overloading of another, for example, there areseparate permanent processes for each active area.

The design and nature of DOLLAR UNIVERSE functions combine to facilitate methodical operationsmanagement within strictly delimited environments. Thanks to the customisation options, it is possible to offereach user a tool precisely tailored to his individual tasks.

Such factors, combined with a structured and rigorous technical architecture, bring greater clarity to theoverall operations process, while increasing the degree of operator control.

Distributed client-server operationsDOLLAR UNIVERSE uses standard protocols, such as DECNET, APPC and TCP/IP to provide client-servercommunications between the different DOLLAR UNIVERSE modules on a network.



Interoperability between DECNET and TCP/IP networks is available in DOLLAR UNIVERSE version 4.2and later.

DOLLAR UNIVERSE enables automation of job sequences spread across several machines, monitoring andcondition checks from a central point, increased reliability, and optimisation of multi-site operationsprocesses.

Distributed operationsThe management unit is DOLLAR UNIVERSE's major contribution to the management of distributedoperations.

A management unit can reside at any node on the network, provided the node is identified in the descriptiveinformation of the management unit.

In addition, DOLLAR UNIVERSE qualifies management units through notions such as:

q Management unit type (factory, depot, sales office, country) differentiating each management unit by itsessential criterion in relation to the operations process,

q 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 ableto interpret expressions of the type:

q Management units of type x,

q Management units dependent on the current management unit,

q Management units of type x dependent on the current management unit.

Each DOLLAR UNIVERSE function can be set up according to the logical operational organisation. Only atthe time of submission does DOLLAR UNIVERSE translate the logical references into the physical reality ofthe network using the descriptive data of the management units.

In this way, DOLLAR UNIVERSE allows the description of flexible processes able to adapt to configurationchanges.

Imagining an operations process that consists in running a job for all the sales offices within a company, mostof the changes can be implemented without modifying the basic operations parameter settings. For example:

q To add a new sales office: create a new management unit with the type "sales office". The session withinwhich the submission is executed remains unchanged (job "a" submits job "b" for all sales offices),

q 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 memorised in a database; DOLLAR UNIVERSE provides the necessarytools for remote distribution to all nodes in question.

Co-operative management of distributed operationsThe expression of conditions in the job descriptions can use logical expressions targeting the managementunits.

In this way, it becomes possible to synchronise 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 oftype z".

In this case without needing to dispatch applications pseudo-files, DOLLAR UNIVERSE implements trulyco-operative multi-machine management. It issues requests towards the nodes of residence of managementunits of the type in question, to determine if the condition is actually met. As soon as the expected eventoccurs, the requesting machine will be automatically informed.



These functions are event-driven (the request is not issued cyclically). They are implemented in a specificcommunication function that guarantees the security of transmissions and the reception of requests, even inthe event of a temporary break in the network.

Central monitoringFor each management unit, DOLLAR UNIVERSE defines whether the management unit in question ismanaged locally or centrally ; the latter case implies the definition of a central monitor node corresponding tothis management unit.

To limit the load on the network, and ensure processing of only that data which is strictly required foroperations 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 thenode defined as central monitoring node. The operations monitoring function allows the dynamic display notonly of the jobs in the local management units, but also the essential jobs in the centrally monitored remotemanagement units.

Monitoring of distributed operations can be extended to include definition of the operations parameters for theremote sites.

To this end, DOLLAR UNIVERSE includes the notion of a parameter template, known as a model. A modelis 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 asingle node.

It should also be noted that all DOLLAR UNIVERSE transactions boast interactive functions which allow theparameter settings of another node to be displayed, without logging in to the node in question.

Remote parameter distributionIn the same way as the transfer between areas, each element of the DOLLAR UNIVERSE operationsparameters can be interactively distributed to all management units in the architecture.

Each distribution operation is logged, providing a history base, which also can be consulted interactively.

DOLLAR UNIVERSE offers the potential to process all forms of local or distributed operations, with local orcentralised management. In this respect, DOLLAR UNIVERSE affords significant advantages when migratingfrom 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.

InterfacesTo allow access to its various functions, DOLLAR UNIVERSE provides the following interfaces:

q Graphical interface (X/MOTIF, Windows),

q Character-mode interface (UAM screen administrator developed by ORSYP),

q Applications programming interface (API),

q Command mode interface.

Furthermore, DOLLAR UNIVERSE proposes standard interfaces to external functions such as:

q Alarm management,

q Transactional monitors,

q Backup packages,



q Remote distribution packages...

Sequence of operationsAutomation of operations with DOLLAR UNIVERSE is implemented step by step as described below. Eachstage is then detailed in the following chapters of this reference manual.

AdministrationThe administration enables the description of the working environment. It makes full use of the differentconcepts for structuring the environment:

q The company,

q The physical architecture supporting the applications with nodes,

q The logical architecture with management units,

q Applications and domains which determine the definition of procedures,

q Declaration of the applications environment (if necessary) by designation of program and data directories,

q Declaration of users and their DOLLAR UNIVERSE access profiles.

Scheduling jobsJobs are scheduled in three main stages designed to:

q Describe the procedures to be automated (Uprocs), including their executing conditions,

q Group the Uprocs into processing streams (sessions),

q Associate these procedures (or streams) with operations environments (management units) to formoperations tasks that can be triggered indifferently by the user or automatically by DOLLAR UNIVERSEdepending on predefined rules and calendars.

Defining UprocsEach applications procedure can be declared within DOLLAR UNIVERSE using the Uproc definition facility.A Uproc contains the application procedure to be automated, its variables as well as each of its pre-requisitesto execution. The Uproc is a developer's tool.

Defining sessionsUprocs combined in a single processing stream (session) benefit from the same schedule and may share thesame execution environment (management unit).

The session also enables the definition of a normal processing path for the job stream with fall over to an"error" path in the case of an abnormal end of job. This means that degraded processing paths can be managedautomatically.

The job sequence in a session must not be confused with the Uprocs own execution conditions, whichrepresent the applications element. The session is an operator's tool.

Defining tasksThe operations task defines, for a given execution environment (management unit), and for each procedure (orset of procedures) :

q The technical execution characteristics,



q Time-related information required to enable automatic submission by DOLLAR UNIVERSE,

Automatic submission is performed by the allocation of scheduling rules or by determination of explicitsubmission dates.

It is supplemented by the possibility of determining a submission timetable which may vary with the day ofthe week.

Finally, the task is applied to the calendar associated with each execution environment (management unit).

Defining calendarsThe notion of calendar accommodates differences in the organisation of work between one management unitand another (such as workdays, closing days or holidays), while maintaining homogeneous parameter settingsfor all management units. Thus, the calendar enables the processing schedule to be generated, but does notdefine it.

Defining rulesIn addition to the standard rules corresponding to the most common requirements, DOLLAR UNIVERSEproposes sophisticated algorithms allowing the customer to build his own rules, and so satisfy any desiredperiodicity.

Operations controlScheduled or initiated processing events can be monitored in real time. The event trace and any otherinterventions are memorised in a complete set of history files.

Job monitoringThe job monitor makes it easy to track job processing and allows rapid diagnosis of all current operations.

From a single monitoring station, it is possible to launch jobs, perform recovery, modify a launch window, orstop running jobs.

Access to history filesHistory files provide a track of operations executed and their status, as well as any interventions performed onthe expected launches (recovery etc.), Or distribution of objects (Uprocs, sessions etc.) to the application'smanagement units.


Reference manual Environmental concepts • 19

Environmental concepts

Introduction

Environmental concepts featuresThe functions concerning the declaration of the environment and general administration of DOLLARUNIVERSE, presented in this section, lay the foundations enabling any automation project to be structured,organised and properly prepared.

Since they play a fundamental role regarding the operations process which will be defined later, they are ofparticular interest to those responsible for the administration of DOLLAR UNIVERSE.

The "Environmental Concepts" chapter, after a rapid presentation of the proposed general architecture,describes each of the concepts making up the architecture, specifying:

q their role in the structuring of the environment, and their mode of administration,

q their role in the automation of operations, as well as relevant information of a functional nature.

The "Applications" chapter introduces the kind of administration associated with the applications, anindispensable preliminary for automating applications procedures.

It also introduces the administration of tables, allowing declaration of the applications environment, and use ofthis same declaration for the internal requirements of DOLLAR UNIVERSE.

The "Users" chapter introduces the different interpretations of "user" within DOLLAR UNIVERSE, defining:

q how they are managed,

q the access rights to the various transactions of DOLLAR UNIVERSE.

PresentationDOLLAR UNIVERSE manages several concepts meant to lend logical structure to the working environment.

The environment may be organised into independent domains which is proved desirable, in many productioncentres, in order to preserve the confidentiality and integrity of the data managed.

Three main organisational levels of data can be distinguished.

q Companies,

q Areas,

q Management units (MU).


20 • Environmental concepts Reference manual

The above concepts are illustrated in the following figure:

Company ACompany B

MU1 MU2 MU3

Application area

Intégration areaSimulation area

Production area

The environmental concepts of DOLLAR UNIVERSE

The company represents the highest level in the concept of environment. Each company corresponds to a newinstallation of the product. It is possible to install a given company on several nodes, or several companies ona 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, production).

Areas are also sealed operations environments which benefit, within a given company, from interactivetransfer 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 logicallayout depending on the different environment concepts proposed.

COMPANY§ Executables and configuration utilities§ Administration and authorization files§ Specific files not managed by area

Applicationarea

§ uprocs§ data§ logs

Integrationarea


Simulationarea


Productionarea


Development universe Production universe

Objects logical layout depending on environment concepts

The notions of area are not managed on an individual basis. The DOLLAR UNIVERSE tables will only beable to differentiate via the definition of the access paths to applications' objects and to data specific to eachmanagement unit.

Finally, the entire logical environment is independent of the physical organisation of the computer systemsand, consequently, exists on each node (machine) in the network.

Moreover, since the co-operative architecture of DOLLAR UNIVERSE imposes no particular constraints onthe organisation of the operators responsible for administering and monitoring operations (that is, no notionsof "master" or "slave"), it is through the nodes themselves that the individual organisation of each context canbe translated.



CompaniesThe division of the environment into companies influences the organisation of the DOLLAR UNIVERSEtables. Tables defining companies and user accounts are unique for a given node, since DOLLAR UNIVERSErequires a single point of entry.

On the other hand, each company represents a complete sub-system, described by its own set of tables(management units, management-unit dependencies, applications). In this respect, a given node will have asmany sets of these specific tables as there are companies defined.

DefinitionThe company is the highest level managed by DOLLAR UNIVERSE. At least one company must be definedat the time of installation of DOLLAR UNIVERSE. In many cases it will be the only company in a givenconfiguration, but all other notions defined in DOLLAR UNIVERSE will take it as their reference.

This concept ensures, during the use of computer assets, strict partitioning of data and technical tools. Itensures the hermetic structure required by the presence of several independent, possibly competing companies(in the judicial sense of the term) on a single computer system.

Independence of companiesSetting up companies (see administration manual for how to configure of multi-company installations)consists in creating totally separate environments (except for the company and user tables).

Companies have their own specific tools (batch motor per company, for example), which feature in clearlyindependent operations. In the case where such a strict dissociation is not necessary, the notion ofmanagement unit will allow the running of parallel operations.

If several companies share a computer system, the various DOLLAR UNIVERSE functions will be able towork in the same way for each company, without any interference in individual operations or sharing oftechnical data. For example, DOLLAR UNIVERSE will manage each company's descriptive environmenttables in totally independent files.

For each listed company, DOLLAR UNIVERSE recognises the computer system sub-assembly (or the entiresystem) which it is allowed to access.

Additional characteristics of companiesEach company authorises the declaration of information of general interest such as:

q The type of editor used

Depending on the operating system in question (except UNIX and Windows), this information allowsdefining of an editor which will be used for all DOLLAR UNIVERSE functions needing to accessoperating system files (command files and log files, mainly).

q Locking of objects

This information allows defining whether, during transfer and distribution operations, reference objects(essentially Uprocs and sessions) need to be accessible or not for modification. (refer to the chapterentitled "refining the operations process" for more information regarding the operating principles of thisfunction).

q 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 ofmaster node, and the related operating precautions.

q Company directory

This information declares the physical location (directory name) of a company's various files (companyspecific tables, scheduling rules, authorisation files etc.) For the node in question.

Note: there is a dual definition for this directory, in order to ensure compatibility with previous versions ofDOLLAR UNIVERSE, which recognised a company's file locations in terms of universes (groups of pairedareas); it therefore requires the same declaration in the two directories proposed for a given company. Since agiven company can be installed differently on each node, it is wise to avoid distributing this table.

AreasIn order to allow gradual testing of applications under development or maintenance in conditions that simulateproduction conditions as closely as possible, DOLLAR UNIVERSE offers four working environments knownas "areas":

q Application area,

q Integration area,

q Simulation area,

q Production area.

The application and integration areas are environments dedicated to the development of operationsprocedures. The simulation and production areas are reserved for computer production proper.

In this respect, for certain areas, DOLLAR UNIVERSE manages different versions of the main objects (referto chapter entitled "refining the operations process" for more information regarding management by version).

The same DOLLAR UNIVERSE transactions are available in all areas. Within each main function, a softwaregateway is available which makes it possible to switch areas, as well as options for transferring objects fromone area to another.

The types of objects managed at the area level are the following:

q Parameters: Uprocs, sessions, calendars, tasks,

q Monitoring: launches, events, history files etc.

The following are managed at the company rather than the area level:

q Administration: all tables,

q Parameters: rules, resources, incompatibility classes.

Management units

DefinitionThe management unit represents a logical working environment. It is present throughout all DOLLARUNIVERSE functions, where it plays a key role.

Each management unit systematically points to a node, so that the mere fact of allocating a procedure to amanagement unit is sufficient to designate the physical environment in which the job in question will be run.In this context, the notion of node becomes transparent in the daily use of DOLLAR UNIVERSE functions, infavour of the notion of management unit. A configuration, be it centralised or distributed, is seen as a singlemachine on which resides a set of management units.



Main features of a management unit:

q For a given physical environment, facilitates the coexistence of parallel processing of identicalapplications respecting different operating constraints;

q Forms the central element in the notion of distributed data-processing. The MU Allows the simulation ofa distributed data processing architecture on a centralised architecture. Because of this, its presencefacilitates changes of architecture for computer solutions (centralised architecture to distributedarchitecture or vice versa), and renders operations methods insensitive to such changes;

q Cannot be defined on several nodes. Nevertheless, a node can support several MU.

UseIn addition to the above mentioned possibilities, the following elements would tend to confirm the efficiencyof the management unit concept.

Computer operations require a permanent dual perspective regarding a company's data processingorganisation:

q On the one hand, the logical view as seen in the applications,

q 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 themanagement units, delaying the translation of logical parameters into physical data until final execution of thedata processes. This interpretation is made dynamically, acting on the descriptive information of themanagement units contained in the central tables of DOLLAR UNIVERSE. This flexibility gives operationsprocesses unequalled stability, thus optimum reliability.

The following example illustrates these features.

Processing streams can apply to several management units: take, for example, the consolidation of commercialstatistics 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 fileslocalised in each of the office environments in question, a change in the organisation of the offices (such asprogressive increase in workload on an application, or switching of an office to a new machine etc.), Couldhave problematic repercussions.

In most cases, procedures will have to be modified to take account of the new context. However, DOLLARUNIVERSE avoids possibly repetitious maintenance operations on the existing processes. The onlyintervention required will consist in updating a central table designed to create a new management unit ormodify the technical characteristics of an existing management unit.

To offer a complete solution, DOLLAR UNIVERSE makes it possible to define hierarchical relationshipsbetween management units. These relationships could be established, for example, between a regional officeand every sales office. This type of relationship is known in DOLLAR UNIVERSE as "hierarchical dataprocessing", or HDP

Management units and areasManagement 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 fromdevelopment up to the implementation phase.



Management unit typesManagement units may be grouped into types ("factory" type, "office" type etc.). The advantage of this type ofclassification is that objects (sales offices, for example), can be identified without having to be namedindividually. This generic addressing feature can be used :

q In job triggering commands within a processing stream,

q In defining conditions (sequence, , non-simultaneity, file presence etc.),

q In formatting specific DOLLAR UNIVERSE commands,

q 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 theroot of hierarchical data processing. It is an integral part of the management unit code, which it functionallycharacterises.

A management unit is coded as follows:

q First character: represents the MU type; this is the character used for HDP Management;

q 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-interestfunctions.

Note : it may be useful to reserve a particular type ("N", for example) to designate management units present in asingle version at a given node. The presence of these management units and a dedicated management unit typewill facilitate the distribution of tables and other objects existing in a single version on a given node, irrespective ofeither the number of management units or areas present (for example, Uprocs or sessions). In this way, defining amanagement unit target to facilitate distributions for these types of objects would thus be limited to "N" (meaning"all management units of type "N"").

Hierarchical data processing

DefinitionHierarchical relationships between management units may be defined, under a technique known as"hierarchical data processing" or HDP using an HDP-specific symbolism, processing streams can be describedwithout prejudging the name(s) or the quantity of management units in question. This guarantees the stabilityof the parameters for operations undertaken within DOLLAR UNIVERSE, irrespective of any changes to thehardware configuration used (creation or concentration of sites), or the data organisation (creation orsuppression of sales offices, for example).

ConventionThese 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 maybe given:

q {XY} designates "all type 'X' MU dependent on the type 'Y' MU on which the current MU depends",

q {X } designates "all type 'X' MU dependent on the current MU",

q { Y} means "all MU of type 'Y' on which depend the MU Where the expression took place",

q { } designates the current MU.

These generic expressions can be used to:

q Express conditions pre-requisite to running a procedure,



q Trigger procedures from within another procedure.

They enable the correlation between execution of a Uproc on a management unit, and the execution of aUproc on a sub-set of management-units. The generic expression is interpreted dynamically. Conditions usingthese expressions automatically take account of creation, deletion or modification of management units.

Assuming a management unit hierarchy as follows:

The different conventions are implemented as follows:

q {XY}

This convention allows a "son" to see all "cousins":

A02 "sees" X11 and X12

A01 "sees" X01, X02, X11 and X12

q {X }

This convention allows a "father" to see all "sons" (but not "nephews"):

Y01 "sees" X01 and X02

Y02 "sees" X11 and X12

q { Y}

This convention allows a "son" to see his "father"

X01 "sees" "Y01"

A02 "sees" Y02

A01 "sees" Y01 et Y02

Implementation of management unitsTo help in understanding this logical representation of the environment, and demonstrate the power of themanagement unit concept, certain operating examples are given below.



The following examples are provided only to demonstrate the extent of possibilities uses of the managementunit concept. Furthermore, the MU will be systematically used as soon as any replication of operations iscalled for.

In the case of a manufacturing companyAssuming a company built around a sales organisation comprising regional offices under the control of a headoffice, with the regional offices themselves controlling factories and sales offices.

The immediate definition of management units for this organisation would consist in creating as many MU asthere 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. Thissimilitude may be translated by attributing a common MU Type to the corresponding management units.

The following management units could be created:

q Head office: C01,

q Regional offices: R01 and R06,

q Factories : U07, U16 and U34

q Offices : A01, A02, A11, A12 and A13.

Certain types of processing, such as consolidations, for example, can be used to highlight the functionaldependency between these entities.

Consolidation of daily production information is done directly by head office, while sales statistics are initiallyaggregated at the regional level then at central level. The following diagram gives an example of suchfunctional dependency:

Functional links between MU

This functional dependency can be translated into straight relationships of dependency between themanagement units. The latter are thus organised in a form of network.

Depending on the availability of the hardware assets, this network can be supported by a greater or lessernumber of nodes, as illustrated below:



Distribution of MU dependencies within physical configuration

It should be borne in mind that all processes are described from the management unit dependencies , theindividual MU remains independent of the physical configuration.

Example 1 : distribution of the "sales statistics" application to offices, or how to usethe MU Type in the distribution process

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

In parallel with distribution of the application, procedures defined within DOLLAR UNIVERSE will bedistributed to all management units of type 'A'.

The offices affected by this distribution are: A01, A02, A11, A12, A13.

Thanks to this generic process, no office will be left out, and DOLLAR UNIVERSE will automatically ensuredistribution to the sites in question.

Example 2 : setting off office jobs after decision by the region, or how to use {X }convention in a triggering process

Following distribution of the sales statistics application and automated procedures within DOLLARUNIVERSE, 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 officesof the region in question.

By this hierarchical method, when the "Regional_ok" is given for one of the regions, the statistics job will beprovoked 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 ortheir links with such or such a region.

Example 3 : synchronising statistics jobs with stock updates, or how to use the {XY}convention in a synchronisation process

The statistics job, mentioned in the previous example, can run only if the daily stock update has beenprocessed on each factory(MU type = U) of the same region.

In which case the statistics job will carry a sequence condition to translate this synchronisation.

This condition, using the HDP Convention "{UR}", means that the statistics job will wait until stock updateprocessing has been correctly performed on all the factories dependent on the region to which that officebelongs.

For example, in order for the statistics job to run on office A02, the stock process must have run correctly forfactories U07 and U16. The same naturally applies for offices A01 and A11.



Synchronisation of the resulting operations remains independent of the region of execution, the number offactories their links to such and such a region.

Example 4 : synchronising the statistics jobs with the logical stock situation, or howto use the { Y} convention within a synchronisation process

The same statistics job, presented above, will also run only if each sales office of the region has declared theday's undelivered orders, this obviously influences the real state of inventory.

It will therefore carry a sequence condition to translate this synchronisation.

The condition, using the HDP Convention "{ R}", means the statistics job will wait until order entryprocessing 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 foroffices A01, A02 and A11. The same naturally applies for offices A01 and A11

Synchronisation of the resulting operations remains independent of the region of execution, or the number ofoffices.

Example 5 : synchronisation of the statistics job with price-book processing, or howto reverse dependencies in a synchronisation process

Finally, the statistics job presented above will run only if the product price book has been delivered by thehead office to each region (bearing in mind that the said price book may differ for each region).

It therefore carries a sequence condition whereby the price book processing (retrieval of price book filesgenerated at the central site) must have completed successfully for the region to which the office in questionbelongs.

This condition, using the HDP Convention "{R }", means the statistics job will wait until the price bookprocessing 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 definedpreviously), 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 havecompleted correctly for region R01.

Synchronisation of the resulting operations remains independent of the region of execution.

Documentation generating applicationThis example concerns a batch application designed to generate multi-lingual documentation for various typesof high-tech equipment.



This application brings together a number of procedures using parameters to indicate the type of equipment inquestion 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 theequipment type/language combination.

This arrangement limits the number of processes to be defined in DOLLAR UNIVERSE, since themanagement units do much replacement (a given operation will run as many times as there are managementunits). The management unit is interpreted at the moment the procedure is executed; the management unitcode 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 differentmanagement units defined, to translate the need for synchronisation of the various procedures in question.

A permutation processing applicationThis example considers a batch application designed to receive a very large number of files from variousclients (such as mail orders, for example).

The application requires special technical optimisation of the disk resources consumed. Considering the greatnumber of files received each day, the aim is to distribute these to each disk of the receiving machine in orderto 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 asthere are disks.

In this example, management units will be used to declare each of these disks and have the procedures run asmany times as there are management units of the "disk" type.

Use of MU to represent technical objects

Apart from reducing the number of objects needing to be defined within DOLLAR UNIVERSE, thisrepresentation has the advantage of not requiring any special parameters to be set when the increasing quantityof data received makes it necessary to add a new disk to the configuration.

Nodes

DefinitionDOLLAR UNIVERSE is designed to automate distributed operations it lends itself naturally to cluster andnetwork architectures.

The node in the DOLLAR UNIVERSE sense has the same meaning as in the computing sense, designating amachine in a network.

As mentioned previously, the notion of node is in fact hidden (in DOLLAR UNIVERSE parameters) behindthe management unit to provide the greatest degree of flexibility in the operations process.

The node then only serves as an object for DOLLAR UNIVERSE to recognise for translating the organisationof human resources (administration and operations monitoring), and for authorising the previously describedenvironments (areas).



Furthermore, in order to guarantee the interoperability of the solution, DOLLAR UNIVERSE proposes, for allversions operating with TCP/IP, the possibly of designating nodes logically; a table provides thecorrespondence between the logical node used by DOLLAR UNIVERSE, and the name of the physicalmachine as recognised by TCPI/IP (see the administration manual for more information regardingadministration of this table)

Central or local administration

Master nodeEven if DOLLAR UNIVERSE benefits from a co-operative architecture and authorises at the same time eitherlocal or central administration, it nevertheless allows management of its administration tables to be limited toa single focal point thanks to the notion of master node.

This arrangement is in many cases desirable on account of the importance of the information contained inthese administration' tables (description of the physical and logical environments).

Each node therefore recognises a master node, which during installation of the company is defined as beingthe node itself thereby authorising it to modify its own administration tables.

If the companies table points to a master node different from the current node, local update of theadministration tables will be impossible. They will have to be updated from another node, and thendistributed.

Note: the notion of master node is independent of the notion of central monitoring node.

The following diagram illustrates the notion of master node;

ADMINISTRATIONcompany tableMaster = Node1

Node1


Node2

Distribution

Update Consultation


Node3

Use of the master node

Note: as indicated in the above diagram, the notion of master node serves only to prevent local modification ofthe administration tables, and in no case indicates any dependency in terms of management of the platform forexample, node 2 recognises node 1 as its master node but can in all cases he supplied (by distribution) fromanother node.

Central monitoringDOLLAR UNIVERSE allows operations to be distributed over any number of nodes; because of this it alsoproposes central monitoring of certain of its 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 logicalvariable - Available on VMS, Windows and UNIX only) to upload to the central node only that informationnecessary for overall operations monitoring.

One node definition option allows it to be declared as the central node for operations monitoring.

So for each node, provided table updates are authorised (see notion of Master node), which is the case wheninstalling DOLLAR UNIVERSE, it is possible to declare a central monitor node which will receive traces ofexecution 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 asingle 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 masternode.


node tableCentral M. = Node2

Node1



Node2

Node tabledistribution



Node3



Node8

Illustration of the notions of master node and central monitor node

Additional characteristics of the node

Authorisation by areaAuthorisation 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 developmentenvironment for the operations processes to a single development node, and distribute DOLLAR UNIVERSEobjects from this node only.

The following diagram illustrates this type of organisation:

Development node Production node

Distributionof

parameters

Development

Production

Transfer

Production

Production

Production node

Authorisation of nodes to areas

Note: this organisation is valid for all operations of definition and modification of parameters, that is, update,transfer and distribution.

DirectoriesSince DOLLAR UNIVERSE does not know beforehand the architecture of the target node, this informationgives direct access to the target node's data and executables.



Declaring the applications environment

Applications and domainsComputer applications are generally reduced into sub-assemblies. The functional domain and the applicationare two distinguishing criteria proposed by DOLLAR UNIVERSE.

q A domain is defined by a code and a label,

q An application is defined by a code, a label and the domain to which it belongs. Several applications canbelong to the same domain.

The application and the domain are used by DOLLAR UNIVERSE for analysis and structure of all the Uprocsit manages.

The definition of the Uproc is effectively linked to the domain and application codes, however, since theversion 4.0 (VMS) and 4.1 (UNIX) it is no longer compulsory to specify these codes in the Uproc code.

For previous versions :

q the domain is one alphanumeric character, for example D,

q the application is two characters, for example AP,

q therefore the procedures (Uprocs) for this domain and this application will be encoded on the followingbasis: DAPXXX,

Note: other objects managed by DOLLAR UNIVERSE undergo no particular constraints as regards naming, andit will in many cases be necessary to define particular norms to this end.

Application or MU directoriesThe notions of areas and management units make it possible to define a logical organisation of the computingenvironment. Each of these notions can be optionally associated with the physical structuring of the overallenvironment, defined within the framework of the administration tables.

This physical organisation is designed to allow meshing of the disk space using access paths to the directorieswhere the main computing objects and data reside.

Since DOLLAR UNIVERSE does not impose any particular constraints on this organ, it allows the individualnorms and standards of each customer to be taken into account.

Each application program directory can thus be defined:

q In VMS, by specifying either a disk name (four-character code) and a directory name, or a global logicalname,

q In OS400, by typing the name of the library in question,

q 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 will be restored, in environment variables(UNIX and Windows), variables (AS400), or symbols (VMS and OPENVMS) during execution of theUprocs, thanks to appropriate commands provided by DOLLAR UNIVERSE.

Note: the environment definition is of course optional, save for DOLLAR UNIVERSE, which locates its owndata and executable programs through these tables.

Application directoriesDOLLAR UNIVERSE can manage access paths to the programs (or other assimilated objects) of applicationsin terms of node, universe or application.



Unlike data, for which it is possible to distinguish access paths area by area, DOLLAR UNIVERSE managesprogram directories only in terms of universe (production or development).

Furthermore, this declaration is independent of the management units resident on the node in question, sincethe objects are independent of the data on which they operate, and consequently, common to the managementunits with which they serve.

The corresponding table can be defined centrally and then distributed to each of the nodes, needing knowledgeof the application environment described.

MU directoriesFor the same reason as the programs, DOLLAR UNIVERSE proposes, for each (area / management unit /application) set (the node is implicit, the management unit being resident on a single node), to declare anaccess 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, needing aknowledge of the applicational environment thus described.


Reference manual Users • 35

Users

General

Recognised usersDOLLAR UNIVERSE distinguishes two main types of user:

q Users of DOLLAR UNIVERSE interfaces (character, commands, Motif and Windows), calleddevelopers,

q Those used as submission accounts for the running of batch operations.

Note : from version 4.1 of DOLLAR UNIVERSE, a given user can have both functions.

In DOLLAR UNIVERSE, developer-users are identified by their profile. Profiles control access to DOLLARUNIVERSE functions and data.

Defining user profiles makes it possible to organise individual work stations in DOLLAR UNIVERSE to suitactual user requirements.

Profiles also allow different menu structures to those offered by the standard DOLLAR UNIVERSEconfiguration to be defined, allowing menus to be configured for optimum user friendliness (character andWindows interfaces).

The author codePrior to logging on, each user must be known to DOLLAR UNIVERSE. This identification is managed by auser 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 characterises a username. It serves as a reference to identify theaccount to use and for running a task in DOLLAR UNIVERSE (see paragraph "Submission accounts" formore information).

Development usersIn order to satisfy the various access control requirements linked to the diversity of operations organisations,DOLLAR UNIVERSE allows total automation of its interactive functions, based on user profiles for thecharacter, commands, Motif and Windows interfaces.


36 • Users Reference manual

Transactions of the character interfaceNot available on Windows.

As a standard feature, DOLLAR UNIVERSE proposes its various constituent transactions, together with thelist of options and possible function keys. It is important to note that a transaction may consist of a singleprogram; alternatively, the larger transactions may comprise a tree structure containing programs whichoverlay, depending on the options or function keys used.

For example, through the job monitor transaction, it is possible, using the appropriate function keys, to call upother programs (expected launches, motor control etc.). These programs form the second level of the treestructure described above; it should be noted that certain programs may be directly associated with atransaction, or on the contrary, called from another transaction by implementing an option or function key. Asan example, motor control forms a transaction as such, which can be called using an option in the job monitortransaction.

The administrator can himself customise the DOLLAR UNIVERSE standard transactions by allocating ordeallocating the options or function keys associated with a program. Nevertheless, these possibilities arelimited to the first two levels of the program tree structure of a given transaction.

RecommendationsFor obvious reasons related to open-ended-maintenance, it is highly recommended not to modify the standardDOLLAR UNIVERSE transactions, since these are updated at each new version received ("cancel andreplace" ). Users are therefore recommended to duplicate transactions before adapting them.

The transactions management proposed by DOLLAR UNIVERSE is based on the description of "elementary"programs managed through integral interactive modules (the "program management" heading). This headingis not available in the standard menus, in order to prevent unfortunate modifications; however, it can easily beactivated (by adding the corresponding transaction into the required profile), ensuring simplified open-endedmaintenance. For example, a recently delivered program may include a new function in the form of a specialfunction key; this will be declared in the corresponding program and allocated to the necessary transaction.

RestrictionsThe list of programs called by an option or a function key cannot be altered by adding a non-DOLLARUNIVERSE program.

Because of this, the use of add-on functions is extremely restrictive, since any DOLLAR UNIVERSE programcannot just be added to any transaction. More importantly, "user" programs cannot be grafted. On the otherhand, the different options or function keys of called programs can be allocated or deallocated.

CustomizationThe character interface of DOLLAR UNIVERSE is based on a system of user profiles, to which the DOLLARUNIVERSE administrator allocates various transactions.

These transactions can be standard (provided with DOLLAR UNIVERSE) or adapted by the administrator asrequired. Access to functions can be customised by:

q Creating specific transactions (duplicating a standard transaction and configuring the options and functionkeys to go with it), then allocating this transaction to those user profiles where it is required;

q When creating a user profile, defining usage restrictions on the allocated transactions (such as disablingcertain function keys or options).

The administrator decides which method is best suited, knowing that either method will have similar effects.He may, for example, provide a new job monitor transaction without the function key which changes theenvironment for several distinct profiles. If this transaction is to be used by a large number of user profiles, itwill be more efficient to create a specific transaction and then allocate this to the profiles in question. If only a



few profiles are involved, it may be quicker to modify the characteristics of the transaction when creating eachindividual profile.

User profilesThe user profile is the basic object used in DOLLAR UNIVERSE by the authorisation management function.

It will be recalled that each user is systematically and necessarily allocated a profile in the DOLLARUNIVERSE user table.

After having started by adjusting access to DOLLAR UNIVERSE standard transaction, this function enablesthe definition of a specific working environment for each profile by implementing access control to all or partof existing transactions (character interface) or on actions/objects which make up the interface (commands,Windows and Motif).

Transactions of a profile in the character interfaceAs at the general level, the transactions allocated to each profile can be tailored to suit individualrequirements.

This possibility is nevertheless not redundant on any changes made to the standard transactions. In fact, thetransactions form an intermediate level, authorising definition of a cut-back transaction offering fewerfunctions than the standard transaction.

This transaction can then be directly allocated to several profiles, without the user having to adapt the standardtransaction for each profile in turn.

For each user profile, it is possible to customise precise DOLLAR UNIVERSE usage rights. Each functioncan be authorised or not, and, within each function, it is possible to control access to each option or functionkey.

Access control in the commands, Windows et Motif interfacesDollar Universe integrates access control by Area to both its functions and its data.

Each individual user, or group of users sharing the same profile, can be subject to specific access control.Access is managed in a DOLLAR UNIVERSE configuration file modifiable by the administrator.

Access to actions is tied directly to the specification of the action (e.g. Display, Create, Update etc.). Theaction 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.

Customization of profilesThese functions are available in the character and Windows interface.

The Motif and Commands interfaces do not allow changes to the vocabulary or the organization of theinterface.

Profile menu or desktopThe aim of this function is to allow the creation of customised menus for the character and Windowsinterfaces tailored to the requirements of each organisation.

The profile menu plays no part in managing the confidentiality of access to the interactive functions ofDOLLAR UNIVERSE, and as a result, can easily be made available to each DOLLAR UNIVERSE user to


38 • Users Reference manual

allow the creation of an individual menu. Nevertheless, caution is called for as regards possible problems withinternal and external assistance.

In the character interface, the profile menu defines :

q The menu hierarchy,

q The sequence of the various headings making up each menu level.

In the Windows interface, it defines :

q The standard desktop,

q The user’s default desktop.

It should be remembered that the wording of transactions or folders can be modified, adding to the degree ofcustomization attained.

Menus or desktop customisationThe standard menus in the character interface can be adapted to suit each organisation's needs, via thecustomisation functions. DOLLAR UNIVERSE's personalised menus offer the following advantages:

q Menu structures and wording are totally free,

q The wording of transactions can be adapted to suit the habitual terminology used at a particular site (it isnevertheless recommended to use this function sparingly, for obvious maintenance reasons).

Customization of the DOLLAR UNIVERSE Windows interface rests both on the definition of a standardDesktop and a user Desktop.

Access controls, coupled with the dynamic menu facility (i.e. Ability to modify the order of presentation oftransactions in relation to the standard DOLLAR UNIVERSE menus) makes it possible to tailor the functionalscope and ergonomics of DOLLAR UNIVERSE to the requirements of individual users.

In addition, by allowing the secure dissemination of general-interest information (such as providingdevelopers or certain users with a read-only job monitor, for example), these functions facilitatecommunication between the data-centre personnel and the other actors involved in the process.

Submission accounts

DefinitionEach of the two user populations described can form a submission account, conditional on the followingrestrictions:

q Developer-users can only be used as a submission account in the development universe,

q End-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 end-user) can be used as a submission account inall areas.

Using the author codeThe author code is a trigram (signature) characterising the user. One such code must be present for every useraccount. 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 (developer or end-user) inreality only memorise the author code, to ensure that automatic conversion can be performed betweensubmission accounts during implementation.



This occurs during the transfer phases (automatic translation of a developer-user into an end-user), and also inthe 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 "001".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, butanother account with the username "accnt" and an author code "001" exists.When it is time to run the task in question, the author code will ensure that the account "accnt" islinked to it.

The above example shows that it is not necessary to standardise accounts for all the nodes affected by aDOLLAR UNIVERSE operation. It is simply necessary to link the reference formed by the author code, toexisting accounts.

The author code therefore contributes to the portability of tasks defined in DOLLAR UNIVERSE, from thedevelopment environment to the production environment.


Reference manual Parameters • 41

Parameters

ResourcesIn Windows, UNIX and VMS, the resource enables, using a logical identifier, the description of a systemresource or a logical one (virtual) which should be scanned in order to condition the running of operationsprocedures.

DefinitionA resource is identified by a reference :

q The reference is a logical identifier allowing the Uproc (and, therefore the application description) toremain transparent in relation to the executing environment. In the event of a change of node (or even ofoperating system), the Uproc description will adapt to take account of any related special features.

q Resource references are defined globally for a given node, irrespective of the area.

A resource is defined by:

Nature FIL : file VMS, UNIX, WindowsLOG : logical VMS, UNIX, WindowsPRC : process VMSDSK : disk VMSLNM : logical name VMSSYS : system object VMSQUE : job queue VMS

A resource is identified by:

q Its name: Physical name of the resource to supervise, in the sense of the operating system.

q Its location : Name of storage object (for example, the directory name for a file).

The resource "location" is exclusively used for resource categories "FIL" and "LNM" (LNM in VMS andOPENVMS).

The notion of "location" of a resource corresponds to an access path used by resource category "FIL" (inVMS and OPENVMS, may take the form of a logical name or symbolic link, unless the resource name isalso expressed in the form of a logical name).: For resource category "LNM" (in VMS and OPENVMSonly), it represents a table name.

Note: this location may refer to resources not resident on the resource analysis node, provided that the primitivesof the operating system used (corresponding to the defined category and attribute), so allow.


42 • Parameters Reference manual

If a resource is defined as "exclusive", it may not be shared by another conditioned Uproc. Otherwise, quotasmay be defined to manage resource sharing between Uprocs :

Quota 1 Maximum value of the resource's quota 1,which may be between 0 (default) and9999.

Quota 2 Maximum value of the resource's quota 2,which may be between 0 (default) and9999.

Finally, a resource is examined according to a specific frequency (by a dedicated process known as thesupervisor: see "The operations process" chapter).

Codification

The resource name may be encoded with certain functional elements proposed by DOLLAR UNIVERSE. Thefollowing expressions can be inserted into a resource name.

This coding is usable only for the resource natures "LOG", "FIL" and "LNM" (the latter available in VMS andOPENVMS only). They can be inserted at any point in the name.

q "!UG!": The management unit code can be inserted into the name; this is the code obtained from datadefined by "inter-MU Checks" on the resource condition. If interpretation of this data points to severalmanagement units, the generic resource name created by insertion of this expression will correspond tothe 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).

q "!DTRAIT!": The processing date can be inserted into the resource name; this is the date expressed in the"functional period definition" of the resource condition (format : YYYYMMDD).

q "!SOC!" Allows the name of the current company to be inserted during examination of the resourcecondition.

q "!ESP!" Allows insertion of the current area code (A, I, S or X) into the resource identifier duringexamination of the resource condition.

Furthermore, in VMS and OPENVMS, logical names are accepted solely for resource category "FIL", andonly if the location is not itself expressed using a logical name. While DOLLAR UNIVERSE checks thesyntax of the specific expressions used ("!ESP!","!SOC!" Etc.), It cannot check for usage restrictions onlogical names described previously.

On UNIX, VMS 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 thecharacters " ? " or " [ ] " accepted by the scheduler.

Note: in VMS and OPENVMS, in order to ensure that the operations process remains as independent as possibleof the environmental organisation, it is advisable to use logical names to define the location (access path) of a filerather 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 beemployed in the resource name.

Example : reception and consolidation of files from shopsThe Uproc employed for consolidating files from the shops has a resource condition based on itsreference, defined as follows:Type FILAttribute exist



Name comm_t!DTRAIT!g.datLocation rep_!ESP!!UG!

The "inter-MU Check" associated with this condition is a HDP convention of type "{S }" (all shopsdepending on head office, such as "S01" and "S02", for example).The "functional period definition" associated with this condition will use identical processing datesto the processing date of the considered Uproc (same day, for example).When launching the Uproc for 21 December 1994, DOLLAR UNIVERSE will translate the symbols"!UG!" And "!DTRAIT!" By their values as obtained in the "inter-MU Check" and the "functionalperiod definition".If the launch takes place in the production area, the files to supervise will be:REP_XM01: COMM_T19941221G.DATREP_XM02: COMM_T19941221G.DATWhere REP_XM01 and REP_XM02 will be logical names describing the directories for storing theCOMM_T19941221G.DAT files.If the option "all necessary" was selected for the "inter-MU Check", the two files must be presentin order for the condition to be satisfied.

Incompatibility classes

PurposeNon-simultaneity conditions make it possible to define extremely refined processing exclusions. Nevertheless,they are not symmetrical. In fact, when two Uprocs are non-simultaneous (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 beingincompatible, therefore, globally non-simultaneous.

In Windows, UNIX and VMS, incompatibility classes are a simple and effective solution to this kind ofproblem.

Using incompatibility classesAssociating a Uproc with a class allows the defining of "incompatible execution" processes, conditioned bythe following rules:

q A Uproc can belong to one (and only one) class (declared in the Uprocs "general information").

q A Uproc may be defined as being incompatible with one or n classes.

The rules for examining these incompatibilities are the following:

q Examination is performed locally,

q For each Uproc launched (assuming that its incompatibility constraints have been satisfied), DOLLARUNIVERSE memorises:

Its membership class (references of the "membership" type),

Other classes with which it is incompatible (references of the "incompatibility" type).

q When launching any Uproc, DOLLAR UNIVERSE ensures:

That its membership class is not already memorised among the classes referenced in the"incompatibilities" type,

That the classes with which it is incompatible are not already memorised as classes referenced in the"membership" type.



Therefore a given Uproc cannot be run simultaneously with another Uproc from a class with which it isdeclared incompatible. Similarly, no Uproc can be run simultaneously with another if it has been declared asincompatible with the other's membership class.

Note: incompatibility classes are examined locally by the launcher: this examination applies only to those Uprocsrunning 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 figurein the launch formula.

Example: Uproc classesA good example of the use of incompatibility class is backup processing, where it is preferable notto 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 bedefined as "incompatible".

Uprocs

DefinitionThe procedure, whether it be a CL program for OS400, a shell script for UNIX, a “.bat” procedure forWindows or a procedure « .com » in DCL on VMS, is one of the essential objects employed in computerproduction. (in the rest of this documentation, CL, DCL and shell are grouped under the generic name of"CL", for "command language").

In addition to the specific features it brings to the CL, DOLLAR UNIVERSE associates it with acomplementary set of information. Combining the CL With this additional data produces a Uproc.

DOLLAR UNIVERSE manages two types of Uprocs: batch Uprocs (dealt with in this section) and interactiveUprocs (next section). Batch Uprocs are intended to be submitted to wait for execution in a batch queue (orrun as background tasks, in UNIX or Windows, in the absence of a queue manager), while interactive Uprocsare intended for end users.

The Uproc therefore designates an assembly, comprising:

q A set of characteristics and logical conditions serving to establish the runability of the procedure (knownas "launching" the Uproc). This information is defined in a totally interactive manner, during writing ofthe procedure.

q At the CL Level, DOLLAR UNIVERSE contributes a convention (based on HDP, for example) andspecific commands. The command language of the Uproc can be run directly in the operating system inquestion, outside DOLLAR UNIVERSE. It is obvious that where specific DOLLAR UNIVERSEcommands are inserted into the CL, they will not be executable outside DOLLAR UNIVERSE.

q So-called "completion" instructions whose purpose is to define the "post-processing" performed forupdates, or for purging history files, or for preparing the dependent job stream.

The resulting Uproc is a standalone object whose constituent parts are indissociable in the DOLLARUNIVERSE sense.

CodingUntil v4.0 of DOLLAR UNIVERSE, the Uproc identifier is structured as follows:

q One alphanumeric character representing the applications domain to which the Uproc belongs. Domainsare defined in DOLLAR UNIVERSE administration tables,



q Two alphanumeric characters representing the application to which the Uproc belongs. Applications arealso defined in DOLLAR UNIVERSE administration tables,

q An additional identifier (free), to be defined by each customer depending on his norms and namingstandards.

From version 4.1 onwards, the Uproc code is free. The association with the domain and application can bemade, by default, using the former rule, or externally.

The Uproc forms the cornerstone of the entire functional architecture of DOLLAR UNIVERSE.

The Uproc creation and management functions are available in each area managed by DOLLAR UNIVERSE.On the node and within the area in which they are created, Uprocs are immediately executable in theenvironment of any of the management units present.

If it is necessary to run a Uproc in another area, a prior transfer of the Uproc will be required. If it is necessaryto run a Uproc on a management unit residing on a node other than its development node, a distribution willbe required.

Writing procedureA DOLLAR UNIVERSE transaction is dedicated to the management of Uprocs. The correspondingorganisation is illustrated below; it highlights the main functions available in the Uproc management menuand demonstrates the scope of the possibilities offered by DOLLAR UNIVERSE. It is worth noting thatUprocs having complex functional specifications will find the means of translating them, while simple Uprocswill require only a limited amount of data entry (limited to definition of the "general characteristics").

UPROCselection

Generalcharacteristics

Writing of CL

IncompatibilityClasses

Executionconditions

Terminationinstructions

Successors

Generalcoherencechecking ofentered data

Variables

Mandatoryfunctions

Optionalfunctions

Organisation of Uproc definition menu

Procedures or programs (DCL, shell, CL, .bat)

Internal or external proceduresTwo options are available for managing the command language file associated with the Uproc, depending onwhether it is to be managed by DOLLAR UNIVERSE or independently.

The decision to manage the command language (CL) externally to DOLLAR UNIVERSE entails identifyingthe file containing the corresponding command language instructions (during definition of the generalinformation). 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 theUproc will run). The access path may be explicitly declared or logically using a local variable declared in thesubmission account's login in order to ensure recognition by the scheduler and in the logical environment filein order to be recognised by the interface.

For Uprocs with internal CL, The file containing the command language is created with the name and theversion number of the Uproc written by the interactive functions of DOLLAR UNIVERSE. It is stored in thedirectory known to DOLLAR UNIVERSE (declared during installation of the latter - see installation manual)as normally containing the Uprocs for the area in question.

Furthermore, DOLLAR UNIVERSE ensures parallel evolution in the Uproc version number and the versionnumber of the CL File for internal Uprocs.: For external Uprocs, this parallel evolution feature is not ensured.Similarly, in all transfer and distribution operations, DOLLAR UNIVERSE ensures the transport of the CLfile (in a homogeneous environment of the operating system) for internal Uprocs only.

Writing procedures

The interactive procedure-writing functions proposed by DOLLAR UNIVERSE use the standard editor of theoperating system in question.

q In Windows or UNIX environments, a local environment variable can be used to specify a text editor forboth read-only and write operations. By default, the vi editor is used on UNIX.

q In the case of VMS, there is a choice between the edt and tpu editors. This choice is made in the tablesused to define the characteristics of each company.

Within the command language, DOLLAR UNIVERSE authorises insertion of specific verbs allowingcommunication between the CL and the applications; this applies for functions such as:

q Inserting execution checkpoints or steps in the CL,

q File manipulation offering a list of parameters ensuring the full benefits of hierarchical data processing.Use of the corresponding verb allows simulating a reduction in the corresponding command line, for asmany times as necessary, depending on the number of occurrences required to resolve the HDPexpression.: For example, the expression "{XY}" inserted as a parameter for the verb "copy" will allowcopying the corresponding file into all management units of type "X" depending directly on themanagement unit type "Y" where the Uproc is run,

q Triggering a Uproc on behalf of a number of management units,

q Restoring, as dedicated variables, the names of the directories containing the data-processing objects ofeach application managed by DOLLAR UNIVERSE. Within the CL Associated with the Uproc, thecorresponding command avoids the explicit reference to data that may differ depending on the executioncontext (i.e. Area, management units).

q Transmitting of messages towards the history trace for the Uprocs managed by DOLLAR UNIVERSEetc.

The DOLLAR UNIVERSE commands which may be inserted into the CL are described in the commands usermanual (some are specific to the operating system).

Job parametersIn DOLLAR UNIVERSE, parameters are transmitted in various ways as presented below and detailed in theDOLLAR UNIVERSE commands user manual.

Context provided by DOLLAR UNIVERSEDuring start-up, DOLLAR UNIVERSE provides a set of environment variables, or logical names that can beused 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, VMS or Windows, "MX" in OS400). Thecomplete list of variables is supplied in the Commands manual.

Transmission of additional parameters to a procedureOver and above the stated execution context (see above), the need for transmission of parameters should bedissociated 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 incases where :

q Parameters are passed from one procedure to another,

q Automatic feeding of default parameter settings, insofar as the CL Systematically requires parametersduring submission (as is the case with os400, where a program intended to run indifferently in a batch oran interactive session (in latter case, configured during writing), will systematically need to receiveparameters),

DOLLAR UNIVERSE satisfies these requirements as follows:

q Within a given session, two procedures can exchange up to 30 parameters of 256 characters each (seecommands manual for details concerning writing of the CL),

q By allowing the handling of purely applicational parameters (called variables) attached to the Uprocs witha mechanism for assigning values which is set out in the next paragraph.

Finally, for non-periodic processes, DOLLAR UNIVERSE offers a specific command for provoking batchUprocs that accepts parameters of the following capacities:

Os No. of parameters LengthOS400 30 30UNIX, VMS,Windows

30 255

Refer to the commands user manual for more information on the conditions for using this command.

VariablesThis DOLLAR UNIVERSE function enables variables to be defined and input. This can be done in commandmode or via the graphic interface and during the development phase for operational objects as well as duringproduction.

Thus, the objective is to allow manual or semi-automatic preparation of the batch operation.

General principlesThus, DOLLAR UNIVERSE enables:

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

q Variables to be allocated to tasks and their value to be modified should the default values in the Uprocsneed to be modified for this scheduling.

q Variables to be allocated to launches and their value to be modified in launches should the task’s defaultvalues need to be modified for this launch.

q A variable’s value to be modified in an execution re-start should a value need to be modified at this stage.

The value of a variable can also be modified when the task is triggered, or when the launch is created incommand mode, or when the CL is executed.



CharacteristicsVariables are defined in Uprocs. They are given names. And they have the following characteristics:

q Maximum number of variables: 80,

q Length of the variable’s name: up to 20 characters,

q Types of variable: date, quantity or text,

q A variable’s value: a maximum of 255 characters for text, 12 for a quantity.

Values are assigned to these variables, by a commands mechanism within the session, in Uprocs at the time oftheir definition, in tasks, launches or an execution restart.

Assigning valuesThe variables can be used directly in the Uproc’s CL. A variable’s value at the time of execution is:

q At the time of execution within a session, the value can be carried over via execution of a command in theUproc’s CL,

q In the event of an execution recovery, the value is that indicated at the time of the recovery,

q Or, the value is that allocated to the launch,

q Or, the value is that allocated to the task,

q Or, the value is the default value of the variable shown at the time of its definition in the Uproc (the valueon the local node where the Uproc is executed).

Functional period and processing date

DefinitionsSince DOLLAR UNIVERSE carries out operations in their order of occurrence, it does not recognise thenotion of operating date; instead it recognises applications periods for which operations are run.

The functional period translates this concept, allowing 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 processingdate (unless the Uproc has no functional period). This date depends directly on the Uprocs functional period.

Accepted values for the functional period are:

None 2 weeks 4 monthsDay Month 6 monthsWeek 2 months Year10 days 3 months Extended month

The processing date is expressed as day, month and year, irrespective of the functional period. If one elementof the processing date is not needed, it will not be requested, and will automatically assume the value of thestarting date of the period that is selected.

This date serves as a reference model to automatically calculate all the other dates encountered during thecondition check, execution of the CL, or completion.

If the Uprocs functional period is:

q Day: the requested period is a complete date (day month year),

q Week : the requested period is the week number (from 1 to 53) in the year (NNYYYY), or thecorresponding date (day month year, which is inevitably a Monday),



q Ten days : the requested period is first the month and the year, then the number of the ten-day period (1, 2or 3), the corresponding processing dates being the first, the eleven and the twenty first of the month,

q Month : the requested period is the month and the year (MMYY) and the processing date is automaticallythe first of the month,

q Twice a month: the requested period is first the month and the year, then the fortnight (1 or 2); thecorresponding processing date is the first and the sixteen of the month,

q Three months : the requested period is the number of the quarter (1, 2, 3 or 4) and the year. Thecorresponding processing date is the first day of the quarter.

UseThe processing date figures in all events recorded in the DOLLAR UNIVERSE history trace. This means thatexecution traces of a Uproc can be conserved and differentiated independently of their schedule or executiondates.

To this end, the processing date will be available within the CL, As a reserved variable, for information (toallow, for example, the correct accounting period to be inserted in the report, independently of the executiondate).

In addition, this processing date will be used in all operations synchronising procedures (such as, Uproc to runonly if it ran correctly the previous month, or if such-and-such other Uproc ran correctly for the same monthetc.).

Example: processing datesAn accounts entry Uproc is monthly; each time it is launched, the requested period is a date withthe format MMYYYY.The month-end Uproc is monthly, and traces of the last 12 runs must be kept in the operating eventsin 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 DOLLARUNIVERSE routinely offers algorithms for automatic calculation of processing dates based on the schedule dates(see Tasks - Processing date).

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 ofthe past month.A similar example might entail an operation, submitted each weekend, to give the summary ofaccounts movements of the current month.

Note: selecting an "extended month" (in character interface only) period prohibits the use of implicit schedulingfor a batch Uproc started by the batch engine: only explicit scheduling is possible for this type of Uproc.: For thisperiod, it is necessary to indicate the maximum number of months considered (necessarily 15 at most). Anyattempt to enter a processing date will be checked against the value thus defined.

The "applicational" nature of the functional period imposes a certain number of usage considerations in anysynchronising or triggering of Uprocs. Refer to the descriptions for execution conditions, completion andsessions for details concerning their respective operational limits.

It is now possible to alter the functional period allocated to a Uproc as of the version 4.0 (VMS) or 4.1 (UNIXand Windows). In the event of conflict in the condition checking phase, the default "whatever the processingdate" will be used.



Event memorisation

PurposeWith DOLLAR UNIVERSE, computing production benefits from guaranteed coherence due to the totalcontrol 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 otherUprocs. However, the majority are of no more than informative interest.

To avoid overloading the history files, DOLLAR UNIVERSE maintains a specific history file that records allUprocs declared as memorised. DOLLAR UNIVERSE examines this file in order to evaluate the executionconditions of each Uproc.

A non-memorised Uproc can never be quoted in the reference conditions used by another Uproc.

The operating events base is maintained by means of this memorisation, or by use of completion instructions.

CharacteristicsMemorisation is defined by means of several parameters:

q Execution

This flag indicates whether the execution of a Uproc will be memorised or not. Memorising a Uprocexecution corresponds in DOLLAR UNIVERSE to memorising an event.

This is necessarily the case if any conditions must be defined on the Uproc in question. On the other hand,"non-memorisation" limits the size of the DOLLAR UNIVERSE operating events base.

q Executions per period

Used only when the Uproc must be memorised (otherwise pointless); this information indicates if thetraces of one or more executions (i.e. Events) need to be kept for the same processing date (date obtainedby applying the functional period to the scheduled date).

Selecting "one only" implies destroying the last-known execution event for the processing date inquestion, as soon as a new execution is started for the same processing date.

This automatic purge feature is completed by the number of periods parameter.

Note: this function can replace the Completion instructions. It does not allow, however, such fine eventmanagement, and therefore cannot replace it systematically.

Caution: the duration for which execution events are retained is decided arbitrarily by the user andrequires that all Uprocs conditioned by these job executions have themselves run correctly before beingpurged by the launcher. The default value (0) means that all executions are memorised.

q Number of periods

Number of periods defines the duration (i.e. A multiple of the Uprocs functional period) for which aUprocs execution events will be retained within the operating events base.

Note: the notes and warnings referring to executions per period are also valid in this case. Furthermore, numberof periods is meaningless for a Uproc having no functional period (in this case, the number operating events keptis either one or all).

Caution: by default, the number of periods is "00", meaning that DOLLAR UNIVERSE will keep allperiods. To keep just a single event, the value entered is "1".

Example: memorised and non-memorised UprocA Uproc designed to update a permanent customer file may be non-memorised because it isunlikely, in functional terms, to condition running of another Uproc.



A Uproc that participates in the month-end accounts closure will certainly be memorised, becauseits correct execution over 12 consecutive months will condition launching of the year-end closureUproc.

SuccessorsThe launcher is an events-driven process; starting and ending of the conditioning Uproc causes the launcher tore-examine any Uprocs which are conditioned (and inhibited) by this Uproc. By default, the new examinationis performed randomly. The aim of successors is to define a preferential order for examining the Uprocswaiting for the completion of the conditioning Uproc.

PurposeThanks to the technical organisation of its functions, and the notion launch conditions and launch formula,dollar universe defines its processing sequence dynamically.

At the end of each job run, dollar universe examines the list of jobs with Uprocs waiting. In each case, a newlaunch will be performed.

The new Uproc launch is performed in random order (conditioned by the internal technical structure of dollaruniverse).

The notion of successor is the definition of a sequence for examination of event waits, so giving a particularUproc higher priority for launch after execution of the Uproc in question.

This function completes the dynamic organisation provided by dollar universe, by allowing real-timeinfluence on job sequencing according to events that have arisen, while maintaining its coherence.

Special featuresOver and above the general points stated above, the proposed function observes the following rules:

q Successors are processed irrespective of the end-of-job status of the conditioning Uproc (T or I),

q Successors are examined in the order in which they were entered,

q The only successors processed are those in event wait on the Uproc in question,

q In this respect, successors are identified by Uproc names only, the other necessary information(management unit, session, user, processing date) being directly provided by the execution conditions ofthe related Uproc,

q Finally, Uprocs awaiting an event on the related Uproc but not designated as successors, are submitted tocondition checking according to the normal examination conditions of dollar universe.

Execution prerequisitesUproc conditioning means describing its functional dependency on other Uprocs, and even technicaldependencies (via the resource conditions).

Note: it is not necessary to translate the operators technical constraints (degraded processing paths, forcedserialisation of operations, insertion of technical processes such as backups etc.) In the elementary conditioningprocess, since the structure provided by DOLLAR UNIVERSE at the session level is specifically designed tohandle this requirement.

DOLLAR UNIVERSE proposes four types of conditions, with the possibility of combining these into a launchformula interpreted at each launch attempt.



For the main conditioning types (sequence and non-simultaneity in particular), references to processing dates,management units and sessions can be integrated into the conditions. The events expected by each conditioncan then be identified with great precision.

Note: all operations events (absence, launch, execution or incident on a Uproc) are stored by DOLLARUNIVERSE as events (if the Uproc is memorised). It is these events that are used for determining if the conditionis satisfied or not.

A Uprocs execution conditions are systematically examined (except in the case of "forced launch at end ofperiod" (see paragraph entitled "Tasks"), whether this Uproc runs within a session or not (the session is only asequencing model, external to the Uproc - see paragraph "Sessions - Definition").

Available types conditions are:

q Non-simultaneity (incompatibility),

q Chronology (except Windows and UNIX),

q Sequence,

q Resource (except OS400).

General features of conditionsIn DOLLAR UNIVERSE, the expression of conditions is based on a set of common principles, entailing:

q Identifying the execution of the conditioning Uproc (event),

q Logical formulation of the condition.

The aim of this paragraph is to describe these common features. A sound understanding will be useful whendiscussing the individual condition types later in the chapter.

Note: these general criteria are also valid when expressing completion instructions; moreover, the description ofthese instructions is based largely on the information contained in this paragraph.

The three main criteria enabling the identification of a conditioning Uproc (or purging of completioninstructions) are described below.

Inter-session checksThe inter-session check function applies to the "non-simultaneity" and "sequence" conditions, as well as tocompletion instructions. It enables the determination of which sessions DOLLAR UNIVERSE must search inorder to locate possible executions of the target Uproc, either to evaluate the said conditions, or cancel thecorresponding event (for the completion instructions).

The options are as follows:

q Same session and same execution

This option limits the search for conditioning events (or events to delete) to the same execution of thesession containing the conditioned Uproc. In this way, if the session runs a second time (possibly at thesame time) or if the target Uproc runs on behalf of another session, the corresponding execution eventswill not be considered in the search.

Note: this option is useful when fine event management through completion instructions is not required, and agiven job stream is to be submitted several times while avoiding confusion between individual runs (as frequentlyarises in demonstrations). In a stabilised production context, however, it should be used sparingly (see below forfault condition).

q Same session and all runs



This option extends the preceding option of searching for conditioning events (or events to delete), to alloccurrences 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.

q Name of session

This option allows precise determination of the session where conditioning events will be searched (ordeleted). All executions of this session will be considered.

Note: as mentioned above, this option is noticeably less used for specifying the parameter settings in question,since it provides the least degree of open-endedness.

q Any session

This option is the initial default when defining the condition or the completion instruction. It is the mostgeneral, allowing searching in all sessions or in no session at all (as for separately scheduled Uproc).

Note: this mode of operation should in all cases be preferred, since conditioning of Uprocs (translating theapplications logic) is normally independent on the operations constraints handled by the session.

Inter-management unit controlThe inter-MU Check can be used in conditions of "incompatibility", "dependence" and "resource" (for certaintypes where the file name or address contain the variable !UG!), As well as to completion instructions. Itdirects the search towards events associated with a specific management-unit.

The options are as follows:

q Management-unit type

This option directs the search for conditioning events (or events to delete) to all management units of agiven type.

Note: this option does not analyse the hierarchical relationships between MU, and it is preferable to restrict its useto certain specific cases (technical processing, for example, such as "synchronise triggering of update operationson all backups"). It will often be ignored in favour of the HDP Technique described below.

q Management unit

This option searches for conditioning events (or events to delete) limited to a specific management unit.

Note: as just discussed, this option serves to process very specific cases. It will be ignored, insofar as possible, infavour of the HDP technique described below, which is unquestionably more adaptable and open-ended.

q Dependent units: HDP

This option enables the expression of the HDP convention, specific to DOLLAR UNIVERSE, whichextends the search for conditioning events (or events to delete) to all management units linked toexecution of the management unit containing the conditioned Uproc (per the same convention).

Refer to the chapter entitled "environment concepts" 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 whichthe conditioned Uproc is executed. Therefore if the conditioning Uproc runs on another managementunit, 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 oftype "a" dependent on the current management unit.

This mode of expression is often to be preferred over the two preceding modes, on account of its naturalopen-endedness, 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 executionconditions 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 } conventionThe 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 simplyrequiring the declaration of the corresponding management unit, and its dependency to one of thetwo regions.Following a large increase in the number of offices, a new region is created. The only task requiredis to declare the corresponding management unit, and duplicate the operations schedule for thenew region, by deleting, if necessary, the dependency of certain offices to one of the originalregions, and creating their dependency on the new region.

q All are necessary

This option complements those given above (which are exclusive), by allowing the operator to indicatewhether for the condition to be valid events must be found for all target management units, or if any oneof 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 incompatibilityconditions, it is not proposed in the corresponding windows. In both cases, the events are considered for allmanagement units designated.

Inter-processing date controlThe functional period (and consequently, the processing date associated with each execution) is used with the"chronology", "sequence" and "resources" type conditions (for certain resource categories), and forcompletion instructions.

Referring to the processing date of the conditioned Uproc, the functional period determines the processingdate for which DOLLAR UNIVERSE must seek possible executions of the Uproc or the targeted resource, viathe conditions or the completion instruction.

The inter-functional period check is therefore performed on a comparison between the processing date of theUproc or the conditioning resource, and the processing date of the conditioned Uproc; this enables thedecompletion of the relationship between the processing date and the processing date sought for the Uproc orthe conditioning resource at the time of launch.

If the conditioning Uproc has a smaller functional period than the conditioned Uproc the condition checkmust remain coherent. To this end a new operand "q" (any) has been added as of the version 4.0 (VMS) and4.1 (UNIX).

Example: use of the inter-period checkUproc "A", which generates an annual statement of accounts, can run only if Uproc "B", whichgenerates 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 correctlyIn practice, at each expected execution of Uproc "A", DOLLAR UNIVERSE will translate itsprocessing 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 takesaccount of the respective processing dates or not (same or any)



The calendar units available for evaluating processing dates or processing-date differences vary with thereference functional period of the Uproc in question; the reference is systematically proposed, as well as theyear (greatest unit). If "month" is greater than the reference functional period, it also is proposed (except forthe week, for obvious reasons of non-compatibility between these two units).

The following table summarises the calendar units proposed, according to the Uprocs functional period:

Calendar unitsF.P. D W 10D 2W M 2M 3M 4M 6M YNoneDay * * *Week * *10 days * * *2 weeks * * *Month * *Extended mth. * *2 months * *3 months * *4 months * *6 months * *Year *

Calendar units proposed for different functional periods

Note: if the conditioning Uproc has "none" for the functional period (corresponding, therefore, to an infiniteperiod), the inter-period control feature will not be effective.

So, the definition of a dependency of a Uproc with functional period on a Uproc without a functional periodwill default to a check on any processing date rather than same processing date (version 4.1 onwards).

Additional characteristics

User accountThe user id can also be used by conditions of the type "sequence" and "non-simultaneity", as well as forcompletion instructions.

This tells DOLLAR UNIVERSE to limit its search for target events in Uproc conditions or the completioninstruction, to those corresponding to executions run under a particular user id.

The option is either a user (default = any), or the same user account as the submission account to which theconditioned Uproc belongs.

Condition expected or excludedThis option tells DOLLAR UNIVERSE which is valid - the proposition as expressed, or the contraryargument (opposing proposition).

This option is used mainly with the DOLLAR UNIVERSE character interface, which distinguishes sub-conditions known as propositions that are implicitly interconnected (within a condition) by "and" operands.This allows the opposing proposition to be chosen, while retaining a very simple expression of the launchformula.

Example: use of the " excluded " optionUproc "iu_000" runs only if Uproc "iu_001" is not running but Uproc "iu_002" is.The elementary description of these two incompatibility conditions employs the condition andproposition numbers "01-01" and "01-02".The second elementary condition is expressed with the characteristic "excluded".The launch formula "=c01" correctly fills out the required applications logic.



Note: the graphic interface and the command interface consider only the condition level in the launch formula;from then on the excluded characteristic is equivalent to an inverse condition. It should be additionally noted thatDOLLAR UNIVERSE automatically converts the proposition into conditions when the graphical interface isused to update a Uprocs conditions (coherence is thus maintained with the character interface).

Fatal conditionsFor batch tasks, and especially tasks where submission is to be automated, a fatal character can be attributed toeach condition.

When one of the conditions in the launch formula is defined as "fatal", non-verification of this condition afterit 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 eventshave 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 forthere to be no point in putting its associated Uproc in a wait state. This is the purpose of the fatal characterassociated with a condition.

The corresponding launch will be seen as refused on the job monitor.

Example: use of "fatal" characteristic with a sequence conditionA "finished-product stock management" process is automated using DOLLAR UNIVERSE. Itrequires a Uproc called "order entry" for the sales-office MU 'S, and a Uproc called "enter goodsrequests" for the factory MU 'S.It will therefore contain sequence conditions to translate this logic.For simplicity, it is assumed that order entry or goods requests are the only operations requiringupdated stocks.It could be very useful for these sequence conditions to be fatal, in that if the data entry Uprocs areinteractive, and if the batch engine runs at night, their absence at a given moment from thehistorical events file for this date will not change during the night (unless data-entry can also takeplace at night...).In this way, the automation process will not redundantly manage the Uproc in a wait state, and theother Uprocs depending on this Uprocs running (or not running) can be submitted earlier.

Example: use of the fatal character on an incompatibility conditionAssuming that in the course of the day several users have used an order entry Uproc which triggersa batch Uproc to process the orders of the day. When the batch engine starts up (it is assumed thatthe batch engine is started only after a certain time of day), it will try to run the order-processingUproc as many times as the order-entry Uproc activated. It is clear, in this case, that a singleexecution of this Uproc is sufficient. The declaration of a fatal incompatibility condition of thebatch Uproc with itself will limit the number of runs to 1.

Text "if not satisfied" messageThis text is used (in character interface only) in the execution history file created by DOLLAR UNIVERSEduring execution of a Uproc. It is only present in the history file if an inhibiting proposition (not satisfied) isencountered, and the proposition in question occurs before the inhibiting proposition during conditionchecking of the launch formula.

Note: correct wording at this stage is essential, since it affects the legibility of DOLLAR UNIVERSE historyfiles.

Example: content of "not-satisfied" message depending on launch formulaCase 1: =c01 and =c02Message c01 appears in the history file if c02 is not satisfiedCase 2: =c01 and =c02



No message appears in the history file if c01 and c02 are satisfiedCase 3: =c01 and =c02Message c02 does not appear in the history file if c01 is not satisfiedCase 4: (=c01 or =c02) and (=c03 or =c04)Message c02 does not appear in the history file if c01 is satisfied

Types of conditions

SequenceSequence conditions make it possible to link functionally dependent Uprocs, whether they run on the same ordifferent nodes.

The purpose of this function is to search the memorised operating events for those conditioning execution ofthe 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). Theconditioning and conditioned Uprocs may be one and the same.

These conditions can be parameterised using criteria discussed previously:

q The management unit(s) for which the conditioning Uproc was run (see "Inter-management unit control"),

q The session where the conditioning Uproc is run (see "Inter-session checks"),

q A specific processing date (see "Inter-processing date control"),

q The user account running the task concerning the conditioning Uproc (which may also be that running thetask in question),

q Other characteristics: fatal or not, expected or excluded.

In addition, a sequence condition will refer to the status in which the task concerning the conditioning Uprocmust occur in the operating events file. Possible statuses are:

q Completed,

q Incident,

q 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 beenactivated, and waiting for an event.

Therefore the sequence conditions are largely based on the notions of processing date, user account andmanagement unit, obtaining the information they require in the operating events file.

It will be appreciated that a non-memorised Uproc cannot act as conditioning Uproc in a sequence condition.

Similarly, in order for date-comparisons to make sense, Uprocs quoted as references must have a functionalperiod compatible with that of the Uproc containing the sequence condition.

Example: sequence conditionsThe accounts month-end Uproc will not run, for a given month, unless the previous month'soccurrence completed correctly (or, for the first month of the year, the year-end for the previousexercise completed correctly).One of the solutions for expressing this logic consists in using sequence conditions. In this case, twoconditions must be used because the logical translation of the process described above impliespresence of an or operand.Condition 01 (proposition 01)Sequencing of the month-end accounts Uproc with itself for the preceding month



Processing dates: " month-1",Meaning of proposition: " expected".AndCondition 02 (proposition 01)Chronology for month other than January"month # 01"Meaning of sub-condition: "true".OrCondition 03 (proposition 01)Sequence with the yearly-starting UprocProcessing date: same yearMeaning of proposition: "expected".AndNo (for condition 02)The launch formula is, therefore:(=c01 and =c02) or (=c03 and #c02)

Example: prohibiting calls to applicationsOnce in operation, an application may sometimes have to be interrupted temporarily (due toapplications problems, overloading of computing resources necessitating the limiting of availableapplications etc.).This example gives a simple means of rapidly inhibiting an application. The only requirement is todevelop, in each application, a special Uproc on which all the other Uprocs in the applicationdepend. This Uproc is then allocated to each MU Using the application in question. The inhibitorcan be used only by the operators, when necessary.Once the Uproc is memorised, the event associated with it remains in the historical events file afterexecution. Two options are offered concerning its completion: "T" (normal completion) and"I"(incident).In each Uproc in the application, the following sequence condition is created on the inhibitor:Condition nn (proposition 01)Target Uproc: inhibitorStatus code required: "I"Meaning of proposition: "excluded"In this way, if there is no trace of the inhibitor on the operating events file because it has neverbeen run, or if there is one with "t" status, condition nn is satisfied and will not prevent the job-run.If on the other hand, an article is encountered at "I" 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 byselecting the option corresponding to completion in "T" status: this updates the operating eventsfile by replacing events coded with the inhibiting "I" status.

Non simultaneityThis group of conditions is the complement to the sequence conditions, and enables the definition of a set ofUprocs which must not be executed simultaneously with the Uproc being launched. The verification centreson the local operating events base at time of launching the conditioned Uproc (an incompatibility conditionmay not be declared with a Uproc which runs on a remote machine). The job statuses concerned by anincompatibility condition translate execution of the latter (or its potential for execution):

q D: started (condition checking),

q A: waiting execution (in batch queue),

q E: execution in progress,

q F: completion instructions in progress.

Each condition (or proposition) is expressed according to the previously discussed features:



q The management unit(s) where the conditioning Uproc was run (see "Inter-management unit control"),

q The session where the conditioning Uproc is run (see "Inter-session checks"),

q A specific processing date (or not) (see "Inter-processing date control"),

q The user account running the task concerning the conditioning Uproc (which may also be that running thetask in question),

q Other characteristics: fatal or not, expected or excluded.

The incompatibility conditions are necessary in each case requiring:

q Non-simultaneous execution of Uprocs using the same files for updates,

q Limiting of two competing resource-hungry Uprocs etc.

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: like Uproc classes and incompatibilities, incompatibility conditions are not reflexive and must beentered in the two Uprocs which must not run simultaneously.

Example: non simultaneity conditionsA Uproc covering end-of-month invoice processing, using permanent files such as customer files orVAT 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.

ChronologyThis group of conditions (available in character interface on VMS only) invalidates launching of a Uproc onbehalf of certain periods of time, based on the processing date, and using one or more arithmetical expressions(temporal expressions).

This might cover, for example, blocking execution of the Uproc for a period corresponding to holiday periodsin the activity in question, or any other functional reason.

In this case, the conditions and their propositions will consist of a comparison (using the operands =, #, >, > =,< and < =) between the processing date of the task and the authorised reference values.

Note: a chronology condition, as for any other condition, is examined before any launching of the Uproc inquestion, independently of the execution frequency for this Uproc. Therefore in the case of scheduled batchUprocs, the chronology conditions are not taken into account in the scheduling process (or simulation), but solelyin the launching process.

It should be recalled that this type of condition serves mainly for controlling the interactive activity of a site,and most often applies, therefore, to Uprocs with interactive launch modes. Nevertheless, it can be also usedwith batch Uprocs to express certain special requirements. It is not possible to allocate a chronology conditionto a Uproc not having a functional period. Furthermore, in view of the low usage rate, this type of conditioncan be defined only through DOLLAR UNIVERSE character interface (updates performed via the graphicalinterface do not alter definition of this condition).

Example: a monthly Uproc must be run only in June each yearA single chronological condition is sufficient to condition the Uproc. This condition will comprisethe expression month = 06 and will have the meaning "expected".During running of the task, a processing date with the format month-year will be requested, andmonth will be compared with 06 at the moment the launch formula is examined. If 'month' isdifferent from 06, the Uproc will not be executed.

Example: a monthly Uproc must be run only in February, or each month starting from September (included)Two chronological conditions, must be defined, each comprising a proposition:



- condition 5 (proposition 1) "month = 02", "expected".- condition 6 (proposition 1) "month > = 09", "expected".The launch formula will include, among other terms, =c05 or =c06

Example: a monthly Uproc must be run every month except January and AugustOne chronological condition, comprising two propositions, is sufficient. Assuming that thiscondition is numbered 12, one or other of the following solutions can be adopted:- condition 12 proposition 1 "month # 01", "expected"- condition 12 proposition 2 "month # 08", "expected"The launch formula will include:=c12Or else- condition 12 proposition 1 "month = 01", "excluded"- condition 12 proposition 2 "month = 08", "excluded"The launch formula will include:=c12

ResourceThis step enables the declaration of an execution pre-requisite for the Uproc, based on the availability orthe status of system or logical resources.

Each condition is expressed according to the characteristics stated above :

q The management unit for which the resource was defined (cf. inter management unit control).

This notion is only valid if the !UG! Variable is embedded in the name or localisation of the resource.

q A processing date (cf. inter functional period control). As stated above, this notion is only valid if the!DTRAIT! Variable is embedded in the name or localisation of the resource.

If the Uproc has no functional period, the processing date !DTRAIT! will translate to 000000.

q Whether the condition is fatal or not, expected or excluded.

Certain characteristics are specific to resource conditions :

q A permanent resource avoids the resource attribute check. A resource by default is considered nonpermanent and its attributes are systematically verified.

Note: the function examining resource conditions is pointed at local resources (unless in VMS it is configured witha logical name pointed at a remote resource).

q Attribute : exist, freeblocks etc. The available attributes depend on the type of resource.

For quantifiable attributes, a resource can be evaluated by :

Operator A logical operator enabling values to be compared (<, >,<=, >=, =)

Value Comparison value : expressed in the units proper to theattributes of the resource being scanned; example : 50,000freeblocks means that the desired threshold is 50,000 diskblocks.

q An exclusive resource means that only one Uproc conditioned by a particular resource can run at a givenmoment. Other Uprocs conditioned by the same resource will have to wait until the resource is madeavailable. The notion of exclusivity may be attached to the resource itself or to the resource condition, inwhich case it will be valid only for the definition of this particular condition.

q For the condition check to succeed, both quotas expressed in the condition should be available. If either ofthe quotas is superior to the quota available at the time of launching, the Uproc will be forced to waitbecause of "insufficient quota".



The definition of resource conditions may include, for certain resource types information of an applicationalnature (for example, filename integrating dates comparable to the processing date, HDP Expressions, orreference to an MU). Resource conditions therefore participate in the elaboration of the launch formula, andcan be defined in much the same way as sequence conditions (with the same characteristics, apart from thestatus).

Note: it should be noted that, with the exception of quota definitions, a resource condition expresses theavailability or the presence of a resource in a given state, at the time of launching., Since DOLLAR UNIVERSEdoes not reserve resources ( except for defined quotas or exclusive resources), it may be that the status oravailability of certain resources in certain operating circumstances change after verification by DOLLARUNIVERSE. If the stability of the resource status, or its availability are a pre-requisite for execution of the Uproc,the user must take the required technical precautions.

The launch formula

PurposeThe launch formula is an expression containing chronology, sequence, resource and incompatibilityconditions, linked by a set of operands (AND, OR, =, #).

The logic translated by this expression is analysed during condition checking of the Uproc. The analysisdepends principally on the examination of the operating events base.

Submission of the Uproc depends on verification or non-verification of this expression. The logical value ofthe launch formula ("true" or "false") determines whether it is possible to run the CL associated with theUproc.

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 jobincompatibilities are checked before the logical expression translated by the launch formula.

Optimisation of the launch formulaThe exploitation of the launch formula by the launcher is initially optimised by a purely logical analysis of theexpression of the formula, which determines whether each condition is principal or not. A condition isqualified 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 tomemorised events. Conditions are examined according to their order of appearance in the formula. When acondition is principal, and the logical value deduced is different from that sought, (satisfied for # CNN and notsatisfied for =CNN), the analysis is not continued, and the launch is refused.

Using this process therefore requires a few operating hints:

q The most improbable conditions to satisfy should be placed at the head of the launch formula, in order toget the best from the analysis.

q Place conditions of a fatal character at the start of the formula, insofar as possible. The launch formulaanalysis will thus be restricted to the maximum if the fatal condition is not satisfied.

q If one of the fatal conditions is not verified, even if it is not principal, the engine is informed and the fatalcharacter can block the following launches.

If the organisation of the formula does not include this precaution, any premature glitch (before analysis of thefatal conditions) will prevent detection of a possibly not-satisfied fatal condition, resulting in unnecessarylaunch attempts.

Note: when a Uproc is launched, DOLLAR UNIVERSE memorises any event inhibiting Uproc launch. Anyintervention 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 anymodifications are processed in real time (except for HDP Analysis).

Launch formula limits

The launch formula is limited to 99 conditions, irrespective of the type of condition.

Completion instructions

PurposeThe completion instructions of a Uproc are performed when the job run ends correctly (execution status ="T").

They allow "purges" required on the operating events base to be identified, that is, previously memorisedUproc executions for deletion; these may have completed correctly (status = "T") or abnormally (status = "I").

The use of completion instructions can be explained by:

q Application requirements,

q Requirement to limit the volume of memorised events.

In a perfect context, all Uprocs memorised by DOLLAR UNIVERSE would have at least one other Uprocresponsible for deleting their successive runs from the operating events base.

Note: as for sequence conditions (whose instructions constitute the counterpart), the functional period (processingdate format) of the Uproc to purge must be the equal or greater than that of the Uproc to which the instructionbelongs ("month" greater than "ten-day period" greater than "day" etc.).

The use of completion instructions is not compulsory, since the data contained in the general information ofthe Uproc enables automatic management of memorised events. Nevertheless, completion instructionsfacilitate intervention on operations events in very specific cases (destruction of a particular event, forexample).

Example: completion instructionsA batch application can run only if the interactive application has been "shut down".A shutdown Uproc is, therefore defined, with the characteristic "memorised". This will condition allbatch 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 nomore 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.

Network operationsIf the condition is networked, the event will be recorded both in the local base ( that of the conditioned Uproc)and in the remote base (that of the conditioning Uproc). If a completion instruction is performed on the localnode, the remote event will remain.

However, if a completion instruction (or event deletion) is performed on the remote node (where theconditioning Uproc resides), then all events on the local bases (for conditioned Uprocs) will be purged as perthe instruction.

General rule:



Any modification of the event on a remote node (creation, update, deletion or purge by a completioninstruction) is transmitted to all nodes having issued a request on the event in question. The correspondence isthen checked locally between the status requested and the status received, to determine :

q Whether to launch the conditioned Uproc,

q Whether to purge the event.

Sessions

DefinitionA session is a tree structure comprising Uprocs that are homogeneous not necessarily from the functionalviewpoint (they may contain Uprocs from several applications or different domains), but in terms of theiroperations constraints.

A session is an sequencing model and external to the execution conditions of the Uprocs it contains. Thesession predefines an order in which the Uprocs are launched, knowing that at each phase, DOLLARUNIVERSE will systematically check the execution conditions of the Uprocs that the session is telling it tolaunch.

The session offers a certain number of facilities, in particular as regards:

q Scheduling, over which the session exerts a simplifying role, since the schedule of the session itselfsuffices to sequence all the constituent Uprocs automatically. Nevertheless, if required, one or moreUprocs in the session can be allocated a specific schedule,

q Maintenance of the order of submission of the procedures: sessions are defined totally externally toUprocs, therefore in the event of changes in the sequence structure, there is no need to intervene in thecommand language or the parameter settings of the related Uprocs. This translates into fewerinterventions Uprocs, thereby increasing reliability,

q Job monitoring: the concept of session is present in all job-monitoring functions; it focuses actions ongroups of Uprocs that application logic (through the DOLLAR UNIVERSE notion of application) cannotcompletely translate.

Example: content of a sessionA 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.

Session codingA session is identified by a freely defined code on ten alphanumeric characters.

It may be of interest, bearing in mind the specifics of each organisation, to normalise coding of the sessions inorder to identify certain of their characteristics, for example, execution frequency (daily, weekly, monthlyetc.).

Structure of sessionsThe relationships between the operations implemented in sessions are illustrated below:



T1

T2 T3 T4

T6 T7 T5

T5

T8

Level n

level n+1

Level n+2

OK KO

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 atlevel n will be parent to the Uprocs at level n+1, known as child Uprocs. Individual Uprocs dependent on agiven parent at a given level are referred to as peer Uprocs. The session thus allows complex processing treestructures to be defined.

A Uproc cannot have a "peer Uproc" with the same name (i.e. Same Uproc at same level having same parentUproc). On the other hand, a given Uproc can appear several times in the tree structure, at different levels, orat the same level with different parent Uprocs.

The relationships thus defined express organisational and operational sequencing requirements, and in no casereplace the functional relationships translating the logical conditions defined at Uproc level. It is possible thatpart of the structure of a session is already partially translated into such conditions, more particularly intosequence conditions. The fact of superimposing these two types of relationships is of no consequence.

Note: in no case should the sequence conditions be cancelled within the Uprocs simply because they will betranslated 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 applicationsand logical constraints defined at the Uproc level. Operations constraints (incompatible execution of tworesource-heavy operations, for example) may evolve independently of applicational constraints.: For maximumsimplicity and reliability of maintenance operations, it is therefore important to avoid mixing these two types ofconstraints.

Scheduling featuresThe Uprocs in a session inherit the schedule, the technical characteristics (job queue, for example) and thefunctional characteristics (processing date, for example) of the session-header Uproc (i.e. The one at the top ofthe tree structure). Nevertheless, where it is desirable not to "copy" these characteristics onto a related Uproc,a "provoked" or "optional" task must be created, mentioning the name and the version of the concernedsession, 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:

q declaring a provoked task, for example, allows the execution of the task to be deferred to a specifiedlaunch window, or inhibiting this job during certain periods. (the tasks in the session depending on thespecified launch window will be deferred to the same degree),

q When an optional task is declared, special scheduling conditions different from those of the session maybe attributed. In this case, the session will run normally, except for the optional task, if the latter were notscheduled for execution on the day and time in question. In this case, non-performance will be interpretedas normal completion, and the session will continue along the normal path associated with the non-executed task.

q These new characteristics will be carried over into the following Uprocs in the session. In the case of anoptional 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 constraintfrom the applicational constraints processed as part of the conditioning function.

The session does not replace the execution conditions of the Uprocs. Therefore, despite the order ofsubmission imposed by the session, DOLLAR UNIVERSE performs condition checking (verifying launchformula) on each Uproc to be submitted as part of a session.

Normal and abnormal processing pathsA session is a group of Uprocs arranged into a tree structure.

Depending on the execution conditions (execution status "I" = incident; "T" = completed), the session allowsdifferent paths to be distinguished within the defined tree structure: the normal path, when the Uproc ends in"T", or the abnormal path if the Uproc ends in "I".

These features of a session are useful when system failures occur, as they provide for degraded processingsequences instead of an outright break in the job stream.

Execution environmentDefining the execution environment of the Uprocs in a session is an integral part of the session definition. Themanagement unit(s) associated with each Uproc must be specified, including:

q The related management unit code, or

q A type of management unit, or

q An expression of the hierarchical data processing (HDP) Type.

Hierarchical data processing functions use the dependency declared between management units. They are usedwithin sessions and conditions to define a "target" set of management units in the job triggering orsynchronising commands. Refer to chapter 2 - "environmental concepts" for more information on the use ofHDP.

The following example illustrates the possibilities offered by HDP.

Example: use of HDP in defining sessionsAssuming an organisation centred 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 allmanagement units of type "a" (= offices) depending on the regional division.This possibility for "generically" designating Uprocs for management-unit targets allows thecreation of general processes that can adapt automatically to modifications in the logicalarchitecture of the environment.: For example, the adding of another "office" MU Will betransparent in a session configured to submit a given process from a regional office to all itsdependent offices.

Note: by default, the type of HDP Convention retained will be "{ }", allowing execution of all Uprocs in a sessionon behalf of a given management unit. Refer to the section entitled "tasks" in this chapter for more informationconcerning the management rules for temporal and technical information within a session.

Carry-over of Uproc variables’ valuesCarry-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 varin the CL of the Uproc or in its post-processing, U_POST_UPROC. Three kinds of carry-over of executionvalues can be requested:



q A complete carry-over of the value of all the variables in the parent Uproc.

q Carry-over of only those values of the father Uproc variables recognised by the son Uproc, in other wordsthe intersection between the list of received variables and those of the son Uproc.

q By explicitly mentioning the variables to be carried over, together with their values.

Cf. the Commands Manual for the syntax to be used for this command.

Storage limitsThe total number of Uprocs managed in a session is 140. Up to 20 Uprocs can be declared at each level of thetree structure (for normal completions), with another 20 Uprocs declared as "ab-ends" (abnormal completionof the so-called parent Uproc).

Note: a given process can occur several times in a given session. Each occurrence decrements the total number ofavailable operations in the session by 1 (from the total of 140).


Reference manual Scheduling • 67

Scheduling

Automation of batch tasksDOLLAR UNIVERSE proposes several means of scheduling operations:

q Explicit scheduling,

q Implicit scheduling

Job scheduling constitutes the entry point of automated operations, and therefore one of its major functions.

Based on pre-defined calendars and pre-defined calculation algorithms, job scheduling enables the automaticcalculation (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 effectiveexecution is determined by the conditions attached to the related Uproc.

Calendars

Calendar application environmentIn 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 "Generalcalendar". 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 organisational entity, calendars can be generated specifically formanagement 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 asearch list in this way, tasks will be scheduled depending on the information contained in:

q The specific management unit calendar for the related task,

q Or, if not, in the specific calendar of the MU type,

q Or, if not, in the general calendar of the area.


68 • Scheduling Reference manual

Calendar modelCalendar models can be created. From these models, calendars can be generated for groups of managementunits with similar needs.

The available options ensure that calendars can be adapted as finely as required for the operational needs ofeach environment. Nevertheless, it is recommended to avoid unnecessary creation of calendars, since theymay become difficult and tedious to manage if the management units at a node become numerous.

Note: as for tasks, distribution can only take place from calendar models. Furthermore, even if distribution isperformed to all MU. 'S of the same type (added possibility), this "generic" addressing will be automaticallytranslated into management units when creating the corresponding objects on the target environment. In this way,calendars defined for MU. Types cannot be distributed, but must be created locally on each node where they arerequired.

Generation of holidaysCalendars can be generated with or without standard French public holidays. The standard French publicholidays are:

q 1st January,

q Easter Monday,

q 1st May,

q 8th May,

q Ascension day,

q Whit Monday,

q 14th July,

q 15th August,

q 1st November,

q 11th November,

q 25th December.

Calendar generation includes complex algorithms (such as calculating Easter), and can in no way be based onan external file comprising possibly modifiable dates. The process cannot, therefore, be adapted torequirements such as the generation of holidays for another country. This would require generating a calendarwith no holidays, then modifying it to take account of the internal requirements of that country. Laterdistributions of this baseline calendar will remove the need for the repetition required by these manualoperations.

Calendar range

A calendar's range is not limited. When creating it, allowance should be made for the requirements imposedby the scheduling rules used. To ensure the necessary calculations (for example, a scheduling algorithm usingan annual period), there must be a calendar starting at least one year before the date at which the calendar willbe used by the batch engine, and extending for four years at least (to allow calculation of the next twoprocessing dates).

A calendar must be generated as illustrated in the following diagram:



year n-1 year n year n+1 year n+2

Referencedate

Minimum range of a calendar

The benefit of generating calendars for a wide period cannot be over-emphasised, since over-running thecalendar will stop all further scheduling of tasks operating on this calendar.

Note: DOLLAR UNIVERSE allows the creation of additional years on an existing calendar. If some years existalready, the newly generated years cancel and replace the earlier ones.

Types of dayStandard closing days are positioned when the calendar is generated.

Each day of a calendar is allocated a characteristic, which can take the following values:

q Workday,

q Closing day,

q Holiday.

Closing days are positioned automatically, from a standard "week" mask, comprising each day of the weekand its associated characteristic.

The characteristic for certain days of the calendar can then be modified day by day, as required.

The scheduling functions of DOLLAR UNIVERSE differentiate between standard closing days and publicholidays, enabling them to fulfil separate purposes.

Impact of modifications on a calendarModifying 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.) DOLLARUNIVERSE 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 withthe 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 calendarIn the is example, we assume that several job streams are performed each working day.Certain technical operations, on the operating system for example, can result in relatively longdown-time, forcing the operations department to defer production to another day (Friday toSaturday, for example).Closing down on a Friday (declaration as a closing day) and opening on a Saturday (declared asworking day) will result in the shifting of all related tasks by the calendar, from Friday to Saturday.

Note: for more information on the precise rules governing the updating of tasks, refer to the chapter entitled"operations process" in this manual.



Scheduling rules

DefinitionA rule is an algorithm which translates the required execution periodicity of a task. A scheduling rule,identified by an eight-character code, is characterised by:

q A periodicity, comprised of a number of days, weeks or months,

q A position - the number of days (working or calendar) from start or the end of the period,

q An authorisation mask for each day of the week, depending on whether it is a working day, closing day orholiday,

q An offset direction, to move the scheduled date backwards or forwards, if application of the algorithmdesignates an unauthorised day (holiday, closing day etc.).

In strict terms, scheduling rules are not "objects" in the DOLLAR UNIVERSE sense, but rather a means ofsimplifying the definition of scheduling characteristics for tasks. Using these rules, a very limited number ofcalendars is necessary. A set of scheduling rules is delivered with DOLLAR UNIVERSE; this means that newrules can be added as desired.

Rules make it possible to express periodicity that will be allocated to the target task during the job schedulingphase, thereby avoiding the need to completely redefine the desired periodicity each time. The allocationprocess copies the rule to the task, which becomes independent on the original rule. So modifying the ruledoes not modify the job schedule defined using this same rule. This mode of management is used in order toreduce manipulation, and because the rules, once they are correctly defined, do not evolve. Distribution ofrules is not therefore necessary. Similarly, within a company, rules are defined independently of areas.

Once allocated to the tasks, the rules are applied to the calendar belonging to the management unit for whichthe related task runs (if there is no calendar, the one belonging to the MU. Type, or the general calendar of thenode are sought).

ExamplesEach working day

Period DayNumber 1Shift 1Days CalendarAnalysis direction + (from start)Offset NoneAuthorisations Mon Tues Wed Thur Fri Sat SunWork closed holiday ynn ynn ynn ynn ynn ynn ynn

In this case, "working day", "analysis direction " and "offset" may be modified, but will have no effect.

All closing days or holidaysPeriod DayNumber 1Shift 1Days CalendarAnalysis direction + (from start)Offset NoneAuthorisations Mon Tues Wed Thur Fri Sat Sun



Work closed holiday nyy nyy nyy nyy nyy nyy nyyIn this case, "working day", "analysis direction " and "offset" may be modified, but will have no effect.

Each third working day of the month, with possible carry-over to following dayPeriod DayNumber 1Shift 3Days WorkingAnalysis direction + (from start)Offset + (next)Authorisations Mon Tues Wed Thur Fri Sat SunWork closed holiday ynn ynn ynn ynn ynn ynn ynn

The rule "every third working day prior to end of month, with possible offset to following day" could havebeen expressed in similar fashion by simply changing the analysis direction from "+" to "-".

Each Tuesday; if Tuesday is a closing day, offset to next dayPeriod WeekNumber 1Shift 2Days CalendarAnalysis direction + (from start)Offset + (next)Authorisations Mon Tues Wed Thur Fri Sat SunWork closed holiday ynn ynn ynn ynn ynn ynn ynn

This rule could also have been expressed by setting the "position" parameter to "5" and the "analysisdirection" parameter to "-".

Each first working Tuesday in each month

Period MonthNumber 1Shift 1Days WorkingAnalysis direction + (from start)Offset + (next)Authorisations Mon Tues Wed Thur Fri Sat SunWork closed holiday nnn ynn nnn nnn nnn nnn nnn

The rule "every last working Tuesday in each month" can be extrapolated from the above example, with justone change ("analysis direction").

Tasks

DefinitionA scheduled task corresponds to running of a Uproc (the procedure) on behalf of a management unit (anenvironment, most often data).

By extension, task also designates the running of a session on a behalf of a management unit. In the precisecase of a session, it is more correct to talk of "set of tasks" rather than a single one.



A task must therefore be encoded by concatenating the code of the Uproc and/or the session from which itcomes, and the code of the management unit for which it will be run.

DOLLAR UNIVERSE distinguishes three types of task:

q Scheduled : this task has a complete schedule (rules and/or explicit dates), and consequently is scheduledautomatically by the calculator.

q Provoked : this task has no schedule other than the expression of specific launch windows, since it will betriggered (via the dedicated command or as part of a session).

q Optional : this task is used solely for a Uproc within a session, allowing to be submitted according to itsown 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 notexist).

A task can be submitted in three main ways:

q Through the various triggering commands provided (see commands manual),

q Through an interactive function (the launches), associated with the job monitor, allowing job submissionin scheduled batches (without altering their actual scheduling); scheduled batch jobs can be modified;

q Through the batch engine, which in this case replace the human operator by acting in conformity with theforecast task workload.

Task modelTo take into account distributed architectures composed of numerous management units, and requiringduplication 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 centralcomputer, for example), for distribution to the target environments.

A task model therefore defines a Uproc or session schedule, independent on any specific management unitcontext. A task model can be defined for any type of task (provoked, scheduled or optional).

The task model is transformed into a task (linked to its executing management unit) upon distribution to amanagement unit, and will therefore be executable on this management unit. In this respect, only task modelsare susceptible to be distributed.

Note: Uprocs and sessions are not executable objects, being independent on the executing environment.: For thisreason they do not need the notion of model.

Types of task

Scheduled taskScheduled tasks benefit from all the facilities available in DOLLAR UNIVERSE in terms of workloadforecasting.

Scheduling rules (algorithms) are applied to the time reference scales, which are set by calendars, allowingthis task to be run recurrently (for example, every third working day of month, every Tuesday etc.). In order tohandle random submission requirements, it is also possible to explicitly define a set operating and exclusiondates.

Provoked taskProvoked tasks are tasks submitted on demand from another (interactive or batch) task, via specific DOLLARUNIVERSE commands or a via 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:

q To define specific parameters for submission of a task in a given environment,

q To desynchronise the task submission request from its effective execution. This option allows non-urgentbatch tasks to be deferred to a less busy time period.

Technical execution characteristicsProvoked tasks allow the special technical characteristics of a Uproc to be specified within a session (bydefault, only the session-header Uproc is scheduled, and its technical features are automatically circulated tothe other Uprocs in the session).

Declaring these data, propagated via the scheduling function, prevents the propagation of those of the parenttask, by imposing the tasks own data. It is therefore possible, for example, to define specific priority and jobqueue parameters for a given provoked task.

Note: these specifications apply only to the target Uproc and not the other Uprocs succeeding it. The same appliesfor calculation of the processing date.

Deferred executionThe advantage in declaring a provoked task in the scheduling functions means that an immediate start (via atriggering command, for example), can be transformed into a deferred execution in a launch window definedfor the particular task.

Application interfaceAs mentioned above, provoked tasks can be triggered via a dedicated command (or API) (documented in thecommands user manual). The former can be directly invoked from an application, mentioning by name thosecomponents of the task that the application needs to trigger. This mode of operation obviously presents thedisadvantage of making the application dependent on the description of the task declared in DOLLARUNIVERSE, thus complicating the associated maintenance operations.

On VMS only with the character interface, DOLLAR UNIVERSE proposes working with an identifier, whichallows triggers to be expressed logically within applications, rather than explicitly. The identifier is, therefore,an additional object described with the same components as those used for tasks. It is managed in the sameway as the tasks (management by area, transfer, notion of models, distribution etc.).

Note: previous versions of DOLLAR UNIVERSE included an additional processor ("interface") which, aftervarious changes, ended up with no other function than inhibiting requests received via the command mentionedabove (by simply stopping the corresponding processor). This function no longer exists.

Optional taskOptional tasks are tasks with schedules that do not exactly follow the same rules as the rest of the session; theyonly apply, therefore, to Uprocs contained in sessions.

During execution of the session, this "optional" character generates an examination of their specificscheduling rules. In this way, if the scheduling characteristics of the related task do not correspond to those ofthe session, the task will be ignored outright in the overall tree structure. This allows, for example, a weeklytask 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.



Common technical characteristicsThe notion of tasks goes beyond the sole scheduling of jobs, by allowing all jobs to be declared with thetechnical and functional characteristics required for their execution.

It should also be noted that these characteristics depend on the execution context (management unit), meaningthat tasks can adapt specifically to each MU.

User accountThe user account is the username (UID) of the user for which the task will be run. This parameter iscompulsory. The username must have been previously defined in the administration tables of DOLLARUNIVERSE.

Refer to the "administration" chapter for more details concerning authorised users and operating guidelines.

It should be remembered that DOLLAR UNIVERSE automatically adapts the user account during transfer ordistribution of tasks, via the author code.

Job descriptionThe job description ("JOBD") is used only with the os400 environment. By default, it is parameterised for*user, meaning that the JOBD of the submission account will be used. Entering another value will override theusual JOBD of the submission account.

Batch queueThis information specifies in which batch queue the task must be run. This batch queue must exist for theselected node.

q In VMS, it can be generic or physical, and expressed in the form of a logical name.

q In OS400, it corresponds to the notion of JOBQ and has the value *JOBD by default. Another value canbe entered to specify a different JOBD from the one entered in the job description.

q 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" jobqueue.

PriorityThe priority of the task represents its "scheduling level" in the job queue in question. The priority level can beset between 1 and 255. The default value is 100. This information is not used in the OS400 environment andwill only have an effect in UNIX when DOLLAR UNIVERSE is used jointly with DQM (distributed queuemanagement).

Note: the priority is not intended to control priority operating, but rather defines a preferential order ofsubmission when jobs are pending in the batch queue.

PrinterDOLLAR UNIVERSE allows selection of a printer for outputting the results of task executions. This code isthe logical name (four characters) of the dedicated print queue.

q In os400, this information is not used, since the OUTQS are directly determined through the jobdescription (JOBD).

q In VMS, Windows and UNIX, this information enables a four-character logical name to be entered todefine the print queue reserved for this job. This field does not necessarily represent a physical printer, itcould point to a print SPOOL.



Automatic restart modeSetting this indicator means that the task will be automatically restarted after a system failure, insofar asmanagement of the job queues allows.

q In OS400, this function is consequently not available.

q In VMS, it corresponds to the system /restart option, allowing the job to be restarted automatically in theevent of a system failure (and only in this case).

q In UNIX or Windows, the information serves no purpose unless DQM (distributed queue management) isbeing 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 byDOLLAR UNIVERSE.

Forced run at end of windowIf the launch formula is not satisfied, (and provided unsatisfied fatal conditions are absent), DOLLARUNIVERSE puts the corresponding launch into a wait state. At the end of the launch window, the launch is setby default to status (overrun), removing it from the current operations stream. A manual intervention isnecessary to reactivate it, by prolonging the launch window.

Setting the "forced run at end of period" indicator results in systematic submission of tasks with unsatisfiedconditions 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 aninteractive launch or in recovery operations (see chapter entitled "The operations process" in this manual).

This indicator must obviously be used with care, especially when the considered task refers to a Uproc havingdeclared incompatibilities.

Central monitoringPositioning this flag means that information concerning execution of the task (during start-up and finishing) isuploaded to the node declared as central monitor node in the DOLLAR UNIVERSE administration. See thechapter entitled "Environmental concepts" for more information on the notion of Central monitoring.

For reasons of network-resource consumption, and because the anomalies encountered in execution logs mostoften arise through specific problems requiring local intervention, the corresponding "logs" are not uploadedto the central monitor.

VariablesTask variables are selected from among those available for the Uproc in the Task identification. In the case ofa Session:

q If the task is scheduled, task variables will be selected from those linked to the Session header Uproc,

q If the Task is Optional, variables will be chosen from the specific Uproc,

q Provoked Tasks will conform to one of the two cases above, depending on whether the Task applies to awhole Session, or a single Uproc within a Session.

In the case of Future Launches, if the Launch was created from a Task variables will be those of the Task, ifnot it's the Uproc's variables which will be proposed.

Task schedulingIn DOLLAR UNIVERSE, scheduling essentially comprises:

q Implicit scheduling: use of scheduling rules



q Explicit scheduling: definition of explicit dates

Implicit scheduling allows the creation of algorithms for defining execution dates of each task. Each algorithmis managed individually in the form of a scheduling rule.

Explicit scheduling allows the processing of various scheduling cases that cannot be dealt with automaticallyby the implicit scheduling mechanism.

Allocation of scheduling rulesEach task can accumulate up to seven different scheduling rules. Each rule must have:

q An application date

This is the date as of which the rule is calculated (indispensable, for example, for a rule with a period oftwo weeks: it must be clear from which week the calculation begins). There must be an application dateper rule allocated to a task.

The application date must correspond to the period's starting date :

• If the period is "week", the application date must be a Monday,

• If the period is "month", the application date must be the first of a month.

More generally, the task itself requires an:

q First schedule date.

This corresponds to the date on which the task is available for operations. Depending on the schedulingparameters, the calculator will possibly reiterate its calculation until it finds a scheduling date greater thanthe first schedule date.

Note: the allocating of rules to a task is not sufficient to produce an integral schedule: the latter must becompleted with a launch timetable corresponding to the days obtained by applying the rule-based schedule.

Explicit addition and cancellation of datesDOLLAR UNIVERSE offers exception dates and explicit dates associated with implicit scheduling, tostabilise and facilitate the implementation of scheduling rules.

Effectively, while implicit scheduling can be used only in the case of scheduling rules remaining relativelystable over time, and if the proposed algorithms can self-adapt to the particularities of the calendars (such aspossible use of "offsets" in implicit scheduling), a certain number of events may, on a particular day, disablethe scheduling principle.

In which case, the use of exception dates and explicit dates will enable:

q Cancelling the effects of implicit scheduling (positioning of an exception date for the invalid day),

q Offsetting of the invalid execution date to another, non-algorithmically calculable date (i.e. Entering anexplicit date).

Apart from covering all imaginable cases, these three possibilities provide an adaptable and flexible meansable of accommodating any unforeseen problems arising in the computer production process.

Explicit datesExplicit 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, torandom scheduling over time.

Explicit scheduling consists in defining a set of information groups comprising:

q The required execution date and time,

q The duration of the launch window,



q The processing date for which the task must be run (when the related Uproc has been defined with afunctional period).

These possibilities allow the implementing of scheduling processes, which are systematically renewed overtime by accommodating as far as possible the special criteria of the calendars.

Note: entering explicit dates serves to complement the scheduling of a task, so providing, via the: forecastworkload function, a precise view of future operations. In the case of one-off launches, which take place more orless immediately, the use of interactive launch possibilities will be preferred, since it avoids interference in thestandard scheduling process.

Exception datesIn cases where, despite the flexibility of the proposed algorithm, a sudden event might disturb the definitivescheduling cycle, exception dates can be defined, making it possible to invalidate an execution at a given date,without imposing modifications to the scheduling rules.

Note: an exception date can serve only to invalidate a date calculated in the framework of implicit scheduling. Ithas no effect on any explicit dates associated with a task. To cancel the effect of an explicit date, the related dateshould be deleted by the explicit date declaration transaction.

Launch windowThe launch timetable option defines a launch window to allow for the particular operations load, which mayvary day by day..

Where a task must be run several times each day, up to 150 executions can be defined on a given day, bydefining the interval between launches for a determined period.

Launch windows are defined once and for all, irrespective of the number of implicit rules entered.

Single job runFor tasks that must be run once a day only, the scheduling times can be different for each type of day of theweek.

Note: this starting time corresponds to the "earliest" possible execution time ensured by the launcher, but doesnot correspond systematically to the execution date and time, which may be deferred if the conditions are notsatisfied.

The beginning of the launch window duration is completed by a duration (HHH.MM format) which is the timethe launcher will keep the launch active pending satisfaction of its conditions. This interval may attain 999hours and 59 minutes.

Multiple executionsThis function allows the entering of multiple launch times, making it possible to submit up to 150 executionsof a given task in the course a day. The launch time limit is calculated by DOLLAR UNIVERSE by addingthe indicated duration to the beginning of the launch window.

The launch timetable is generated automatically for the specified period. This automatic generation feature canbe repeated as many times as necessary, the generated times appearing gradually on the screen in ascendingorder.

Note: this multiple daily launch function is not designed for supervising technical or applications events. If this isrequired, an external process will be needed; while obviously using fewer resources, it will not perturb the robotprocess. It is therefore recommended to use resource conditions or commands, not triggering.

Schedules of provoked tasksA provoked task may include launch times, which defers execution to periods with lower machine loads.(forexample). Like scheduled tasks, the launch window is calculated from a starting time and a duration.



Note: in the absence of a starting time, requests are processed immediately. If no duration is specified, the requestsare considered as unlimited over time (the default is actually 999h59).

Exclusion periods can also be defined so as to inhibit execution of the related provoked task for certain partsof the day. This notion is useful in that it allows user-requested batch tasks, or very resource-heavy batchtasks, run in lightly loaded periods, while automatically ensuring repeat submissions from one day to the next(provided the condition checking period has not expired).

Processing dateEach time a task is launched, it is accompanied by calculation of (or a request for) a processing date whichdepends on the functional period (FP) of the related Uproc for this task (unless the Uproc has no functionalperiod).

FP of Uproc Format of processing dateNo FP No processing dateDay Day Month YearWeek Week Year10 days 10d n° Month Year2 weeks 2w n° Month YearMonth Month YearExtended month Ext. Month Year2 months 2 Months Year3 months Quarter Year4 months 4 Months Year6 months 6 Months YearYear Year

The processing date occurs in all operations events recorded in the DOLLAR UNIVERSE execution historyfile. This makes it possible to conserve and distinguish the job traces of a task independently of the schedulingor execution dates.

Example: processing dateAn accounts entry Uproc is monthly; at each launch, the requested period is a date with the formatMMYYYY.The month-end closing Uproc is also monthly, and must conserve the trace (in the operating eventsfile) of 12 correct executions to enable the year-end Uproc to run.

Note: the functional period (format of the processing date) is independent, and can differ from the schedulingperiod of the related Uproc, even if DOLLAR UNIVERSE routinely proposes the algorithms necessary forautomatically 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 ofthe past month.A similar example might entail an operation, submitted each end-of-week, to give a summary ofmovements for the current month.

In order to specify this processing date more finely and allow the possibility of differentiating the processingdate from the task scheduling date, additional parameters may be defined. The calculation method is based onthe following chronological phases:

q Applying the difference in days, if necessary taking account of working days (otherwise calendar days),

q Projection of the date obtained in the corresponding functional period,

q Applying the difference between the periods, in order to obtain the processing date.



Example: processing datesConsider 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 launchingis the same as its scheduling date.If the specified period shift is "-1", the processing date automatically associated with it is the daypreceding the scheduled date.

Example: calculation of a processing dateFor a task constructed on a monthly Uproc, a difference in calendar days of +5 associated with aperiod shift of +1 gives the following successive calculations:June + 5 days => 2 JulyJuly => month of July (by projection)July + 1 period => month of august=> 19890801

Note: the difference in days is not a simple repetition of the period difference, except for the "daily" functionalperiod. 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 periodsReturning 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 expressedin days in order for these two executions to "point" to a given month.Considering the following differences:Period difference = -1Day difference = +2Irrespective of the date of the first Monday, the processing date obtained for the two executions willbe the current month:June + 2 days => 2 July => June => 19900601Mon. 4 July + 2 days => 6 July => June => 19890601A similar result can be obtained with the following hypotheses:period difference = +0day period = -7

Note: since version 3.4, which introduced the possibility of offsetting a task beyond the period handled(depending on the authorisations defined for the day of the week), the processing date has been calculated beforeoffset (date calculated by the rule before applying the possible offset contained in the rule).

Examples: calculations of processing dates for scheduled tasksThe execution date is taken as Tuesday 27 June 1989, with the calendar for the month of Juneconfigured as follows:Month June (06)Monday 05 work 12 work 19 work 26 workTuesday 06 work 13 work 20 work 27 work

Wednesday 07 work 14 work 21 work 28 workThursday 01 work 08 work 15 work 22 work 29 workFriday 02 work 09 work 16 work 23 work 30 workSaturday 03 closed 10 closed 17 closed 24 closedSunday 04 closed 11 v 18 closed 25 closed

Some calculation examples:Reference FP Delta of FP Work days Processing date

Day 0 yes 27/06/1989Day 0 no 27/06/1989Day +5 yes 04/07/1989Day -2 yes 23/06/1989



Day -2 no 25/06/198910 days 0 21/06/198910 days -1 11/06/198910 days +2 11/07/1989Week 0 26/06/1989Week -1 19/06/1989Week +1 03/07/1989

2 weeks 0 16/07/19892 weeks +1 01/07/19892 weeks -1 01/06/1989Month 0 01/06/1989

2 months -1 01/05/1989Quarter +1 01/07/1989

4 months +1 01/09/19894 months -1 01/05/19896 months 0 01/01/19896 months +1 01/07/1989

Year 0 01/01/1989Year +1 01/01/1990

Superimposing launch windowsFor a given task and a given date, there may be two launch windows characterised by the couples (hd1,hf1)and (hd2,hf2). This situation can arise in the following cases:

q two identical explicit dates with different windows,

q An implicit scheduling algorithm, resolution of which gives a date included in the explicit dates,

q two algorithms occasionally giving the same dates for a given task.

Arbitration takes place according to the following rule :

If one period totally contains the other, the "including" period is retained, the "included" period being purelyand simply forgotten. If this is not the case, two distinct launches are scheduled. The one with the earlieststarting time maintains its original window; the other has its start time adjusted to the end of the previouswindow, while keeping the same finishing time.

Example: the effect of superimposed periods

H H

H H

H H

H H

H

e1b1

b2 e2

b1 e1

b1

b2

single launch: H - He1b1

two launches: H - H & H - He1b1 b2 e2

two launches: H - H & H - Hb2 e2 e2 e1

H Hb2 e2

e2

He2


Reference manual Refining the operations process • 81

Refining the operations process

Manipulation

UpdatingDOLLAR UNIVERSE objects are managed with the following options:

Create A new object (Uproc, session etc.) In theselected working environment: company -node - area. Creation will be refused if theobject already exists in the environment.

Duplicate A source object to a target object. Theobjects will be of the same kind, but can havedifferent types (model, non-model), withdifferent identifiers (for example duplicateUproc"tstref/001"onto Uproc tratbr/002), ordifferent versions. Duplication on an alreadyexisting target object will be refused.

Update The characteristics of an object. Its identifieris not accessible.

Display The characteristics of an object, withoutbeing able to modify them.

Delete An object. Its identifier and characteristicswill be cancelled from the workingenvironment (including the CL Procedurefile if the Uproc is internal).

Updating an object in a given environment (company, node, area) is specific to this environment and has noimpact on the object in other environments. This means, for example, that a Uproc cancelled from the centraldictionary is not cancelled from the local dictionaries.

Other update operations are specific to certain objects, these are described later in this chapter.

Technical locking of objectsWhen a Uproc is accessed for update by a user, it becomes inaccessible to all other users, whether they beDOLLAR UNIVERSE users or even 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


82 • Refining the operations process Reference manual

the launch window) the new launch will not be schedule until the task is updating, but it should beautomatically calculated when the modification of the task will be completed.

Version managementIn the development environment (application and integration areas), DOLLAR UNIVERSE manages objectversions (Uprocs and sessions) to facilitate the tuning of the operations process.

UprocsDOLLAR UNIVERSE manages Uproc versions in the application and integration areas. In the simulation andproduction areas, the version is always null. DOLLAR UNIVERSE ensures parallel changes between theversion number of an internal Uproc and the version number of the associated CL file. Parallel management ofversion 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, isprocessed 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 thedevelopment universe.

SessionsAs for Uprocs, sessions are DOLLAR UNIVERSE objects which follow similar rules for development andimplementation.

Therefore:

q In the application, integration and simulation areas, sessions are managed by version. The entiresession/version group is accessible from the application or integration areas. In this respect, Uprocversions processed during a session will be versions defined explicitly as the "current version".

q In the production area only one version of a session is available.

Changing environment

Transfer to an areaIn DOLLAR UNIVERSE, descriptive data concerning operations processes are principally assembled withinthe following objects:

q Uprocs,

q Sessions,

q Calendars,

q Tasks.

The management transactions associated with each of these objects make it possible to transfer each oneinteractively 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).

Transfers between areas are authorised 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 definition of"Nodes"), or if the object in question comprises a management unit that is unavailable in the target area (this mayoccur with calendars, tasks or allocations - see definition of "Management units").

Transfer of an object already existing in the target area causes the existing object to be replaced by thetransferred 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":

q Transfer of a Uproc to the simulation or production area will result in the creation, of the Uproc with aversion number of 000 in the target area,

q Transferring a session to the production area will result in creation of the session with a version numberof 000 in the production area.

Note: the commands uxext and uxins can not be used to transfer an object from an area to another (cf.Commands manual).

Distribution to management unitsDistribution means conveying certain parameters, not between one area and another, but from one machine toa 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 relatingto the Uproc along with its associated CL.

As for the transfer, each object category within DOLLAR UNIVERSE can be sent for distribution includingthe administration tables:

Administration tables: Objects:Companies UprocsNodes SessionsManagement units CalendarsManagement unit types TasksManagement unit dependencies Incompatibility classesApplications ResourcesDomainsApplication and MU directoriesUsers

Distribution functions entail:

q Extraction of descriptive information concerning the object and its source environment,

q Transfer to the destination environment,

q 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 notdeleted). If the object already exists in the target area, it will simply be replaced by the newly distributedobject.

Objects can be distributed to:

q An explicit list of management units,

q A management unit type, meaning, all the management units of the indicated type.



Target of the distributionAll of the phases presented above run in real time, whether the target management units reside on the samenode or on another node in the network.

In the case of objects defined independently of the operations environment, (i.e. the management units - thiscovers tables, Uprocs or sessions), only the nodes are targeted through the management unit list. If twomanagement units resident on the same node are designated as targets for a distribution, the object is sent onlyonce to the destination node. Similarly, if certain of the management units targeted are resident on the nodewhere the distribution is performed, these will be ignored.

Distribute a modelIn the case of objects which do depend on the operations environment (i.e. calendars and tasks), only thosedefined as models can be distributed. They will become immediately operational for their target managementunits as soon as the distribution is validated (allowing a delay for transmission and installation). Unlikeenvironment independent objects, distribution of model objects to local management units will result in theircreation on the local node.

Note: this function may be excluded if the target management units are not valid for the area in question (seedefinition of "Management units" ), or if the targeted nodes, through these management units, are not authorisedfor the area in question.

Distribute an administration tableDOLLAR UNIVERSE does not allow "delta" distribution of tables (i.e. Differences only), any more than itallows customised distribution node by node. Attention must be given to ensuring that a table is distributed toall nodes as soon as it is created or modified, so that every node has a coherent view of the environment thusdefined.The effect of distributing an administration table is to replace the entire target table by the original table: ifthere were records in the target table which are not in the original table, these will be destroyed by thedistribution of the original table. An exception to the rule is the nodes table. Since version 4.3 its distributionno longer overwrites the local node.Note: the distribution of area level objects requires the presence (quite apart from network processes - seeadministration manual) of the exchanger for the area in which the distribution is performed. When distributionconcerns objects at company level (as is the case with the administration tables), the exchanger of the productionarea is used.

Importing and exporting dataTo allow desynchronisation of the decision to distribute and the effective insertion of parameters, export andimport commands are available in the DOLLAR UNIVERSE command interface (see Commands manual).

Functional locking of objectsTransfer or distribution can optionally lock an object for protection against all modification by non-authorisedusers.

This option is enabled during creation of a company, by setting the "lock Uprocs and sessions" option. Objectswill 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 Uprocor the session.



Distribution loggingAll moves performed by the transfer or distribution functions are logged and displayable in the distributionhistory.

These history files are designed to give a global view of the various parameters existing throughout theconfiguration, the ability to detect potential incoherence rapidly facilitates overall parameter management. Thehistory file will display the type and identifier of the object, together with information concerning the move:

q Type and identifier of objects distributed

The identifier is a concatenation of data concerning the distributed object, as illustrated in the followingtable:

Table LabelUproc Uproc, versionResource ResourceSession Session, versionCalendar MU, (model)Tasks Session, version, Uproc, version, MU, (model)

q Type of move: transfer, distribution or acquisition,

q The status of the move for the current environment (i.e. That containing the interrogation function).During the move, this code can differ between the source and the target, and take the following values:

• Move request in progress (D3), this status is returned for a distribution when the sending site cannotwrite the acquisition order to the remote site.

• Move requested (D4), this status is returned for a distribution when the sending site has succeeded inwriting the acquisition order to the remote site, but the latter has not returned an acknowledgement.

• Move acquisition in progress (A3), this status is returned at the receiving site of a distribution, whenthe site has been successful in acquiring the required information. It is also obtained for a transfer,where it signifies the initialisation of the transfer.

• Move acquired (A4), this status is returned for both a transfer and a distribution ; it indicates correctcompletion of the operation in question (for a distribution, means that the receiving site hasacknowledged to sending site).

If the status does not reach value A4, it means there is a problem with the corresponding operation: it isthen necessary to check that the DOLLAR UNIVERSE I/O server (for UNIX) is properly running on thenode and in the target area addressed by the transfer or the distribution. In this last case, a check isnecessary to see if the network server and the exchanger are also running on the two nodes in question(for the targeted areas, in the case of the exchanger).

q The target node (and source respectively) of the move,

q The target area (and source respectively) of the move,

q The target management unit (and source respectively) of the move,

q The date and time of the move (for the target) (updated at each change of status during the move,respectively for the source).

In the case of a distribution, the history file of the move is systematically updated on the two nodes inquestion, so that a given node always has a clear view of incoming and outgoing moves.

Simulation of scheduled tasksAvailable in Windows, UNIX and VMS



Production schedules are dynamically maintained by DOLLAR UNIVERSE, without use of predefined plans.In such circumstances, it may be necessary to interactively obtain a summary view of the projected jobschedule over a given period, then monitor running of the projected job schedule.

The above tasks are performed by the forecast workload and simulation functions.

These functions make full use of all possibilities offered by DOLLAR UNIVERSE for describing operationsobjects and consequently, the applications logic.

ObjectivesThe interactive functions for defining and scheduling a task allow a simulation to be performed at any giventime in relation to the reference calendar, and viewing the effect of the schedule on this particular task. Thissimulation can be executed over any configurable period.

The aim of the present function is to obtain a much wider view of operations between two given dates, toallow subsequent:

q Simulation of task sequencing,

q Simulation of the overall duration of selected operations.

For performance reasons, this function is restricted to simulating local operations. Remote events default tocorrect comletion to ensure local simulation continuity. The selected schedule can be executed virtually byDOLLAR UNIVERSE.

Workload forecastingTo enhance the readability of the workload forecasts, tasks to be processed can be selected, together with theirdisplay conditions:

q Task may be selected according to individual components (Uprocs, sessions or management units), eithergenerically or explicitly,

q The starting and ending date and time of the forecast workload.

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

Session componentsSessions may be displayed generally or in detail, that is to say all component tasks on the processing pathrunning on the selected management units.

The forecast will take into account the particularities of those component tasks. In which case, optional taskswhose 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 forecastworkload displays sessions without displaying the detail of their component Uprocs.

Launch windowsThe 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.

Remote management unitsSessions 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 insertedbetween 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 sessionand the starting time of each task in the session.

Workload simulation

ObjectivesAvailable in VMS with the character interface.

Using all the available data, DOLLAR UNIVERSE can format a projected workload over a given period,starting at any date (even in the past). Refer to the previous section for a definition of simulated job schedule.The simulation of the projected workload is interactive. This enables:

q Displaying the job sequence,

q Precise positioning of a job’s starting time and an estimation of its elapsed time (use of statisticalreferences – see "Statistics"),

q Modifying the end of job status for each job (default = normal) for testing fallback and recovery routines.

The execution traces formatted by DOLLAR UNIVERSE, combined with the job execution logs, provide ageneral view of production job behaviour. All necessary tools are supplied to enable a complete and rapidanalysis of job behaviour and performance.

Simulation of forecast workloadsFor performance reasons, this function is restricted to simulating local operations only. Remote events aredefault to correct completion to ensure local simulation continuity. Finally, the execution times for these sameremote events are ignored, since including them would require interrogation of the actual remote sites.

The forecast generated can then be executed virtually by DOLLAR UNIVERSE. The corresponding screenresembles the job-monitor screen. The following information is displayed for each simulated task:

q Session, Uproc and sequence number in the system, as well as the management unit,

q The status of each task,

q The starting date and time, and expected finishing time for each task,

q The mean elapsed time of a task, based on the statistics of the last 100 executions of the task (see"Statistics"),

q The actions performed on each task.

Special optionsEven if most of the functions are identical to those provided by the job monitor, the simulation function hasspecial options for further analysis of simulated operations:

q Incident simulation: enables hypotheses to be built on an incident on the selected task simply by settingthe completion status to "Incident". By default, the expected status is "completed".

q Update options:

• Modify event: enables updating of the task status once it has ended (switching status "T" to status "I"and vice-versa).

• Modify completion: once the expected launch has been accepted by the simulation function,modification of the final status remains possible thanks to this option.



q Restart simulation: at any given time, launch the simulation starting at a given date and time: all simulatedevents with launch dates later than the new simulation start dates are cancelled ; they then reappear as"expected launches".

Step-by-step modeThe "step-by-step" mode of production simulation allows job executions to be broken down into three phases:

q Initial activation: the function goes to the start of the next launch window,

q At the second activation, the function goes to "condition checking" status, meaning that the executionconditions of the first task are being examined. The first task then appears with a status "D", meaning"condition check started", then to status "E" (executing), or "W" (waiting for event),

q At the third activation, the function changes to status "T" ("completed"), meaning that the task completioninstructions are being examined. The task then passes to the "Completed" or "Aborted" status. Thefunction then automatically returns to the "wait" status, advancing to the next programmed launchdate/time.

The cycle continues for each task. However, it should be noted that if several tasks are activated at the sametime, launching of these will be requested first. Their completion processing is completed after the conditionchecking phase.


Reference manual The operations process • 89

The operations process

Role of the batch engineDOLLAR UNIVERSE provides dynamic sequencing and launch control for each job, based on acyclicalprocesses that react to events in real time (time, job completion or start-up, change of resource status,parameter update etc.).

In this respect, DOLLAR UNIVERSE does not make use on a predefined operations plan, but rather interpretssets of descriptive information concerning the various jobs and their associated scheduling data, taking intoaccount events as they occur, including any operator interventions. Thanks to this highly interactive approach,DOLLAR UNIVERSE brings:

q High performance (minimal resource consumption, due to the absence of a cyclical process, and "just-in-time" job submissions),

q Exceptional flexibility and reactivity,

q Genuine user comfort, since the operator retains all freedom for real-time interventions.

The automation processThe working of the DOLLAR UNIVERSE engine is represented by the following diagram:

Calendars Rules

TasksUprocs /

MUCalculator

LaunchesLauncher Executions

AwaitingLocal orremoteevents

Exchanger

To remote sites

Supervisor

OperatingsystemAdministrator

Operator

DOLLAR UNIVERSE batch engine functions

Job scheduling is built upon tasks, which are procedures (Uprocs) or groups of procedures (sessions) to be runin 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 appropriatetime, launches the task by verifying the execution prerequisites (existing events or expected resources). If the


90 • The operations process Reference manual

production environment is distributed, the batch engine communicates with the other machines, via thenetwork.

These various phases are performed by DOLLAR UNIVERSE through a series of different processes knownas the calculator, the launcher, the supervisor and the exchanger.

Components of the batch engineThe batch engine comprises three main components:

q The calculator, whose role is to calculate the following execution dates for all scheduled tasks orrecalculate those dates following modification of the calendar or the task,

q The launcher, which provides three essential functions, namely: condition checking, submission andcompletion of those tasks that the calculator has determined as being "ready to launch" (or that have beenrequested by user or operator trigger commands), it is assisted by the supervisor in the detection of systemresources,

q The exchanger, which manages DOLLAR UNIVERSE specific data exchanges between nodes.

The role of the batch engine is to optimise resource usage ("just in time" launches, launches at low-loadperiods, 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 requirementsof the production which they manage. DOLLAR UNIVERSE's automation functions are particularly efficientin terms of resource consumption.

Furthermore, the calculator, like the launcher, work on the basis of the system date and time. Special care isrequired when changing the system date and time, since any changes not planned with rigor and with theproduction load in mind may well disorganise the automated production functions.

Location of the batch engineThe batch processors (calculator + launcher) are specific to each company using DOLLAR UNIVERSE, andto each area within a given company. To ensure complete separation between the respective automationprocesses of each area on systems comprising several areas, a batch engine is necessary for each area in use.

In addition, there must be a batch engine available for operations on all machines comprising the dataprocessing system. For organisations using cluster architecture (in VMS and open VMS), the required processmay be present on each machine in the cluster. The files used by these process are, on the other hand, sharedby all batch processes installed on the cluster machines.

Note: the calculator and the launcher must be present for normal operation of DOLLAR UNIVERSE. Whereautomation is applied across the network, the exchanger is also indispensable: this means that the robot processesmust be started in the working environment (company-node-area).

Refer to the Administration manual for more ample information on the technical architecture supporting thebatch engine.

Submission across the networkThe different batch engines installed exchange necessary information via a client-server connection comprisedof a dedicated function called the exchanger (located in a distinct process). This process allows jobs to beexecuted on remote management units, or to condition them on remote job runs without this being apparent toan application running locally.



Execution phases of a taskExecution of a task comprises five main phases:

q Scheduling: calculation of the next launch date (for scheduled batch tasks),

q Launch: examination of dates and times, and receipt of triggering commands,

q Condition checking: verification of the conditions expressed in the launch formula,

q Execution of the associated CL. Procedure,

q Completion: execution of instructions; processing of event waits, provocation of sessions.

Manualsubmission

Automatic submission :calculating of execution

dates

Launchingof tasks

Condition checkingof launches

ok fatal ok

Eventcollection

Time limitoverrun

Reception ofexpected events

Wait

Abandon

Termination

Execution

Task execution diagram

The five phases shown in the above diagram are performed each time a task is executed. Passage from onephase to another constitutes an operation event which is recorded by DOLLAR UNIVERSE.

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

Operation of the calculatorThe calculator maintains the next execution date for each task in real time. This calculation is performed in thefollowing conditions:

q Each time the calculator detects an outdated execution date for a task (calculation of next execution datefor the task in question), so at the end of the launch window,

q Following calendar update: next launch dates of all tasks dependent on the modified calendar arerecalculated,

q And, of course, each time the task's scheduling parameters are updated. In this case, only the updatedtask's next launch date is recalculated.



After each calculation, the calculator programs itself to wakeup at the end of the next launch window. Finally,the calculator resets the launcher's alarm if the task's launch window precedes its current wake up time.

Note: the fact that a task has a valid launch window does not necessarily mean that the task will actually run at thestart of, or even within, the launch window (the interval of time between the first possible submission time andthe last submission time defined in the task scheduling function). Job submission depends on the satisfaction ofthat job's execution prerequisites expressed in the launch formula.

The calculator generates launches, which are objects distinct from tasks (different files). It is the launches thatwill be considered by the launcher, and not the tasks themselves.

Impact of modifying a taskIn general terms, all modification (or activation) of a task results in the recalculation and update of the initialexpected launch, on condition that the current system date and time is not within the initial launch window, inwhich case the recalculation will be performed when the end of the launch window is reached.

Assuming that the update takes place outside the initial launch window, leaving aside the detailed workingprinciples of the calculator which are designed for optimum performance, two points must be considered :

q If an update concerns only the task's technical information, it will affect all future launches of this taskwithout recalculation of the next launch, consequently any existing expected launch is not regenerated,

q All modification of at least one of the three scheduling modes (implicit scheduling rules, explicit andexception dates), results in the recalculation of the particular task's next launch window (if it is notdisabled and the calculator is present) to reflect the new definition.

Enabling - disabling of a taskIrrespective of its category, a task can be disabled. An inactive task is a task for which scheduled launches areprovisionally suspended.

When a task changes from the enabled to the disabled status, its effect is immediate. Nevertheless, it has noeffect on existing expected launches (irrespective of their state of advancement in the automation process).

The calculator continues to generate launches for disabled tasks, however these launches are generated with adisabled status. When the task is enabled, the first effective execution will occur for the next launch followingthe date on which the task was re-enabled.

Disabling tasks which have multiple daily launches may result in a rapidly expanding expected launches fileand should consequently be avoided.

Provoked tasks and optional tasks are disabled in the same way as scheduled tasks ( of the "autodate" type).Similarly to scheduled tasks, processing requests will appear as disabled expected launches.

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 generatedexpected 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 freegenerated expected launches with launch windows having submission start dates and times earlier than thecurrent date.

Sequencing and launching

The launcherThe launcher contains the four main sequencing and launch phases, namely:



q Launch: examination of dates and times, and receipt of triggering commands,

q Condition checking: examination of execution conditions,

q The submission of the batch envelope

q Completion: execution of instructions, processing of events on hold, execution of sessions.

The launcher compares the system date and time with the date and time of the next launch as defined by thecalculator; in the event of equality, it performs condition checking for this launch. In the opposite case, thelauncher will hibernate until the date and time of the next expected launch. The data required for the launcherare transmitted by the calculator (or by various manual operations).

In the case where condition checking of the launch is not satisfied, and provided the inhibiting conditions arenot fatal, the launch is put on event wait (until the end of the defined launch window).

The launcher does not cyclically retry to submit the launch for condition checking. This is taken care of by anevent-driven management process. Indeed, at the moment of condition checking, expected events inhibitingthe satisfaction of the launch formula for the Uproc in question are stored. As soon as these events haveoccurred, the launch will be resubmitted for repeat condition checking.

When the condition checking has successfully completed, the launcher submits the batch envelope whichexecutes the actual CL. Procedure.

After execution of the CL., The completion phase in particular determines which launches awaiting eventsrequire re-examination; this phase also ensures execution of the completion instructions associated with theUproc in question; it also insures management of sequences defined in the sessions.

The launch

Origin of launchesA launch can originate from:

q The automatic generation by the calculator for each scheduled task,

q Intervention on an expected launch (creation other than by the scheduling, modification, suspension, re-activation or triggering command, using the interactive function or commands and API provided in thestandard DOLLAR UNIVERSE release),

q The task triggering command or a launch creating command (see commands or API manual).

Launch statusA launch equates to an examination of the launch dates and times of the task, and receipt of triggeringcommands; during this phase, the task can have the following statuses :

q Awaiting launch,

q Held (after deactivation of the launch),

q Released after suspension,

q Condition checking,

q Event wait (condition not satisfied),

q Launch window overdue.

Launch window overdueThe launch window is a period of time granted to ensure that all the conditions considered as pre-requisites toexecution of the task are effectively satisfied. So a launch expected for 7:00 p.m. With a launch window oftwo 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 be purely and simply abandoned. For some specialcases, it is possible to impose execution of the launch at the end of this interval, even if all of the conditionsare not met using the "forced run" option.

In the event of a "launch window overdue" status, the launch can no longer be submitted. It must therefore beeither abandoned (by cancellation), or have its credit restored (by extending the launch window).

This function will be very useful in the event of a system halt that is too long for DOLLAR UNIVERSE to beable to restart all non executed jobs: in effect, DOLLAR UNIVERSE regenerates all launches that should haveoccurred (but solely in the production area), and, if the launch window is overdue, attributes them the"overdue " status: the user will then be able to decide which launches are to be executed or abandoned.

Operations on launchesDOLLAR UNIVERSE comprises functions for operations analysis and job monitoring. In the job monitor, itmay be necessary to intervene on expected launches.

In this case, it may be necessary to:

q Manually start an unscheduled job,

q Modify or delete a scheduled execution,

q Modify the variables of the launch or their values,

q Hold (or release) the execution of a task.

All these operations are possible through the "launches" functions. These operations do not allocate the actualtask but solely the occurrences of the launches for each task.

Suspending or reactivating a launchThis function allows all launches of a task to be suspended. The task can then no longer be started byDOLLAR 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.Depending on the time of its reactivation, if the launch is outside its launch window, it can pass into " timeoverrun" status.

Starting an unscheduled jobDOLLAR UNIVERSE allows new launches to be created manually, whether these apply to already scheduledtasks or not. If the task is already scheduled, the new launch occurrence will be added to the one produced bythe scheduling function, without modifying or suspending it.

Creation of a launch is entered much like a task; the task identifier must be given: Uproc, MU. And perhapssession, plus the technical information necessary for the execution (identical to that given in followingparagraph). If the scheduled task exists, its technical information will by default be proposed.

Updating expected launchesUpdating a launch allows some or all parameters to be modified:

q The task user's account,

q Technical information: printer, batch queue, and priority,

q The job's launch window,

q The launch exclusion period: comprised between the same limits as the launch window, this allowsmomentarily inhibiting launch of the task,

q The processing date of the launch in question,



q Bypass condition check: indicates if the launch is performed with condition,

q Checking (examination of execution conditions) or not. This option is also proposed during job recovery,it is different from the option described below,

q 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 fed to the monitor node as definedin the node table,

q Automatic relaunch or restart mode: in VMS, indicates if the launch in question is to be submitted withthe VMS restart option, that is, whether it can be automatically restarted by VMS after a system failure. InUNIX, the joint use of DOLLAR UNIVERSE and DQM allows access to the same functionality. Thiswill resubmit those launches that were in progress at the time of the system failure, provided this optionhas been selected.

q Modification of variables: in the case of a launch and where the launch has been created from a task, it isthe variables of the task which apply. Where the launch has been created from a session, it is the variablesof the Uproc in question which will be selected. In any event, these variables remain capable ofmodification so long as the launch has not been condition checked by the engine.

Cancelling a launchA launch cancellation can involve a launch created by a scheduled task, a new job creation, or triggered fromthe DOLLAR UNIVERSE interactive command. Cancellation results in disappearance of the launch, which istherefore 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 calculatedaccording 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 thislaunch.

Launch historyIn order to keep track of all interventions performed, each operation on expected launches is memorised andmade available in a modified launch history.

The purpose of this function is to record the various manual interventions performed on the automatedproduction process. While such interventions are a major advantage in the form of dynamic productionmanagement, they can nevertheless cause damage if not used with care.

Interventions are marked by:

q The author code at the source of the modification (or creation) of the launch.

q 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",

q The date and time of the intervention.

The detailed record of the technical information associated with the launch (user, batch queue, launch windowetc.) Is also accessible.



The operations events fileCondition 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.

On VMS, in the application area, there is a current events file per application, the corresponding files beingphysically stored in application directories as defined in the corresponding table. This arrangement is used tofacilitate unitary application tests (resetting of the file, updating without disturbing other applications).

On OS400, Windows and UNIX, where file structures must necessarily exist, this arrangement is not used, theapplication being only a selection criterion.

Each of these bases stores every event corresponding to all runs of Uprocs declared "memorised".

Modify eventsThere are several reasons for wanting to modify events:

q When implementing a job or application, the conditions defined at the Uproc level may refer to tasks thathave never run (such as conditioning a task on correct execution of the same task the previous day, forexample). In this case, it will be necessary to create the required event artificially in order to definitivelyinitialise the production cycle;

q During a recovery process or during an intervention following a system failure, it may be necessary tomodify or create operations, class or resource events in order to automatically continue a productionsequence.

In these conditions it should be clear that any intervention on production events can have a particularly heavyimpact on the production process.

During the launch, execution and completion phases, the progression over time of a launch may be determinedby the changes in its execution status. This is recorded in the current events history, which is used by thelauncher for condition checking or recovery of Uprocs.

Network operationsWhen conditions are used across the network (i.e. The conditioning Uproc is on a different node to theconditioned Uproc), the Uprocs events base plays a special role.

When the conditioned Uproc is launched, the event request (session, Uproc, MU.) Is transmitted to theconcerned node. When the conditioning Uproc runs, the event is created in the local base and is uploaded tothe bases of all the conditioned Uprocs which are waiting for this event.

Registered 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 isuploaded systematically.

The conditioning Uprocs events base is managed according to the rules of memorisation defined in the Uprocgeneral information. However, in the conditioned Uprocs events base, only the last event for the conditioningUproc for the period in question (whatever the memorisation parameters of the conditioning Uproc).A signal to complete or manual deletion of an event from the conditioning Uproc’s events base automaticallycarries through to the events base of the conditioned Uproc. The reverse does not hold good.

Condition checking

Launch statusThe different status values possible for launch executions are summarised in the following figure:



Launch wait

Condition check

Pending

Eventwait

RefusedTimeoverdue

Executing

Completion

Completed

Aborted

Execution status of a batch task

The values of the execution status have the following meaning:

q D or "Started": launch condition checking phase.

q W or "Event wait ": indicates non-satisfaction of the launch formula.

q R or "Refused": indicates non-verification of the launch formula with a fatal condition.

q O or "Time overdue": indicates the conditions were not satisfied at the end of the launch window.

q A or "Pending": pending execution of a batch task, having successfully negotiated the condition checkingphase and being submitted to the batch queue.

q E or "Executing": throughout execution of the CL.

q 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.).

q F or "Completion": throughout the completion phase after a correct job run.

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

Condition checksEach launch is submitted to condition checking as soon as the start of the launch window is reached. Thelaunch 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 classevents base.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 therebeing any fatal condition, the condition checking function puts the launch on hold and records those missingevents 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"). It should be noted that only inhibiting events are



memorised at each condition check (see "The launch formula" in the description concerning Uprocs), so thateach new condition check can bring up any new inhibiting event.

Unmet conditions inhibiting verification of the launch formula are processed as follows:

q If the condition concerns execution of a task on the same node, the event is recorded. As soon asDOLLAR UNIVERSE intercepts the corresponding event, the launcher will renew the condition check onthis task,

q If the condition concerns a task on another node, the exchanger process will trigger recording of theexpected condition on the node in question. When DOLLAR UNIVERSE intercepts the eventcorresponding to the condition, it will transmit the information to the initial node, which will rerun acondition check on the task. This method of managing expected events provides, at the Uproc level,conditioning that is totally independent of the organisation or the layout of the environments within theconfiguration.

Upon expiry of the launch window, and if the launch formula is still not satisfied, execution of this task willbe abandoned and the launch status will become "Time overrun". The possibility remains, nevertheless, ofperforming a forced run. In this case, upon expiry of this launch window, the task will be submitted, with theexecution conditions being ignored.

Note: a forced run ignores the launch formula outright, whether the latter contains incompatibility conditions ornot. Use of the forced run therefore requires prudence.

Finally, if the launch formula is verified, the launcher ensures creation of the execution process, and submitsthe CL. associated with this process.

Substitution of the resource supervisorWhen the launch formula contains a resource condition (the resource having been defined and the resourcecondition having been integrated into the launch formula), the launcher looks for this resource attribute on thesystem.

If the resource attribute is found, the launcher continues to analyse the formula.

If the resource attribute is not found, the launcher requests the supervisor to warn it when the resource ispresent at the node; it also memorises the fact that it is waiting for a resource event. From this point, thesupervisor will cyclically scan for presence of the resource using the period indicated in the resourcedefinition. 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 requiresverification of its attributes (non permanent resource).

After the resource has been analysed and deemed available, the supervisor will notify its presence in theresource events base (from the expected events base) and will inform the launcher that it can begin a newcondition checking cycle for the Uprocs waiting for this resource. Only one request is communicated to thesupervisor 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, thesupervisor does not intervene in the condition checking operations.

Verification of resource condition quotasIf the condition is satisfied, ( i.e. If the required quota is inferior to the available quota ), the Uproc reservesthe quota, expressed in the condition, for the duration of its execution. If the resource was defined withautomatic unlocking, the reserved quota will made available upon Uproc completion (status T or I), if not aspecific 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 launcherpositions 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 resourceattributes pertaining to the waiting Uproc.

Note: for performance reasons, whenever possible, it is generally better to use the provocation commands inpreference to resource conditions. For example, when a task should be run at every occurrence of a giventechnical event, i.e. arrival of a file.

Reserving resource quotas and scheduling priorities

With effect from DOLLAR UNIVERSE version 4.3, on Windows, UNIX and VMS, a function ( a window ingraphic 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 definedenvironment (company, node, area) on behalf of a processing date.

This enables:

q Blocking of resource quotas while a task is awaiting execution:

During condition checking the launcher will recognise the task which has reserved the quotas and willrelease them to it so as to authorise its execution. The immediate effect of this will be to block the quotasrequested by the condition according to the usual process.

Once quotas have been reserved by a task, any other launches presented for condition checking may bemade to wait for their quotas by the launcher if the quantity requested is no longer available.

q Definition of scheduling priorities between tasks having made reservations on the same resource:

If two tasks have reserved quotas on the same resource, the one to be executed first will be the one havingrequested more quotas (quota1 or quota2) in its reservation. If these are not yet available the launcher willawait 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 aresource condition capable of being resolved by the launcher because the quotas are available, then thelauncher will validate the condition and authorise the execution of the launch (even if other tasks arewaiting for reasons of reservation).

Example: reserving resourcesThe 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 thecurrent 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 atthe outcome of the execution of the command.Another task not having made any reservation on this resource can be run if its condition on thisresource requires a quota of 10 or less.If a second reservation on the resource prio_ordo is requested by the following command: uxrsv resres=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 whichhas reserved more quotas will be executed first, in this case the one defined on Uproc IU_DT1.

Uproc submissionWhen the Launcher has validated the condition-checking phase of a Uproc, it submits the Uproc to the "batchenvelope". It is this "batch envelope" which, thereafter, will initialise execution of the Uproc (by a connectionto the submission account) and execute the completion phase (issuing of the return code).



Pre-processing

Post-processing

UPROC

U_BATCH

Uproc submission

The "batch envelope" also performs the completion of the execution: recuperation of the return code in thecompletion file.

Additional processingOn Windows, UNIX and VMS, the execution of a Uproc, (shell script or DCL procedure) may be preceded bythe execution of a pre-processing which will be common to all Uprocs. If this procedure exists it will be runsystematically before each and every Uproc.

The execution of the pre-processing may be used, for example, to define local environment variable or logicalnames which will be known to the Uproc during execution. This avoids having to integrate common code inthe CL.

In the same way, the Uproc execution may be followed by a post-processing, which if it exists will be runsystematically for each Uproc. It will be common to all Uprocs.

Pre-processing is called U_ANTE_UPROC and is situated in the mgr directory. Under VMS, it must beplaced in the programmes directory.

Post-processing is called U_POST_UPROC and is situated in the mgr directory. Under VMS, it must beplaced in the programmes directory.

Under VMS, these two procedures are supplied with a "TEMPLATE" extension in the programmes directoryand can be adapted according to needs.

Job completionThis represents the final phase in execution of a task. For batch tasks, it is provided by the completion functionof the launcher.

The launcher is enabled at the end of execution of each Uproc's CL, providing the following functions:

q Executes the completion instructions for the Uproc in question,

q Inserts the corresponding event in the events file,

q Compares the event that it processes against the expected events, and re-enables (if required) conditionchecking when there is a correspondence between the created event and an expected event,

q Submits (if necessary) the "child Uproc" depending of the session. When the submissions have to bemade to nodes other than the node running the launcher, the exchanger will execute all operationsrequired for activating the launcher on the node(s) in question,

q Uploads operations events towards the central monitor node, where central job monitoring is being usedfor a multi-site production environment,

q Therefore completes the circle initiated by the calculator and the launch and condition checking functionsof the same launcher.



Inter-machine communications

Role of the exchangerThe exchanger is a process in the DOLLAR UNIVERSE batch engine that handles all batch communicationsbetween the different nodes of the network (at the same time relieving the launchers and other interactiveprocesses of these same operations).

The functions provided by the exchanger are:

q Submission of tasks for remote management units,

q Transmission of event wait states (conditioning a "local task" on the end of execution of a "remote task",for example),

q Distribution of various objects forming the DOLLAR UNIVERSE parameter settings,

q 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 hasa configurable cycle to ensure the security of data transfers.

All information which transits by the Exchanger (production or distribution events) can be accessed from theexchange events base.

Operating principlesThe 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 intended for a remote node, the launcher will use the exchangers of the source and target nodes toinform the launchers at the nodes in question.

Launcher

Exchanger

1

Launcher

Exchanger

3

network

2

Exchanger mechanisms

In the latter case, the local launcher transmits the condition checking command to its exchanger (phase 1). Thelatter transmits the request to the exchanger of the management units in question (phase 2). The remoteexchanger warns the launcher (phase 3), which submits the launch on the management unit.

A sequence or incompatibility condition belonging to a local task on a remote task uses the same operatingprinciples.

If the expected event is not found locally by the launcher, it formulates a request for an event wait to theexchanger (phase 1). The local exchanger transmits the request, together with the name of the sender, to theremote 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 thelatter occurs, the reply will be transmitted to the original launcher, which will resolve its own event wait andrecord 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 administrationmanual.

System failuresIn the event of a system failure, four situations can arise:

q The system failure occurs before the launch has been performed. In this case, DOLLAR UNIVERSE willautomatically re-examine the validity of this launch window and possible condition checking. If thelaunch was already on hold, it will not be considered (no point);

q The system failure occurs in the course of launch. In this case, no irremediable operation has beenperformed, and it will simply resume the launch and submit it to repeat condition checking (performedautomatically by the batch engine);

q The system crashes simultaneous with the completion phase. In this case, a DOLLAR UNIVERSEfunction started during the boot or with the computer IPL resumes and ends the completion instructionsfor each launch remaining at the "F" status (instructions in progress);

q The system failure takes place during the execution. In this case, DOLLAR UNIVERSE offers thepossibility of automatically restarting the corresponding launches, using specific parameter settingsassociated with each task (automatic restart on UNIX if DQM is used, or restart on VMS). At start-up,DOLLAR UNIVERSE will consider all of its portfolio and will synchronise with these same processingoperations (in order to await their completion), or will declare them as "incidents" if they are no longerpresent. In addition, DOLLAR UNIVERSE authorises insertion of recovery steps in the CL., Enablingpartial recovery of interrupted processes.

The above features (particularly the last one) are a natural guarantee towards security of operations, including,even, a crash of DOLLAR UNIVERSE itself (even if this certainly does represent a very serious problem).

To complete this security aspect, the calculator automatically regenerates all launches (but only in theproduction area) which should have taken place during the system failure (either crash of operating system orDOLLAR UNIVERSE itself).


Reference manual The operations monitoring • 103

The operations monitoring

Job monitoring

PurposeDOLLAR UNIVERSE attributes a particularly important role to the tracking and supervision of operations,with the sole aim of facilitating job monitoring, accelerating the identification and diagnosis of incidents, andpermitting the necessary diagnosis and recovery procedures. There is a transaction dedicated entirely to jobmonitoring.

Organised around a control screen, the job monitor provides dynamic display (audible alarm, automatic screenrefresh) 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:

q The history trace formatted by DOLLAR UNIVERSE, recording the phases performed by the job and, forjobs in an event wait state, the events expected. This history trace can receive comments or operatorinstructions transmitted from the command interpreter via a specific DOLLAR UNIVERSE command,

q The job execution log,

q The next jobs to run, etc.

As well as the main functions allowing for intervening on the operations process:

q Recovery after incident,

q Interactive launching of unscheduled jobs,

q Updating of operations events ...

The job monitor provides the operator with a single point from which to make all necessary interventions onthe operations process.

Naturally, the job monitor allows all or certain of the operations events occurring on a node, for a given areato be displayed.

Central monitoringNevertheless, ever since DOLLAR UNIVERSE version 3.3, it has been possible from a node defined as thecentral monitoring node (see paragraph entitled "Central monitoring") to display not only local productionevents but also remote events generated by tasks defined with central job monitoring.


104 • The operations monitoring Reference manual

For this latter type of task, the events concerning the start and end of execution are systematically transmittedto the central monitoring node. In this way, the job monitoring function active at the central monitoring nodesees all major events occurring on all computers in the network.

The job monitor is sufficiently critical to merit a dedicated terminal.

The use of filters on the events to monitor ensures detailed and precise supervision.

Job statusThe following job statuses are to be found in the job monitor :

Status Code MeaningCompleted T Normal successful completion of a Uproc.Aborted I Abnormal end-of-job. This status is normally

generated by the procedure itself (see thecommands manual chapter entitled"execution CL" for more informationregarding the possibilities for managingreturn codes)

Completion F This status appears only during correctcompletion of the procedure, and correspondsto execution of the completion instructions.Irrespective of the final status, the othercompletion-phase operations are performed:reactivating of events on hold, request forlaunch of following Uprocs in a session

Execution E Execution of job in progressPending A This status corresponds to submission of the

job in a batch queue, following a successfulcondition check. The duration of this phase ofthe launch can vary with the technicalcharacteristics of the batch queue at any onemoment.

Held H Launch on hold. This status can occurfollowing an intervention of this type: in theexpected launches function (or after thecorresponding command), in the job monitor,or the associated batch queue managementfunction.

Launch refused R This abandon occurs when a fatal condition isnot satisfied during the launch's conditioncheck.

Event wait W If one or more non fatal conditions are notsatisfied (but no fatal), an event wait isposted. A given launch can be put into anevent wait several times. Each of themcorresponds to an unsuccessful conditioncheck. After the first unsatisfied conditioncheck, the launcher is set to await thecorresponding event. Occurrence of theexpected event results in a new conditioncheck. If this new condition check brings upanother unsatisfied condition, the launch isagain put into an event wait.



Time overrun O Launch window overrun. This status occurseach time that an expected event does notoccur during the valid launch window orwhen one or other of the calculator orlauncher functions has been absent for toolong.

Conditioncheck

D Condition check in progress. This phasecorresponds to examination of the executionconditions of the launch. It should be notedthat this status is considered as inhibiting inrelation to any non-simultaneity conditions(or incompatibility criteria) from other jobs.

DiagnosticsThe DOLLAR UNIVERSE job monitor retains only the last occurrence of these successive examinations. Itremains nonetheless possible to consult the various occurrences thanks to the option "display previouslaunches", or by browsing the execution history.

In order to monitor its activity, DOLLAR UNIVERSE feeds to a general log file containing all errors from theproduct and its interfaces detected during operation (except for OS400, where a spool file is used). A log fileis also generated for each process or robot process, containing operating errors and specific informationmessages for the process (all operating systems).

On VMS, use of this option is not compulsory. During installation of the product, if the option is selected, thefile is created by default in the production area logs directory on UNIX and Windows systems.

The files may be deleted; they are automatically recreated by DOLLAR UNIVERSE as soon as there is amessage to be recorded in them.

Authorised interventions

Kill a jobThis function can only be accessed if the execution status is "Execution in progress". It has the effect ofstopping 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".

Recover jobThis function is accessible only if the event applies to a task whose execution ended with the "incident" status.Similarly, the Uproc must have been configured as memorised in order for this function to be accessible. Itremains possible to modify or to create the considered event, in order to give it "Incident" status and so be ableto restart it.

Display previous launchesThis option displays all condition checks concerning a launch before being executed or abandoned as well asthe "history traces" corresponding to each launch or condition check.

Display history traceThe DOLLAR UNIVERSE job history trace is presented in the form of a formatted screen in which messagesare displayed by the various components of the robot processes.

This function allows access to the job's execution history, and to display the job's descriptive labels along withdate and time of condition checking by the launcher, the processing date, the date, time and number of theentry on the batch queue and an explanatory message concerning the state of the task.



It is possible, using a special $u command (see commands manual) to insert operator instructions into thistrace, from the Uprocs.

Display logThe user can consult the job's execution log via a text editor. Querying can be performed at any given time,whether the execution is in progress or has completed. DOLLAR UNIVERSE redirects itself the job'sSTDOUT and STDERR to the execution log file.

Management of job queuesJob queue management is available in VMS or by using DQM in UNIX. Operations describe below concernonly the character interface on VMS.

This option allows the operator, without leaving the job monitor, to manage batch queues and jobs that theycontain, whether scheduled batches or user requests, submitted by DOLLAR UNIVERSE or otherwise (anadded view of the technical environment over and above the functional view provided by the operationstracking of the job monitor).

The following information is available:

q Name of batch queue,

q Queue status ("L" for start; "A" for stop; "P" for pause),

q Maximum number of jobs able to run simultaneously in the queue in question. Can be modified byentering a new job limit,

q Number of jobs running in the queue,

q Total number of jobs present in the queue (running and pending).

An option is provided for stopping, either immediately or after the job in progress, and restarting any batchqueue.

Another option gives access to the batch queue job list, to display:

q The name of the batch queue, during display or "management",

q The name of the job in the batch queue,

q The job's status in the queue:

• "S" for suspended (batch queue paused)

• "P" for "pending",

• "H" for "held" (if requested),

• "E" for executing,

q The job's queue entry number,

q The job's username,

q The job's system PID,

To modify the execution batch queue's parameters, or the job priority, or to immediately suspend or stop thejob in question.

Modifications may only be performed on jobs pending execution (i.e. Status = P).



History files and statisticsDOLLAR UNIVERSE comprises a series of functions dedicated to maintaining histories of operationsevents. These functions provide access to :

q A journal listing interventions performed on the most strategic function - controlling "expected launches"(see chapter entitled "Launch history");

q A complete execution history, which nevertheless allows daily purging of the job monitoring screen (see"Execution history");

q Indispensable information concerning resource consumption by all jobs, whether batch or interactive (see"Statistics");

q Instantaneous view of all transfer or distribution operations performed on DOLLAR UNIVERSE objects,giving the global situation of the parameter settings in force at any one moment (see chapter entitled"Distribution logging").

Every task run under DOLLAR UNIVERSE is memorised. In each case, apart from the information useddirectly for automating operations, DOLLAR UNIVERSE stores a series of technical information concerningthe resources consumed by each task.

Execution historyJob monitoring makes it possible to follow the different phases in the execution of a task. Within thistransaction, events may be purged for convenience, as soon as necessary. Because of this, the job monitor cannot guarantee a complete history of executions.

Nevertheless, these same events are stored elsewhere as operating events. They will be used by the launcherduring the condition checking phase to verify the launch formula of each Uproc. For operations reasons, theseoperating events can themselves be destroyed manually or automatically from the Uproc completioninstructions.

DOLLAR UNIVERSE therefore manages a third level of history in which no random or manual purging ispossible, other than a systematic purge based over a defined retention period.

For instructions concerning the technical purging procedure, refer to the paragraph entitled "processing ofoperations parameters" in the present manual, and to the paragraph dealing with maintenance tasks in thetechnical manual.

Note: all launch attempts performed by DOLLAR UNIVERSE are recorded in this history file, to facilitatecomprehension, at a later date, of the sequencing events managed by DOLLAR UNIVERSE. If a given launchhas been through condition checking three times (following the arrival of expected events), the launch will appearthree times, with three different sequence numbers.

Available informationExecutions are marked by the identifiers of the different tasks: Uproc, session, M.U., And by their executionnumber. The information contained in the execution history therefore can identify:

q The task submission account, or the party requesting the launch (in the event of an intervention on anexpected launch),

q The launch mode of the task: this can have three values:

• "P" for schedule,

• "L" for interactive launch,

• "R" for relaunch,

q Dates and times of start and end of execution,



q The final status code of the execution,

q Breakdown of the technical information linked to the task (batch queue, launch window etc.),

q The values of the variables,

q The trace formatted by DOLLAR UNIVERSE during execution of the task.

StatisticsFor each job run, DOLLAR UNIVERSE memorises the consumption of essential resources (CPU, direct andbuffered I/O, memory, elapsed time etc., Depending on the operating system), the elapsed time of the lasthundred job runs and calculates the median values.

This method of calculation provides values corresponding to 50% of job runs. It also limits the impact ofexceptional, insignificant results on the values calculated. All this data can be displayed interactively ingraphic form. To allow precise execution-time simulations, they can be updated (removal of "rogue values",creation of estimated values for new jobs never before executed).

Update functions are used only where an intervention is required on the statistical values of certain tasks inorder to modify the behaviour of other DOLLAR UNIVERSE functions, particularly simulation. Only the"histogram" function does not respect this rule, since it consists in a graphical display showing changes intask-resource consumption over time.

q The creation function is necessary for initialising all the parameters managed for a new task.

q The modification function allows partial alteration of all available data for a given task.

q The deletion function allows complete destruction of a task in the statistics, while the cancellationfunction serves for initialising the statistical values of a task.

Purging

Operating events fileThe operating events file is fed by the execution of Uprocs that have been declared as memorised. Dependingon the memorisation parameters declared during definition of the Uproc, one or all of its job runs will bearchived over the number of periods indicated. Since this file serves for conditioning other procedures, caremust be used when purging it.

An automatic purge can be performed using completion instructions. These are meant to purge certain eventsat the end of a Uprocs execution. A manual purge can also be performed, by selecting events then deletingthem from the file.

Job monitoringJob monitor records are purged manually. This means that all occurrences selected will be purged andtherefore 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 onnormal operating. It can only prevent the re-start of an execution which has been purged.

Jobs purged from the job monitor will remain present in the execution history and, if they are memorised, inthe operating events file.

The execution of the purging Uproc enables deletion from the job monitor of any remaining records from priorto the purge date.



The job monitor can equally be purged by means of a purge command which allows more precise selectionthan the purging Uproc. See the commands manual for details of its use.

History filesHistory files are purged by a batch Uproc delivered with DOLLAR UNIVERSE. This procedure must bescheduled at least once a month. It will purge the execution history of any operation whose retention periodhas expired.

Since the 4.3 version of DOLLAR UNIVERSE , when purging job runs, the execution history file do notretains the last execution of any given procedure, irrespective of its date. This Uproc must be scheduled andexecuted for each area of the company. Scheduling of this special procedure must not specify a processingdate.

Refer to the administration manual for more details.

Log filesDOLLAR UNIVERSE generates several log files:

q The DOLLAR UNIVERSE general log declared during installation (except for OS400),

q Process operation logs (declared when configuring the company),

q The execution log for each procedure.

These log files are not purged automatically by DOLLAR UNIVERSE, but left to the administrator, who cantherefore allow for his own operations constraints.

Refer to the administration manual for more details.


Reference manual Glossary • 111

Glossary

1st Scheduling DateCorresponds to a startup date. According to the scheduling parameters, the calculatormay reiterate its calculation until a scheduling date greater than the first schedulingdate is found to generate the first launch of this task.

AbortedStatus of an execution which ended abnormally, either via the application positioningof the script exit value (see completed status), or via a sudden exit from scriptexecution.

Application DateDate beginning with which the calculation of the rule applies (indispensable, forexample, for a rule invoking a two week period: the week with which the calculationbegins must be known).The application date must correspond to a period start date defined for the rule. Forexample for a "week" period rule, the application date must be a Monday.

AreaWork environment within a company.Four Areas are proposed and named: Application, Integration, Simulation andProduction. The production area is the only one that must be started up. The othersare optional.The areas are sealed, secured operating environments but featuring interactiveconfiguration transfer functions (within the same company).

CalculatorThe calculator is an engine specific to an area. On an occurrence basis, it calculatesthe next scheduling date for each of the tasks and updates this schedule each timetheir planned launch window has expired or in the event of a task or attachedcalendar change.

CalendarDefines the types of days: working, not worked, and holidays over a range of yearsfor a management unit, the types of management unit or by default the area (this isthe general calendar, it is unnamed).The calendar is used by the calculator engine as a reference to calculate thescheduling of tasks.


112 • Glossary Reference manual

CompanyThe company represents a DOLLAR UNIVERSE installation and consequently awork (data) environment for the automation of production. The company is a securedoperating environment that can only communicate through its configurationimport/export commands.

CompletedStatus of a properly completed execution. This status is obtained by:

• "exit 0" from the UPROC script under UNIX,

• "S_RESEXE==V" in the DCL under VMS,

• "set RESEXE=0" in the command file under Windows.Any other UPROC script exit status yields an aborted execution status.

Condition CheckExamination by the launcher engine of the UPROC execution conditions andpossibly putting the launch on standby if the conditions are not met.During a condition check, the status of the launch is "condition check", if theconditions are not solved the status of the launch becomes "event wait", if theconditions are solved, the launcher proceeds with processing submission.

Drag & DropGraphic method used to retrieve an object to move it or copy it in another location(entry field, graphic area, etc.). It is performed using one of the 3 methods describedbelow depending on the hardware or operating system used:When an object has been selected (color change or reverse video):1. By maintaining the central mouse button (for 3-button mouse) pressed,2. By maintaining the 2 mouse buttons (for 2-button mouse) pressed,3. By simultaneously pressing the left mouse button and Ctrl (for Windows) on the

keyboard,You can move the object (the cursor of the mouse changes) to the reception site. Ifthe reception is refused (because this is not the intended site) the object returns to itsinitial location.

Event WaitStatus of a launch in its launch window whose launch formula has not been entirelysolved.

ExchangerThe exchanger is an engine specific to an area. It is used in network communicationswithin a DOLLAR UNIVERSE company to perform configuration distribution,network event transmission or network submission order operations.

Floating MenuBy placing the mouse in the left list of a window and clicking on the right mousebutton you can access a floating menu in which you may select an action to beperformed. The object on which the action is to be performed must be selected in thelist beforehand unless the Create option is selected.A floating menu is also available in a graphic area.


Reference manual Glossary • 113

Functional PeriodProcessing frequency in the application sense (e.g. a balance sheet is monthly)possibly distinct from the processing scheduling frequency. The functional perioddefines the format of the processing date (daily, weekly, monthly etc.).

LaunchA launch is an occurrence of the calculation of a task. It may be the result of thescheduling by the calculator or of an explicit creation request by an operator, or of aninvocation (via session progress or a command).

Launch FormulaBoolean equation uniting the conditions necessary for the execution of a UPROC.This formula may contain all the types of conditions: chaining, non-simultaneity orresource linked by the boolean operators AND, OR and NOT. It may contain up to99 conditions and 9 levels of parentheses.The order of the launch formula determines the order of the condition check by theLauncher engine.

LauncherThe launcher is an engine specific to an area. It schedules launches on the basis ofevents. It works mainly with the date and time of the next launch, at which time itreactivates itself and performs the condition check and processing submissionoperations.It is also reactivated by events attached at the end of processing execution to run newcondition checks.

Management UnitLogical work environment of the application tools. One or more management unitscan 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 M.U. typesallows the processing to be configured generically (for example "all type A M.U.s").Configuration thus becomes independent of the physical configuration of thearchitecture.

NodeLogical title (limited to 10 characters) representing a physical machine.The uxsrsrv.sck file of the mgr directory of the Company provides thecorrespondence between the NODE name (in the DOLLAR UNIVERSE sense) andthe physical name of the machine (in the operating system sense).

OverrunStatus of a launch whose condition check by the launcher was unable to result in asubmission during the launch window defined for it.

Processing DateDate qualifying the period for which the UPROC works. The processing date may bedifferent from the processing scheduling date (e.g.: for scheduling on February 3, theprocessing date may be calculated automatically via an algorithm defined by thecustomer as being the preceding month, that is January 1st).The processing date is usable in the UPROC script in a variable or in conditioningbetween UPROCs.


114 • Glossary Reference manual

ResourceA resource is used to describe, via a logical identifier, a system resource (a file forexample) 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 realitybut is managed by notions of exclusivity or quota assignment (with respect to amaximum).

RulePeriodic algorithm (of the day, week or month type) allowing the scheduling dates ofa task to be defined. The rules work on the management unit calendar for which theconcerned task is executed (if it does not exist, the calendar of the type ofmanagement unit and the general calendar of the node are sought).

SelectTo select an object of the graphic interface, click on the line of the object with theleft mouse button. If the object is part of a list, the selection is made in the left list;the line appears in reverse video. If the object is selected in a graphic area it changescolor.

SessionA session is a homogenous set of UPROCs (e.g.: same scheduling). It is used todescribe a UPROC submission order and to define downgraded processes in theevent of a UPROC execution incident.

SubmissionIf a UPROC launch formula is solved, the launcher submits the execution of theprocessing to the batch queue manager or in its absence to the operating system.

SupervisorThe supervisor is the only engine common to all the areas on a node. Its function isto supervise the resources on launcher request when it examines a UPROC whoseresource condition is not met. The supervision process is cyclical, according to aperiod defined for each resource.

TaskTechnical and execution scheduling characteristics of a UPROC or a session on amanagement unit. Three types of tasks can be defined:

• Scheduled task: periodically or via the scheduling dates

• Optional task: to set up an exception in periodic scheduling

• Provoked task: to be triggered "on request" or to set up an exception in thetechnical characteristics of a scheduled task.

The calculator generates a launch on the basis of the definition of a task.

UPROCObject used to define, around a command file (script, DCL, CL, .bat), all theapplication conditions necessary to the execution of the processing (inter-sessionchaining, file standby, parameters, processing date etc.) except for the technical andtemporal execution conditions.


Reference manual Index • 115

Index

$

$Uaccess control 13architecture 13batch management 8batch queues 8central monitoring 15client-server 13co-operative architecture 14customisation 35description of a job stream 9distributed architecture 14environment 19features 8Implementation 12interfaces 15job description 9job monitoring 8modification operations 81objectives 7parameters distribution and

transfer 15scheduling 9security 12sequencing 11simulation 12statistics 11technical locking on objects 81

A

Access controlprinciples 13

Access pathrestoration in the CL 32

Add years in a calendar 68Allocate

a transaction of $U 36Application

definition and use 32definition of the area 22directories table 32use in coding of Uprocs 44

Architectureco-operative 14distributed 14secure operations 13

Areadefinition 19, 22distribute an object within an

area 83location of batch engine 90management by version of

session 82management by version of

Uproc 82node authorisation 31transfer of an object to an area

82use in resource identifiers 42use of the management unit 23

Author codedefinition 35use 38

Automatic restartdefining for a task 75

B

Batch enginecomponents 90consequences of a system

failure 102execution phases 91functional architecture 89job completion 100location of components 90role 89

role of the supervisor inresource conditions checking98

submission and conditioning oftasks across network 101

working principles of thecalculator 91

working principles of theexchanger 101

working principles of thelauncher 92

Batch envelopeadditional processing 100role 99

Batch queuemanagement 106

C

Calculatorimpact of modifications of a

task 92role 90working principles 91

Calendardistribute a model 84distribution history 85distribution to MU 83impact of modification on tasks

69impact of update on task

schedule 91minimum range 68model 68presentation 10principles of generation 68purpose 67transfer to an area 82type of days 69

Central monitoringcompletion role 100


116 • Index Reference manual

defining in a task 75definition of the central monitor

node 30purpose 103role of the exchanger 101updating at launch 94

Chronology conditionpurpose and definition 59

CLdefinition 44description 45insert a message in the history

trace 105use of commands 46version management of internal

Uprocs 82Class

example 43purpose 43use 43verifying at launch 61

Client-serverprinciples 13

CodingMU and MU type 24of tasks 71of Uprocs 44sessions 63

Command$U specific commands 105use in the CL 46

Command file see CLCompany

definition 19, 21editor, object locking, master

node, directory 21independence of companies 21location of batch engine 90role 21use in resource identifiers 42users table 35

Completionrole 100

Completion instructionscompletion role 100consequences of a system

failure 102definition 44general characteristics 52network operation 62purge events 108purpose 62purpose and operations 62using the notion of MU 53using the notion of processing

date 54

using the notion of session 52using the user account 55

Conditionchronology 59definition 51expected or excluded 55fatal - definition 56fatal - processing in the launch

formula 61general characteristics 52network operation 62non simultaneity see non

simultaneity conditionresource see resource conditionrole of conditions in the launch

formula 61sequence see sequence

conditiontext if proposition satisfied or

not 56use of memorised Uprocs 50using the notion of MU 53using the notion of processing

date 54using the notion of session 52using the user account 55

Condition checkacross network 101bypass condition check of a

launch 94consequences of a system

failure 102examination of incompatibility

classes 43forced run 93network operations 96operations 97previous launches 105principles 92priority 99role of the exchanger 101

Condition of non-simultaneitydifferences between

incompatibility classes andnon-simultaneity conditions43

Condition of resourceoperating principle 98

Create years in a calendar 68Current version of an Uproc 82Customise $U

profile features 36recommendations 36restrictions 36user menus 37

D

Dateexception date 77explicit 76first schedule date of a task 76of application of a rule 76

Day of scheduling 70Days in a calendar 69Deallocate

a transaction of $U 36Deferring launch

execution of a provoked task 77use of provoked task 73

Definitionapplication and domain 32areas 22author code 35automatic restart of a task 75batch engine 89batch queue of a task 74calendar 67calendar model 68calendar range 68calendar type of days 69central monitor node 30central monitoring in a task 75chronology condition 59company 21company, area, MU 19completion instructions 44condition 51current version of an Uproc 82fatal condition 56forced launch at end of window

of a task 75hierarchical data processing

(HDP) 24internal CL or external CL file

45JOBD (job description) 74launch window 77launching a task 44management unit 22master node 30memorised Uproc 50MU dependencies 24MU Type 24node, logical node, physical

node 29non simultaneity condition 58normal or abnormal processing

path of a session 65optional task 73previous launches 105print queue of a task 74



priority of a task 74processing date 78provoked task 72resource 41resource condition 60resource reference 41scheduled task 72scheduling rule 70sequence condition 57session 63session header 63submission account 38successor 51task 71task model 72Uproc 44Uproc parent, child or per in a

session 63user account 74user profile 35, 36variables 47variables in a task 75

Dependenciesexamples 25

Diagnosticlog file 105

Directoryaccess path to applications

objects 32access path to MU objects 33access path to objects 32company 21company on a node 31MU or application – restore in

the CL 46of a CL associated to an Uproc

45Disable

a task 92Display history trace

in the job monitor 105Display previous launches

in the job monitor 105Distribute

a model 84a table 84

Distributioncalendar model 68history 85node - impact on central

monitoring 30object locking 84principles 15, 83role of the exchanger 101status 85task model 72

to a local MU 84Uproc with internal CL 45using MU Type 24

Domaindefinition and use 32use in coding of Uprocs 44

EEditor

definition in the company table21

to write the CL 46Elapsed time

of execution in forecastworkload 86

Enablea task 92

Environmentpresentation 19restoration of access paths

stored in the tables 32structure 19submission account 38submission accounts 38user accounts 35

Eventcompletion role 100creation by the batch engine 91description of the event file 96list of status values 104memorised Uproc 50network operations 96purge by completion

instructions 62purge in the events file 108purge in the job monitoring 108using 96

Examplechronology conditions 59completion instructions 62excluded condition 55fatal condition 56incompatibility class 43memorised Uproc 50modify a calendar 69MU, MU type, dependencies,

HDP 25non simultaneity conditions 58processing date 78resource 42scheduling rule 70sequence conditions 57use of HDP in a session 65use of HDP in conditions 53

Exception of scheduling within asession 64

Exchangerrole 90, 101submission and conditioning

across network 101Excluded

characteristic of a condition 55Exclusivity

use in resource conditions 60EXE

value 32Execution

consequences of system failure102

display history trace 105display previous launches 105history file 107kill 105list of status 104possible values of status 96recover 105

Execution environment of asession

using HDP or the MU 65Execution report

history trace 105insert a message from the CL 46log file 106text if proposition satisfied or

not 56Execution status

use in completion instructions62

use in sequence conditions 57Expected

characteristic of a condition 55Explicit

add or cancel dates 76scheduling 67scheduling a task 75

ExternalUproc CL file 45

F

Failureconsequences of system failure

102Fatal condition

definition 56processing in the launch formula

61FIC

value 33File manipulation



use commands in the CL 46Forced launch

bypass condition check 94defining in a task 75

Forecast workloaddisplay the session components

86launch window 86manipulation 86objectives 86simulation of schedule 85tasks executed on a remote node

86Functional period

calculation of the processingdate 78

definition 48use 49use in chronology condition 59use in conditions and

completion instructions 54use in non simultaneity

condition 58use in sequence condition 57

H

HDPconvention and use 24definition 24examples 25use in a session 65use in CL 46use in condition and completion

instructions 53use in non simultaneity

conditions 58use in resource conditions 60use in sequence conditions 57

Headerfirst Uproc of a session 63scheduling a session 64

Hierarchical data processing seeHDP

History fileavailable information 107distribution and transfer 85executions 107interventions on launches 95overview 107purge 109

History tracedisplay in the job monitor 105insert a message from the CL 46text if proposition satisfied or

not 56

I

Identifierinterface with provoked tasks 73

Implementationprinciples 12

Implicitallocating of rules to a task 76examples of scheduling 70scheduling 67scheduling a task 75scheduling rule 70

Incompatibility see ClassInheritance

MU of execution within asession 65

of technical characteristics –exception of the provokedtask 73

of technical characteristics ofthe task within a session 64

Inhibit execution of Uproc forgiven period see Chronologycondition

Integrationdefinition of the area 22

Inter MU checkprinciples 53

Inter processing date checkprinciples 54

Inter session checkprinciples 52

Interfacewith provoked tasks 73

Interfacesof $U 15

InternalUproc CL file 45

J

Job logdisplay the log in the job

monitor 106Job monitor

display history trace 105display in the job monitor 106display previous launches 105job queue management 106kill a job 105kill an execution 105purge 108purpose 103

Job queuemanagement 106

JOBD

defining 74

K

Killan execution 105

L

Launchcancelling 95condition check 97conditions of analysis of launch

formula 61definition 44extension of launch window 93holding or releasing 94impact of a fatal condition 56impact of the notion of

successor 51interventions on launches

history 95list of status 93manual launch of a task 94operations 94origin of launch 93possible launch modes 71possible values of status 96previous launches 105processing of Uproc successors

51purpose of execution events 51purpose of the launch formula

61updating 94

Launch formulaexample with chronology

conditions 59example with non simultaneity

conditions 58example with sequence

conditions 57limits 62optimisation hints 61purpose 61

Launch windowextension 93in forecast workload 86of a provoked task 77superimposing launch windows

80updating at launch 94

Launch windowdefinition 77multiple executions 77single job run 77



Launcherrole 90working principles 92

Limitsmaximum number of Uprocs in

a session 66maximum number of conditions

in a launch formula 62Linking two Uprocs see session

see sequence conditionLocking

declaration in the company table21

functional on objects 84technical on objects 81

Log filediagnostic tool 105display in the job monitor 106purge 109

M

Management unitand the areas 23calendar 67coding 24definition 19, 22definition of MU Type 24distribute objects 83examples 25involvement in HDP 24MU Type definition 24objectives 14scheduling environment of a

task 71use 23use in condition and completion


conditions 58use in resource conditions 60use in resource identifiers 42use in sequence conditions 57using dependencies in the HDP

24using for defining the execution

environment of a session 65Master node

declaration in the company table21

definition 30Memorisation

characteristics 50definition 50

Menuscustomise 38

Modeldistribute 84of calendar 68of task 72

Modifyorganisation of $U menus 37the priority in a job queue 106

Monitoring see Job monitoringMU

directories table 33MU dependencies see HDPMU type

calendar 67distribution restriction of

calendar 68examples 25role, definition and coding 24

NNature

of resource 41Network

location batch engine 90Node

access path to applicationsdirectories 32

access path to MU directories33

area authorisation 31calendar 67central monitoring 30company directory 31definition and use 29master 30user accounts 35, 37

Non-simultaneitydifferences between

incompatibility classes andnon-simultaneity conditions43

purpose and definition of thecondition 58

use the incompatibility classes43

Normal or abnormal paths in asession 65

Number of executions per periodmemorised Uproc 50

Number of functional periodsmemorised Uproc 50

O

Objectdistribute 83

transfer principles 82Offset of scheduling 70Operating date

use of functional period 48Operations monitoring

objectives 11Optional task

definition 73display in the forecast workload

86Order the examination of Uprocs

waiting an event 51

P

Parameterstransmission to Uprocs 46

Pathnormal or abnormal in a session

65Period of scheduling 70Previous launches

display in the job monitor 105Print queue

defining in a task 74Priority

defining in a task 74modify a job queue on VMS

106Processing date

definition 48purpose and definition 78updating at launch 94use 49use in chronology condition 59use in conditions and

completion instructions 54use in non simultaneity

condition 58use in resource condition 60use in resource identifiers 42use in sequence condition 57

Productiondefinition of the area 22

Profiledefinition and use 35definition, role and use 36of a user 37

Propositioncondition element 55text if proposition satisfied or

not 56Provoked task

deferring launch 73definition 72



display in the forecast workload86

exception of inheritance oftechnical characteristics 73

interface with applications 73Public holidays in a calendar 68Purge

events 62, 108events in the job completion 100histories 109job monitoring 108log files 109with completion instructions 62

Q

Queue batchdefining in a task 74

Quotasdefinition and use 41use in resource condition 60

RRange

minimum for a calendar 68Recover

an execution 105Report

history trace 105of execution - display in the job

monitor 106Reservation

of a logical resource 99Resource

coding with MU Code,processing date, company orarea 42

definition and use 41distribution history 85identifier, nature and quotas 41reservation of a logical resource

99restriction on use of variables 42

Resource conditionoperating principle 98purpose and definition 60

Resource reference see ResourceRestart mode

updating at launch 94Robot process see Batch engineRules

presentation 10Running a task

purpose of launch 51

S

Scheduled taskdefinition 72

Schedulingcalculator operations 91consequences of a system

failure 102definition 71effective scheduling date 76examples of rules 70exception of the optional task

within a session 73explicit 76explicit or implicit 67generation principles of

calendar 68impact of updating calendars 69implicit

application date for a rule 76implicit or explicit 75inheritance within a session 64launch window 77objectives 9presentation 8, 10purpose of the calendar 67scheduling rules 70

Scheduling ruleexamples 70presentation 10purpose and definition 70

Securityobjectives 12

Sequence conditionpurpose and definition 57

Sequencingobjectives 11

Sequencing Uprocsusing sessions 65

Sessioncoding 63definition 63definition of paths 65display in the forecast workload

86distribution history 85distribution to MU 83first run 96inheritance of scheduling of

header 64management of versions by area

82maximum number of Uprocs 66presentation 9scheduling 71structure 63

transfer to an area 82use in condition and completion


condition 58use in sequence condition 57using HDP or the MU 65using MU Type to distribute 24variables 65

Session headerscheduling 64

Simulation see Forecast workloaddefinition of the area 22presentation 12

Statisticspresentation 11purpose 108use by forecast workload 86

Statusof executions 104of launches 93of the distribution or transfer 85possible values for a launch or

an execution 96use in non simultaneity

conditions 58use in sequence conditions 57

Stepsdefine in the CL 46

Stopan execution 105

Structureaccess path to applications

directories 32access path to MU directories

33Submission

across network 101role of the exchanger 101

Submission accountdefinition 38

Successordefinition 51processing by the launcher 51purpose 51

Supervisorpurpose for resource conditions

98Suspend

temporary the task execution 92System failure

effect on executions 102extension of launch window 93



T

Tablesapplications directories 32company 21distribute 84distribution history 85management unit 22MU dependencies 24MU directories 33user accounts 35, 37using MU type to distribute 24

Targetof the distribution 84

Target of a conditioninter MU check 53inter processing date check 54inter session check 52user account 55

Taskapplication date of a scheduling

rule 76cancelling a launch 95defining JOBD 74defining the automatic restart 75defining the batch queue 74defining the central monitoring

75defining the print queue 74defining the priority 74defining variables 75definition 71distribute a model 84distribution history 85distribution to MU 83enable/disable - impacts 92execution phases 91explicit scheduling 76extension of launch window 93first run 96first schedule date 76forced launch at end of window

75forced run 93holding or releasing the launch

of a task 94implicit or explicit scheduling

75inheritance within a session 64interventions on launches

history 95launch window 77list of execution status values

104list of status of launches 93manual launch 94

model 72optional 73origin of launch 93processing date 78provoked 72schedule 72scheduling rules 70superimposing launch windows

80transfer to an area 82updating the launch 94user account 74

Text if proposition satisfied or notdefinition and use 56

Transactioncustomise the menus 38definition 36purpose 37user menus 37

Transferhistory 85object locking 84principles 15, 82Uproc with internal CL 45

Trigger a Uprocfrom the CL 46

Type of days in a calendar 69Type of resource 41

U

Universeuse of the management unit 23

Updateof a calendar - impact on tasks

69scheduling rule - impact on

scheduled tasks 70Uproc

chronology condition 59coding 44completion instructions 62define the variables 47definition 44definition of the current version

82distribution history 85distribution to MU 83execution conditions 51functional period 48general characteristics of

conditions and completioninstructions 52

impact of successors on launch51

insert a message in theexecution report 105

internal or external CL 45launch formula 61management of versions in

relation to areas 82maximum number in a session

66memorisation 50non simultaneity condition 58parent, child or peer in a session

63presentation 9purpose of incompatibility class

43purpose of the processing date

78repetition in a session 63resource condition 60restoration in the CL of access

paths stored in the tables 32scheduling 71sequence condition 57transfer to an area 82transmitting parameters in the

CL 46using fatal conditions 56using MU Type to distribute 24using the classes 43write the CL 46writing procedure 45

Userauthor code 35, 38presentation 35profile features 36submission account 38transactions of a profile 37use in non simultaneity

conditions 58use in sequence conditions 57

User accountdefining 74use in conditions and

completion instructions 55User profile

customisation 38purpose 37

Username see User

V

Variablesdefining in a task 75defining in the session 65definition 47



in the Uprocs - characteristics48

in the Uprocs - objectives 47in the Uprocs - value 48restriction on use in a resource

42updating at launch 94

Versionmanagement by area (session)

82management in relation to areas

(Uproc) 82of CL for Uproc with internal

CL 45

W

Workload simulationfunctions 87limitations 87objectives 87step-by-step mode 88



ORSYP Addresses

ORSYP France S.A.Tour Franklin

101 quartier Boïeldieu92042 Paris la Defense cedex

Tel : 33 [0]1 47 73 12 12Fax : 33 [0]1 47 73 12 10

ORSYP Software Inc.54 Middlesex Turnpike

MA 01803 BURLINGTONUSA

Tel . : 1 [781] 276 4600Fax : 1 [781] 271 0947

ORSYP Deutschland GmbHSteinhof, 5

D-40699 ERKRATH

Tel . : 49 [0]211 24 50 15 00Fax.: 49 [0]211 24 50 15 20

ORSYP Espanac/Orense, 85

E-28020 Madrid

Tel: 00 34 91 567 84 26Fax: 00 34 91 571 42 44

ORSYP Italia SrlCentro Direzionale Villa Fiorita

Palazzo DP.zza Maestri del lavoro, 7

20063 - Cernusco s/Naviglio

Tel: + 33 02/9273111Fax: + 33 02/92731122

ORSYP UKSussex House, 6 The Forbury

ReadingBerkshire RG1 3EJ

Tel . : 44 [0]118 9253 277Fax : 44 [0]118 9253 278

E-mail : [email protected] site : http://www.orsyp.com

84094282 dollar universe reference manual ingles

Documents