Dollar Universe Reference Manual (Ingles)

Reference manual

DOLLAR UNIVERSE version 5 for 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

Table of contents Introduction

7

Functional objectives...................................................................................................... 7 Scheduling and sequencing ............................................................................... 8 Batch queues .................................................................................................... 8 Job monitoring ................................................................................................. 8 Overview ....................................................................................................................... 8 Job description ................................................................................................. 9 Scheduling ....................................................................................................... 9 Job sequencing and launching......................................................................... 11 Operations monitoring .................................................................................... 11 Execution statistics ......................................................................................... 11 Simulation...................................................................................................... 12 Security of operations ..................................................................................... 12 Distributed client-server operations................................................................. 13 Interfaces........................................................................................................ 15 Sequence of operations................................................................................................. 16 Administration................................................................................................ 16 Scheduling jobs .............................................................................................. 16 Operations control .......................................................................................... 17

Environmental concepts

19

Introduction ................................................................................................................. 19 Environmental concepts features..................................................................... 19 Presentation.................................................................................................... 19 Companies ................................................................................................................... 21 Definition....................................................................................................... 21 Independence of companies ............................................................................ 21 Additional characteristics of companies .......................................................... 21 Areas ........................................................................................................................... 22 Management units ........................................................................................................ 22 Definition....................................................................................................... 22 Management unit types ................................................................................... 24 Hierarchical data processing ........................................................................... 24 Implementation of management units.............................................................. 25 Nodes........................................................................................................................... 29 Definition....................................................................................................... 29 Central or local administration ........................................................................ 30 Additional characteristics of the node.............................................................. 31 Declaring the applications environment ........................................................................ 32 Applications and domains............................................................................... 32 Application or MU directories......................................................................... 32

Users

Reference manual

35

•3

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

General ........................................................................................................................ 35 Recognised users ............................................................................................ 35 The author code.............................................................................................. 35 Development users....................................................................................................... 35 Transactions of the character interface ............................................................ 36 User profiles................................................................................................... 37 Customization of profiles................................................................................ 37 Submission accounts .................................................................................................... 38 Definition....................................................................................................... 38 Using the author code ..................................................................................... 38

Parameters

41

Resources..................................................................................................................... 41 Definition....................................................................................................... 41 Codification ................................................................................................... 42 Incompatibility classes ................................................................................................. 43 Purpose .......................................................................................................... 43 Using incompatibility classes.......................................................................... 43 Uprocs ......................................................................................................................... 44 Definition....................................................................................................... 44 Procedures or programs (DCL, shell, CL, .bat)................................................ 45 Variables........................................................................................................ 47 Functional period and processing date............................................................. 48 Event memorisation........................................................................................ 50 Successors...................................................................................................... 51 Execution prerequisites ................................................................................................ 51 General features of conditions......................................................................... 52 Additional characteristics................................................................................ 55 Types of conditions ........................................................................................ 57 The launch formula ........................................................................................ 61 Completion instructions.................................................................................. 62 Sessions ....................................................................................................................... 63 Definition....................................................................................................... 63 Normal and abnormal processing paths ........................................................... 65 Execution environment................................................................................... 65 Carry-over of Uproc variables’values............................................................. 65 Storage limits ................................................................................................. 66

Scheduling

67

Automation of batch tasks............................................................................... 67 Calendars..................................................................................................................... 67 Calendar application environment................................................................... 67 Calendar model .............................................................................................. 68 Generation of holidays.................................................................................... 68 Calendar range ............................................................................................... 68 Types of day................................................................................................... 69 Impact of modifications on a calendar............................................................. 69 Scheduling rules........................................................................................................... 70 Definition....................................................................................................... 70 Examples ....................................................................................................... 70 Tasks ........................................................................................................................... 71 Definition....................................................................................................... 71 Task model..................................................................................................... 72 Types of task .................................................................................................. 72

4 •

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Refining the operations process

81

Manipulation................................................................................................................ 81 Updating ........................................................................................................ 81 Technical locking of objects............................................................................ 81 Version management.................................................................................................... 82 Uprocs............................................................................................................ 82 Sessions.......................................................................................................... 82 Changing environment ................................................................................................. 82 Transfer to an area .......................................................................................... 82 Distribution to management units.................................................................... 83 Importing and exporting data .......................................................................... 84 Functional locking of objects .......................................................................... 84 Distribution logging........................................................................................ 85 Simulation of scheduled tasks....................................................................................... 85 Objectives ...................................................................................................... 86 Workload forecasting...................................................................................... 86 Workload simulation .................................................................................................... 87 Objectives ...................................................................................................... 87 Simulation of forecast workloads .................................................................... 87

The operations process

89

Role of the batch engine ............................................................................................... 89 The automation process .................................................................................. 89 Components of the batch engine ..................................................................... 90 Location of the batch engine ........................................................................... 90 Submission across the network ....................................................................... 90 Execution phases of a task .............................................................................. 91 Job scheduling ............................................................................................................. 91 Operation of the calculator.............................................................................. 91 Impact of modifying a task ............................................................................. 92 Enabling - disabling of a task .......................................................................... 92 Sequencing and launching ............................................................................................ 92 The launcher................................................................................................... 92 The launch...................................................................................................... 93 Operations on launches ................................................................................... 94 Condition checking......................................................................................... 96 Uproc submission ........................................................................................... 99 Job completion ............................................................................................. 100 Inter-machine communications................................................................................... 101 Role of the exchanger ................................................................................... 101 Operating principles ..................................................................................... 101 System failures........................................................................................................... 102

The operations monitoring

103

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

•5

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

History files and statistics........................................................................................... 107 Execution history.......................................................................................... 107 Statistics....................................................................................................... 108 Purging ...................................................................................................................... 108 Operating events file..................................................................................... 108 Job monitoring ............................................................................................. 108 History files.................................................................................................. 109 Log files ....................................................................................................... 109

6 •

Glossary

111

Index

115

ORSYP Addresses

123

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Introduction

Functional objectives DOLLAR UNIVERSE is designed to meet several objectives, the main ones being to reduce the constraints weighing upon the technical organisation in charge of managing computer operations, and the quest for optimum reliability in the operations cycle. As a means towards these objectives, DOLLAR UNIVERSE offers : q

Functions covering the essential part of the central operations process, through which it allows, at any given 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 of the operations cycle and allowing automatic management of recovery processing sequences when incidents 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 physical configuration and the applications environment. The possibilities offered by DOLLAR UNIVERSE reduce the number and scope of maintenance operations and increase the resulting quality of the operations process.

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

Remote distribution

Batch scheduling Batch submission Operations monitoring

Output management

Stages in the life cycle of a computer application

DOLLAR UNIVERSE proposes a series of functions for managing each of the themes presented in the above figure. The remote distribution and output management functions represent two modules that are independent from the automation module discussed in this reference manual.

Reference manual

Introduction • 7

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Batch queues DOLLAR 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 be provided by an additional DOLLAR UNIVERSE product: DQM (distributed queue management). This module provides a technical organisation of the production process, above and beyond the functional organisation provided by DOLLAR UNIVERSE, while dissociating the management of associated constraints.

Job monitoring DOLLAR UNIVERSE proposes a group of functions that allow dynamic tracking and intervention in the operations process. Built around a screen displaying current processes, the job monitoring function itself represents a veritable work station, allowing the operator to monitor all his jobs without ever losing sight of the overall operations scenario.

Overview DOLLAR UNIVERSE aims to offer users a global automation solution, irrespective of the type of operations being undertaken. Within DOLLAR UNIVERSE, two essential notions can be distinguished: q

The company,

q

The management unit.

The notion of company means that, in a given computing environment, a single copy of DOLLAR UNIVERSE can manage the operations of several distinct companies independently. Thanks to its access control functions and its technical architecture, DOLLAR UNIVERSE allows totally hermetic separation of their operations. Within the company, DOLLAR UNIVERSE can handle distinct environments where several different operations scenarios will be run in parallel, as might be the case with a company using the same applications on different data. These environments are called management units. DOLLAR UNIVERSE can manage several thousand management units.

8 • Introduction

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Job description Elementary job description The description of a job rests essentially on identification of the procedure (DCL, CL, shell… ), definition of its 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 constraints using the logical operators: and, or, =, not =, ( and ). The use of free syntax in this expression, and the rich parameter-setting possibilities, means that the functional logic governing execution of the various jobs can be precisely transcribed. This makes it easy to run normal processing scenarios (i.e. Sequences respecting the normal processing path), as well as incident situations (degraded processing paths or recovery).

Description of a job stream From a more macroscopic viewpoint, DOLLAR UNIVERSE offers the notion of "job stream", referred to as a session, for procedures presenting homogeneous operations constraints (same scheduling conditions, for example). The session allows jobs to be ordered in a tree structure, whereby each job is told which jobs follow it in both normal and abnormal operating circumstances. The sequences so-defined within a session do not substitute for the dependencies defined at the individual job level, but rather supplement them. It is therefore possible to define (see "Elementary job description") the associated functional conditions for each job and, via the session, superimpose on these the execution sequence required by the operator. In so doing operations imperatives (time constraints, optimisation of resource consumption etc.) Can be integrated without 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 error conditions.

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

Scheduling Scheduling 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,

Reference manual

Introduction • 9

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

q

A series of execution frequencies called scheduling rules, either predefined or definable, depending on requirements.

Calendars Each 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 can always be modified. The work involved with calendar definition or maintenance is practically zero.

Scheduling rules The most common scheduling rules are supplied as a standard feature of DOLLAR UNIVERSE. It is still possible to define specific scheduling rules to meet particular cases. A scheduling rule is: 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 the calendar is not a workday, this date will be shifted to the first workday preceding or following the targeted date.

A scheduling rule can translate execution frequencies of the type: q

Every working day,

q

The first working Tuesday in each month,

q

Every 87 days etc.

Job scheduling DOLLAR UNIVERSE proposes two main scheduling methods, which can be used together if required, for handling recurrent and/or random runs: Implicit scheduling of the analysis of the execution cycle of the job in question, consists in: 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 150 launches per day, etc.), And a waiting period for the conditions to be met. After this interval, the execution will be abandoned or forced (option),

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 majority of foreseeable cases. By offering combined features such as: automatic generation of calendars; the possibility of mixing normal submission frequencies; processing of random cases via explicit schedules and exception 10 • Introduction

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

dates, DOLLAR UNIVERSE limits the amount of maintenance required by the operations schedule, while preserving the user's freedom of intervention.

Job sequencing and launching DOLLAR UNIVERSE provides dynamic sequencing and launch control for each job, based on acyclical processes that react in accordance with events detected in real time (date/time, end or start of job, change resource availability, updating of operations parameters etc.). It uses no permanent, predefined plan, but rather interprets, in accordance with the actual operations events occurring (and any interventions by the operators) all descriptive information concerning the various jobs, and their associated scheduling data. Thanks to this fully interactive approach, DOLLAR UNIVERSE means: 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 monitoring DOLLAR UNIVERSE affords particular attention to the tracking and supervision of operations with the sole aim of facilitating job monitoring, accelerating the identification and diagnosis of incidents, and permitting the necessary recovery procedures. There is a dedicated job monitoring function. 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 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 steps performed by the job and, in the case of jobs in an event wait state, the expected events. The history trace can contain comments or operator instructions transmitted from the command interpreter via a specific DOLLAR UNIVERSE command,

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 on the current operations process.

Execution statistics For each job run, DOLLAR UNIVERSE memorises the consumption of essential resources (CPU, direct and buffered 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.

Reference manual

Introduction • 11

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

In order to give precise simulations of execution times, it can be updated (removal of deviations, creation of estimated values for new jobs that have never run).

Simulation DOLLAR UNIVERSE offers several simulation functions, notably : q

Simulation of a single job schedule,

q

Simulated execution of a projected workload.

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

Simulate workload Using all available data, DOLLAR UNIVERSE can format an operations schedule, for a given duration and starting 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 the estimated duration (use of statistical information),

q

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

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

Security of operations Security of operations is one of the guiding factors behind the design and development of DOLLAR UNIVERSE. 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 applications For 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 technical or functional cycle. As a standard feature, DOLLAR UNIVERSE offers an interactive function allowing parameter settings to be debugged in one area, then moved by transfer to another area (transfer from the integration area to the simulation area, for example).

12 • Introduction

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Each interactive transfer of DOLLAR UNIVERSE objects is logged, an operation which essentially memorises: 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 (multicriteria selections such as date, job in question, operator etc.), They allow retrospective constitution of the development path of the parameter settings present in the production area, for example. The transfer history aims to facilitate the analysis of disparities between an expected parameters and the actual parameter setting.

Access control Before any connection takes place, each user must be identified by DOLLAR UNIVERSE principally to allow the allocation of a user profile. For each user profile, it is possible to customise strict rights of use of DOLLAR UNIVERSE. Access to each transaction and, within each transaction, the use of each option or function key may be individually authorised or inhibited. The resulting access control, coupled with menu definition functions (modifying the order of presentation of transactions in relation to the standard DOLLAR UNIVERSE menus) allows the functional scope of DOLLAR UNIVERSE to be tailored to individual needs. In addition, the secure dissemination of information of general interest (such as giving read-only access to the job monitor to certain developers or users, for example) facilitates communications between the data-center personnel and the other actors in the process.

Architecture Several 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 the dialogue at the same point. This approach is used to ensure that all tasks performed during operational parameter settings always complete correctly. In identical circumstances (system crash) the basic processes are designed 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 are separate permanent processes for each active area. The design and nature of DOLLAR UNIVERSE functions combine to facilitate methodical operations management within strictly delimited environments. Thanks to the customisation options, it is possible to offer each user a tool precisely tailored to his individual tasks. Such factors, combined with a structured and rigorous technical architecture, bring greater clarity to the overall operations process, while increasing the degree of operator control.

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

Reference manual

Introduction • 13

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Interoperability between DECNET and TCP/IP networks is available in DOLLAR UNIVERSE version 4.2 and later. DOLLAR UNIVERSE enables automation of job sequences spread across several machines, monitoring and condition checks from a central point, increased reliability, and optimisation of multi-site operations processes.

Distributed operations The management unit is DOLLAR UNIVERSE's major contribution to the management of distributed operations. A management unit can reside at any node on the network, provided the node is identified in the descriptive information 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 its essential 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 able to 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 at the time of submission does DOLLAR UNIVERSE translate the logical references into the physical reality of the network using the descriptive data of the management units. In this way, DOLLAR UNIVERSE allows the description of flexible processes able to adapt to configuration changes. Imagining an operations process that consists in running a job for all the sales offices within a company, most of the changes can be implemented without modifying the basic operations parameter settings. For example: q

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

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 necessary tools for remote distribution to all nodes in question.

Co-operative management of distributed operations The expression of conditions in the job descriptions can use logical expressions targeting the management units. In this way, it becomes possible to 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 of type z". In this case without needing to dispatch applications pseudo-files, DOLLAR UNIVERSE implements truly co-operative multi-machine management. It issues requests towards the nodes of residence of management units of the type in question, to determine if the condition is actually met. As soon as the expected event occurs, the requesting machine will be automatically informed.

14 • Introduction

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Central monitoring For each management unit, DOLLAR UNIVERSE defines whether the management unit in question is managed locally or centrally ; the latter case implies the definition of a central monitor node corresponding to this management unit. To limit the load on the network, and ensure processing of only that data which is strictly required for operations monitoring, each job contains a flag that indicates if it will be centrally monitored or not. The monitoring of operations on strategic tasks for the management units in question will be shifted to the node defined as central monitoring node. The operations monitoring function allows the dynamic display not only of the jobs in the local management units, but also the essential jobs in the centrally monitored remote management units. Monitoring of distributed operations can be extended to include definition of the operations parameters for the remote sites. To this end, DOLLAR UNIVERSE includes the notion of a parameter template, known as a model. A model is an inactive parameter setting which only becomes operational after distribution to a target management unit. The notion of model makes it possible to manage parameter settings for all distributed operations from a single node. It should also be noted that all DOLLAR UNIVERSE transactions boast interactive functions which allow the parameter settings of another node to be displayed, without logging in to the node in question.

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

Interfaces To 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,

Reference manual

Introduction • 15

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

q

Remote distribution packages...

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

Administration The administration enables the description of the working environment. It makes full use of the different concepts 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 jobs Jobs 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 form operations tasks that can be triggered indifferently by the user or automatically by DOLLAR UNIVERSE depending on predefined rules and calendars.

Defining Uprocs Each 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-requisites to execution. The Uproc is a developer's tool.

Defining sessions Uprocs combined in a single processing stream (session) benefit from the same schedule and may share the same 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 managed automatically. The job sequence in a session must not be confused with the Uprocs own execution conditions, which represent the applications element. The session is an operator's tool.

Defining tasks The operations task defines, for a given execution environment (management unit), and for each procedure (or set of procedures) : q

The technical execution characteristics,

16 • Introduction

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 explicit submission dates. It is supplemented by the possibility of determining a submission timetable which may vary with the day of the week. Finally, the task is applied to the calendar associated with each execution environment (management unit).

Defining calendars The notion of calendar accommodates differences in the organisation of work between one management unit and another (such as workdays, closing days or holidays), while maintaining homogeneous parameter settings for all management units. Thus, the calendar enables the processing schedule to be generated, but does not define it.

Defining rules In addition to the standard rules corresponding to the most common requirements, DOLLAR UNIVERSE proposes sophisticated algorithms allowing the customer to build his own rules, and so satisfy any desired periodicity.

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

Job monitoring The 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, or stop running jobs.

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

Reference manual

Introduction • 17

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Environmental concepts

Introduction Environmental concepts features The functions concerning the declaration of the environment and general administration of DOLLAR UNIVERSE, 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 of particular 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, an indispensable preliminary for automating applications procedures. It also introduces the administration of tables, allowing declaration of the applications environment, and use of this same declaration for the internal requirements of DOLLAR UNIVERSE. The "Users" chapter introduces the different interpretations of "user" within DOLLAR UNIVERSE, defining: q

how they are managed,

q

the access rights to the various transactions of DOLLAR UNIVERSE.

Presentation DOLLAR 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 production centres, 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).

Reference manual

Environmental concepts • 19

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

The above concepts are illustrated in the following figure: Company A Company B Application area Intégration area Simulation area Production area

MU1

MU2

MU3

The environmental concepts of DOLLAR UNIVERSE

The company represents the highest level in the concept of environment. Each company corresponds to a new installation of the product. It is possible to install a given company on several nodes, or several companies on a given node. Companies are sealed working environments that can communicate only through import/export of parameters. A company is divided into four distinct areas (applications, integration, simulation, production). Areas are also sealed operations environments which benefit, within a given company, from interactive transfer of parameters. Certain areas also accept the definition of object versions (Uproc and session). The following diagram shows the main objects managed by DOLLAR UNIVERSE, as well as their logical layout depending on the different environment concepts proposed. COMPANY

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

Development universe Application area § uprocs § data § logs

Integration area § uprocs § data § logs

Production universe Simulation area § uprocs § data § logs

Production area § uprocs § data § logs

Objects logical layout depending on environment concepts

The notions of area are not managed on an individual basis. The DOLLAR UNIVERSE tables will only be able to differentiate via the definition of the access paths to applications' objects and to data specific to each management unit. Finally, the entire logical environment is independent of the physical organisation of the computer systems and, consequently, exists on each node (machine) in the network. Moreover, since the co-operative architecture of DOLLAR UNIVERSE imposes no particular constraints on the organisation of the operators responsible for administering and monitoring operations (that is, no notions of "master" or "slave"), it is through the nodes themselves that the individual organisation of each context can be translated.

20 • Environmental concepts

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Companies The division of the environment into companies influences the organisation of the DOLLAR UNIVERSE tables. Tables defining companies and user accounts are unique for a given node, since DOLLAR UNIVERSE requires 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 as many sets of these specific tables as there are companies defined.

Definition The company is the highest level managed by DOLLAR UNIVERSE. At least one company must be defined at the time of installation of DOLLAR UNIVERSE. In many cases it will be the only company in a given configuration, 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. It ensures 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 companies Setting 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 clearly independent operations. In the case where such a strict dissociation is not necessary, the notion of management unit will allow the running of parallel operations. If several companies share a computer system, the various DOLLAR UNIVERSE functions will be able to work in the same way for each company, without any interference in individual operations or sharing of technical data. For example, DOLLAR UNIVERSE will manage each company's descriptive environment tables in totally independent files. For each listed company, DOLLAR UNIVERSE recognises the computer system sub-assembly (or the entire system) which it is allowed to access.

Additional characteristics of companies Each 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 allows defining of an editor which will be used for all DOLLAR UNIVERSE functions needing to access operating 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 chapter entitled "refining the operations process" for more information regarding the operating principles of this function).

q

Master node This information indicates the company's master node.

Reference manual

Environmental concepts • 21

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Refer to the heading "nodes" in this chapter for more information regarding the meaning of the notion of master node, and the related operating precautions. q

Company directory This information declares the physical location (directory name) of a company's various files (company specific 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 of DOLLAR UNIVERSE, which recognised a company's file locations in terms of universes (groups of paired areas); it therefore requires the same declaration in the two directories proposed for a given company. Since a given company can be installed differently on each node, it is wise to avoid distributing this table.

Areas In order to allow gradual testing of applications under development or maintenance in conditions that simulate production conditions as closely as possible, DOLLAR UNIVERSE offers four working environments known as "areas": q

Application area,

q

Integration area,

q

Simulation area,

q

Production area.

The application and integration areas are environments dedicated to the development of operations procedures. The simulation and production areas are reserved for computer production proper. In this respect, for certain areas, DOLLAR UNIVERSE manages different versions of the main objects (refer to 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 software gateway is available which makes it possible to switch areas, as well as options for transferring objects from one 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 Definition The management unit represents a logical working environment. It is present throughout all DOLLAR UNIVERSE 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 a management 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, in favour of the notion of management unit. A configuration, be it centralised or distributed, is seen as a single machine on which resides a set of management units. 22 • Environmental concepts

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Main features of a management unit: q

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

q

Forms the central element in the notion of distributed data-processing. The MU Allows the simulation of a distributed data processing architecture on a centralised architecture. Because of this, its presence facilitates changes of architecture for computer solutions (centralised architecture to distributed architecture 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.

Use In addition to the above mentioned possibilities, the following elements would tend to confirm the efficiency of the management unit concept. Computer operations require a permanent dual perspective regarding a company's data processing organisation: 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 the management units, delaying the translation of logical parameters into physical data until final execution of the data processes. This interpretation is made dynamically, acting on the descriptive information of the management units contained in the central tables of DOLLAR UNIVERSE. This flexibility gives operations processes 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 commercial statistics of sales offices at the regional office level: If the consolidation operation has to submit operations to run on each sales office environment, or copy files localised in each of the office environments in question, a change in the organisation of the offices (such as progressive increase in workload on an application, or switching of an office to a new machine etc.), Could have problematic repercussions. In most cases, procedures will have to be modified to take account of the new context. However, DOLLAR UNIVERSE avoids possibly repetitious maintenance operations on the existing processes. The only intervention required will consist in updating a central table designed to create a new management unit or modify the technical characteristics of an existing management unit. To offer a complete solution, DOLLAR UNIVERSE makes it possible to define hierarchical relationships between management units. These relationships could be established, for example, between a regional office and every sales office. This type of relationship is known in DOLLAR UNIVERSE as "hierarchical data processing", or HDP

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

Reference manual

Environmental concepts • 23

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Management unit types Management units may be grouped into types ("factory" type, "office" type etc.). The advantage of this type of classification is that objects (sales offices, for example), can be identified without having to be named individually. This generic addressing feature can be used : 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 the root of hierarchical data processing. It is an integral part of the management unit code, which it functionally characterises. 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-interest functions. Note : it may be useful to reserve a particular type ("N", for example) to designate management units present in a single version at a given node. The presence of these management units and a dedicated management unit type will facilitate the distribution of tables and other objects existing in a single version on a given node, irrespective of either the number of management units or areas present (for example, Uprocs or sessions). In this way, defining a management unit target to facilitate distributions for these types of objects would thus be limited to "N" (meaning "all management units of type "N"").

Hierarchical data processing Definition Hierarchical 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 described without prejudging the name(s) or the quantity of management units in question. This guarantees the stability of the parameters for operations undertaken within DOLLAR UNIVERSE, irrespective of any changes to the hardware configuration used (creation or concentration of sites), or the data organisation (creation or suppression of sales offices, for example).

Convention These generic expressions allow implementation of the information contained in the management unit types, and in the management unit dependencies, to be combined. Some examples of the associated convention may be given: 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,

24 • Environmental concepts

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

q

Trigger procedures from within another procedure.

They enable the correlation between execution of a Uproc on a management unit, and the execution of a Uproc on a sub-set of management-units. The generic expression is interpreted dynamically. Conditions using these expressions automatically take 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 units To help in understanding this logical representation of the environment, and demonstrate the power of the management unit concept, certain operating examples are given below.

Reference manual

Environmental concepts • 25

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

In the case of a manufacturing company Assuming a company built around a sales organisation comprising regional offices under the control of a head office, with the regional offices themselves controlling factories and sales offices. The immediate definition of management units for this organisation would consist in creating as many MU as there were entities (head office, regional offices, branch offices and factories). Each entity of a given type will in all likelihood employ identical, or at least similar, data applications. This similitude may be translated by attributing a common MU Type to the corresponding management units. The following management units could be created: 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 functional dependency between these entities. Consolidation of daily production information is done directly by head office, while sales statistics are initially aggregated at the regional level then at central level. The following diagram gives an example of such functional dependency:

Functional links between MU

This functional dependency can be translated into straight relationships of dependency between the management 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 lesser number of nodes, as illustrated below:

26 • Environmental concepts

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Distribution of MU dependencies within physical configuration

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

Example 1 : distribution of the "sales statistics" application to offices, or how to use the 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 this application. In parallel with distribution of the application, procedures defined within DOLLAR UNIVERSE will be distributed to all management units of type 'A'. The offices affected by this distribution are: A01, A02, A11, A12, A13. Thanks to this generic process, no office will be left out, and DOLLAR UNIVERSE will automatically ensure distribution 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 DOLLAR UNIVERSE, a processing stream is built as illustrated below.

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

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 been processed 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 update processing has been correctly performed on all the factories dependent on the region to which that office belongs. For example, in order for the statistics job to run on office A02, the stock process must have run correctly for factories U07 and U16. The same naturally applies for offices A01 and A11.

Reference manual

Environmental concepts • 27

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Example 4 : synchronising the statistics jobs with the logical stock situation, or how to 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 the day'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 entry processing has been correctly performed for all offices dependent on the current region. For example, in order for the statistics job to run on office A02, order processing must have run correctly for offices A01, A02 and A11. The same naturally applies for offices A01 and A11 Synchronisation of the resulting operations remains independent of the region of execution, or the number of offices.

Example 5 : synchronisation of the statistics job with price-book processing, or how to reverse dependencies in a synchronisation process Finally, the statistics job presented above will run only if the product price book has been delivered by the head office to each region (bearing in mind that the said price book may differ for each region). It therefore carries a sequence condition whereby the price book processing (retrieval of price book files generated at the central site) must have completed successfully for the region to which the office in question belongs.

This condition, using the HDP Convention "{R }", means the statistics job will wait until the price book processing has completed correctly for the region to which that office belongs. This convention implies the definition of a dependency (inverted in relation to the dependency defined previously), between each office and its associated region, as illustrated in the diagram hereafter (upwardpointing arrows"):

Thus, for example, in order for the statistics job to run on office A02, the price book processing must have completed correctly for region R01. Synchronisation of the resulting operations remains independent of the region of execution.

Documentation generating application This example concerns a batch application designed to generate multi-lingual documentation for various types of high-tech equipment. 28 • Environmental concepts

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

This application brings together a number of procedures using parameters to indicate the type of equipment in question and the language in which the documentation has to be generated as parameters. Thus the same processing stream will be executed for a set of management units based directly on the equipment type/language combination. This arrangement limits the number of processes to be defined in DOLLAR UNIVERSE, since the management units do much replacement (a given operation will run as many times as there are management units). The management unit is interpreted at the moment the procedure is executed; the management unit code has only to be translated into type of equipment and language code. Where certain jobs are common to all languages for example, a hierarchy could be set up between the different management units defined, to translate the need for synchronisation of the various procedures in question.

A permutation processing application This example considers a batch application designed to receive a very large number of files from various clients (such as mail orders, for example). The application requires special technical optimisation of the disk resources consumed. Considering the great number of files received each day, the aim is to distribute these to each disk of the receiving machine in order to balance the i/o of each disk during processing of the files. During handling of these files by the application, the latter will perform a given operation as many times as there are disks. In this example, management units will be used to declare each of these disks and have the procedures run as many times as there are management units of the "disk" type.

Use of MU to represent technical objects

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

Nodes Definition DOLLAR UNIVERSE is designed to automate distributed operations it lends itself naturally to cluster and network architectures. The node in the DOLLAR UNIVERSE sense has the same meaning as in the computing sense, designating a machine in a network. As mentioned previously, the notion of node is in fact hidden (in DOLLAR UNIVERSE parameters) behind the management unit to provide the greatest degree of flexibility in the operations process. The node then only serves as an object for DOLLAR UNIVERSE to recognise for translating the organisation of human resources (administration and operations monitoring), and for authorising the previously described environments (areas).

Reference manual

Environmental concepts • 29

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Central or local administration Master node Even if DOLLAR UNIVERSE benefits from a co-operative architecture and authorises at the same time either local or central administration, it nevertheless allows management of its administration tables to be limited to a single focal point thanks to the notion of master node. This arrangement is in many cases desirable on account of the importance of the information contained in these 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 being the 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 the administration tables will be impossible. They will have to be updated from another node, and then distributed. Note: the notion of master node is independent of the notion of central monitoring node. The following diagram illustrates the notion of master node; Node1

Node2

ADMINISTRATION company table Master = Node1

ADMINISTRATION company table Master = Node1

Distribution

Update

Consultation Node3 ADMINISTRATION company table Master = Node5

Use of the master node

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

Central monitoring DOLLAR UNIVERSE allows operations to be distributed over any number of nodes; because of this it also proposes 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 logical variable - Available on VMS, Windows and UNIX only) to upload to the central node only that information necessary 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 when installing DOLLAR UNIVERSE, it is possible to declare a central monitor node which will receive traces of execution of all tasks declared with the central monitoring flag.

30 • Environmental concepts

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Furthermore, it should be noted that only one node can be declared as central monitor node (in the node table), so that distribution of the node table to a set of other nodes will result in recognition by all the said nodes of a single central monitor node (possibly distinct from the master node). The following example illustrates this notion of central monitor node and the impact of the notion of master node. Node1

Node2

ADMINISTRATION company table Master = Node1 node table Central M. = Node2

Node table distribution

ADMINISTRATION company table Master = Node1 node table Central M. = Node2

Node8

Node3

ADMINISTRATION company table Master = Node8 node table Central M. = Node9

ADMINISTRATION company table Master = Node5 node table Central M. = Node2

Illustration of the notions of master node and central monitor node

Additional characteristics of the node Authorisation by area Authorisation to the development universe (application and integration areas) and the production universe (simulation and production) is determined in the node table. In this way, access can be limited to certain areas on, a given machine. Note: in order to avoid disparities between parameters, it is recommended to locate the development environment for the operations processes to a single development node, and distribute DOLLAR UNIVERSE objects from this node only. The following diagram illustrates this type of organisation: Production node

Development node Development Transfer

Production Distribution of parameters

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.

Directories Since DOLLAR UNIVERSE does not know beforehand the architecture of the target node, this information gives direct access to the target node's data and executables.

Reference manual

Environmental concepts • 31

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Declaring the applications environment Applications and domains Computer applications are generally reduced into sub-assemblies. The functional domain and the application are 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 can belong to the same domain.

The application and the domain are used by DOLLAR UNIVERSE for analysis and structure of all the Uprocs it manages. The definition of the Uproc is effectively linked to the domain and application codes, however, since the version 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 following basis: DAPXXX,

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

Application or MU directories The notions of areas and management units make it possible to define a logical organisation of the computing environment. Each of these notions can be optionally associated with the physical structuring of the overall environment, defined within the framework of the administration tables. This physical organisation is designed to allow meshing of the disk space using access paths to the directories where the main computing objects and data reside. Since DOLLAR UNIVERSE does not impose any particular constraints on this organ, it allows the individual norms 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 logical name,

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 the Uprocs, thanks to appropriate commands provided by DOLLAR UNIVERSE. Note: the environment definition is of course optional, save for DOLLAR UNIVERSE, which locates its own data and executable programs through these tables.

Application directories DOLLAR UNIVERSE can manage access paths to the programs (or other assimilated objects) of applications in terms of node, universe or application.

32 • Environmental concepts

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Unlike data, for which it is possible to distinguish access paths area by area, DOLLAR UNIVERSE manages program directories only in terms of universe (production or development). Furthermore, this declaration is independent of the management units resident on the node in question, since the objects are independent of the data on which they operate, and consequently, common to the management units with which they serve. The corresponding table can be defined centrally and then distributed to each of the nodes, needing knowledge of the application environment described.

MU directories For 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 an access path to the application-specific data for the management unit in question. The corresponding table can also be defined centrally and distributed to each of the nodes, needing a knowledge of the applicational environment thus described.

Reference manual

Environmental concepts • 33

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Users

General Recognised users DOLLAR UNIVERSE distinguishes two main types of user: q

Users of DOLLAR UNIVERSE interfaces developers,

q

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

(character, commands, Motif and Windows), called

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 DOLLAR UNIVERSE functions and data. Defining user profiles makes it possible to organise individual work stations in DOLLAR UNIVERSE to suit actual user requirements. Profiles also allow different menu structures to those offered by the standard DOLLAR UNIVERSE configuration to be defined, allowing menus to be configured for optimum user friendliness (character and Windows interfaces).

The author code Prior to logging on, each user must be known to DOLLAR UNIVERSE. This identification is managed by a user record in the “user table” which in turn points to a user profile and an “ author code “. The author code is a trigram (signature) that characterises a username. It serves as a reference to identify the account to use and for running a task in DOLLAR UNIVERSE (see paragraph "Submission accounts" for more information).

Development users In 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 the character, commands, Motif and Windows interfaces.

Reference manual

Users • 35

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Transactions of the character interface Not available on Windows. As a standard feature, DOLLAR UNIVERSE proposes its various constituent transactions, together with the list of options and possible function keys. It is important to note that a transaction may consist of a single program; alternatively, the larger transactions may comprise a tree structure containing programs which overlay, 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 up other programs (expected launches, motor control etc.). These programs form the second level of the tree structure described above; it should be noted that certain programs may be directly associated with a transaction, or on the contrary, called from another transaction by implementing an option or function key. As an example, motor control forms a transaction as such, which can be called using an option in the job monitor transaction. The administrator can himself customise the DOLLAR UNIVERSE standard transactions by allocating or deallocating the options or function keys associated with a program. Nevertheless, these possibilities are limited to the first two levels of the program tree structure of a given transaction.

Recommendations For obvious reasons related to open-ended-maintenance, it is highly recommended not to modify the standard DOLLAR UNIVERSE transactions, since these are updated at each new version received ("cancel and replace" ). 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 heading is not available in the standard menus, in order to prevent unfortunate modifications; however, it can easily be activated (by adding the corresponding transaction into the required profile), ensuring simplified open-ended maintenance. For example, a recently delivered program may include a new function in the form of a special function key; this will be declared in the corresponding program and allocated to the necessary transaction.

Restrictions The list of programs called by an option or a function key cannot be altered by adding a non-DOLLAR UNIVERSE program. Because of this, the use of add-on functions is extremely restrictive, since any DOLLAR UNIVERSE program cannot just be added to any transaction. More importantly, "user" programs cannot be grafted. On the other hand, the different options or function keys of called programs can be allocated or deallocated.

Customization The character interface of DOLLAR UNIVERSE is based on a system of user profiles, to which the DOLLAR UNIVERSE administrator allocates various transactions. These transactions can be standard (provided with DOLLAR UNIVERSE) or adapted by the administrator as required. Access to functions can be customised by: q

Creating specific transactions (duplicating a standard transaction and configuring the options and function keys 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 disabling certain 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 the environment for several distinct profiles. If this transaction is to be used by a large number of user profiles, it will be more efficient to create a specific transaction and then allocate this to the profiles in question. If only a

36 • Users

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

User profiles The 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 DOLLAR UNIVERSE user table. After having started by adjusting access to DOLLAR UNIVERSE standard transaction, this function enables the definition of a specific working environment for each profile by implementing access control to all or part of existing transactions (character interface) or on actions/objects which make up the interface (commands, Windows and Motif).

Transactions of a profile in the character interface As at the general level, the transactions allocated to each profile can be tailored to suit individual requirements. This possibility is nevertheless not redundant on any changes made to the standard transactions. In fact, the transactions form an intermediate level, authorising definition of a cut-back transaction offering fewer functions than the standard transaction. This transaction can then be directly allocated to several profiles, without the user having to adapt the standard transaction for each profile in turn. For each user profile, it is possible to customise precise DOLLAR UNIVERSE usage rights. Each function can be authorised or not, and, within each function, it is possible to control access to each option or function key.

Access control in the commands, Windows et Motif interfaces Dollar 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.). The action is authorized or denied for specified objects. Objects are protected either by their type. (e.g. Uproc, Task, Engine), or for the subset of a type (e.g. Uproc=U*, restrains the specified action to all Uprocs beginning with U). For each object there are a certain number of keys which may carry restrictions.

Customization of profiles These 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 the interface.

Profile menu or desktop The aim of this function is to allow the creation of customised menus for the character and Windows interfaces tailored to the requirements of each organisation. The profile menu plays no part in managing the confidentiality of access to the interactive functions of DOLLAR UNIVERSE, and as a result, can easily be made available to each DOLLAR UNIVERSE user to

Reference manual

Users • 37

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

allow the creation of an individual menu. Nevertheless, caution is called for as regards possible problems with internal 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 of customization attained.

Menus or desktop customisation The standard menus in the character interface can be adapted to suit each organisation's needs, via the customisation 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 is nevertheless recommended to use this function sparingly, for obvious maintenance reasons).

Customization of the DOLLAR UNIVERSE Windows interface rests both on the definition of a standard Desktop and a user Desktop. Access controls, coupled with the dynamic menu facility (i.e. Ability to modify the order of presentation of transactions in relation to the standard DOLLAR UNIVERSE menus) makes it possible to tailor the functional scope and ergonomics of DOLLAR UNIVERSE to the requirements of individual users. In addition, by allowing the secure dissemination of general-interest information (such as providing developers or certain users with a read-only job monitor, for example), these functions facilitate communication between the data-centre personnel and the other actors involved in the process.

Submission accounts Definition Each of the two user populations described can form a submission account, conditional on the following restrictions: 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 in all areas.

Using the author code The author code is a trigram (signature) characterising the user. One such code must be present for every user account. It serves as a reference identifying the account to use when running tasks in DOLLAR UNIVERSE. All jobs scheduled within DOLLAR UNIVERSE, even if attributable to a user (developer or end-user) in reality only memorise the author code, to ensure that automatic conversion can be performed between submission accounts during implementation.

38 • Users

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

This occurs during the transfer phases (automatic translation of a developer-user into an end-user), and also in the distribution phases (for example, automatic translation of an end-user for a given node into another enduser 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, but another 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" is linked to it. The above example shows that it is not necessary to standardise accounts for all the nodes affected by a DOLLAR UNIVERSE operation. It is simply necessary to link the reference formed by the author code, to existing accounts. The author code therefore contributes to the portability of tasks defined in DOLLAR UNIVERSE, from the development environment to the production environment.

Reference manual

Users • 39

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Parameters

Resources In Windows, UNIX and VMS, the resource enables, using a logical identifier, the description of a system resource or a logical one (virtual) which should be scanned in order to condition the running of operations procedures.

Definition A resource is identified by a reference : q

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

q

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

A resource is defined by: Nature FIL : file LOG : logical PRC : process DSK : disk LNM : logical name SYS : system object QUE : job queue

VMS, UNIX, Windows VMS, UNIX, Windows VMS VMS VMS VMS 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 and OPENVMS). The notion of "location" of a resource corresponds to an access path used by resource category "FIL" (in VMS and OPENVMS, may take the form of a logical name or symbolic link, unless the resource name is also expressed in the form of a logical name).: For resource category "LNM" (in VMS and OPENVMS only), it represents a table name.

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

Reference manual

Parameters • 41

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Quota 2

Maximum value of the resource's quota 1, which may be between 0 (default) and 9999. Maximum value of the resource's quota 2, which may be between 0 (default) and 9999.

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

Codification The resource name may be encoded with certain functional elements proposed by DOLLAR UNIVERSE. The following expressions can be inserted into a resource name. This coding is usable only for the resource natures "LOG", "FIL" and "LNM" (the latter available in VMS and OPENVMS 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 data defined by "inter-MU Checks" on the resource condition. If interpretation of this data points to several management units, the generic resource name created by insertion of this expression will correspond to the same number of resource names as there were management units designated. Caution: even if the management units targeted by the condition are not resident on the examined node, the corresponding resources will be searched locally (unless the location refers to a remote resource).

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 resource condition.

q

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

Furthermore, in VMS and OPENVMS, logical names are accepted solely for resource category "FIL", and only if the location is not itself expressed using a logical name. While DOLLAR UNIVERSE checks the syntax of the specific expressions used ("!ESP!","!SOC!" Etc.), It cannot check for usage restrictions on logical 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 the characters " ? " or " [ ] " accepted by the scheduler. Note: in VMS and OPENVMS, in order to ensure that the operations process remains as independent as possible of the environmental organisation, it is advisable to use logical names to define the location (access path) of a file rather than its name. In general terms, adding variables into resource names and locations will depend on the "dynamic" character of the parameters proposed (that is, which can change over time): therefore "static" concepts ("!UG!", "!SOC!" And "!ESP!") Will be used for the location, while "dynamic" concepts ("!DTRAIT!") will be employed in the resource name. Example : reception and consolidation of files from shops The Uproc employed for consolidating files from the shops has a resource condition based on its reference, defined as follows: Type FIL Attribute exist

42 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Name comm_t!DTRAIT!g.dat Location rep_!ESP!!UG! The "inter-MU Check" associated with this condition is a HDP convention of type "{S }" (all shops depending on head office, such as "S01" and "S02", for example). The "functional period definition" associated with this condition will use identical processing dates to 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 "functional period definition". If the launch takes place in the production area, the files to supervise will be: REP_XM01: COMM_T19941221G.DAT REP_XM02: COMM_T19941221G.DAT Where REP_XM01 and REP_XM02 will be logical names describing the directories for storing the COMM_T19941221G.DAT files. If the option "all necessary" was selected for the "inter-MU Check", the two files must be present in order for the condition to be satisfied.

Incompatibility classes Purpose Non-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 nonsimultaneity condition must be present in the description of each Uproc. This constraint can be problematic in the case where whole applications must be considered as being incompatible, therefore, globally non-simultaneous. In Windows, UNIX and VMS, incompatibility classes are a simple and effective solution to this kind of problem.

Using incompatibility classes Associating a Uproc with a class allows the defining of "incompatible execution" processes, conditioned by the 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), DOLLAR UNIVERSE 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.

Reference manual

Parameters • 43

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Therefore a given Uproc cannot be run simultaneously with another Uproc from a class with which it is declared incompatible. Similarly, no Uproc can be run simultaneously with another if it has been declared as incompatible with the other's membership class. Note: incompatibility classes are examined locally by the launcher: this examination applies only to those Uprocs running for the management units residing on the examining node. Incompatibilities described by means of classes are systematically examined before condition checking (examining operating conditions) on the Uproc in question. In this respect, the notion of class does not figure in the launch formula. Example: Uproc classes A good example of the use of incompatibility class is backup processing, where it is preferable not to have any other type of processing running concurrently. All backup Uprocs will be declared as belonging to a class, with which all the other Uprocs will be defined as "incompatible".

Uprocs Definition The procedure, whether it be a CL program for OS400, a shell script for UNIX, a “.bat” procedure for Windows or a procedure « .com » in DCL on VMS, is one of the essential objects employed in computer production. (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 a complementary 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 interactive Uprocs (next section). Batch Uprocs are intended to be submitted to wait for execution in a batch queue (or run as background tasks, in UNIX or Windows, in the absence of a queue manager), while interactive Uprocs are 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 (known as "launching" the Uproc). This information is defined in a totally interactive manner, during writing of the procedure.

q

At the CL Level, DOLLAR UNIVERSE contributes a convention (based on HDP, for example) and specific commands. The command language of the Uproc can be run directly in the operating system in question, outside DOLLAR UNIVERSE. It is obvious that where specific DOLLAR UNIVERSE commands 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 for updates, or for purging history files, or for preparing the dependent job stream.

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

Coding Until 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. Domains are defined in DOLLAR UNIVERSE administration tables,

44 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

q

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

q

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

From version 4.1 onwards, the Uproc code is free. The association with the domain and application can be made, 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 the environment 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 necessary to run a Uproc on a management unit residing on a node other than its development node, a distribution will be required.

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

General characteristics Variables Writing of CL Incompatibility Classes

General coherence checking of entered data

Execution conditions Termination instructions Successors

Mandatory functions Optional functions

Organisation of Uproc definition menu

Procedures or programs (DCL, shell, CL, .bat) Internal or external procedures Two options are available for managing the command language file associated with the Uproc, depending on whether it is to be managed by DOLLAR UNIVERSE or independently. The decision to manage the command language (CL) externally to DOLLAR UNIVERSE entails identifying the file containing the corresponding command language instructions (during definition of the general information). This parameter is a filename whose writing conventions comply with those of the operating Reference manual

Parameters • 45

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

system in question. Any access path can be used to this file (but it naturally must exist on the node where the Uproc will run). The access path may be explicitly declared or logically using a local variable declared in the submission account's login in order to ensure recognition by the scheduler and in the logical environment file in order to be recognised by the interface. For Uprocs with internal CL, The file containing the command language is created with the name and the version number of the Uproc written by the interactive functions of DOLLAR UNIVERSE. It is stored in the directory 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 version number 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 CL file (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 the operating system in question. q

In Windows or UNIX environments, a local environment variable can be used to specify a text editor for both 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 tables used to define the characteristics of each company.

Within the command language, DOLLAR UNIVERSE authorises insertion of specific verbs allowing communication 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 as many times as necessary, depending on the number of occurrences required to resolve the HDP expression.: For example, the expression "{XY}" inserted as a parameter for the verb "copy" will allow copying the corresponding file into all management units of type "X" depending directly on the management 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 of each application managed by DOLLAR UNIVERSE. Within the CL Associated with the Uproc, the corresponding command avoids the explicit reference to data that may differ depending on the execution context (i.e. Area, management units).

q

Transmitting of messages towards the history trace for the Uprocs managed by DOLLAR UNIVERSE etc.

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

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

Context provided by DOLLAR UNIVERSE During start-up, DOLLAR UNIVERSE provides a set of environment variables, or logical names that can be used for writing the procedure. These variables are the same regardless of the operating system in question,

46 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

but have a distinct prefix in each case (such as "S_" in UNIX, VMS or Windows, "MX" in OS400). The complete list of variables is supplied in the Commands manual.

Transmission of additional parameters to a procedure Over and above the stated execution context (see above), the need for transmission of parameters should be dissociated from the question of whether the related processes are periodic or not; periodic processes (automatic submission without human presence) naturally require no particular parameter settings except in cases where : q

Parameters are passed from one procedure to another,

q

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

DOLLAR UNIVERSE satisfies these requirements as follows: q

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

q

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

Finally, for non-periodic processes, DOLLAR UNIVERSE offers a specific command for provoking batch Uprocs that accepts parameters of the following capacities: Os No. of parameters Length OS400 30 30 UNIX, VMS, 30 255 Windows Refer to the commands user manual for more information on the conditions for using this command.

Variables This DOLLAR UNIVERSE function enables variables to be defined and input. This can be done in command mode or via the graphic interface and during the development phase for operational objects as well as during production. Thus, the objective is to allow manual or semi-automatic preparation of the batch operation.

General principles Thus, 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 Uprocs need 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 default values 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 in command mode, or when the CL is executed.

Reference manual

Parameters • 47

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Characteristics Variables 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 of their definition, in tasks, launches or an execution restart.

Assigning values The 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 the Uproc’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 value on the local node where the Uproc is executed).

Functional period and processing date Definitions Since DOLLAR UNIVERSE carries out operations in their order of occurrence, it does not recognise the notion 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 processing date (unless the Uproc has no functional period). This date depends directly on the Uprocs functional period. Accepted values for the functional period are: None Day Week 10 days

2 weeks Month 2 months 3 months

4 months 6 months Year Extended month

The processing date is expressed as day, month and year, irrespective of the functional period. If one element of the processing date is not needed, it will not be requested, and will automatically assume the value of the starting date of the period that is selected. This date serves as a reference model to automatically calculate all the other dates encountered during the condition check, execution of the CL, or completion. If the Uprocs functional period is: 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 the corresponding date (day month year, which is inevitably a Monday),

48 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

q

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

q

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

q

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

q

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

Use The processing date figures in all events recorded in the DOLLAR UNIVERSE history trace. This means that execution traces of a Uproc can be conserved and differentiated independently of their schedule or execution dates. To this end, the processing date will be available within the CL, As a reserved variable, for information (to allow, for example, the correct accounting period to be inserted in the report, independently of the execution date). In addition, this processing date will be used in all operations synchronising procedures (such as, Uproc to run only if it ran correctly the previous month, or if such-and-such other Uproc ran correctly for the same month etc.). Example: processing dates An accounts entry Uproc is monthly; each time it is launched, the requested period is a date with the format MMYYYY. The month-end Uproc is monthly, and traces of the last 12 runs must be kept in the operating events in order for the year-end Uproc to be able to run. Note: the functional period is independent on the scheduling period for the Uproc in question, even if DOLLAR UNIVERSE routinely offers algorithms for automatic calculation of processing dates based on the schedule dates (see 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 of the past month. A similar example might entail an operation, submitted each weekend, to give the summary of accounts movements of the current month. Note: selecting an "extended month" (in character interface only) period prohibits the use of implicit scheduling for a batch Uproc started by the batch engine: only explicit scheduling is possible for this type of Uproc.: For this period, it is necessary to indicate the maximum number of months considered (necessarily 15 at most). Any attempt 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 any synchronising or triggering of Uprocs. Refer to the descriptions for execution conditions, completion and sessions 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 (UNIX and Windows). In the event of conflict in the condition checking phase, the default "whatever the processing date" will be used.

Reference manual

Parameters • 49

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Event memorisation Purpose With DOLLAR UNIVERSE, computing production benefits from guaranteed coherence due to the total control that DOLLAR UNIVERSE exercises over each event in the data operations cycle. A certain number of these events are important and their presence may condition the execution of certain other Uprocs. However, the majority are of no more than informative interest. To avoid overloading the history files, DOLLAR UNIVERSE maintains a specific history file that records all Uprocs declared as memorised. DOLLAR UNIVERSE examines this file in order to evaluate the execution conditions 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.

Characteristics Memorisation 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 Uproc execution 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 the traces of one or more executions (i.e. Events) need to be kept for the same processing date (date obtained by applying the functional period to the scheduled date). Selecting "one only" implies destroying the last-known execution event for the processing date in question, as soon as a new execution is started for the same processing date. This automatic purge feature is completed by the number of periods parameter.

Note: this function can replace the Completion instructions. It does not allow, however, such fine event management, and therefore cannot replace it systematically. Caution: the duration for which execution events are retained is decided arbitrarily by the user and requires that all Uprocs conditioned by these job executions have themselves run correctly before being purged 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 a Uprocs 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, number of periods is meaningless for a Uproc having no functional period (in this case, the number operating events kept is either one or all). Caution: by default, the number of periods is "00", meaning that DOLLAR UNIVERSE will keep all periods. To keep just a single event, the value entered is "1". Example: memorised and non-memorised Uproc A Uproc designed to update a permanent customer file may be non-memorised because it is unlikely, in functional terms, to condition running of another Uproc.

50 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

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

Purpose Thanks 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 new launch will be performed. The new Uproc launch is performed in random order (conditioned by the internal technical structure of dollar universe). The notion of successor is the definition of a sequence for examination of event waits, so giving a particular Uproc higher priority for launch after execution of the Uproc in question. This function completes the dynamic organisation provided by dollar universe, by allowing real-time influence on job sequencing according to events that have arisen, while maintaining its coherence.

Special features Over 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 of the related Uproc,

q

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

Execution prerequisites Uproc conditioning means describing its functional dependency on other Uprocs, and even technical dependencies (via the resource conditions). Note: it is not necessary to translate the operators technical constraints (degraded processing paths, forced serialisation of operations, insertion of technical processes such as backups etc.) In the elementary conditioning process, since the structure provided by DOLLAR UNIVERSE at the session level is specifically designed to handle this requirement. DOLLAR UNIVERSE proposes four types of conditions, with the possibility of combining these into a launch formula interpreted at each launch attempt.

Reference manual

Parameters • 51

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 condition can then be identified with great precision. Note: all operations events (absence, launch, execution or incident on a Uproc) are stored by DOLLAR UNIVERSE as events (if the Uproc is memorised). It is these events that are used for determining if the condition is satisfied or not. A Uprocs execution conditions are systematically examined (except in the case of "forced launch at end of period" (see paragraph entitled "Tasks"), whether this Uproc runs within a session or not (the session is only a sequencing 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 conditions In 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 when discussing the individual condition types later in the chapter. Note: these general criteria are also valid when expressing completion instructions; moreover, the description of these 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 completion instructions) are described below.

Inter-session checks The inter-session check function applies to the "non-simultaneity" and "sequence" conditions, as well as to completion instructions. It enables the determination of which sessions DOLLAR UNIVERSE must search in order to locate possible executions of the target Uproc, either to evaluate the said conditions, or cancel the corresponding event (for the completion instructions). The options are as follows: q

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

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

Same session and all runs

52 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

This option extends the preceding option of searching for conditioning events (or events to delete), to all occurrences of the session in which the conditioned Uproc is found. Unlike the preceding definition, previous occurrences of the session can be taken into account by this option. q

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

Note: 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 most general, 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 the applications logic) is normally independent on the operations constraints handled by the session.

Inter-management unit control The inter-MU Check can be used in conditions of "incompatibility", "dependence" and "resource" (for certain types where the file name or address contain the variable !UG!), As well as to completion instructions. It directs the search towards events associated with a specific management-unit. The options are as follows: q

Management-unit type This option directs the search for conditioning events (or events to delete) to all management units of a given type.

Note: this option does not analyse the hierarchical relationships between MU, and it is preferable to restrict its use to certain specific cases (technical processing, for example, such as "synchronise triggering of update operations on 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, in favour 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, which extends the search for conditioning events (or events to delete) to all management units linked to execution of the management unit containing the conditioned Uproc (per the 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 which the conditioned Uproc is executed. Therefore if the conditioning Uproc runs on another management unit, the corresponding execution events will not be considered in the search.

Note: this option is the default taken by DOLLAR UNIVERSE during creation of a condition or an instruction. • "{A }" limits the search for conditioning events (or events to delete), to all the management units of type "a" dependent on the current management unit. This mode of expression is often to be preferred over the two preceding modes, on account of its natural open-endedness, as illustrated by the following two examples: Example: 1. Use of the { } convention

Reference manual

Parameters • 53

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

An accounts processing stream runs each month within a given company, according to execution conditions expressed in the "{ }" convention. Following a readjustment of activity or acquisition, the company divides into two distinct entities, each entity's accounts being processed separately. The only task required is to create a second management unit and duplicate the workload schedule, in order for the jobs to run coherently on the second entity, independently of the first. Example: 2. Use of the {A } convention The updates on a commercial database are consolidated each month for each region of a company, according to execution conditions expressed in convention "{A }". Up until now, operations have been based on two regions, incorporation of new offices simply requiring the declaration of the corresponding management unit, and its dependency to one of the two regions. Following a large increase in the number of offices, a new region is created. The only task required is to declare the corresponding management unit, and duplicate the operations schedule for the new region, by deleting, if necessary, the dependency of certain offices to one of the original regions, and creating their dependency on the new region. q

All are necessary This option complements those given above (which are exclusive), by allowing the operator to indicate whether for the condition to be valid events must be found for all target management units, or if any one of them suffices. Given the frequency of the "yes" option, this parameter is taken as the default when creating a condition.

Note: since this information has no meaning when considering completion instructions and incompatibility conditions, it is not proposed in the corresponding windows. In both cases, the events are considered for all management units designated.

Inter-processing date control The 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 for completion instructions. Referring to the processing date of the conditioned Uproc, the functional period determines the processing date for which DOLLAR UNIVERSE must seek possible executions of the Uproc or the targeted resource, via the conditions or the completion instruction. The inter-functional period check is therefore performed on a comparison between the processing date of the Uproc or the conditioning resource, and the processing date of the conditioned Uproc; this enables the decompletion of the relationship between the processing date and the processing date sought for the Uproc or the conditioning resource at the time of launch. If the conditioning Uproc has a smaller functional period than the conditioned Uproc the condition check must remain coherent. To this end a new operand "q" (any) has been added as of the version 4.0 (VMS) and 4.1 (UNIX). Example: use of the inter-period check Uproc "A", which generates an annual statement of accounts, can run only if Uproc "B", which generates the monthly balance, ran correctly. Uproc "A" is declared with a annual period, Uproc "B" is declared with a monthly period. Uproc "A" comprises a condition stipulating that Uproc "b" must have run correctly In practice, at each expected execution of Uproc "A", DOLLAR UNIVERSE will translate its processing date (for example, 1995) into a processing date for Uproc "B" (01/xx/95), according to the formula used ("any month, same year"). Note: similarly, incompatibility conditions are expressed simply by declaring whether this incompatibility takes account of the respective processing dates or not (same or any) 54 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

The calendar units available for evaluating processing dates or processing-date differences vary with the reference functional period of the Uproc in question; the reference is systematically proposed, as well as the year (greatest unit). If "month" is greater than the reference functional period, it also is proposed (except for the week, for obvious reasons of non-compatibility between these two units). The following table summarises the calendar units proposed, according to the Uprocs functional period: F.P. D None Day * Week 10 days 2 weeks Month Extended mth. 2 months 3 months 4 months 6 months Year

Calendar units W 10D 2W M 2M 3M 4M 6M * * * *

* * * * * * * *

Y * * * * * * * * * * *

Calendar units proposed for different functional periods

Note: if the conditioning Uproc has "none" for the functional period (corresponding, therefore, to an infinite period), the 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 period will default to a check on any processing date rather than same processing date (version 4.1 onwards).

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

Condition expected or excluded This option tells DOLLAR UNIVERSE which is valid - the proposition as expressed, or the contrary argument (opposing proposition). This option is used mainly with the DOLLAR UNIVERSE character interface, which distinguishes subconditions 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 launch formula. Example: use of the " excluded " option Uproc "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 and proposition 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.

Reference manual

Parameters • 55

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 that DOLLAR UNIVERSE automatically converts the proposition into conditions when the graphical interface is used to update a Uprocs conditions (coherence is thus maintained with the character interface).

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

Text "if not satisfied" message This text is used (in character interface only) in the execution history file created by DOLLAR UNIVERSE during execution of a Uproc. It is only present in the history file if an inhibiting proposition (not satisfied) is encountered, and the proposition in question occurs before the inhibiting proposition during condition checking of the launch formula. Note: correct wording at this stage is essential, since it affects the legibility of DOLLAR UNIVERSE history files. Example: content of "not-satisfied" message depending on launch formula Case 1: =c01 and =c02 Message c01 appears in the history file if c02 is not satisfied Case 2: =c01 and =c02

56 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Types of conditions Sequence Sequence conditions make it possible to link functionally dependent Uprocs, whether they run on the same or different nodes. The purpose of this function is to search the memorised operating events for those conditioning execution of the Uproc being launched. This group of conditions allows linking two Uprocs, and conditioning the execution of one Uproc (conditioned Uproc) on execution (or non-execution) of another Uproc (conditioning Uproc). The conditioning and conditioned Uprocs may be one and the same. These conditions can be 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 the task 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 Uproc must 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 been activated, and waiting for an event. Therefore the sequence conditions are largely based on the notions of processing date, user account and management 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 functional period compatible with that of the Uproc containing the sequence condition. Example: sequence conditions The accounts month-end Uproc will not run, for a given month, unless the previous month's occurrence completed correctly (or, for the first month of the year, the year-end for the previous exercise completed correctly). One of the solutions for expressing this logic consists in using sequence conditions. In this case, two conditions must be used because the logical translation of the process described above implies presence of an or operand. Condition 01 (proposition 01) Sequencing of the month-end accounts Uproc with itself for the preceding month

Reference manual

Parameters • 57

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Processing dates: " month-1", Meaning of proposition: " expected". And Condition 02 (proposition 01) Chronology for month other than January "month # 01" Meaning of sub-condition: "true". Or Condition 03 (proposition 01) Sequence with the yearly-starting Uproc Processing date: same year Meaning of proposition: "expected". And No (for condition 02) The launch formula is, therefore: (=c01 and =c02) or (=c03 and #c02) Example: prohibiting calls to applications Once in operation, an application may sometimes have to be interrupted temporarily (due to applications problems, overloading of computing resources necessitating the limiting of available applications etc.). This example gives a simple means of rapidly inhibiting an application. The only requirement is to develop, in each application, a special Uproc on which all the other Uprocs in the application depend. This Uproc is then allocated to each MU Using the application in question. The inhibitor can be used only by the operators, when necessary. Once the Uproc is memorised, the event associated with it remains in the historical events file after execution. 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: inhibitor Status 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 never been 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 by selecting the option corresponding to completion in "T" status: this updates the operating events file by replacing events coded with the inhibiting "I" status.

Non simultaneity This group of conditions is the complement to the sequence conditions, and enables the definition of a set of Uprocs which must not be executed simultaneously with the Uproc being launched. The verification centres on the local operating events base at time of launching the conditioned Uproc (an incompatibility condition may not be declared with a Uproc which runs on a remote machine). The job statuses concerned by an incompatibility condition translate execution of the latter (or its potential for execution): 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:

58 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 the task 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 be entered in the two Uprocs which must not run simultaneously. Example: non simultaneity conditions A Uproc covering end-of-month invoice processing, using permanent files such as customer files or VAT Rate files cannot simultaneously accept the Uprocs which update the said permanent files. Therefore all the Uprocs will have incompatibility conditions such as: All invoice-processing operations will exclude the possibility of updates, Conversely, all updates will prevent start-up of invoice processing.

Chronology This group of conditions (available in character interface on VMS only) invalidates launching of a Uproc on behalf 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 periods in 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 in question, independently of the execution frequency for this Uproc. Therefore in the case of scheduled batch Uprocs, the chronology conditions are not taken into account in the scheduling process (or simulation), but solely in 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 used with batch Uprocs to express certain special requirements. It is not possible to allocate a chronology condition to a Uproc not having a functional period. Furthermore, in view of the low usage rate, this type of condition can be defined only through DOLLAR UNIVERSE character interface (updates performed via the graphical interface do not alter definition of this condition). Example: a monthly Uproc must be run only in June each year A single chronological condition is sufficient to condition the Uproc. This condition will comprise the 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, and month will be compared with 06 at the moment the launch formula is examined. If 'month' is different 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:

Reference manual

Parameters • 59

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

- 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 August One chronological condition, comprising two propositions, is sufficient. Assuming that this condition 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: =c12 Or else - condition 12 proposition 1 "month = 01", "excluded" - condition 12 proposition 2 "month = 08", "excluded" The launch formula will include: =c12

Resource This step enables the declaration of an execution pre-requisite for the Uproc, based on the availability or the status of system or logical resources. Each condition is expressed according to the characteristics stated above : 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 non permanent and its attributes are systematically verified.

Note: the function examining resource conditions is pointed at local resources (unless in VMS it is configured with a 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 Value

A logical operator enabling values to be compared (, =, =) Comparison value : expressed in the units proper to the attributes of the resource being scanned; example : 50,000 freeblocks means that the desired threshold is 50,000 disk blocks.

q

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

q

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

60 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

The definition of resource conditions may include, for certain resource types information of an applicational nature (for example, filename integrating dates comparable to the processing date, HDP Expressions, or reference to an MU). Resource conditions therefore participate in the elaboration of the launch formula, and can be defined in much the same way as sequence conditions (with the same characteristics, apart from the status). Note: it should be noted that, with the exception of quota definitions, a resource condition expresses the availability or the presence of a resource in a given state, at the time of launching., Since DOLLAR UNIVERSE does not reserve resources ( except for defined quotas or exclusive resources), it may be that the status or availability of certain resources in certain operating circumstances change after verification by DOLLAR UNIVERSE. If the stability of the resource status, or its availability are a pre-requisite for execution of the Uproc, the user must take the required technical precautions.

The launch formula Purpose The launch formula is an expression containing chronology, sequence, resource and incompatibility conditions, linked by a set of operands (AND, OR, =, #). The logic translated by this expression is analysed during condition checking of the Uproc. The analysis depends 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 of the launch formula ("true" or "false") determines whether it is possible to run the CL associated with the Uproc. If impossible, the non-verify condition is displayed in the history trace. Note: the Uproc incompatibility classes do not play a part in the expression launch formula. Any resulting job incompatibilities are checked before the logical expression translated by the launch formula.

Optimisation of the launch formula The exploitation of the launch formula by the launcher is initially optimised by a purely logical analysis of the expression of the formula, which determines whether each condition is principal or not. A condition is qualified as principal if its non-verification entails non-verification of the entire formula. This is typically the case for conditions not included between parentheses and preceded by an AND. As a second step, the launcher determines the satisfied or unsatisfied character of each condition in relation to memorised events. Conditions are examined according to their order of appearance in the formula. When a condition is principal, and the logical value deduced is different from that sought, (satisfied for # CNN and not satisfied for =CNN), the analysis is not continued, and the launch is refused. Using this process therefore requires a few operating hints: q

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

q

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

q

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

If the organisation of the formula does not include this precaution, any premature glitch (before analysis of the fatal conditions) will prevent detection of a possibly not-satisfied fatal condition, resulting in unnecessary launch attempts. Note: when a Uproc is launched, DOLLAR UNIVERSE memorises any event inhibiting Uproc launch. Any intervention from the job monitor on other events will be ineffectual. Furthermore, each new launch will

Reference manual

Parameters • 61

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

systematically examine all conditions afresh (those satisfied beforehand may no longer be), so that any modifications are processed in real time (except for HDP Analysis).

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

Completion instructions Purpose The 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 memorised Uproc 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 Uproc responsible for deleting their successive runs from the operating events base. Note: as for sequence conditions (whose instructions constitute the counterpart), the functional period (processing date format) of the Uproc to purge must be the equal or greater than that of the Uproc to which the instruction belongs ("month" greater than "ten-day period" greater than "day" etc.). The use of completion instructions is not compulsory, since the data contained in the general information of the Uproc enables automatic management of memorised events. Nevertheless, completion instructions facilitate intervention on operations events in very specific cases (destruction of a particular event, for example). Example: completion instructions A batch application can run only if the interactive application has been "shut down". A shutdown Uproc is, therefore defined, with the characteristic "memorised". This will condition all batch runs of this application. A start-up Uproc is also defined, containing a completion instruction to delete the event (job run) associated with the shutdown Uproc. When the application is started, the memory record for the shutdown Uproc will be deleted, and no more batch processing can be submitted. Note: completion instruction's impact is limited to the node on which they are performed. If the condition is local, the completion instruction purges the event from the local base.

Network operations If 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 local node, the remote event will remain. However, if a completion instruction (or event deletion) is performed on the remote node (where the conditioning Uproc resides), then all events on the local bases (for conditioned Uprocs) will be purged as per the instruction. General rule:

62 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Whether to launch the conditioned Uproc,

q

Whether to purge the event.

Sessions Definition A session is a tree structure comprising Uprocs that are homogeneous not necessarily from the functional viewpoint (they may contain Uprocs from several applications or different domains), but in terms of their operations constraints. A session is an sequencing model and external to the execution conditions of the Uprocs it contains. The session predefines an order in which the Uprocs are launched, knowing that at each phase, DOLLAR UNIVERSE will systematically check the execution conditions of the Uprocs that the session is telling it to launch. 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 itself suffices to sequence all the constituent Uprocs automatically. Nevertheless, if required, one or more Uprocs in the session can be allocated a specific schedule,

q

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

q

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

Example: content of a session A company runs an accounts-payable job stream every week. Supplier cheques are issued by a specific application which formats and prints the cheques. From the operations viewpoint, the function is completed only if the cheques are effectively issued. A session could therefore be created to unify these two related applications.

Session coding A 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 in order to identify certain of their characteristics, for example, execution frequency (daily, weekly, monthly etc.).

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

Reference manual

Parameters • 63

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Level n

T1 OK T2

T3

T6

KO T4

T7

T5

T5

level n+1

Level n+2

T8

Structure of session

A session begins always with only one Uproc called the session header. These relationships make it possible to define hierarchical relationships of the parent -child type. The Uproc at level n will be parent to the Uprocs at level n+1, known as child Uprocs. Individual Uprocs dependent on a given parent at a given level are referred to as peer Uprocs. The session thus allows complex processing tree structures to be defined. A Uproc cannot have a "peer Uproc" with the same name (i.e. Same Uproc at same level having same parent Uproc). On the other hand, a given Uproc can appear several times in the tree structure, at different levels, or at the same level with different parent Uprocs. The relationships thus defined express organisational and operational sequencing requirements, and in no case replace the functional relationships translating the logical conditions defined at Uproc level. It is possible that part of the structure of a session is already partially translated into such conditions, more particularly into sequence 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 be translated in the tree structure defined by the session. The existence of sessions is justified, among other factors, by the need to dissociate operations constraints (represented by the session tree structure) from the applications and logical constraints defined at the Uproc level. Operations constraints (incompatible execution of two resource-heavy operations, for example) may evolve independently of applicational constraints.: For maximum simplicity and reliability of maintenance operations, it is therefore important to avoid mixing these two types of constraints.

Scheduling features The Uprocs in a session inherit the schedule, the technical characteristics (job queue, for example) and the functional characteristics (processing date, for example) of the session-header Uproc (i.e. The one at the top of the tree structure). Nevertheless, 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 concerned session, 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 specified launch window, or inhibiting this job during certain periods. (the tasks in the session depending on the specified launch window will be deferred to the same degree),

q

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

q

These new characteristics will be carried over into the following Uprocs in the session. In the case of an optional task, the characteristics will be carried over whether or not the optional task is executed.

64 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Note: the session can also be used for handling operations constraints, thereby dissociating this type of constraint from 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 of submission imposed by the session, DOLLAR UNIVERSE performs condition checking (verifying launch formula) on each Uproc to be submitted as part of a session.

Normal and abnormal processing paths A session is a group of Uprocs arranged into a tree structure. Depending on the execution conditions (execution status "I" = incident; "T" = completed), the session allows different 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 processing sequences instead of an outright break in the job stream.

Execution environment Defining the execution environment of the Uprocs in a session is an integral part of the session definition. The management 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 used within sessions and conditions to define a "target" set of management units in the job triggering or synchronising commands. Refer to chapter 2 - "environmental concepts" for more information on the use of HDP. The following example illustrates the possibilities offered by HDP. Example: use of HDP in defining sessions Assuming an 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 all management units of type "a" (= offices) depending on the regional division. This possibility for "generically" designating Uprocs for management-unit targets allows the creation of general processes that can adapt automatically to modifications in the logical architecture of the environment.: For example, the adding of another "office" MU Will be transparent in a session configured to submit a given process from a regional office to all its dependent offices. Note: by default, the type of HDP Convention retained will be "{ }", allowing execution of all Uprocs in a session on behalf of a given management unit. Refer to the section entitled "tasks" in this chapter for more information concerning the management rules for temporal and technical information within a session.

Carry-over of Uproc variables’values Carry-over of the values of Uproc variables within a session is not automatic. By default, if nothing is done, the value of the variable is not carried over and the engine applies the rules for assigning values by default. The carry-over of the execution value to a child Uproc can be requested by executing the command uxset var in the CL of the Uproc or in its post-processing, U_POST_UPROC. Three kinds of carry-over of execution values can be requested:

Reference manual

Parameters • 65

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 words the 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 limits The total number of Uprocs managed in a session is 140. Up to 20 Uprocs can be declared at each level of the tree structure (for normal completions), with another 20 Uprocs declared as "ab-ends" (abnormal completion of the so-called parent Uproc). Note: a given process can occur several times in a given session. Each occurrence decrements the total number of available operations in the session by 1 (from the total of 140).

66 • Parameters

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Scheduling

Automation of batch tasks DOLLAR 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 automatic calculation (by the batch engine) of scheduling dates and times for the various tasks in hand. Note: determining a scheduling date and time does not mean systematically that the task will be run at the start of (or even during) the launch window period (= interval between the starting and finishing dates), since effective execution is determined by the conditions attached to the related Uproc.

Calendars Calendar application environment In DOLLAR UNIVERSE, calendars serve as a time reference base and in no case an operations schedule. DOLLAR UNIVERSE imposes the definition of at least one calendar per node and per area called "General calendar". In this case, all the management units present at this node will refer to the same calendar. To cater for the special needs of each organisational entity, calendars can be generated specifically for management units or types of management units. A specific calendar can be defined for each area (application, integration, simulation and production), in which a management unit is present. To avoid having to duplicate calendars for each management unit, the calendar function is managed by a search list in this way, tasks will be scheduled depending on the information contained in: 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.

Reference manual

Scheduling • 67

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Calendar model Calendar models can be created. From these models, calendars can be generated for groups of management units with similar needs. The available options ensure that calendars can be adapted as finely as required for the operational needs of each environment. Nevertheless, it is recommended to avoid unnecessary creation of calendars, since they may become difficult and tedious to manage if the management units at a node become numerous. Note: as for tasks, distribution can only take place from calendar models. Furthermore, even if distribution is performed to all MU. 'S of the same type (added possibility), this "generic" addressing will be automatically translated 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 are required.

Generation of holidays Calendars can be generated with or without standard French public holidays. The standard French public holidays 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 on an external file comprising possibly modifiable dates. The process cannot, therefore, be adapted to requirements such as the generation of holidays for another country. This would require generating a calendar with no holidays, then modifying it to take account of the internal requirements of that country. Later distributions of this baseline calendar will remove the need for the repetition required by these manual operations.

Calendar range A calendar's range is not limited. When creating it, allowance should be made for the requirements imposed by the scheduling rules used. To ensure the necessary calculations (for example, a scheduling algorithm using an annual period), there must be a calendar starting at least one year before the date at which the calendar will be used by the batch engine, and extending for four years at least (to allow calculation of the next two processing dates). A calendar must be generated as illustrated in the following diagram:

68 • Scheduling

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

year n-1

year n

year n+1

year n+2

Reference date

Minimum range of a calendar

The benefit of generating calendars for a wide period cannot be over-emphasised, since over-running the calendar 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 exist already, the newly generated years cancel and replace the earlier ones.

Types of day Standard 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 week and 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 public holidays, enabling them to fulfil separate purposes.

Impact of modifications on a calendar Modifying a calendar is a delicate operation, given that it can have great impact on the operations processes. For all update operations on a calendar (creation, modification, delete, transfer, distribution etc.) DOLLAR UNIVERSE immediately and systematically updates the related scheduled tasks affected by this calendar (i.e. Those tasks operating on behalf of the management unit linked with this calendar, or management units with the same type as the calendar). The general calendar for the node is a special case, with all tasks being updated. Example: shifting of a group of operations by updating a calendar In 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 long down-time, forcing the operations department to defer production to another day (Friday to Saturday, for example). Closing down on a Friday (declaration as a closing day) and opening on a Saturday (declared as working day) will result in the shifting of all related tasks by 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.

Reference manual

Scheduling • 69

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Scheduling rules Definition A 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 or holiday,

q

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

In strict terms, scheduling rules are not "objects" in the DOLLAR UNIVERSE sense, but rather a means of simplifying the definition of scheduling characteristics for tasks. Using these rules, a very limited number of calendars is necessary. A set of scheduling rules is delivered with DOLLAR UNIVERSE; this means that new rules can be added as desired. Rules make it possible to express periodicity that will be allocated to the target task during the job scheduling phase, thereby avoiding the need to completely redefine the desired periodicity each time. The allocation process copies the rule to the task, which becomes independent on the original rule. So modifying the rule does not modify the job schedule defined using this same rule. This mode of management is used in order to reduce manipulation, and because the rules, once they are correctly defined, do not evolve. Distribution of rules 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 which the related task runs (if there is no calendar, the one belonging to the MU. Type, or the general calendar of the node are sought).

Examples Each working day Period Day Number 1 Shift 1 Days Calendar Analysis direction + (from start) Offset None Authorisations Mon Tues Wed Thur Fri Sat Sun Work 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 holidays Period Number Shift Days Analysis direction Offset Authorisations

70 • Scheduling

Day 1 1 Calendar + (from start) None Mon Tues Wed Thur Fri

Sat

Sun

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Work closed holiday nyy nyy nyy nyy nyy nyy nyy In 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 day Period Number Shift Days Analysis direction Offset Authorisations Work closed holiday

Day 1 3 Working + (from start) + (next) Mon Tues Wed Thur Fri ynn ynn ynn ynn ynn

Sat ynn

Sun ynn

The rule "every third working day prior to end of month, with possible offset to following day" could have been expressed in similar fashion by simply changing the analysis direction from "+" to "-". Each Tuesday; if Tuesday is a closing day, offset to next day Period Number Shift Days Analysis direction Offset Authorisations Work closed holiday

Week 1 2 Calendar + (from start) + (next) Mon Tues Wed Thur Fri ynn ynn ynn ynn ynn

Sat ynn

Sun ynn

This rule could also have been expressed by setting the "position" parameter to "5" and the "analysis direction" parameter to "-". Each first working Tuesday in each month Period Number Shift Days Analysis direction Offset Authorisations Work closed holiday

Month 1 1 Working + (from start) + (next) Mon Tues Wed Thur Fri nnn ynn nnn nnn nnn

Sat nnn

Sun nnn

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

Tasks Definition A scheduled task corresponds to running of a Uproc (the procedure) on behalf of a management unit (an environment, most often data). By extension, task also designates the running of a session on a behalf of a management unit. In the precise case of a session, it is more correct to talk of "set of tasks" rather than a single one.

Reference manual

Scheduling • 71

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

A task must therefore be encoded by concatenating the code of the Uproc and/or the session from which it comes, and the code of the management unit for which it will 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 scheduled automatically by the calculator.

q

Provoked : this task has no schedule other than the expression of specific launch windows, since it will be triggered (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 its own scheduling rules (for example: a task can be defined for a Uproc that must run only on Fridays, whereas the session to which it belongs is daily; apart from Friday, the session runs as if the Uproc did not exist).

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 submission in 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 the forecast task workload.

Task model To take into account distributed architectures composed of numerous management units, and requiring duplication of a given task for each operations environment, DOLLAR UNIVERSE proposes the task model. The purpose of the model is to allow non-executable reference parameter settings to be defined (on a central computer, for example), for distribution to the target environments. A task model therefore defines a Uproc or session schedule, independent on any specific management unit context. 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 a management unit, and will therefore be executable on this management unit. In this respect, only task models are susceptible to be distributed. Note: Uprocs and sessions are not executable objects, being independent on the executing environment.: For this reason they do not need the notion of model.

Types of task Scheduled task Scheduled tasks benefit from all the facilities available in DOLLAR UNIVERSE in terms of workload forecasting. Scheduling rules (algorithms) are applied to the time reference scales, which are set by calendars, allowing this task to be run recurrently (for example, every third working day of month, every Tuesday etc.). In order to handle random submission requirements, it is also possible to explicitly define a set operating and exclusion dates.

Provoked task Provoked tasks are tasks submitted on demand from another (interactive or batch) task, via specific DOLLAR UNIVERSE commands or a via a session. These tasks may be submitted on management units other than that

72 • Scheduling

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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-urgent batch tasks to be deferred to a less busy time period.

Technical execution characteristics Provoked tasks allow the special technical characteristics of a Uproc to be specified within a session (by default, only the session-header Uproc is scheduled, and its technical features are automatically circulated to the other Uprocs in the session). Declaring these data, propagated via the scheduling function, prevents the propagation of those of the parent task, by imposing the tasks own data. It is therefore possible, for example, to define specific priority and job queue parameters for a given provoked task. Note: these specifications apply only to the target Uproc and not the other Uprocs succeeding it. The same applies for calculation of the processing date.

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

Application interface As mentioned above, provoked tasks can be triggered via a dedicated command (or API) (documented in the commands user manual). The former can be directly invoked from an application, mentioning by name those components of the task that the application needs to trigger. This mode of operation obviously presents the disadvantage of making the application dependent on the description of the task declared in DOLLAR UNIVERSE, thus complicating the associated maintenance operations. On VMS only with the character interface, DOLLAR UNIVERSE proposes working with an identifier, which allows 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 same way as the tasks (management by area, transfer, notion of models, distribution etc.). Note: previous versions of DOLLAR UNIVERSE included an additional processor ("interface") which, after various changes, ended up with no other function than inhibiting requests received via the command mentioned above (by simply stopping the corresponding processor). This function no longer exists.

Optional task Optional tasks are tasks with schedules that do not exactly follow the same rules as the rest of the session; they only apply, therefore, to Uprocs contained in sessions. During execution of the session, this "optional" character generates an examination of their specific scheduling rules. In this way, if the scheduling characteristics of the related task do not correspond to those of the session, the task will be ignored outright in the overall tree structure. This allows, for example, a weekly task to be inserted in a daily session. Scheduling of optional tasks follows the same rules as those for scheduled tasks. Note: an optional task must refer to the session to which it belongs.

Reference manual

Scheduling • 73

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

User account The user account is the username (UID) of the user for which the task will be run. This parameter is compulsory. The username must have been previously defined in the administration tables of DOLLAR UNIVERSE. 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 or distribution of tasks, via the author code.

Job description The 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 the usual JOBD of the submission account.

Batch queue This information specifies in which batch queue the task must be run. This batch queue must exist for the selected 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 can be 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" job queue.

Priority The priority of the task represents its "scheduling level" in the job queue in question. The priority level can be set between 1 and 255. The default value is 100. This information is not used in the OS400 environment and will only have an effect in UNIX when DOLLAR UNIVERSE is used jointly with DQM (distributed queue management). Note: the priority is not intended to control priority operating, but rather defines a preferential order of submission when jobs are pending in the batch queue.

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

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

q

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

74 • Scheduling

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Automatic restart mode Setting this indicator means that the task will be automatically restarted after a system failure, insofar as management of the job queues allows. 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 the event of a system failure (and only in this case).

q

In UNIX or Windows, the information serves no purpose unless DQM (distributed queue management) is being used jointly with DOLLAR UNIVERSE.

Tip: it may prove useful to allow for recovery points in the CL, using OS checkpoints or the steps proposed by DOLLAR UNIVERSE.

Forced run at end of window If the launch formula is not satisfied, (and provided unsatisfied fatal conditions are absent), DOLLAR UNIVERSE puts the corresponding launch into a wait state. At the end of the launch window, the launch is set by default to status (overrun), removing it from the current operations stream. A manual intervention is necessary to reactivate it, by prolonging the launch window. Setting the "forced run at end of period" indicator results in systematic submission of tasks with unsatisfied conditions at the end of the launch window.. Note: this information must not be confused with the bypass condition check option, which can be used with an interactive launch or in recovery operations (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 having declared incompatibilities.

Central monitoring Positioning this flag means that information concerning execution of the task (during start-up and finishing) is uploaded to the node declared as central monitor node in the DOLLAR UNIVERSE administration. See the chapter 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 most often arise through specific problems requiring local intervention, the corresponding "logs" are not uploaded to the central monitor.

Variables Task variables are selected from among those available for the Uproc in the Task identification. In the case of a 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 a whole 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, if not it's the Uproc's variables which will be proposed.

Task scheduling In DOLLAR UNIVERSE, scheduling essentially comprises: q

Implicit scheduling: use of scheduling rules

Reference manual

Scheduling • 75

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

q

Explicit scheduling: definition of explicit dates

Implicit scheduling allows the creation of algorithms for defining execution dates of each task. Each algorithm is managed individually in the form of a scheduling rule. Explicit scheduling allows the processing of various scheduling cases that cannot be dealt with automatically by the implicit scheduling mechanism.

Allocation of scheduling rules Each 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 of two weeks: it must be clear from which week the calculation begins). There must be an application date per rule allocated to a task. The application date must correspond to the period's starting date : • 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 scheduling parameters, the calculator will possibly reiterate its calculation until it finds a scheduling date greater than the first schedule date.

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

Explicit addition and cancellation of dates DOLLAR UNIVERSE offers exception dates and explicit dates associated with implicit scheduling, to stabilise and facilitate the implementation of scheduling rules. Effectively, while implicit scheduling can be used only in the case of scheduling rules remaining relatively stable over time, and if the proposed algorithms can self-adapt to the particularities of the calendars (such as possible use of "offsets" in implicit scheduling), a certain number of events may, on a particular day, disable the 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 an explicit date).

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

Explicit dates Explicit scheduling is the simplest way of scheduling a task. Tasks may be scheduled in absolutely any manner, from a permanent and repetitive multiple daily schedule, to random scheduling over time. Explicit scheduling consists in defining a set of information groups comprising: q

The required execution date and time,

q

The duration of the launch window,

76 • Scheduling

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

q

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

These possibilities allow the implementing of scheduling processes, which are systematically renewed over time 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: forecast workload function, a precise view of future operations. In the case of one-off launches, which take place more or less immediately, the use of interactive launch possibilities will be preferred, since it avoids interference in the standard scheduling process.

Exception dates In cases where, despite the flexibility of the proposed algorithm, a sudden event might disturb the definitive scheduling 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. It has no effect on any explicit dates associated with a task. To cancel the effect of an explicit date, the related date should be deleted by the explicit date declaration transaction.

Launch window The launch timetable option defines a launch window to allow for the particular operations load, which may vary day by day.. Where a task must be run several times each day, up to 150 executions can be defined on a given day, by defining 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 run For tasks that must be run once a day only, the scheduling times can be different for each type of day of the week. Note: this starting time corresponds to the "earliest" possible execution time ensured by the launcher, but does not correspond systematically to the execution date and time, which may be deferred if the conditions are not satisfied. The beginning of the launch window duration is completed by a duration (HHH.MM format) which is the time the launcher will keep the launch active pending satisfaction of its conditions. This interval may attain 999 hours and 59 minutes.

Multiple executions This function allows the entering of multiple launch times, making it possible to submit up to 150 executions of a given task in the course a day. The launch time limit is calculated by DOLLAR UNIVERSE by adding the indicated duration to the beginning of the launch window. The launch timetable is generated automatically for the specified period. This automatic generation feature can be repeated as many times as necessary, the generated times appearing gradually on the screen in ascending order. Note: this multiple daily launch function is not designed for supervising technical or applications events. If this is required, an external process will be needed; while obviously using fewer resources, it will not perturb the robot process. It is therefore recommended to use resource conditions or commands, not triggering.

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

Reference manual

Scheduling • 77

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Note: in the absence of a starting time, requests are processed immediately. If no duration is specified, the requests are 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 parts of the day. This notion is useful in that it allows user-requested batch tasks, or very resource-heavy batch tasks, 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 date Each time a task is launched, it is accompanied by calculation of (or a request for) a processing date which depends on the functional period (FP) of the related Uproc for this task (unless the Uproc has no functional period). FP of Uproc No FP Day Week 10 days 2 weeks Month Extended month 2 months 3 months 4 months 6 months Year

Format of processing date No processing date Day Month Week 10d n° Month 2w n° Month Month Ext. Month 2 Months Quarter 4 Months 6 Months

Year Year Year Year Year Year Year Year Year Year Year

The processing date occurs in all operations events recorded in the DOLLAR UNIVERSE execution history file. This makes it possible to conserve and distinguish the job traces of a task independently of the scheduling or execution dates. Example: processing date An accounts entry Uproc is monthly; at each launch, the requested period is a date with the format MMYYYY. The month-end closing Uproc is also monthly, and must conserve the trace (in the operating events file) of 12 correct executions to enable the year-end Uproc to run. Note: the functional period (format of the processing date) is independent, and can differ from the scheduling period of the related Uproc, even if DOLLAR UNIVERSE routinely proposes the algorithms necessary for automatically calculating the processing dates based on the scheduling dates.. Example: a monthly accounting-statement procedure is run twice a month: On the 30th of each month (month-end), to extract an initial statement of the past month, On the first Monday of each month to extract a complete statement integrating the "fifth "week of the past month. A similar example might entail an operation, submitted each end-of-week, to give a summary of movements for the current month. In order to specify this processing date more finely and allow the possibility of differentiating the processing date from the task scheduling date, additional parameters may be defined. The calculation method is based on the following chronological phases: 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.

78 • Scheduling

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Example: processing dates Consider a procedure defined with a period of "day" (processing date in DDMMYYYY format). It is assumed also that the day difference is "0". If the specified period shift is "0", the processing date automatically associated with it at launching is the same as its scheduling date. If the specified period shift is "-1", the processing date automatically associated with it is the day preceding the scheduled date. Example: calculation of a processing date For a task constructed on a monthly Uproc, a difference in calendar days of +5 associated with a period shift of +1 gives the following successive calculations: June + 5 days => 2 July July => month of July (by projection) July + 1 period => month of august => 19890801 Note: the difference in days is not a simple repetition of the period difference, except for the "daily" functional period. This is a valuable distinction when processing cases such as that shown in the following example: Example: distinguishing between differences expressed in days and in periods Returning to the example of the monthly accounting statement that is systematically submitted twice (on 30th of each month and on first Monday of following month). The difference must be expressed in days in order for these two executions to "point" to a given month. Considering the following differences: Period difference = -1 Day difference = +2 Irrespective of the date of the first Monday, the processing date obtained for the two executions will be the current month: June + 2 days => 2 July => June => 19900601 Mon. 4 July + 2 days => 6 July => June => 19890601 A similar result can be obtained with the following hypotheses: period difference = +0 day 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 before offset (date calculated by the rule before applying the possible offset contained in the rule). Examples: calculations of processing dates for scheduled tasks The execution date is taken as Tuesday 27 June 1989, with the calendar for the month of June configured as follows: Month June (06) Monday 05 work 12 work 19 work 26 work Tuesday 06 work 13 work 20 work 27 work Wednesday 07 work 14 work 21 work 28 work Thursday 01 work 08 work 15 work 22 work 29 work Friday 02 work 09 work 16 work 23 work 30 work Saturday 03 closed 10 closed 17 closed 24 closed Sunday 04 closed 11 v 18 closed 25 closed Some calculation examples: Reference FP Delta of FP Work days Processing date Day 0 yes 27/06/1989 Day 0 no 27/06/1989 Day +5 yes 04/07/1989 Day -2 yes 23/06/1989

Reference manual

Scheduling • 79

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Day 10 days 10 days 10 days Week Week Week 2 weeks 2 weeks 2 weeks Month 2 months Quarter 4 months 4 months 6 months 6 months Year Year

-2 0 -1 +2 0 -1 +1 0 +1 -1 0 -1 +1 +1 -1 0 +1 0 +1

no

25/06/1989 21/06/1989 11/06/1989 11/07/1989 26/06/1989 19/06/1989 03/07/1989 16/07/1989 01/07/1989 01/06/1989 01/06/1989 01/05/1989 01/07/1989 01/09/1989 01/05/1989 01/01/1989 01/07/1989 01/01/1989 01/01/1990

Superimposing launch windows For 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 purely and simply forgotten. If this is not the case, two distinct launches are scheduled. The one with the earliest starting time maintains its original window; the other has its start time adjusted to the end of the previous window, while keeping the same finishing time. Example: the effect of superimposed periods H b1

He1

Hb2

He2

single launch:

e1

Hb2

two launches: H

H e2 He2 H

b2

80 • Scheduling

- H b1

e1

H

H b1

Hb1

H

two launches:

- H b2

H

& e2

- H b1

H

& e1

- H e2

e1

H

- H b2

e2

He2

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Refining the operations process

Manipulation Updating DOLLAR UNIVERSE objects are managed with the following options: Create

Duplicate

Update Display Delete

A new object (Uproc, session etc.) In the selected working environment: company node - area. Creation will be refused if the object already exists in the environment. A source object to a target object. The objects will be of the same kind, but can have different types (model, non-model), with different identifiers (for example duplicate Uproc"tstref/001"onto Uproc tratbr/002), or different versions. Duplication on an already existing target object will be refused. The characteristics of an object. Its identifier is not accessible. The characteristics of an object, without being able to modify them. An object. Its identifier and characteristics will be cancelled from the working environment (including the CL Procedure file if the Uproc is internal).

Updating an object in a given environment (company, node, area) is specific to this environment and has no impact on the object in other environments. This means, for example, that a Uproc cancelled from the central dictionary 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 objects When a Uproc is accessed for update by a user, it becomes inaccessible to all other users, whether they be DOLLAR 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

Reference manual

Refining the operations process • 81

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

the launch window) the new launch will not be schedule until the task is updating, but it should be automatically calculated when the modification of the task will be completed.

Version management In the development environment (application and integration areas), DOLLAR UNIVERSE manages object versions (Uprocs and sessions) to facilitate the tuning of the operations process.

Uprocs DOLLAR UNIVERSE manages Uproc versions in the application and integration areas. In the simulation and production areas, the version is always null. DOLLAR UNIVERSE ensures parallel changes between the version number of an internal Uproc and the version number of the associated CL file. Parallel management of version numbers does not apply to external Uprocs. Current version The current version of a Uproc is the one which, of those Uproc versions available in a given area, is processed during execution of a session. Note: since only one version of a Uproc is possible in the production universe, this option can be used only in the development universe.

Sessions As for Uprocs, sessions are DOLLAR UNIVERSE objects which follow similar rules for development and implementation. Therefore: q

In the application, integration and simulation areas, sessions are managed by version. The entire session/version group is accessible from the application or integration areas. In this respect, Uproc versions processed during a session will be versions defined explicitly as the "current version".

q

In the production area only one version of a session is available.

Changing environment Transfer to an area In DOLLAR UNIVERSE, descriptive data concerning operations processes are principally assembled within the 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 one interactively 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:

82 • Refining the operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 may occur 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 the transferred object. For Uprocs with internal CL, transferring the Uproc will also entail transferring the associated commandlanguage 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 a version 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 number of 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 units Distribution means conveying certain parameters, not between one area and another, but from one machine to a set of management units, and through them, to other operations machines (within the same area). As before, the distribution of Uprocs with internal CL means the parallel distribution of descriptive information relating to the Uproc along with its associated CL. As for the transfer, each object category within DOLLAR UNIVERSE can be sent for distribution including the administration tables: Administration tables: Companies Nodes Management units Management unit types Management unit dependencies Applications Domains Application and MU directories Users

Objects: Uprocs Sessions Calendars Tasks Incompatibility classes Resources

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 not deleted). If the object already exists in the target area, it will simply be replaced by the newly distributed object. Objects can be distributed to: q

An explicit list of management units,

q

A management unit type, meaning, all the management units of the indicated type.

Reference manual

Refining the operations process • 83

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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

Distribute a model In the case of objects which do depend on the operations environment (i.e. calendars and tasks), only those defined as models can be distributed. They will become immediately operational for their target management units as soon as the distribution is validated (allowing a delay for transmission and installation). Unlike environment independent objects, distribution of model objects to local management units will result in their creation on the local node. Note: this function may be excluded if the target management units are not valid for the area in question (see definition of "Management units" ), or if the targeted nodes, through these management units, are not authorised for the area in question.

Distribute an administration table DOLLAR UNIVERSE does not allow "delta" distribution of tables (i.e. Differences only), any more than it allows customised distribution node by node. Attention must be given to ensuring that a table is distributed to all nodes as soon as it is created or modified, so that every node has a coherent view of the environment thus defined. The effect of distributing an administration table is to replace the entire target table by the original table: if there were records in the target table which are not in the original table, these will be destroyed by the distribution of the original table. An exception to the rule is the nodes table. Since version 4.3 its distribution no longer overwrites the local node. Note: the distribution of area level objects requires the presence (quite apart from network processes - see administration manual) of the exchanger for the area in which the distribution is performed. When distribution concerns objects at company level (as is the case with the administration tables), the exchanger of the production area is used.

Importing and exporting data To allow desynchronisation of the decision to distribute and the effective insertion of parameters, export and import commands are available in the DOLLAR UNIVERSE command interface (see Commands manual).

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

84 • Refining the operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Distribution logging All moves performed by the transfer or distribution functions are logged and displayable in the distribution history. These history files are designed to give a global view of the various parameters existing throughout the configuration, the ability to detect potential incoherence rapidly facilitates overall parameter management. The history 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 following table: Table Uproc Resource Session Calendar Tasks

Label Uproc, version Resource Session, version MU, (model) 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 cannot write the acquisition order to the remote site. • Move requested (D4), this status is returned for a distribution when the sending site has succeeded in writing the acquisition order to the remote site, but the latter has not returned an acknowledgement. • Move acquisition in progress (A3), this status is returned at the receiving site of a distribution, when the site has been successful in acquiring the required information. It is also obtained for a transfer, where it signifies the initialisation of the transfer. • Move acquired (A4), this status is returned for both a transfer and a distribution ; it indicates correct completion of the operation in question (for a distribution, means that the receiving site has acknowledged to sending site). If the status does not reach value A4, it means there is a problem with the corresponding operation: it is then necessary to check that the DOLLAR UNIVERSE I/O server (for UNIX) is properly running on the node and in the target area addressed by the transfer or the distribution. In this last case, a check is necessary to see if the 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 in question, so that a given node always has a clear view of incoming and outgoing moves.

Simulation of scheduled tasks Available in Windows, UNIX and VMS

Reference manual

Refining the operations process • 85

DOLLAR UNIVERSE version 5 for 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 job schedule 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 operations objects and consequently, the applications logic.

Objectives The interactive functions for defining and scheduling a task allow a simulation to be performed at any given time in relation to the reference calendar, and viewing the effect of the schedule on this particular task. This simulation can be executed over any configurable period. The aim of the present function is to obtain a much wider view of operations between two given dates, to allow 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 to correct comletion to ensure local simulation continuity. The selected schedule can be executed virtually by DOLLAR UNIVERSE.

Workload forecasting To enhance the readability of the workload forecasts, tasks to be processed can be selected, together with their display conditions: q

Task may be selected according to individual components (Uprocs, sessions or management units), either generically 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 components Sessions may be displayed generally or in detail, that is to say all component tasks on the processing path running on the selected management units. The forecast will take into account the particularities of those component tasks. In which case, optional tasks whose scheduling conditions do not correspond to those of the session will not be displayed. Similarly, deferred provoked tasks will appear offset in relation to the other tasks of the session. By default, the forecast workload displays sessions without displaying the detail of their component Uprocs.

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

Remote management units Sessions can include tasks running on remote management units. These tasks do not appear in the forecast, since their statistical information is not available on the local node. However, if these tasks are inserted between locally executed tasks, the calculator will take account of their existence, since the statistical 86 • Refining the operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

information operates on both the elapsed time for each task, and the interval between the start of the session and the starting time of each task in the session.

Workload simulation Objectives Available 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 statistical references – 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 a general view of production job behaviour. All necessary tools are supplied to enable a complete and rapid analysis of job behaviour and performance.

Simulation of forecast workloads For performance reasons, this function is restricted to simulating local operations only. Remote events are default to correct completion to ensure local simulation continuity. Finally, the execution times for these same remote 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 screen resembles 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 options Even if most of the functions are identical to those provided by the job monitor, the simulation function has special options for further analysis of simulated operations: q

Incident simulation: enables hypotheses to be built on an incident on the selected task simply by setting the 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.

Reference manual

Refining the operations process • 87

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

q

Restart simulation: at any given time, launch the simulation starting at a given date and time: all simulated events with launch dates later than the new simulation start dates are cancelled ; they then reappear as "expected launches".

Step-by-step mode The "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 execution conditions 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 completion instructions are being examined. The task then passes to the "Completed" or "Aborted" status. The function then automatically returns to the "wait" status, advancing to the next programmed launch date/time.

The cycle continues for each task. However, it should be noted that if several tasks are activated at the same time, launching of these will be requested first. Their completion processing is completed after the condition checking phase.

88 • Refining the operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

The operations process

Role of the batch engine DOLLAR UNIVERSE provides dynamic sequencing and launch control for each job, based on acyclical processes 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 interprets sets of descriptive information concerning the various jobs and their associated scheduling data, taking into account events as they occur, including any operator interventions. Thanks to this highly interactive approach, DOLLAR UNIVERSE brings: q

High performance (minimal resource consumption, due to the absence of a cyclical process, and "just-intime" job submissions),

q

Exceptional flexibility and reactivity,

q

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

The automation process The working of the DOLLAR UNIVERSE engine is represented by the following diagram: Calendars

Rules Operator

Tasks Uprocs / MU

Launches Calculator

Launcher

Awaiting Local or remote events Administrator

Executions

Exchanger

Supervisor

To remote sites

Operating system

DOLLAR UNIVERSE batch engine functions

Job scheduling is built upon tasks, which are procedures (Uprocs) or groups of procedures (sessions) to be run in an environment (MU), according to scheduling rules and calendars. The DOLLAR UNIVERSE batch engine then calculates the task's next execution date, then, at the appropriate time, launches the task by verifying the execution prerequisites (existing events or expected resources). If the

Reference manual

The operations process • 89

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

production environment is distributed, the batch engine communicates with the other machines, via the network. These various phases are performed by DOLLAR UNIVERSE through a series of different processes known as the calculator, the launcher, the supervisor and the exchanger.

Components of the batch engine The batch engine comprises three main components: q

The calculator, whose role is to calculate the following execution dates for all scheduled tasks or recalculate those dates following modification of the calendar or the task,

q

The launcher, which provides three essential functions, namely: condition checking, submission and completion of those tasks that the calculator has determined as being "ready to launch" (or that have been requested by user or operator trigger commands), it is assisted by the supervisor in the detection of system resources,

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-load periods, such as night or weekends), potentially without any operator needing to be present. The calculator and the launcher therefore do not function cyclically, but in direct reaction to the requirements of the production which they manage. DOLLAR UNIVERSE's automation functions are particularly efficient in terms of resource consumption. Furthermore, the calculator, like the launcher, work on the basis of the system date and time. Special care is required when changing the system date and time, since any changes not planned with rigor and with the production load in mind may well disorganise the automated production functions.

Location of the batch engine The batch processors (calculator + launcher) are specific to each company using DOLLAR UNIVERSE, and to each area within a given company. To ensure complete separation between the respective automation processes 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 data processing system. For organisations using cluster architecture (in VMS and open VMS), the required process may be present on each machine in the cluster. The files used by these process are, on the other hand, shared by all batch processes installed on the cluster machines. Note: the calculator and the launcher must be present for normal operation of DOLLAR UNIVERSE. Where automation is applied across the network, the exchanger is also indispensable: this means that the robot processes must be started in the working environment (company-node-area). Refer to the Administration manual for more ample information on the technical architecture supporting the batch engine.

Submission across the network The different batch engines installed exchange necessary information via a client-server connection comprised of a dedicated function called the exchanger (located in a distinct process). This process allows jobs to be executed on remote management units, or to condition them on remote job runs without this being apparent to an application running locally.

90 • The operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Execution phases of a task Execution 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. Automatic submission : calculating of execution dates

Manual submission

Event collection

Launching of tasks

Condition checking of launches ok

fatal

ok

Abandon

Reception of expected events Wait Time limit overrun

Execution

Termination

Task execution diagram

The five phases shown in the above diagram are performed each time a task is executed. Passage from one phase to another constitutes an operation event which is recorded by DOLLAR UNIVERSE.

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

Operation of the calculator The calculator maintains the next execution date for each task in real time. This calculation is performed in the following conditions: q

Each time the calculator detects an outdated execution date for a task (calculation of next execution date for the task in question), so at the end of the launch window,

q

Following calendar update: next launch dates of all tasks dependent on the modified calendar are recalculated,

q

And, of course, each time the task's scheduling parameters are updated. In this case, only the updated task's next launch date is recalculated.

Reference manual

The operations process • 91

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 the start of, or even within, the launch window (the interval of time between the first possible submission time and the last submission time defined in the task scheduling function). Job submission depends on the satisfaction of that 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 that will be considered by the launcher, and not the tasks themselves.

Impact of modifying a task In general terms, all modification (or activation) of a task results in the recalculation and update of the initial expected launch, on condition that the current system date and time is not within the initial launch window, in which case the recalculation will be performed when the end of the launch window is reached. Assuming that the update takes place outside the initial launch window, leaving aside the detailed working principles 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 task without 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 and exception dates), results in the recalculation of the particular task's next launch window (if it is not disabled and the calculator is present) to reflect the new definition.

Enabling - disabling of a task Irrespective of its category, a task can be disabled. An inactive task is a task for which scheduled launches are provisionally suspended. When a task changes from the enabled to the disabled status, its effect is immediate. Nevertheless, it has no effect 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 a disabled status. When the task is enabled, the first effective execution will occur for the next launch following the date on which the task was re-enabled. Disabling tasks which have multiple daily launches may result in a rapidly expanding expected launches file and 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 generated expected launch, or create the corresponding event, to simulate, if need be, execution of the task. Enabling corresponds to a complete update of the task. In this respect, activating a provoked task does not free generated expected launches with launch windows having submission start dates and times earlier than the current date.

Sequencing and launching The launcher The launcher contains the four main sequencing and launch phases, namely: 92 • The operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 the calculator; in the event of equality, it performs condition checking for this launch. In the opposite case, the launcher will hibernate until the date and time of the next expected launch. The data required for the launcher are transmitted by the calculator (or by various manual operations). In the case where condition checking of the launch is not satisfied, and provided the inhibiting conditions are not 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 an event-driven management process. Indeed, at the moment of condition checking, expected events inhibiting the satisfaction of the launch formula for the Uproc in question are stored. As soon as these events have occurred, the launch will be resubmitted for repeat condition checking. When the condition checking has successfully completed, the launcher submits the batch envelope which executes the actual CL. Procedure. After execution of the CL., The completion phase in particular determines which launches awaiting events require re-examination; this phase also ensures execution of the completion instructions associated with the Uproc in question; it also insures management of sequences defined in the sessions.

The launch Origin of launches A 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, reactivation or triggering command, using the interactive function or commands and API provided in the standard DOLLAR UNIVERSE release),

q

The task triggering command or a launch creating command (see commands or API manual).

Launch status A launch equates to an examination of the launch dates and times of the task, and receipt of triggering commands; 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 overdue The launch window is a period of time granted to ensure that all the conditions considered as pre-requisites to execution of the task are effectively satisfied. So a launch expected for 7:00 p.m. With a launch window of two hours may wait up to two hours for its conditions to be satisfied. If after this interval at least one of the

Reference manual

The operations process • 93

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

conditions is not satisfied, execution of this launch will be purely and simply abandoned. For some special cases, it is possible to impose execution of the launch at the end of this interval, even if all of the conditions are not met using the "forced run" option. In the event of a "launch window overdue" status, the launch can no longer be submitted. It must therefore be either 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 be able to restart all non executed jobs: in effect, DOLLAR UNIVERSE regenerates all launches that should have occurred (but solely in the production area), and, if the launch window is overdue, attributes them the "overdue " status: the user will then be able to decide which launches are to be executed or abandoned.

Operations on launches DOLLAR UNIVERSE comprises functions for operations analysis and job monitoring. In the job monitor, it may 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 actual task but solely the occurrences of the launches for each task.

Suspending or reactivating a launch This function allows all launches of a task to be suspended. The task can then no longer be started by DOLLAR UNIVERSE , until it has been released using the same option. All launches (irrespective of their "status") can be suspended, except for these that are already. Depending on the time of its reactivation, if the launch is outside its launch window, it can pass into " time overrun" status.

Starting an unscheduled job DOLLAR UNIVERSE allows new launches to be created manually, whether these apply to already scheduled tasks or not. If the task is already scheduled, the new launch occurrence will be added to the one produced by the scheduling function, without modifying or suspending it. Creation of a launch is entered much like a task; the task identifier must be given: Uproc, MU. And perhaps session, plus the technical information necessary for the execution (identical to that given in following paragraph). If the scheduled task exists, its technical information will by default be proposed.

Updating expected launches Updating 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 allows momentarily inhibiting launch of the task,

q

The processing date of the launch in question,

94 • The operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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 defined in the node table,

q

Automatic relaunch or restart mode: in VMS, indicates if the launch in question is to be submitted with the VMS restart option, that is, whether it can be automatically restarted by VMS after a system failure. In UNIX, the joint use of DOLLAR UNIVERSE and DQM allows access to the same functionality. This will resubmit those launches that were in progress at the time of the system failure, provided this option has been selected.

q

Modification of variables: in the case of a launch and where the launch has been created from a task, it is the variables of the task which apply. Where the launch has been created from a session, it is the variables of the Uproc in question which will be selected. In any event, these variables remain capable of modification so long as the launch has not been condition checked by the engine.

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

Launch history In order to keep track of all interventions performed, each operation on expected launches is memorised and made available in a modified launch history. The purpose of this function is to record the various manual interventions performed on the automated production process. While such interventions are a major advantage in the form of dynamic production management, 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 window etc.) Is also accessible.

Reference manual

The operations process • 95

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

The operations events file Condition checking of a launch is based on the resolution of the launch formula for the corresponding Uproc. This Uproc contains a certain number of conditions which are deemed either "satisfied" or "unsatisfied", according to analysis of the events occurred during operations. To ensure strict environmental separation, each area has its own current events file. On VMS, in the application area, there is a current events file per application, the corresponding files being physically stored in application directories as defined in the corresponding table. This arrangement is used to facilitate 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, the application being only a selection criterion. Each of these bases stores every event corresponding to all runs of Uprocs declared "memorised".

Modify events There 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 that have never run (such as conditioning a task on correct execution of the same task the previous day, for example). In this case, it will be necessary to create the required event artificially in order to definitively initialise the production cycle;

q

During a recovery process or during an intervention following a system failure, it may be necessary to modify or create operations, class or resource events in order to automatically continue a production sequence.

In these conditions it should be clear that any intervention on production events can have a particularly heavy impact on the production process. During the launch, execution and completion phases, the progression over time of a launch may be determined by the changes in its execution status. This is recorded in the current events history, which is used by the launcher for condition checking or recovery of Uprocs.

Network operations When conditions are used across the network (i.e. The conditioning Uproc is on a different node to the conditioned Uproc), the Uprocs events base plays a special role. When the conditioned Uproc is launched, the event request (session, Uproc, MU.) Is transmitted to the concerned node. When the conditioning Uproc runs, the event is created in the local base and is uploaded to the 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 is uploaded systematically. The conditioning Uprocs events base is managed according to the rules of memorisation defined in the Uproc general information. However, in the conditioned Uprocs events base, only the last event for the conditioning Uproc 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 automatically carries through to the events base of the conditioned Uproc. The reverse does not hold good.

Condition checking Launch status The different status values possible for launch executions are summarised in the following figure:

96 • The operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Launch wait Condition check

Time overdue

Event wait

Refused

Pending

Executing

Completion

Aborted

Completed

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 checking phase 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 checks Each launch is submitted to condition checking as soon as the start of the launch window is reached. The launch status is set to "D "(started) for the whole duration of the condition checking phase. Condition checking begins by examination of any incompatibility classes. These may be managed in the class events 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 there being any fatal condition, the condition checking function puts the launch on hold and records those missing events which prevented the success of the condition check. Throughout this time, the launch status is at "W "event wait". Each time a missing Uproc or resource event occurs (before the end of the launch window), the launch is resubmitted for condition checking (returns to status "D"). It should be noted that only inhibiting events are

Reference manual

The operations process • 97

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

memorised at each condition check (see "The launch formula" in the description concerning Uprocs), so that each new condition check can bring up any new inhibiting event. Unmet conditions inhibiting verification of the launch formula are processed as follows: q

If the condition concerns execution of a task on the same node, the event is recorded. As soon as DOLLAR UNIVERSE intercepts the corresponding event, the launcher will renew the condition check on this task,

q

If the condition concerns a task on another node, the exchanger process will trigger recording of the expected condition on the node in question. When DOLLAR UNIVERSE intercepts the event corresponding to the condition, it will transmit the information to the initial node, which will rerun a condition check on the task. This method of managing expected events provides, at the Uproc level, conditioning that is totally independent of the organisation or the layout of the environments within the configuration.

Upon expiry of the launch window, and if the launch formula is still not satisfied, execution of this task will be abandoned and the launch status will become "Time overrun". The possibility remains, nevertheless, of performing a forced run. In this case, upon expiry of this launch window, the task will be submitted, with the execution conditions being ignored. Note: a forced run ignores the launch formula outright, whether the latter contains incompatibility conditions or not. Use of the forced run therefore requires prudence. Finally, if the launch formula is verified, the launcher ensures creation of the execution process, and submits the CL. associated with this process.

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

Verification of resource condition quotas If the condition is satisfied, ( i.e. If the required quota is inferior to the available quota ), the Uproc reserves the quota, expressed in the condition, for the duration of its execution. If the resource was defined with automatic unlocking, the reserved quota will made available upon Uproc completion (status T or I), if not a specific script command will have to be run to free up the reserved quota (manual liberation). If the condition is not satisfied, because the requested quota is superior to the available quota, the launcher positions a quota wait on the resource in question. When the corresponding quota is increased, either by

98 • The operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

another Uprocs completion or by the specific command , the launcher will once again examine the resource attributes pertaining to the waiting Uproc. Note: for performance reasons, whenever possible, it is generally better to use the provocation commands in preference to resource conditions. For example, when a task should be run at every occurrence of a given technical 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 in graphic mode and two commands) enables reservations to be made on quotas of a resource. This reservation is carried out by virtue of a task (session, Uproc, management unit) executed in a defined environment (company, node, area) on behalf of a processing date. This enables: 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 will release them to it so as to authorise its execution. The immediate effect of this will be to block the quotas requested by the condition according to the usual process. Once quotas have been reserved by a task, any other launches presented for condition checking may be made 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 having requested more quotas (quota1 or quota2) in its reservation. If these are not yet available the launcher will await their release to run the task with the higher priority. If a task is presented for launch without having made any reservation on this resource but having a resource condition capable of being resolved by the launcher because the quotas are available, then the launcher will validate the condition and authorise the execution of the launch (even if other tasks are waiting for reasons of reservation).

Example: reserving resources The command: uxrsv res res=prio_ordo esp=x upr=IU_DT1 mu=S01 qt1=90 qt2=0 pdate=${S_DATRAIT} reserves for the task defined by Uproc iu_dt1, management unit s01in the production area, for the current processing date, the resource with the reference prio_ordo with a quota qt 1 of 90. If the resource prio_ordo has available to it a quota qt 1 of a maximum of 100, 10 remain free at the outcome of the execution of the command. Another task not having made any reservation on this resource can be run if its condition on this resource requires a quota of 10 or less. If a second reservation on the resource prio_ordo is requested by the following command: uxrsv res res=prio_ordo esp=X upr=IU_DT2 mu=S01 qt1=10 qt2=0. These two commands define a condition checking priority by DOLLAR UNIVERSE. The task which has reserved more quotas will be executed first, in this case the one defined on Uproc IU_DT1.

Uproc submission When the Launcher has validated the condition-checking phase of a Uproc, it submits the Uproc to the "batch envelope". It is this "batch envelope" which, thereafter, will initialise execution of the Uproc (by a connection to the submission account) and execute the completion phase (issuing of the return code).

Reference manual

The operations process • 99

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

U_BATCH Pre-processing UPROC

Post-processing

Uproc submission

The "batch envelope" also performs the completion of the execution: recuperation of the return code in the completion file.

Additional processing On Windows, UNIX and VMS, the execution of a Uproc, (shell script or DCL procedure) may be preceded by the execution of a pre-processing which will be common to all Uprocs. If this procedure exists it will be run systematically before each and every Uproc. The execution of the pre-processing may be used, for example, to define local environment variable or logical names which will be known to the Uproc during execution. This avoids having to integrate common code in the CL. In the same way, the Uproc execution may be followed by a post-processing, which if it exists will be run systematically for each Uproc. It will be common to all Uprocs. Pre-processing is called U_ANTE_UPROC and is situated in the mgr directory. Under VMS, it must be placed in the programmes directory. Post-processing is called U_POST_UPROC and is situated in the mgr directory. Under VMS, it must be placed in the programmes directory. Under VMS, these two procedures are supplied with a "TEMPLATE" extension in the programmes directory and can be adapted according to needs.

Job completion This represents the final phase in execution of a task. For batch tasks, it is provided by the completion function of 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) condition checking 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 be made to nodes other than the node running the launcher, the exchanger will execute all operations required for activating the launcher on the node(s) in question,

q

Uploads operations events towards the central monitor node, where central job monitoring is being used for a multi-site production environment,

q

Therefore completes the circle initiated by the calculator and the launch and condition checking functions of the same launcher.

100 • The operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Inter-machine communications Role of the exchanger The exchanger is a process in the DOLLAR UNIVERSE batch engine that handles all batch communications between the different nodes of the network (at the same time relieving the launchers and other interactive processes 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 has a configurable cycle to ensure the security of data transfers. All information which transits by the Exchanger (production or distribution events) can be accessed from the exchange events base.

Operating principles The batch engine manages task submissions via the launcher, in the following way: If the launches are to be triggered on a management unit, the launcher submits them for condition checking, If they are intended for a remote node, the launcher will use the exchangers of the source and target nodes to inform the launchers at the nodes in question. Launcher

Launcher

1

3

Exchanger

Exchanger 2 network

Exchanger mechanisms

In the latter case, the local launcher transmits the condition checking command to its exchanger (phase 1). The latter transmits the request to the exchanger of the management units in question (phase 2). The remote exchanger warns the launcher (phase 3), which submits the launch on the management unit. A sequence or incompatibility condition belonging to a local task on a remote task uses the same operating principles. If the expected event is not found locally by the launcher, it formulates a request for an event wait to the exchanger (phase 1). The local exchanger transmits the request, together with the name of the sender, to the remote exchanger (phase 2). The latter transmits it to the remote launcher (phase 3). If the event is available, the reply is immediate; otherwise the remote launcher posts an event wait; when the latter occurs, the reply will be transmitted to the original launcher, which will resolve its own event wait and record it in its current events file (to avoid searching for it each time it is needed).

Reference manual

The operations process • 101

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Note: for a technical description of the inter-machines communication operations, reports to the administration manual.

System failures In 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 will automatically re-examine the validity of this launch window and possible condition checking. If the launch was already on hold, it will not be considered (no point);

q

The system failure occurs in the course of launch. In this case, no irremediable operation has been performed, and it will simply resume the launch and submit it to repeat condition checking (performed automatically by the batch engine);

q

The system crashes simultaneous with the completion phase. In this case, a DOLLAR UNIVERSE function started during the boot or with the computer IPL resumes and ends the completion instructions for each launch remaining at the "F" status (instructions in progress);

q

The system failure takes place during the execution. In this case, DOLLAR UNIVERSE offers the possibility of automatically restarting the corresponding launches, using specific parameter settings associated with each task (automatic restart on 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 processing operations (in order to await their completion), or will declare them as "incidents" if they are no longer present. In addition, DOLLAR UNIVERSE authorises insertion of recovery steps in the CL., Enabling partial 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 the production area) which should have taken place during the system failure (either crash of operating system or DOLLAR UNIVERSE itself).

102 • The operations process

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

The operations monitoring

Job monitoring Purpose DOLLAR 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, and permitting the necessary diagnosis and recovery procedures. There is a transaction dedicated entirely to job monitoring. Organised around a control screen, the job monitor provides dynamic display (audible alarm, automatic screen refresh) of all or part of the finished or current job runs. The job monitor features fine selection criteria, allowing the operators to focus on the most strategic jobs. All essential data is directly accessible from the job monitor: q

The history trace formatted by DOLLAR UNIVERSE, recording the phases performed by the job and, for jobs in an event wait state, the events expected. This history trace can receive comments or operator instructions 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 on the operations process. Naturally, the job monitor allows all or certain of the operations events occurring on a node, for a given area to be displayed.

Central monitoring Nevertheless, ever since DOLLAR UNIVERSE version 3.3, it has been possible from a node defined as the central monitoring node (see paragraph entitled "Central monitoring") to display not only local production events but also remote events generated by tasks defined with central job monitoring.

Reference manual

The operations monitoring • 103

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

For this latter type of task, the events concerning the start and end of execution are systematically transmitted to the central monitoring node. In this way, the job monitoring function active at the central monitoring node sees 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 status The following job statuses are to be found in the job monitor : Status Completed Aborted

Completion

Execution Pending

Held

Launch refused

Event wait

Code Meaning T Normal successful completion of a Uproc. I Abnormal end-of-job. This status is normally generated by the procedure itself (see the commands manual chapter entitled "execution CL" for more information regarding the possibilities for managing return codes) This status appears only during correct F completion of the procedure, and corresponds to execution of the completion instructions. Irrespective of the final status, the other completion-phase operations are performed: reactivating of events on hold, request for launch of following Uprocs in a session E Execution of job in progress A This status corresponds to submission of the job in a batch queue, following a successful condition check. The duration of this phase of the launch can vary with the technical characteristics of the batch queue at any one moment. H Launch on hold. This status can occur following an intervention of this type: in the expected launches function (or after the corresponding command), in the job monitor, or the associated batch queue management function. This abandon occurs when a fatal condition is R not satisfied during the launch's condition check. W If one or more non fatal conditions are not satisfied (but no fatal), an event wait is posted. A given launch can be put into an event wait several times. Each of them corresponds to an unsuccessful condition check. After the first unsatisfied condition check, the launcher is set to await the corresponding event. Occurrence of the expected event results in a new condition check. If this new condition check brings up another unsatisfied condition, the launch is again put into an event wait.

104 • The operations monitoring

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Time overrun

O

Condition check

D

Launch window overrun. This status occurs each time that an expected event does not occur during the valid launch window or when one or other of the calculator or launcher functions has been absent for too long. Condition check in progress. This phase corresponds to examination of the execution conditions of the launch. It should be noted that this status is considered as inhibiting in relation to any non-simultaneity conditions (or incompatibility criteria) from other jobs.

Diagnostics The DOLLAR UNIVERSE job monitor retains only the last occurrence of these successive examinations. It remains nonetheless possible to consult the various occurrences thanks to the option "display previous launches", or by browsing the execution history. In order to monitor its activity, DOLLAR UNIVERSE feeds to a general log file containing all errors from the product and its interfaces detected during operation (except for OS400, where a spool file is used). A log file is also generated for each process or robot process, containing operating errors and specific information messages 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, the file 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 a message to be recorded in them.

Authorised interventions Kill a job This function can only be accessed if the execution status is "Execution in progress". It has the effect of stopping the execution of the Uproc at the level of the system thereby stopping all dependent sub-processes. The execution then takes on the status "Aborted".

Recover job This 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. It remains possible to modify or to create the considered event, in order to give it "Incident" status and so be able to restart it.

Display previous launches This option displays all condition checks concerning a launch before being executed or abandoned as well as the "history traces" corresponding to each launch or condition check.

Display history trace The DOLLAR UNIVERSE job history trace is presented in the form of a formatted screen in which messages are 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 with date and time of condition checking by the launcher, the processing date, the date, time and number of the entry on the batch queue and an explanatory message concerning the state of the task. Reference manual

The operations monitoring • 105

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

It is possible, using a special $u command (see commands manual) to insert operator instructions into this trace, from the Uprocs.

Display log The 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's STDOUT and STDERR to the execution log file.

Management of job queues Job queue management is available in VMS or by using DQM in UNIX. Operations describe below concern only the character interface on VMS. This option allows the operator, without leaving the job monitor, to manage batch queues and jobs that they contain, whether scheduled batches or user requests, submitted by DOLLAR UNIVERSE or otherwise (an added view of the technical environment over and above the functional view provided by the operations tracking 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 by entering 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 batch queue. 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 the job in question. Modifications may only be performed on jobs pending execution (i.e. Status = P).

106 • The operations monitoring

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

History files and statistics DOLLAR UNIVERSE comprises a series of functions dedicated to maintaining histories of operations events. 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 used directly for automating operations, DOLLAR UNIVERSE stores a series of technical information concerning the resources consumed by each task.

Execution history Job monitoring makes it possible to follow the different phases in the execution of a task. Within this transaction, events may be purged for convenience, as soon as necessary. Because of this, the job monitor can not guarantee a complete history of executions. Nevertheless, these same events are stored elsewhere as operating events. They will be used by the launcher during the condition checking phase to verify the launch formula of each Uproc. For operations reasons, these operating events can themselves be destroyed manually or automatically from the Uproc completion instructions. DOLLAR UNIVERSE therefore manages a third level of history in which no random or manual purging is possible, other than a systematic purge based over a defined retention period. For instructions concerning the technical purging procedure, refer to the paragraph entitled "processing of operations parameters" in the present manual, and to the paragraph dealing with maintenance tasks in the technical manual. Note: all launch attempts performed by DOLLAR UNIVERSE are recorded in this history file, to facilitate comprehension, at a later date, of the sequencing events managed by DOLLAR UNIVERSE. If a given launch has been through condition checking three times (following the arrival of expected events), the launch will appear three times, with three different sequence numbers.

Available information Executions are marked by the identifiers of the different tasks: Uproc, session, M.U., And by their execution number. 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 an expected 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,

Reference manual

The operations monitoring • 107

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

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.

Statistics For each job run, DOLLAR UNIVERSE memorises the consumption of essential resources (CPU, direct and buffered I/O, memory, elapsed time etc., Depending on the operating system), the elapsed time of the last hundred job runs and calculates the median values. This method of calculation provides values corresponding to 50% of job runs. It also limits the impact of exceptional, insignificant results on the values calculated. All this data can be displayed interactively in graphic 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 in order 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 in task-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 cancellation function serves for initialising the statistical values of a task.

Purging Operating events file The operating events file is fed by the execution of Uprocs that have been declared as memorised. Depending on the memorisation parameters declared during definition of the Uproc, one or all of its job runs will be archived over the number of periods indicated. Since this file serves for conditioning other procedures, care must be used when purging it. An automatic purge can be performed using completion instructions. These are meant to purge certain events at the end of a Uprocs execution. A manual purge can also be performed, by selecting events then deleting them from the file.

Job monitoring Job monitor records are purged manually. This means that all occurrences selected will be purged and therefore will disappear from the job monitor screen. If several executions of the same procedure are purged, they will all be cancelled. The purge does not keep the last execution. Purging the job monitor has no effect on normal 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, in the operating events file. The execution of the purging Uproc enables deletion from the job monitor of any remaining records from prior to the purge date.

108 • The operations monitoring

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

The job monitor can equally be purged by means of a purge command which allows more precise selection than the purging Uproc. See the commands manual for details of its use.

History files History files are purged by a batch Uproc delivered with DOLLAR UNIVERSE. This procedure must be scheduled at least once a month. It will purge the execution history of any operation whose retention period has expired. Since the 4.3 version of DOLLAR UNIVERSE , when purging job runs, the execution history file do not retains the last execution of any given procedure, irrespective of its date. This Uproc must be scheduled and executed for each area of the company. Scheduling of this special procedure must not specify a processing date. Refer to the administration manual for more details.

Log files DOLLAR 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 can therefore allow for his own operations constraints. Refer to the administration manual for more details.

Reference manual

The operations monitoring • 109

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Glossary

1st Scheduling Date Corresponds to a startup date. According to the scheduling parameters, the calculator may reiterate its calculation until a scheduling date greater than the first scheduling date is found to generate the first launch of this task.

Aborted Status of an execution which ended abnormally, either via the application positioning of the script exit value (see completed status), or via a sudden exit from script execution.

Application Date Date beginning with which the calculation of the rule applies (indispensable, for example, for a rule invoking a two week period: the week with which the calculation begins must be known). The application date must correspond to a period start date defined for the rule. For example for a "week" period rule, the application date must be a Monday.

Area Work environment within a company. Four Areas are proposed and named: Application, Integration, Simulation and Production. The production area is the only one that must be started up. The others are optional. The areas are sealed, secured operating environments but featuring interactive configuration transfer functions (within the same company).

Calculator The calculator is an engine specific to an area. On an occurrence basis, it calculates the next scheduling date for each of the tasks and updates this schedule each time their planned launch window has expired or in the event of a task or attached calendar change.

Calendar Defines the types of days: working, not worked, and holidays over a range of years for a management unit, the types of management unit or by default the area (this is the general calendar, it is unnamed). The calendar is used by the calculator engine as a reference to calculate the scheduling of tasks.

Reference manual

Glossary • 111

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Company The company represents a DOLLAR UNIVERSE installation and consequently a work (data) environment for the automation of production. The company is a secured operating environment that can only communicate through its configuration import/export commands.

Completed Status 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 Check Examination by the launcher engine of the UPROC execution conditions and possibly putting the launch on standby if the conditions are not met. During a condition check, the status of the launch is "condition check", if the conditions are not solved the status of the launch becomes "event wait", if the conditions are solved, the launcher proceeds with processing submission.

Drag & Drop Graphic 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 described below 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. If the reception is refused (because this is not the intended site) the object returns to its initial location.

Event Wait Status of a launch in its launch window whose launch formula has not been entirely solved.

Exchanger The exchanger is an engine specific to an area. It is used in network communications within a DOLLAR UNIVERSE company to perform configuration distribution, network event transmission or network submission order operations.

Floating Menu By placing the mouse in the left list of a window and clicking on the right mouse button you can access a floating menu in which you may select an action to be performed. The object on which the action is to be performed must be selected in the list beforehand unless the Create option is selected. A floating menu is also available in a graphic area.

112 • Glossary

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Functional Period Processing frequency in the application sense (e.g. a balance sheet is monthly) possibly distinct from the processing scheduling frequency. The functional period defines the format of the processing date (daily, weekly, monthly etc.).

Launch A launch is an occurrence of the calculation of a task. It may be the result of the scheduling by the calculator or of an explicit creation request by an operator, or of an invocation (via session progress or a command).

Launch Formula Boolean equation uniting the conditions necessary for the execution of a UPROC. This formula may contain all the types of conditions: chaining, non-simultaneity or resource linked by the boolean operators AND, OR and NOT. It may contain up to 99 conditions and 9 levels of parentheses. The order of the launch formula determines the order of the condition check by the Launcher engine.

Launcher The launcher is an engine specific to an area. It schedules launches on the basis of events. It works mainly with the date and time of the next launch, at which time it reactivates itself and performs the condition check and processing submission operations. It is also reactivated by events attached at the end of processing execution to run new condition checks.

Management Unit Logical work environment of the application tools. One or more management units can be defined on the same node. The management units are grouped per type (represented by the first letter of the management unit). The handling of M.U. types allows the processing to be configured generically (for example "all type A M.U.s"). Configuration thus becomes independent of the physical configuration of the architecture.

Node Logical title (limited to 10 characters) representing a physical machine. The uxsrsrv.sck file of the mgr directory of the Company provides the correspondence between the NODE name (in the DOLLAR UNIVERSE sense) and the physical name of the machine (in the operating system sense).

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

Processing Date Date qualifying the period for which the UPROC works. The processing date may be different from the processing scheduling date (e.g.: for scheduling on February 3, the processing date may be calculated automatically via an algorithm defined by the customer as being the preceding month, that is January 1st). The processing date is usable in the UPROC script in a variable or in conditioning between UPROCs.

Reference manual

Glossary • 113

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Resource A resource is used to describe, via a logical identifier, a system resource (a file for example) which is to be supervised to condition the execution of a UPROC. By extension a resource may also be logical (or virtual). It has no physical reality but is managed by notions of exclusivity or quota assignment (with respect to a maximum).

Rule Periodic algorithm (of the day, week or month type) allowing the scheduling dates of a task to be defined. The rules work on the management unit calendar for which the concerned task is executed (if it does not exist, the calendar of the type of management unit and the general calendar of the node are sought).

Select To select an object of the graphic interface, click on the line of the object with the left 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 changes color.

Session A session is a homogenous set of UPROCs (e.g.: same scheduling). It is used to describe a UPROC submission order and to define downgraded processes in the event of a UPROC execution incident.

Submission If a UPROC launch formula is solved, the launcher submits the execution of the processing to the batch queue manager or in its absence to the operating system.

Supervisor The supervisor is the only engine common to all the areas on a node. Its function is to supervise the resources on launcher request when it examines a UPROC whose resource condition is not met. The supervision process is cyclical, according to a period defined for each resource.

Task Technical and execution scheduling characteristics of a UPROC or a session on a management unit. Three types of tasks can be defined: • Scheduled task: periodically or via the 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 the technical characteristics of a scheduled task. The calculator generates a launch on the basis of the definition of a task.

UPROC Object used to define, around a command file (script, DCL, CL, .bat), all the application conditions necessary to the execution of the processing (inter-session chaining, file standby, parameters, processing date etc.) except for the technical and temporal execution conditions.

114 • Glossary

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Index

$ $U access control 13 architecture 13 batch management 8 batch queues 8 central monitoring 15 client-server 13 co-operative architecture 14 customisation 35 description of a job stream 9 distributed architecture 14 environment 19 features 8 Implementation 12 interfaces 15 job description 9 job monitoring 8 modification operations 81 objectives 7 parameters distribution and transfer 15 scheduling 9 security 12 sequencing 11 simulation 12 statistics 11 technical locking on objects 81

A Access control principles 13 Access path restoration in the CL 32 Add years in a calendar 68 Allocate a transaction of $U 36 Application

Reference manual

definition and use 32 definition of the area 22 directories table 32 use in coding of Uprocs 44 Architecture co-operative 14 distributed 14 secure operations 13 Area definition 19, 22 distribute an object within an area 83 location of batch engine 90 management by version of session 82 management by version of Uproc 82 node authorisation 31 transfer of an object to an area 82 use in resource identifiers 42 use of the management unit 23 Author code definition 35 use 38 Automatic restart defining for a task 75

B Batch engine components 90 consequences of a system failure 102 execution phases 91 functional architecture 89 job completion 100 location of components 90 role 89

role of the supervisor in resource conditions checking 98 submission and conditioning of tasks across network 101 working principles of the calculator 91 working principles of the exchanger 101 working principles of the launcher 92 Batch envelope additional processing 100 role 99 Batch queue management 106

C Calculator impact of modifications of a task 92 role 90 working principles 91 Calendar distribute a model 84 distribution history 85 distribution to MU 83 impact of modification on tasks 69 impact of update on task schedule 91 minimum range 68 model 68 presentation 10 principles of generation 68 purpose 67 transfer to an area 82 type of days 69 Central monitoring completion role 100

Index • 115

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

defining in a task 75 definition of the central monitor node 30 purpose 103 role of the exchanger 101 updating at launch 94 Chronology condition purpose and definition 59 CL definition 44 description 45 insert a message in the history trace 105 use of commands 46 version management of internal Uprocs 82 Class example 43 purpose 43 use 43 verifying at launch 61 Client-server principles 13 Coding MU and MU type 24 of tasks 71 of Uprocs 44 sessions 63 Command $U specific commands 105 use in the CL 46 Command file see CL Company definition 19, 21 editor, object locking, master node, directory 21 independence of companies 21 location of batch engine 90 role 21 use in resource identifiers 42 users table 35 Completion role 100 Completion instructions completion role 100 consequences of a system failure 102 definition 44 general characteristics 52 network operation 62 purge events 108 purpose 62 purpose and operations 62 using the notion of MU 53 using the notion of processing date 54

116 • Index

using the notion of session 52 using the user account 55 Condition chronology 59 definition 51 expected or excluded 55 fatal - definition 56 fatal - processing in the launch formula 61 general characteristics 52 network operation 62 non simultaneity see non simultaneity condition resource see resource condition role of conditions in the launch formula 61 sequence see sequence condition text if proposition satisfied or not 56 use of memorised Uprocs 50 using the notion of MU 53 using the notion of processing date 54 using the notion of session 52 using the user account 55 Condition check across network 101 bypass condition check of a launch 94 consequences of a system failure 102 examination of incompatibility classes 43 forced run 93 network operations 96 operations 97 previous launches 105 principles 92 priority 99 role of the exchanger 101 Condition of non-simultaneity differences between incompatibility classes and non-simultaneity conditions 43 Condition of resource operating principle 98 Create years in a calendar 68 Current version of an Uproc 82 Customise $U profile features 36 recommendations 36 restrictions 36 user menus 37

D Date exception date 77 explicit 76 first schedule date of a task 76 of application of a rule 76 Day of scheduling 70 Days in a calendar 69 Deallocate a transaction of $U 36 Deferring launch execution of a provoked task 77 use of provoked task 73 Definition application and domain 32 areas 22 author code 35 automatic restart of a task 75 batch engine 89 batch queue of a task 74 calendar 67 calendar model 68 calendar range 68 calendar type of days 69 central monitor node 30 central monitoring in a task 75 chronology condition 59 company 21 company, area, MU 19 completion instructions 44 condition 51 current version of an Uproc 82 fatal condition 56 forced launch at end of window of a task 75 hierarchical data processing (HDP) 24 internal CL or external CL file 45 JOBD (job description) 74 launch window 77 launching a task 44 management unit 22 master node 30 memorised Uproc 50 MU dependencies 24 MU Type 24 node, logical node, physical node 29 non simultaneity condition 58 normal or abnormal processing path of a session 65 optional task 73 previous launches 105 print queue of a task 74

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

priority of a task 74 processing date 78 provoked task 72 resource 41 resource condition 60 resource reference 41 scheduled task 72 scheduling rule 70 sequence condition 57 session 63 session header 63 submission account 38 successor 51 task 71 task model 72 Uproc 44 Uproc parent, child or per in a session 63 user account 74 user profile 35, 36 variables 47 variables in a task 75 Dependencies examples 25 Diagnostic log file 105 Directory access path to applications objects 32 access path to MU objects 33 access path to objects 32 company 21 company on a node 31 MU or application – restore in the CL 46 of a CL associated to an Uproc 45 Disable a task 92 Display history trace in the job monitor 105 Display previous launches in the job monitor 105 Distribute a model 84 a table 84 Distribution calendar model 68 history 85 node - impact on central monitoring 30 object locking 84 principles 15, 83 role of the exchanger 101 status 85 task model 72

Reference manual

to a local MU 84 Uproc with internal CL 45 using MU Type 24 Domain definition and use 32 use in coding of Uprocs 44

E Editor definition in the company table 21 to write the CL 46 Elapsed time of execution in forecast workload 86 Enable a task 92 Environment presentation 19 restoration of access paths stored in the tables 32 structure 19 submission account 38 submission accounts 38 user accounts 35 Event completion role 100 creation by the batch engine 91 description of the event file 96 list of status values 104 memorised Uproc 50 network operations 96 purge by completion instructions 62 purge in the events file 108 purge in the job monitoring 108 using 96 Example chronology conditions 59 completion instructions 62 excluded condition 55 fatal condition 56 incompatibility class 43 memorised Uproc 50 modify a calendar 69 MU, MU type, dependencies, HDP 25 non simultaneity conditions 58 processing date 78 resource 42 scheduling rule 70 sequence conditions 57 use of HDP in a session 65 use of HDP in conditions 53

Exception of scheduling within a session 64 Exchanger role 90, 101 submission and conditioning across network 101 Excluded characteristic of a condition 55 Exclusivity use in resource conditions 60 EXE value 32 Execution consequences of system failure 102 display history trace 105 display previous launches 105 history file 107 kill 105 list of status 104 possible values of status 96 recover 105 Execution environment of a session using HDP or the MU 65 Execution report history trace 105 insert a message from the CL 46 log file 106 text if proposition satisfied or not 56 Execution status use in completion instructions 62 use in sequence conditions 57 Expected characteristic of a condition 55 Explicit add or cancel dates 76 scheduling 67 scheduling a task 75 External Uproc CL file 45

F Failure consequences of system failure 102 Fatal condition definition 56 processing in the launch formula 61 FIC value 33 File manipulation

Index • 117

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

use commands in the CL 46 Forced launch bypass condition check 94 defining in a task 75 Forecast workload display the session components 86 launch window 86 manipulation 86 objectives 86 simulation of schedule 85 tasks executed on a remote node 86 Functional period calculation of the processing date 78 definition 48 use 49 use in chronology condition 59 use in conditions and completion instructions 54 use in non simultaneity condition 58 use in sequence condition 57

H HDP convention and use 24 definition 24 examples 25 use in a session 65 use in CL 46 use in condition and completion instructions 53 use in non simultaneity conditions 58 use in resource conditions 60 use in sequence conditions 57 Header first Uproc of a session 63 scheduling a session 64 Hierarchical data processing see HDP History file available information 107 distribution and transfer 85 executions 107 interventions on launches 95 overview 107 purge 109 History trace display in the job monitor 105 insert a message from the CL 46 text if proposition satisfied or not 56

118 • Index

defining 74

I Identifier interface with provoked tasks 73 Implementation principles 12 Implicit allocating of rules to a task 76 examples of scheduling 70 scheduling 67 scheduling a task 75 scheduling rule 70 Incompatibility see Class Inheritance MU of execution within a session 65 of technical characteristics – exception of the provoked task 73 of technical characteristics of the task within a session 64 Inhibit execution of Uproc for given period see Chronology condition Integration definition of the area 22 Inter MU check principles 53 Inter processing date check principles 54 Inter session check principles 52 Interface with provoked tasks 73 Interfaces of $U 15 Internal Uproc CL file 45

J Job log display the log in the job monitor 106 Job monitor display history trace 105 display in the job monitor 106 display previous launches 105 job queue management 106 kill a job 105 kill an execution 105 purge 108 purpose 103 Job queue management 106 JOBD

K Kill an execution 105

L Launch cancelling 95 condition check 97 conditions of analysis of launch formula 61 definition 44 extension of launch window 93 holding or releasing 94 impact of a fatal condition 56 impact of the notion of successor 51 interventions on launches history 95 list of status 93 manual launch of a task 94 operations 94 origin of launch 93 possible launch modes 71 possible values of status 96 previous launches 105 processing of Uproc successors 51 purpose of execution events 51 purpose of the launch formula 61 updating 94 Launch formula example with chronology conditions 59 example with non simultaneity conditions 58 example with sequence conditions 57 limits 62 optimisation hints 61 purpose 61 Launch window extension 93 in forecast workload 86 of a provoked task 77 superimposing launch windows 80 updating at launch 94 Launch window definition 77 multiple executions 77 single job run 77

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

Launcher role 90 working principles 92 Limits maximum number of Uprocs in a session 66 maximum number of conditions in a launch formula 62 Linking two Uprocs see session see sequence condition Locking declaration in the company table 21 functional on objects 84 technical on objects 81 Log file diagnostic tool 105 display in the job monitor 106 purge 109

M Management unit and the areas 23 calendar 67 coding 24 definition 19, 22 definition of MU Type 24 distribute objects 83 examples 25 involvement in HDP 24 MU Type definition 24 objectives 14 scheduling environment of a task 71 use 23 use in condition and completion instructions 53 use in non simultaneity conditions 58 use in resource conditions 60 use in resource identifiers 42 use in sequence conditions 57 using dependencies in the HDP 24 using for defining the execution environment of a session 65 Master node declaration in the company table 21 definition 30 Memorisation characteristics 50 definition 50 Menus customise 38

Reference manual

Model distribute 84 of calendar 68 of task 72 Modify organisation of $U menus 37 the priority in a job queue 106 Monitoring see Job monitoring MU directories table 33 MU dependencies see HDP MU type calendar 67 distribution restriction of calendar 68 examples 25 role, definition and coding 24

N Nature of resource 41 Network location batch engine 90 Node access path to applications directories 32 access path to MU directories 33 area authorisation 31 calendar 67 central monitoring 30 company directory 31 definition and use 29 master 30 user accounts 35, 37 Non-simultaneity differences between incompatibility classes and non-simultaneity conditions 43 purpose and definition of the condition 58 use the incompatibility classes 43 Normal or abnormal paths in a session 65 Number of executions per period memorised Uproc 50 Number of functional periods memorised Uproc 50

O Object distribute 83

transfer principles 82 Offset of scheduling 70 Operating date use of functional period 48 Operations monitoring objectives 11 Optional task definition 73 display in the forecast workload 86 Order the examination of Uprocs waiting an event 51

P Parameters transmission to Uprocs 46 Path normal or abnormal in a session 65 Period of scheduling 70 Previous launches display in the job monitor 105 Print queue defining in a task 74 Priority defining in a task 74 modify a job queue on VMS 106 Processing date definition 48 purpose and definition 78 updating at launch 94 use 49 use in chronology condition 59 use in conditions and completion instructions 54 use in non simultaneity condition 58 use in resource condition 60 use in resource identifiers 42 use in sequence condition 57 Production definition of the area 22 Profile definition and use 35 definition, role and use 36 of a user 37 Proposition condition element 55 text if proposition satisfied or not 56 Provoked task deferring launch 73 definition 72

Index • 119

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

display in the forecast workload 86 exception of inheritance of technical characteristics 73 interface with applications 73 Public holidays in a calendar 68 Purge events 62, 108 events in the job completion 100 histories 109 job monitoring 108 log files 109 with completion instructions 62

Q Queue batch defining in a task 74 Quotas definition and use 41 use in resource condition 60

R Range minimum for a calendar 68 Recover an execution 105 Report history trace 105 of execution - display in the job monitor 106 Reservation of a logical resource 99 Resource coding with MU Code, processing date, company or area 42 definition and use 41 distribution history 85 identifier, nature and quotas 41 reservation of a logical resource 99 restriction on use of variables 42 Resource condition operating principle 98 purpose and definition 60 Resource reference see Resource Restart mode updating at launch 94 Robot process see Batch engine Rules presentation 10 Running a task purpose of launch 51

120 • Index

S Scheduled task definition 72 Scheduling calculator operations 91 consequences of a system failure 102 definition 71 effective scheduling date 76 examples of rules 70 exception of the optional task within a session 73 explicit 76 explicit or implicit 67 generation principles of calendar 68 impact of updating calendars 69 implicit application date for a rule 76 implicit or explicit 75 inheritance within a session 64 launch window 77 objectives 9 presentation 8, 10 purpose of the calendar 67 scheduling rules 70 Scheduling rule examples 70 presentation 10 purpose and definition 70 Security objectives 12 Sequence condition purpose and definition 57 Sequencing objectives 11 Sequencing Uprocs using sessions 65 Session coding 63 definition 63 definition of paths 65 display in the forecast workload 86 distribution history 85 distribution to MU 83 first run 96 inheritance of scheduling of header 64 management of versions by area 82 maximum number of Uprocs 66 presentation 9 scheduling 71 structure 63

transfer to an area 82 use in condition and completion instructions 52 use in non simultaneity condition 58 use in sequence condition 57 using HDP or the MU 65 using MU Type to distribute 24 variables 65 Session header scheduling 64 Simulation see Forecast workload definition of the area 22 presentation 12 Statistics presentation 11 purpose 108 use by forecast workload 86 Status of executions 104 of launches 93 of the distribution or transfer 85 possible values for a launch or an execution 96 use in non simultaneity conditions 58 use in sequence conditions 57 Steps define in the CL 46 Stop an execution 105 Structure access path to applications directories 32 access path to MU directories 33 Submission across network 101 role of the exchanger 101 Submission account definition 38 Successor definition 51 processing by the launcher 51 purpose 51 Supervisor purpose for resource conditions 98 Suspend temporary the task execution 92 System failure effect on executions 102 extension of launch window 93

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

T Tables applications directories 32 company 21 distribute 84 distribution history 85 management unit 22 MU dependencies 24 MU directories 33 user accounts 35, 37 using MU type to distribute 24 Target of the distribution 84 Target of a condition inter MU check 53 inter processing date check 54 inter session check 52 user account 55 Task application date of a scheduling rule 76 cancelling a launch 95 defining JOBD 74 defining the automatic restart 75 defining the batch queue 74 defining the central monitoring 75 defining the print queue 74 defining the priority 74 defining variables 75 definition 71 distribute a model 84 distribution history 85 distribution to MU 83 enable/disable - impacts 92 execution phases 91 explicit scheduling 76 extension of launch window 93 first run 96 first schedule date 76 forced launch at end of window 75 forced run 93 holding or releasing the launch of a task 94 implicit or explicit scheduling 75 inheritance within a session 64 interventions on launches history 95 launch window 77 list of execution status values 104 list of status of launches 93 manual launch 94

Reference manual

model 72 optional 73 origin of launch 93 processing date 78 provoked 72 schedule 72 scheduling rules 70 superimposing launch windows 80 transfer to an area 82 updating the launch 94 user account 74 Text if proposition satisfied or not definition and use 56 Transaction customise the menus 38 definition 36 purpose 37 user menus 37 Transfer history 85 object locking 84 principles 15, 82 Uproc with internal CL 45 Trigger a Uproc from the CL 46 Type of days in a calendar 69 Type of resource 41

U Universe use of the management unit 23 Update of a calendar - impact on tasks 69 scheduling rule - impact on scheduled tasks 70 Uproc chronology condition 59 coding 44 completion instructions 62 define the variables 47 definition 44 definition of the current version 82 distribution history 85 distribution to MU 83 execution conditions 51 functional period 48 general characteristics of conditions and completion instructions 52 impact of successors on launch 51

insert a message in the execution report 105 internal or external CL 45 launch formula 61 management of versions in relation to areas 82 maximum number in a session 66 memorisation 50 non simultaneity condition 58 parent, child or peer in a session 63 presentation 9 purpose of incompatibility class 43 purpose of the processing date 78 repetition in a session 63 resource condition 60 restoration in the CL of access paths stored in the tables 32 scheduling 71 sequence condition 57 transfer to an area 82 transmitting parameters in the CL 46 using fatal conditions 56 using MU Type to distribute 24 using the classes 43 write the CL 46 writing procedure 45 User author code 35, 38 presentation 35 profile features 36 submission account 38 transactions of a profile 37 use in non simultaneity conditions 58 use in sequence conditions 57 User account defining 74 use in conditions and completion instructions 55 User profile customisation 38 purpose 37 Username see User

V Variables defining in a task 75 defining in the session 65 definition 47

Index • 121

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

in the Uprocs - characteristics 48 in the Uprocs - objectives 47 in the Uprocs - value 48 restriction on use in a resource 42 updating at launch 94

122 • Index

Version management by area (session) 82 management in relation to areas (Uproc) 82 of CL for Uproc with internal CL 45

W Workload simulation functions 87 limitations 87 objectives 87 step-by-step mode 88

Reference manual

DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS

ORSYP Addresses ORSYP France S.A. Tour Franklin 101 quartier Boïeldieu 92042 Paris la Defense cedex

ORSYP Software Inc. 54 Middlesex Turnpike MA 01803 BURLINGTON USA

Tel : 33 [0]1 47 73 12 12 Fax : 33 [0]1 47 73 12 10

Tel . : 1 [781] 276 4600 Fax : 1 [781] 271 0947

ORSYP Deutschland GmbH Steinhof, 5 D-40699 ERKRATH

ORSYP Espana c/Orense, 85 E-28020 Madrid

Tel . : 49 [0]211 24 50 15 00 Fax.: 49 [0]211 24 50 15 20

Tel: 00 34 91 567 84 26 Fax: 00 34 91 571 42 44

ORSYP Italia Srl Centro Direzionale Villa Fiorita Palazzo D P.zza Maestri del lavoro, 7 20063 - Cernusco s/Naviglio

ORSYP UK Sussex House, 6 The Forbury Reading Berkshire RG1 3EJ

Tel: + 33 02/9273111 Fax: + 33 02/92731122

Tel . : 44 [0]118 9253 277 Fax : 44 [0]118 9253 278

E-mail : [email protected] WEB site : http://www.orsyp.com

Reference manual

Index • 123