Defining and Managing Job Conditions

Logical conditions are dependencies between jobs. Jobs within a job network are linked by user-defined logical conditions. A logical condition can be added, deleted or modified. A logical condition can have either of two statuses that determine how Entire Operations is to continue processing: true (condition exists) or false (condition does not exist).

During execution of networks and submission of jobs, Entire Operations automatically checks the status of logical conditions and triggers system actions accordingly. Alternatively, logical conditions can be set by an API routine (see the relevant section).

All conditions are identified by name and a reference date to allow the Entire Operations Monitor to distinguish between the same event occurring on different dates. Condition names must be unique within a job network. Dates can be specified as relative dates or explicit dates. All relative dates are converted to real dates when the job is put in the active queue.

Apart from a name and reference date, the user can also assign a mailbox to a condition. Entire Operations will automatically notify each user of all pending conditions assigned to any mailboxes associated with his user ID.

Jobs are linked by defining the output condition (End-of-Job checking) of one job as the input condition (prerequisite) of the subsequent job.

This document covers the following topics:

Related Topics:

Use of Input and Output Conditions

There are two ways of using logical conditions:

  • As input conditions;

  • As output conditions.

This section covers the following topics:

Input Conditions

Input conditions are prerequisites for job submission. Entire Operations does not submit a job until all input conditions and other prerequisites are set (fulfilled). Before job submission, all input conditions defined for the job are checked automatically by the Entire Operations Monitor. If you want the checking to be done by a Natural user exit, this routine must also be defined as an input condition.

An input condition can be set by the occurrence of an event detected by Entire Operations or manually by the user when maintaining active job conditions. It can also be set by a reply to a mailbox request.

You can set an input condition to true or false. The job then must wait until the condition is fulfilled before it starts running. This is useful, for example, to avoid that two or more jobs with the same input condition run at the same time. You can also specify whether an input condition is reset after job submission.

If no input condition is defined for a job, Entire Operations assumes a virtual true input condition. This means that this job can be submitted immediately at the (earliest) starting time defined for it, unless the job has other prerequisites such as resources.

It is possible to define a maximum of 40 input conditions per job. If you need more input conditions, you must use intermediate dummy jobs to collect the conditions. See also Job Execution as a Dummy Job.

Input conditions can refer not only to the current run of a job network, but also to given time frames in the past or to previous runs.

You can also use an input condition to turn a job into a dummy job when it occurs. For further information on this topic, see Using a Dummy Job.

Output Conditions

Output conditions can be set or reset during End-of-Job checking of Entire Operations. For each job or job step (operating system job), you can specify any number of possible events. Each event can be associated with up to 20 output conditions. When any of these events occur, Entire Operations automatically sets the associated output conditions and starts those jobs which have these conditions as input conditions (see also Defining and Managing End-of-Job (EOJ) Checking and Actions).

As in the case of input conditions, output conditions are defined by name and reference. Additionally, you can specify whether the output condition is to be set (to true) or reset (set to false) when the associated event occurs.

Example of Job Linkage by Using Conditions

The figure below illustrates a simple example of two jobs linked by logical conditions:

graphics/overview_condition.png

To link the two jobs: an Output Condition of Job 1 is defined as an Input Condition for Job 2.

Listing Input Conditions

Start of instruction set To list input conditions

This section covers the following topics:

Columns: Input Conditions

The following table explains the column headings for the data listed on the Input Conditions page of the Maintenance Job Master window:

Column Description
Condition  User-defined condition name.

See also Restrictions for Condition Names and Global Conditions.

Reference  Reference date used to refer to a certain occurrence of the input condition.

For possible entries, see Possible References for Input Conditions in the section Input Condition References.

Type                                    The values shown in this column refer to the condition defined in the Input Condition window:
true  Condition must exist for the job to be submitted.
false  Condition must not exist for the job to be submitted.
exclusive  Exclusive use of the condition.
destruct.  Condition is deleted after use.
extern +  Condition from another network must exist.
extern -  Condition from another network must not exist.
Exit Condition depends on the result of a user exit.
File +  File must exist.
File -  File must not exist.
User Sw +  User switch must exist (BS2000 only).
User Sw -  User switch must not exist (BS2000 only).
Job Var.  Condition depends on a job variable (BS2000 only).
Symbol  Condition depends on the value of a symbol in a symbol table.
mult.Sfx. Condition depends on multiple suffixes.
Mailbox + Condition must exist. It is prompted in the mailbox and must be set or reset to continue job execution.
Mailbox -  It is prompted in the mailbox and must be set or reset to continue job execution.
Recov.tmp.  Condition is used for recovery (only temporary created by the Entire Operations Monitor for active jobs only).
Sched.Dep.  If the condition is defined to be schedule-dependent, a short summary of the dependency appears in this column.

For more information, see Defining Schedule Dependencies for an Input Condition in the section Schedule Maintenance.

Ex.   x mark in the table  Condition must exist.
no mark in the table Condition must not exist.
Library  Natural library where a defined user exit resides.

Functions: Input Conditions

The following functions are available on the Input Conditions page:

Function Description
Add Add an input condition definition.
Modify Modify the input condition definition.
Delete Delete the input condition definition.
Schedule Dep. Add or modify schedule dependency.

See Defining Schedule Dependencies for an Input Condition in the section Schedule Maintenance.

Where Used Display jobs for which the condition is used as an input or output condition.

See Viewing the Usage of a Prerequisite Resource.

Edit Edit user exit to set input condition.
Open Net. Open the network definition for an external input condition.

See Accessing another Network Defined for an Input Condition.

Diagram View the network diagram for the input condition.

For further information, see Viewing and Maintaining a Job Network Diagram.

Adding and Modifying a Master Input Condition

Start of instruction setTo add or modify an input condition

  1. On the tabbed page Input Conditions, choose Add to create a new input condition.

    Or:
    On the tabbed page Input Conditions select an input condition from the table and choose Modify to change an input condition.

    An Input Condition window similar to the example below opens:

    graphics/add_inputcondition.png

  2. Make your definitions. The fields and options in the window are described in Fields and Selection Options: Input Condition.

  3. Choose OK.

    The new input condition is now allocated to the job master.

Note:
After an input condition has been defined or modified, a loop check is performed for the network. The same conditions apply as described in Checking for a Loop in a Job Network in the section Network Maintenance, with one exception: if a loop is detected in the job flow, no corresponding message appears.

This section covers the following topics:

Fields and Selection Options: Input Condition

The input fields and selection options in the Input Condition window are described in the following table.

The fields and options provided in the Type specific settings section of the window depend on the Reference and Type selected for the condition.

Field Description
Condition    Name assigned to the condition.

The condition name and its reference date uniquely identify an active condition.

See also Restrictions for Condition Names.

Run  Current run number (for active jobs only).
Reference  Reference date to specify which occurrence of this definition the job uses. 

For possible selection options, see Possible References for Input Conditions in the section Input Condition References.

Activate checked  Input condition definition is always activated (for job activations as well).
unchecked Default.

Input condition definition is activated for network activations only.

Type specific settings section:
Must Exist checked  Specifies that the condition must exist (be true) as a prerequisite to job submission.
unchecked Specifies that the condition must not exist (be false) as a prerequisite for job submission. Alternatively, this field also controls the setting of the condition according to the existence or non-existence of a file specified in the File Existence field (file or member in a file).
Exclusive  checked  Specifies that when this condition is in use, no other job can access this condition until it is free (job finished).
unchecked Any job can use the condition at any time. This feature is useful to prevent simultaneous execution of jobs with the same input conditions.

Default.
Delete after usage checked Specifies that the condition is automatically reset after the job is submitted.
unchecked Do not reset condition: later job runs can use this condition according to the Reference date.

Default.

Activate checked  Input condition definition is always activated (for job activations as well).
unchecked Input condition definition is activated for network activations only.

Default.

Type section:
Standard Select this radio button (default) to set the standard condition usage options (must exit, exclusive and/or delete after usage).
User Exit Select this radio button if the condition is to be set by a user exit.

For further information and the fields/options available in the Type specific settings section, see Input Condition with User Exit.

File Existence Select this radio button to define an input condition dependent on the existence or non-existence of a file.

For further information and the fields/options available in the Type specific settings section, see Input Condition: File Existence.

User Switch (BS2000) User switch (BS2000 only).

Select this radio button to define an input condition dependent on the existence or non-existence of a user switch.

For further information and the fields/options available in the Type specific settings section, see Input Condition: BS2000 User Switch.

Job Variable (BS2000) Job variable (BS2000 only).

Select this radio button to define an input condition dependent on a comparison with the contents of a BS2000 job variable.

For further information and the fields/options available in the Type specific settings section, see Input Condition: BS2000 Job Variable.

Multiple Suffixes Select this radio button to define a symbol to be used for the active condition name.

For further information and the fields/options available in the Type specific settings section, see Input Condition: Multiple Suffixes.

Mailbox Select this radio button to define a user prompt to a mailbox.

For further information and the fields/options available in the Type specific settings section, see Input Condition: Mailbox.

Symbol Value Select this radio button to define an input condition dependent on a comparison with the value of a symbol in a symbol table.

For further information and the fields/options available in the Type specific settings section, see Input Condition: Symbol Value.

External Select this radio button to define an input condition dependent on another network.

See also Accessing another Network Defined for an Input Condition.

Restrictions for Condition Names

The name of a condition can contain numbers and letters as required. The maximum name length is 20 bytes.

The following restrictions apply:

  • Umlauts are not allowed.

  • The use of special characters is restricted to the following: 

    -+/§#$_&

  • Names of global conditions begin with a plus sign (+).

  • The activation escape character, the submission escape character and a period (.) symbol delimiter are still accepted if symbol replacement is allowed for the relevant name fields.

  • The following condition names are reserved for special purposes and may not be used for common conditions:

    Reserved Condition Name Explanation
    NET-BEGIN

    NET-END

    NET-END-NOTOK

    NET-END-OK

    		 Used for subnetwork control.

    These reserved conditions are described in detail in the section Link the Main Network.

    P-STOPCYC - jobname If this condition is set in the active symbol table of a job with the special type C, the cyclic execution is stopped.

    For detailed information, see the field Special Type in the section Fields: Job Master Definition.

    jobname-MAX-RETRY The special condition jobname-MAX-RETRY is set by the Entire Operations Monitor when the message EOR5316 (Recovery Retry Maximum:1: exceeded) is issued during a job recovery.

Accessing another Network Defined for an Input Condition

Start of instruction setTo access another network defined for an input condition

Input Condition References

To check an input condition, you must know which reference is meant. References can result in time or run number intervals.

The simplest reference is RUN, which refers to conditions set in the current network run. However, if you define an external input condition (which is not produced by the current network), you should always remember that different networks usually have different run numbers, which implies that RUN makes no sense in this case.

Run numbers are not assigned sequentially in chronological order. For references to previous network runs use LNR.

With the exception of RUN, all references described in this section also apply to global conditions.

Possible References for Input Conditions

The following table describes all references you can select from the drop-down list box next to the Reference field of the Input Condition window.

Reference

Unit of
Relative Value

Description
AAC   Job uses condition only if there is at least one entry in the active database for the owner, the network and the job.
ABS   Job uses condition only if it is absolute. Absolute conditions are independent of run numbers and can exist only once under the same name.
ANY   Job uses any occurrence of the condition, except ABS (absolute), which has a reserved run number.
ANT   Job uses condition only if there is no entry in the active database for this owner, network and job.
DAT Days Job uses the condition as set by the network run on the current date.
Explicit date   A date entered in the format YYYYMMDD.

Job uses condition only if set on the explicit date. The job then uses the condition as set by the network run on this date (does not apply when job can run more than once daily).

DST   Job uses the condition as set during the network run on the date specified as the job start time.
DUM   If this condition is satisfied, the job is started as a temporary dummy job. If this condition is not satisfied, the job is started normally.

If several conditions with the reference DUM are defined for a job, only one condition must be satisfied for the job to be executed as a dummy. The condition can have a special dependency (for example, on a file).

The active condition is also accepted if it has the reference ABS (absolute).

If a job is started as a temporary dummy job on account of a condition, then this is written to the log.

HRC Hours Job uses the condition only if it was set a defined number of hours previous to the check time of the condition.

This reference can only be entered with a relative hour value.

HRC-24 is the default value if this field is left blank and if the condition is set in a different network.

(RUN is the default in the same network.)

LNR Hours

  • If the condition was set by another network:

    Job uses the condition if it was set by the most recent run in the previous nnn hours.

  • If the condition was set by an earlier run of the same network:

    Job uses the condition if it was set by an earlier run in the previous nnn hours.

  • The condition is not set if an error occurred during the most recent or earlier run.

This reference is recommended for constructing chains of networks and must be followed by a relative value (see Relative Values).

LNT Hours This reference is used like LNR.

Additionally, the condition is set to true if the creating job network did not have an active run in the previous nnn hours. Network runs that were already deactivated are indicated in the accounting data.

MON Months Job uses the condition as set by the network run of the current month.
NSD   Job uses the condition as set during the network run on the date specified as the network start time.
PDA Days Job uses the condition only if set on the same production date.

The production date end time can be defined in the Entire Operations default settings: see Defaults for Time Ranges in the Administration documentation.

Note:
This reference does not evaluate schedules or calendars.

PDS   Job uses the condition only if set on the same production date.

The production date end time can be defined in the Entire Operations default settings: see Defaults for Time Ranges in the Administration documentation.

Note:
This reference does not evaluate schedules or calendars.

RCA   A job with multiple active subnetworks uses the same input conditions defined for a predecessor job that runs in the primary subnetwork.

If Multiple suffixes are used as an input condition (see Input Condition: Multiple Suffixes) for the predecessor, the multiple suffixes are appended to the job.

If RCA is specified, the output condition of the corresponding predecessor job must be referenced with RCM: see RCM in the section Field Descriptions: Output Conditions.

RUN Run numbers Job uses the condition as set by the current network run.

This is the default value if this field is left blank and if the condition is set in the same network.

(HRC-24 is the default in a different network.)

WEK Weeks Job uses the condition as set by the network run of the current week.
WCC Days Real date, relative to the current day.
WCW Days Calendar day, relative to the current day, in a linked calendar (workday).
WCS Days Schedule day, relative to the current day, in a linked schedule.

Relative Values

Some references can be followed by a minus (-) or plus (+) sign and a numeric offset. This is called a relative value. For example:

DAT-1  Refers to yesterday.
HRC-2 Refers to the previous 2 hours.
WEK-1 Refers to the previous week.

In this case, additional fields appear next to the Reference field where you can select the required sign (+ or -) and enter a number.

Global Conditions

Logical conditions are either set for a single job network or independently of any networks. Independent conditions are referred to as global conditions.

A global condition is not restricted to a particular owner, network or job but reflects the current value of a condition set for the given environment. It is defined once and can be used in several networks and job environments.

The following applies to a global condition:

  • A global condition has the prefix + (plus sign).

  • A global condition is assigned to the owner SYSDBA and to the network SYSDBA.

  • A global condition gets the reference abs. (absolute). The reference RUN is accepted but is converted to abs. at runtime.

This document covers the following topics:

Related Topic:

Restrictions for Global Conditions

For global conditions, only the following references are allowed:

With the definition of an active condition ABS, ANY, RUN
If used as input condition  HRC, DAT, PDA, WEK, MON, ABS, ANT, DUM, RUN, ANY
If used as output condition  ABS, RUN

Input Condition with User Exit

Input conditions can depend on the result of a user exit (P-CALL-PLACE set to ICO; see Parameters Used for Different Call Places). If a user exit is defined for an input condition, Entire Operations automatically executes the exit when checking the status of input conditions during the prerequisite check. The user exit can perform any database or Entire System Server call to obtain the necessary information. This allows Entire Operations to react to complex or user-specific dependencies.

User exits are Natural subprograms and can be edited with the Entire Operations editor. See also the section User Exits.

When defining a user exit as an input condition, consider the following:

  • The Entire Operations Monitor sets the parameter field P-RC (return code) to 0 (zero) before the user exit is called.

  • You can also specify an input condition user exit for an input condition with the reference DUM (execute the active job as a temporary dummy job). See Return Code Settings for an Input Condition User Exit for the meaning of the return codes used for the input condition reference DUM.

This section covers the following topics:

Defining and Editing a User Exit for an Input Condition

Start of instruction set To define a user exit for an input condition

  1. In the Input Condition window, select User exit from the Type section.

    In the Type specific settings section, enter the name of the user exit and the name of the Natural library in which the user exit resides.

    The input fields available are described in Fields: Input Condition User Exit.

  2. When finished, choose OK to save your entries and close the window.

Start of instruction setTo edit the user exit of an input condition

  1. From the table on the tabbed page Input Conditions, select an input condition of the type Exit and choose Edit.

    An editor window opens containing the source of a Natural subprogram similar to the Example of a User Exit.

    (If no user exit is specified for the selected input condition, an appropriate message occurs instead.)

  2. Modify the user exit as required.

    For detailed information on handling user exits, see the section User Exits.

Fields: Input Condition User Exit

The input fields provided for a user exit in the Type specific settings section of the Input Condition window are described in the following table:

Field Description
Natural Library  Name of the Natural library where the user exit resides.

This library must be different from the Entire Operations system library.

Exit  Name of the user exit which sets the condition.

The user exit coding must start with DEFINE DATA PARAMETER USING NOPXPL-A.

For further information, see Common User Exit Parameter Area NOPXPL-A.

Return Code Settings for an Input Condition User Exit

When defining a user exit as an input condition for a job, you must set the return code as follows:

Input Condition Reference Return Code Meaning
DUM 0 Job executes as dummy due to condition.
99 Job waits for the input condition, for example, until an ICO user exit sets another return code.
other Job executes normally.
other 0 Job executes normally.
other Job waits for the input condition, for example, until an ICO exit sets another return code.

Example of a User Exit

Below is an example of a user exit which sets an input condition: 

* 
Entire Operations


* USER EXIT TO SET AN INPUT CONDITION
*
* THIS ROUTINE CHECKS THE EXISTENCE OF A FILE, DEPENDING ON
* GIVEN PARAMETERS
*
DEFINE DATA PARAMETER USING NOPXPL-A
LOCAL                   /* LOCAL VARIABLES START HERE
1 CATALOG VIEW OF CATALOG        /* An Entire System Server VIEW
  2 NODE
  2 DSNAME
  2 ERROR-CODE
  2 ERROR-TEXT
*
1 #DSNAME         (A54)
END-DEFINE
* ----------------------
RESET P-RC                /* ASSUME GOOD RETURN -> SET CONDITION
COMPRESS P-OWNER '.SYSF.SRCE' INTO #DSNAME LEAVING NO SPACE
CAT. FIND CATALOG WITH NODE = P-EXECUTION-NODE
    AND DSNAME = #DSNAME
  IF CAT.ERROR-CODE NE 0
    MOVE CAT.ERROR-CODE TO P-RC      /* BAD RETURN
    MOVE CAT.ERROR-TEXT TO P-RT
    ESCAPE ROUTINE
  END-IF
END-FIND        /* (CAT.)
END

The user exit must set a return code in P-RC.

If P-RC is not equal to 0, the condition is reset (false) and the user is notified with a message. In the example above, the returned condition code (ERROR-CODE) sets (fulfills) the input condition for which the user exit is defined if the routine finds a file with the string owner.SYSF.SRCE.

Input Condition: Multiple Suffixes

If you define a symbol for multiple suffixes, its contents are separated and the single fields are concatenated to the active condition name. These multiple conditions are used to wait until all parallel executing predecessors are finished.

The active conditions are created during activation of the job network. For example, if the condition name is COND and if the specified symbol contains 001003012, the active conditions COND001, COND003 and COND012 are created.

Start of instruction set To define an input condition dependent on multiple suffixes

  1. In the Input Condition window, select Multiple suffices from the Type section.

  2. In the Type specific settings section, enter a symbol name and select a symbol table/version, if required. See also Fields: Input Condition Multiple Suffixes.

  3. When finished, choose OK to save your entries and close the window.

This section covers the following topics:

Fields: Input Condition Multiple Suffixes

The input fields provided for multiple suffixes in the Type specific settings section of the Input Condition window are described in the following table:

Field Description
Always use Job Symbol Table Specifies whether the symbol table defined for the job is used.

Possible check box settings:
checked The multiple suffix is taken from the symbol table defined for the job (default).

(A symbol table defined for the network to which the job belongs is ignored.)

unchecked The multiple suffix is taken from the symbol table specified for this input condition only.

Note:
In the case of a job or network copy, it is recommended to select this check box. By this you make sure that always the defined symbol table of the job is used, even if it was changed in the job definition.

Symbol Table  Name of the symbol table with the symbol that contains the suffix(es) to be used for the condition when the job network is activated.

You must specify the same symbol table in the predecessor job definition.

Version Version of the symbol table (if defined).
Symbol  Name of the symbol that contains the suffix(es) to be used for the condition when the job network is activated.

You must specify the same symbol in the predecessor job definition.

Always Job Table  Possible check box settings:
checked The multiple suffix is always taken from the job symbol table. A local definition is ignored (default).
unchecked Use the symbol table defined here.

Note:
In the case of a job or network copy, it is recommended to select this check box. By this you make sure that always the defined symbol table of the job is used, even if it was changed in the job definition.

Input Condition: File Existence

An input condition value can be dependent on the existence or non-existence of a file or of one of its members. The Monitor checks for the file or member on the job's execution node until the condition is satisfied.

Start of instruction set To define an input condition that requires a file

  1. In the Input Condition window, select File existence from the Type section.

  2. In the Type specific settings, enter a file and a member name. The input fields and options are described in Fields: Input Condition File Existence.

  3. When finished, choose OK to save your entries and close the window.

This section covers the following topics:

Fields: Input Condition File Existence

The input fields provided for a file existence check in the Type specific settings section of the Input Condition window are described in the following table:

Field Description
File  

Name of the file that must or must not exist. If the file is not cataloged, specify the volume serial number in the format file/volume.

Note:
When entering a file name, remember to observe the rules for upper and lower case which are specific to some operating systems.

See also Rules for File Names and File Checking.

Member (Optional field)

If the input condition is dependent on the existence or non-existence of a member in the file specified in the File field, enter the member name. Using a Wildcard in the Member Name: A wildcard (*) can be used at the string end. The condition is set (or not set) if at least one member is found.

Note:
Only specify a member where necessary and possible. If this field is left blank, the existence of the whole file is checked.

See also Rules for File Names and File Checking.

Must exist  Possible check box settings:
checked The file (or member) must exist as a prerequisite to job submission.
unchecked The file (or member) must not exist as a prerequisite.

Rules for File Names and File Checking

The following rules apply when specifying a file as an input condition check:

BS2000 Files

The condition is satisfied only if the file is closed. For opened BS2000 files, the condition is not satisfied.

Migrated (archived) Files

Migrated (archived) files are recognized like files that are actively used. If a member is included in the file existence check, the active job is set to a permanent error, with the error text Prerequisite File Check - Library containing member is archived.

Entire System Server Node used for File Check

The node used for the file check is always the execution node of the job. The file is checked with the access rights of the Submit User ID (on UNIX and Windows: submit and submit group).

If you must check a file on a different node, use a predecessor dummy job with a different execution node and/or Submit User ID for this purpose.

Variable File Name: Using Escape Characters

The fields File and/or Member can contain symbols preceded by an activation escape character.

If the activation escape character is used, symbol replacement is performed during the first existence check.

Symbol replacement can be used, for example, for:

  • file generation groups;

  • changing input files;

After successful symbol replacement, these fields will contain the replaced value in the active job. This reduces the effort with symbol replacements.

The symbols are taken from the active symbol table assigned to the job. The symbol replacement in the file name is performed only once and the result is written back to the active input condition definition for further check. A missing symbol causes a permanent error.

It is also possible to use the submission escape character. In the case of an unsatisfied condition, the symbol replacement in the file name is performed before each file check. The result is not written back. This allows more flexible use of symbols, but may cause more system overhead.

File in Use

The case file in use is handled as a temporary error. The file check is repeated as long as the file is in use. The waiting job is not sent to passive wait.

z/OS: HSM Migrated Libraries

The following applies only if the operating system of an Entire System Server node is z/OS, and if the Entire System Server version is greater than or equal to Version 3.2.1. The Entire Operations Monitor performs the initialization of a file recall.

The file member check is repeated in intervals of two minutes, until the file is reloaded. A reload is not initiated if the file check is on file level only.

Input Condition: Mailbox

Mailboxes are defined to the system and assigned to user IDs by using the appropriate context function of the Mailbox Definition metanode. For more information on defining mailboxes, see Mailbox Definition in the Administration documentation.

For more information on how mailboxes can be used, see Working with Mailboxes.

This section covers the following topics:

Using Mailboxes with Input Conditions

Each logical condition can be assigned to a mailbox.

  • If the condition is the only one pending (unfulfilled) and is therefore delaying the start of the subsequent job, a message is automatically sent to the mailbox.

  • If an input condition is dependent on manual action(s), a message is sent to a mailbox that asks a user to confirm completion of the action(s).

Each user linked to this mailbox receives this message.

A user can be associated with up to ten mailboxes.

Defining an Input Condition of the Type Mailbox

Start of instruction set To send a message to a mailbox for an input condition that is not satisfied during network execution

  1. In the Input Condition window, select Mailbox from the Type section.

  2. In the Mailbox field of the Type specific settings section, enter the name of the mailbox to which you want to send a message.

    Or:
    Select a name from the drop-down list box next to the Mailbox field.

  3. When finished, choose OK to save your entry and close the window.

Input Condition: Symbol Value

An input condition can be dependent on a comparison with the contents of a symbol (symbol value) or the substring of a symbol value in a symbol table. The Monitor checks the value of the symbol on the job's execution node until the condition is satisfied.

You can specify the instance of a symbol table to be used for the symbol check: the active symbol table or the master symbol table.

This section covers the following topics:

Defining an Input Condition of the Type Symbol Value

Start of instruction set To define an input condition that depends on a symbol value

  1. In the Input Condition window, select Symbol value from the Type section.

    In the Type specific settings section you can enter the symbol to be compared and further parameters to specify the symbol.

    The input fields available are described in Fields: Input Condition Symbol Value.

  2. When finished, choose OK to save your definitions and close the window.

Fields: Input Condition Symbol Value

The input fields of the Type specific settings for the type Symbol value in the Input Condition window are described in the following table:

Field Description
Symbol Valid symbol name.

Predefined symbols can also be used.

The value of this symbol, or a part of it, is to be compared with the given value.

Symbol table  Valid symbol table name.

If you leave this field blank, the symbol search procedure starts with the active symbol table of the job. Otherwise, the active symbol table with this name is searched instead of the symbol table of the job. If the symbol is not found there or in the caller's symbol tables, the owner's symbol master table with this name is searched too.

See also Symbol Table Types and Symbol Search Order in the section Symbol Table and Symbol Maintenance.

Version Symbol table version.

Possible version names:
(current) Current version at determination date.
(nv) Same version as network version.
(svn) Symbol table version of network.
(svj) Symbol table version of job.
(unnamed) Unnamed version (without name).
Symbol instance Instance of the symbol table where to perform the symbol value check.

Valid selection options:
Check symbol in the active symbol table Perform symbol check in the active symbol table (default).

This setting has no effect on the symbol tables SYSDBA/A and owner/A. They only exist as master symbol tables, and are therefore always checked as master symbol tables.

(See also Symbol Table Types and Symbol Search Order in the section Symbol Table and Symbol Maintenance.)

Check symbol in the master symbol table Perform symbol check in the master symbol table.
Position  Position of the substring of the symbol value to be checked.

(Checked only if Format is set to A.)

Possible values: 1 to 120 characters.
Length  Length of the substring of the symbol value to be checked.

(Checked only if Format is set to A.)

Possible values: 1 to 120 characters.
Format  Format in which the substring of the symbol value is to be checked against the comparison string.

Possible selection options:
A  Alphanumeric.
D  Date in the format YYYYMMDD.

See also Date and Time Formats.

N  Numeric (zoned).
Symbol is Comparison operator.

Specify a logical operator for the comparison of the defined symbol against the comparison string (see below).

Possible selection options:
=  or  EQ   Code is equal to specified value.
>=  or  GE   Code is greater than or equal to specified value.
> or  GT   Code is greater than specified value.
<=  or  LE   Code is lower than or equal to specified value.
< or  LT   Code is lower than specified value.
<>  or  NE   Code is different from specified value.
compared to

comparison string

  		Comparison string.

In the input lines below compared to, enter the string or field to be compared with the substring of the symbol value.

The strings are compared in the defined Format.

Symbol replacement is possible in this field.

  • If an activation escape character is used, the replacement is performed once during activation. A symbol replacement error is treated as a permanent error in this case.

  • If a submission escape character is used, the replacement is performed directly before each prerequisite check. This causes more system overhead. A symbol replacement error is treated as temporary error in this case.

Nested Symbol Evaluation

The symbol value may contain other (nested) symbols, prefixed by both activation escape character and submission escape character.

Symbols prefixed by the activation escape character are evaluated only once, at job activation.

Symbols prefixed by the submission escape character are evaluated at each prerequisite check of the active job.

Input Condition: BS2000 User Switch

An input condition value can be dependent on the existence or non-existence of a BS2000 user switch. The Monitor checks for the user switch on the job's execution node until the condition is satisfied.

This section covers the following topics:

Defining an Input Condition of the Type User Switch

Start of instruction set To define an input condition that depends on a user switch

  1. In the Input Condition window, select User switch (BS2000) from the Type section.

    In the Type specific settings section, enter a user switch and BS2000 user ID.

    The input fields available are described in Fields: Input Condition User Switch.

  2. When finished, choose OK to save your entries and close the window.

Fields: Input Condition User Switch

The input fields of the Type specific settings for the type User switch (BS2000) in the Input Condition window are described in the following table:

Field Description
User Switch  Number of a user switch.
BS2000 User ID BS2000 user ID to which the specified user switch belongs.
Must exist  Possible check box settings:
checked The user switch must exist as a prerequisite to job submission.
unchecked The user switch must not exist as a prerequisite.

Input Condition: BS2000 Job Variable

An input condition can be dependent on a comparison with the contents of a BS2000 job variable. The Monitor checks for the job variable on the job's execution node until the condition is satisfied.

This section covers the following topics:

Defining an Input Condition of the Type Job Variable

Start of instruction set To define an input condition that depends on a job variable

  1. In the Input Condition window, select Job variable (BS2000) from the Type section.

    In the Type specific settings section, enter a job variable and further parameters to specify the input condition.

    The input fields are described in Fields: Input Condition Job Variable (BS2000).

  2. When finished, choose OK to save your entries and close the window.

Fields: Input Condition Job Variable (BS2000)

The input fields provided for a job variable in the Type specific settings section of the Input Condition window are described in the following table:

Field Description
Job variable

Enter the name of a valid BS2000 job variable.

  • If the specified job variable does not exist, a content comparison is done by Entire Operations, when the Monitor detects that the job variable has been created.

  • If a job variable does not exist, a job cannot be declared "dummy due to condition". Instead, the Entire Operations Monitor waits until the job variable exists and then performs the check.

  • If the job variable is specified without an explicit user ID, the job default BS2000 user ID is used as prefix.

  • Symbol replacement: see Using Symbols.

Position  Enter the position of the substring of the job variable value to be checked. Possible values: 1 to 253.
Length Enter the length of the substring of the job variable value to be checked. Possible values: 1 to 253.
Format Specify the format in which the substring of the job variable value is to be checked against the comparison string.

Possible selection options:
A Alphanumeric.
N Numeric (zoned).
Variable is   This is the comparison operator.

Specify a logical operator for the comparison of the defined job variable substring against the comparison string (see below).

Possible selection options:
=  or  EQ   Code is equal to specified value.
>= or  GE   Code is greater than or equal to specified value.
>  or  GT   Code is greater than specified value.
<=  or  LE   Code is lower than or equal to specified value.
<  or  LT   Code is lower than specified value.
<> or  NE   Code is different from specified value.
compared to

comparison string

In the input lines below compared to, enter the string or field to be compared with the substring of the job variable value.

The strings are compared in the defined Format. The content of this field is compared with the substring of the job variable value, or it is inserted into the substring of the job variable value.

The content is treated as blank if '' (2 single quotes, no space) or ' ' (single quote, space, single quote) is defined. The comparison is made in the defined format.

Symbol replacement: see Using Symbols.

Password (Optional field)

If the job variable is read password-protected, specify the password here.

Using Symbols

Resolving symbols in the job variable name produces the same behavior as resolving symbols in the job variable value:

  • If the activation escape character is used:

    • The symbol is replaced once during the job activation.

    • The active job variable name is the resolved string.

  • If the submission escape character is used:

    • The symbol is resolved during each performed prerequisite check.

    • This allows symbol setting shortly before the usage.

    Note:
    The submission escape character option causes more system overhead.

Listing Jobs Linked to an Input Condition

You can list jobs that also use a selected input condition as an input condition, or that use this input condition as an output condition (see also Defining Output Condition Actions).

Start of instruction set To list jobs linked to a condition

  1. From the table on the tabbed page Input Conditions, select an input condition and choose Where Used.

    A Where used Condition window similar to the example below opens:

    graphics/whereused_inputcondition.png

    The window displays the name of the selected condition and two lists of jobs:

    • one lists the jobs which use the condition as input condition;

    • the other lists the jobs which use the condition as output condition.

    The jobs are listed according to owner, network and job name.

Note:
For an active input condition, a similar window opens: see the Active Usage Condition window described in the section Active Job Networks.

Deleting an Input Condition Definition

Start of instruction setTo delete an input condition

  1. On the tabbed page Input Conditions, select an input condition in the table and choose Delete.

  2. Select an input condition in the table.

  3. Choose the Delete button.

    The input condition is now deleted for this job master.