Defining and Managing Job Input Conditions

Jobs within a job network are linked by user-defined logical conditions. Logical conditions (see also the Concepts and Facilities documentation) are variables within Entire Operations and describe job dependencies.

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

In order to link two jobs, an input condition (prerequisite) defined for one job must also be defined as output (End-of-Job) condition for the preceding job.

Note:
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.

This document covers the following topics:

Related Topics:

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                                    User-defined condition type expressed as any of the following:
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 will be destroyed after use.
dummy  If the condition is satisfied, the job is started as a temporary dummy job.
extern +  Condition from another network must exist.
extern -  Condition from another network must not exist.
mult.Sfx. Condition depends on multiple suffixes.
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.
Mailbox + Condition must exist; prompted in mailbox.
Mailbox -  Condition must not exist; prompted in mailbox.
Recov.tmp.  Condition is used for recovery (temporary - created by 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 in the Input Condition window are described in the following table.

The fields 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 will always be activated (for job activations as well).
unchecked Default.

Input condition definition will be 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.
Destroy 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 will always be activated (for job activations as well).
unchecked Input condition definition will be 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 destroy 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: 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: User Switch - BS2000.

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: Job Variable - BS2000.

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 submit 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 will be 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 will be 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 will also be 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 will be 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 occurrence in the time frame to be observed.

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 Day in real time, relative to the current day.
WCW Days Day in calendar (work day), relative to the current day.
WCS Days Day in schedule, relative to the current day.

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: User Exit

Input conditions can depend on the result of a user exit (P-CALL-PLACE set to ICO; see the section User Exits). 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 (dummy job).

    In this case, the job executes as dummy due to condition if the exits returns 0 for P-RC.

    The job executes normally if the exit returns a non-zero value for P-RC.

This section covers the following topics:

Defining and Editing an Input Condition of the Type User Exit

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

  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.

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 Job Table Specifies whether the symbol table defined for the job is used.

Possible check box settings:

checked The multiple suffix is always taken from the job symbol table. A local definition will be 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 will be 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 will be 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 will be 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 Check.

Member

(optional) 

 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.

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

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 standard existing files. If a member is included in the file existence check, the active job will be 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 being 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 a 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 will be 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 will not be 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 will be repeated in intervals of two minutes, until the file is reloaded. A reload will not be 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 sees 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 in a symbol table. The Monitor checks the value of the symbol on the job's execution node until the condition is satisfied.

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

Is a valid symbol name.

Predefined symbols may be used too here.

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

Symbol table  Enter the name of a valid symbol table.

If you leave this field blank, symbol search will start with the active symbol table of the job. Otherwise, the active symbol table with this name will be searched instead of the symbol table of the job. If the symbol is not found there or in the calling symbol tables, the owner's symbol master table with this name will be 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).
Position  Enter the position of symbol substring to be checked.

Possible values: 1 through 80. (Checked only if Format is set to A.)

Length  Enter length of symbol substring to be checked.

Possible values: 1 through 80. (Checked only if Format is set to A.)

Format  Specify the format in which the symbol substring 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 This is the 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 symbol (substring).

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 will be treated as 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 will be 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 submit escape character.

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

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

Input Condition: User Switch - BS2000

An input condition value can be dependent on the existence or non-existence of a 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: Job Variable - BS2000

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 will be 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 position of job variable substring to be checked. Possible values: 1 through 253.
Length Enter the length of job variable substring to be checked. Possible values: 1 through 253.
Format Specify the format in which the job variable substring 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 job variable substring.

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

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)

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.

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.