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. A quick way to link two jobs is to use the connect function, in which Entire Operations provides a default condition as an output condition for one job and as input condition for another (see Connecting Jobs from the Same or Different Networks).

This document covers the following topics:

• Use of Input and Output Conditions

• Listing Input Conditions

• Adding and Modifying a Master Input Condition

• Input Condition References

• Global Conditions

• Input Condition with User Exit

• Input Condition: Multiple Suffixes

• Input Condition: File Existence

• Input Condition: Mailbox

• Input Condition: Symbol Value

• Input Condition: BS2000 User Switch

• Input Condition: BS2000 Job Variable

• Listing Jobs Linked to an Input Condition

• Deleting an Input Condition Definition

• Displaying Currently Active Conditions

Related Topics:

• Defining Schedule Dependencies for an Input Condition in the section Schedule Maintenance

• Maintaining Active Job Conditions in the section Active Job Networks

• Logical Conditions in the Concepts and Facilities documentation

---

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

• Output Conditions

• Example of Job Linkage by Using Conditions

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:

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

Listing Input Conditions

To list input conditions

1. Select option 1 on the Main Menu to display the Network Maintenance screen.

2. Issue the line command L for the network containing the job to be linked.

3. Type I in the line command input field of the job with which you wish to associate the input condition.

4. Press ENTER.

   An Input Conditions Maintenance screen similar to the example below appears:

   29.03.16 ***** Entire Operations ***** 15:44:24 Input Conditions Maintenance Owner EXAMPLE Network B60-FLOW Version Job JOB-03 ------------------------------------------------------------------------------- C Condition Reference Type Sched.Dep. U ex. Library Exit _ E60-JOB2-O1 RUN true Y _ EX-2 RUN true Y _ EX-3 RUN true Y _ E05-UR01-NOK RUN true Y ******************************* Bottom of Data ******************************* D Delete E Edit Exit M Modify S Sched.Dep. W Where used Command => ____________________________________________________________ Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12--- Help Add End ACond Save Up Down Menu

   All input conditions defined for the job are listed on the screen.

   The columns and commands available on the screen are explained in Columns: Input Conditions Maintenance and Commands: Input Conditions Maintenance.

This section covers the following topics:

• Columns: Input Conditions Maintenance

• Commands: Input Conditions Maintenance

Columns: Input Conditions Maintenance

The following table explains the column headings for the data listed on the Input Conditions Maintenance screen:

Column	Description
C	One-character line command input field. The line commands available are described in Line Commands: Input Conditions.
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 Master 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.
U	Usage. For active input conditions with schedule dependency only. One of the following values appears:
	Y	Condition is used for the current activation.
	N	Condition is not used for current activation.
	Schedule is always dynamically tested for this display.
ex.	Y	Condition must exist.
	N	Condition must not exist.
Library	Natural library where a defined user exit resides.
Exit	Natural user exit to set the condition (see the section Input Condition with User Exit).

Commands: Input Conditions Maintenance

This section describes the line commands and special PF keys available on the Input Conditions Maintenance screen.

Line Commands: Input Conditions Maintenance

Next to each input condition listed on the screen, you can enter one of the following line commands to perform the functions described in the table below:

Line Command	Description
D	Delete an input condition definition.
E	Edit user exit to set input condition.
M	Modify input condition definition.
S	Add/modify schedule dependency. See Defining Schedule Dependencies for an Input Condition in the section Schedule Maintenance.
W	Display jobs for which the condition is used as input or output condition.

Special PF Keys: Input Conditions Maintenance

You can perform the following function using this special PF key:

PF Key	Name	Function
PF4	ACond	Display list of currently active conditions.

Adding and Modifying a Master Input Condition

To add an input condition definition for a job

1. Choose PF2 (Add) on the Input Conditions Maintenance screen.

   A Master Input Condition window similar to the example below opens:

   +-------------------------------------------------------------+ | | | Master Input Condition Modification | | | | Owner ==> EXAMPLE___ | | Network ==> B60-FLOW__ Version ==> | | Condition ==> E60-JOB2-O1_________ | | Reference ==> RUN_____ | | | | Usage (mark with Y or N) | | Must Exist: Y Exclusive: _ Delete after usage: _ | | Activation Mode ==> N | | | | Depending on | | Exit ==> _ Multiple Suffixes ==> _ | | File Existence ==> _ Mailbox ==> _ | | User Sw.(BS2000) ==> _ Symbol Value ==> _ | | Job Var.(BS2000) ==> _ | | | | -PF1---PF2---PF3-------PF5------------PF9---PF10---PF12-- | | Help Add End Save Xref ScDep Menu | +-------------------------------------------------------------+

2. Enter the required values. The input fields are explained in Fields: Input Condition.

   When you are finished, choose PF5 (Save) to save your entries.

3. If you want to add another input condition, choose PF2.

   The Master Input Condition Addition window is cleared and you can enter a new input condition definition.

4. Choose PF3 (End) to return to the Input Conditions Maintenance screen.

   All new input conditions are listed on the screen.

5. If you defined a user exit to set the condition, you can edit the routine by using the line command E (Edit Exit) for the condition on the Input Conditions Maintenance screen.

   For more information, see Defining and Editing an Input Condition of the Type User Exit.

To modify an input condition definition for a job

1. On the Input Conditions Maintenance screen, type the line command M next to the input condition you want to modify.

   A Master Input Condition window similar to the previous example opens.

2. Change the entries as required. The input fields are explained in Fields: Input Condition.

   When you are finished, choose PF5 (Save) to save your changes.

3. Choose PF3 (End) to return to the Input Conditions Maintenance screen.

This section covers the following topics:

• Fields: Input Condition

• Special PF Keys: Input Condition

Fields: Input Condition

The input fields in the Master Input Condition window are described in the following table.

Field	Description
Owner	The job owner is assumed as the default. You can select a different owner. The field may contain symbols.
Network	The job network is assumed as the default. You can select a different network. The field may contain symbols.
Version	Version of the network.
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 input values, see Possible References for Input Conditions in the section Input Condition References.
Activation Mode	A	Input condition definition is always activated (for job activations as well).
	N	Default. Input condition definition is activated for network activations only.
Usage section:
Must Exist	Y	Specifies that the condition must exist (be true) as a prerequisite to job submission.
	N	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	Y	Specifies that when this condition is in use, no other job can access this condition until it is free (job finished).
	N or blank	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	Y	Specifies that the condition is automatically reset after the job is submitted.
	N or blank	Do not reset condition: later job runs can use this condition according to the Reference date. Default.
Activation Mode	A	Input condition definition is always activated (for job activations as well).
	N	Input condition definition is activated for network activations only. Default.
Depending on section:
Exit	Enter any character and press ENTER if the condition is to be set by a user exit. A window opens in which you can enter the name of the user exit routine and the name of the Natural library in which the user exit resides. For further information and the fields/options available in the window, see Input Condition with User Exit.
File Existence	Enter any character and press ENTER to define an input condition dependent on the existence or non-existence of a file. A window opens in which you can enter the name of the file. For further information and the fields/options available in the window, see Input Condition: File Existence.
User Sw. (BS2000)	User switch (BS2000 only). Enter any character and press ENTER to define an input condition dependent on the existence or non-existence of a user switch. A window opens in which you can enter the name of the user switch. For further information and the fields/options available in the window, see Input Condition: BS2000 User Switch.
Job Var. (BS2000)	Job variable (BS2000 only). Enter any character and press ENTER 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 window, see Input Condition: BS2000 Job Variable.
Multiple Suffixes	Enter any character and press ENTER to define a symbol to be used for the active condition name. A window opens in which you can enter a symbol name. For further information and the fields/options available in the window, see Input Condition: Multiple Suffixes.
Mailbox	Enter any character and press ENTER to define a user prompt to a mailbox. A window opens in which you can enter the name of the mailbox. For further information and the fields/options available in the window, see Input Condition: Mailbox.
Symbol Value	Enter any character and press ENTER to define an input condition dependent on a comparison with the value of a symbol in a symbol table. A window opens in which you can enter the symbol name and other parameters. For further information and the fields/options available in the window, see Input Condition: Symbol Value.

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

Special PF Keys: Input Condition

You can perform the following functions from the Master Input Condition window using these PF keys:

PF Key	Name	Function
PF9	Xref	Display the jobs for which the condition is defined as an input or output condition. The same window opens as if you had issued the W (Where used) line command for the condition. For further information, see Displaying Jobs Linked to a Condition.
PF10	ScDep	Define schedule dependency for an input condition. The same window opens as if you had issued the S (Sched.Dep.) line command for the condition. For further information, see Defining Schedule Dependencies for an Input Condition in the section Schedule Maintenance.

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

• Relative Values

Possible References for Input Conditions

The following table describes all references you can enter in the Reference field of the Master 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.
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 Default Setting (2) 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 Default Setting (2) 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.

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:

• Restrictions for Global Conditions

Related Topic:

• Maintaining Active Job Conditions in the section Active Job Networks.

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

• Fields: Input Condition User Exit

• Special PF Keys: Input Condition User Exit

• Return Code Settings for an Input Condition User Exit

• Example of a User Exit

Defining and Editing a User Exit for an Input Condition

To define a user exit for an input condition

1. In the Master Input Condition window, enter any character in the Exit field under the Depending on heading.

2. Press ENTER.

   An Input Condition Exit window similar to the example below opens:

   16-09-20 ***** Entire Operations ***** 15:42:21 +-------------------------------------------------------------+ Owner E ! ! ! Master Input Condition Addition ! -------- ! ! ------ C Condi ! Owner ==> EXAMPLE___ ! it _ E60-J ! Network ==> B60-FLOW__ Version ==> ! ! Condition ==> COND-1______________ ! ! Reference ==> ________ ! ! ! ! Usage ( +------------------------------------------+ ! ! Must ! ! : _ ! ! Activat ! Input Condition Exit ! ! ! ! ! ! ! Dependi ! Condition ==> COND-1 ! ! ! Exit ! Run ==> ! > _ ! ******* ! File ! ! > _ ! ****** D Delet ! User ! Value will be determined by ! > _ ! ! Job V ! Natural Library ==> ________ ! ! ! ! Exit ==> ________ ! ! Command ! -PF1---P ! ! 2-- ! ! Help A ! PF1 Help PF3 End PF5 Save PF9 Delete ! u ! +--------- +------------------------------------------+ ------+ Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12--- Help Add End ACond Save Up Down Menu

   In this window you can 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.

3. When finished, choose PF3 (End) to save data and return to the Master Input Condition window.

To edit the user exit of an input condition

1. On the Input Conditions Maintenance screen, type E (Edit Exit) in the line command input field next to an input condition of the type Exit.

2. Press ENTER.

   The first page of the Natural subprogram appears in the editor screen. See also Example of a User Exit.

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

3. Modify the user exit as required by using editor commands and PF keys. For a full description of the editor, see Software AG Editor in the Natural documentation.

   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 Input Condition Exit 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.

Special PF Keys: Input Condition User Exit

You can perform the following function from the Input Condition Exit window using this PF key:

PF Key	Name	Function
PF9	Delete	Delete input condition dependent on user exit.

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.

To define an input condition dependent on multiple suffixes

1. In the Master Input Condition window, enter any character in the Multiple Suffixes field under the Depending on heading.

2. Press ENTER.

   An Input Condition: Multiple Suffixes window similar to the following opens:

   +--------------------------------------------------------------+ | | | Input Condition: Multiple Suffixes | | | | Condition ==> NEWCOND | | Run ==> | | | | Suffixes will be taken from Always use | | Symbol Table ==> ADMIN_____ Job Symbol Table ==> N | | SymTab Version ==> __________ | | Symbol ==> MULT____________________________________ | | | | PF1 Help PF3 End PF5 Save PF7 Symbols PF9 Delete | +--------------------------------------------------------------+

   Enter a symbol name and a symbol table/version, if required. See also Fields: Input Condition Multiple Suffixes.

3. When finished, choose PF3 (End) to save data and return to the Master Input Condition window.

This section covers the following topics:

• Fields: Input Condition Multiple Suffixes

• Special PF Keys: Input Condition Multiple Suffixes

Fields: Input Condition Multiple Suffixes

The input fields provided for multiple suffixes in the Input Condition: Multiple Suffixes 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 values:
	Y	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.)
	N	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 set this field to Y. 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.
SymTab 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 values:
	Y	The multiple suffix is always taken from the job symbol table. A local definition is ignored (default).
	N	Use the symbol table defined here.
	Note: In the case of a job or network copy, it is recommended to set this field to Y. 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.

Special PF Keys: Input Condition Multiple Suffixes

You can perform the following functions from the Input Condition: Multiple Suffixes window using these PF keys:

PF Key	Name	Function
PF7	Symbols	List symbols in symbol table.
PF9	Delete	Delete input condition dependent on multiple suffixes.

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.

To define an input condition that requires a file

1. In the Master Input Condition window, enter any character in the File Existence field under the Depending on heading.

2. Press ENTER.

   An Input Condition depending on File window similar to the example below opens:

   16-09-20 ***** Entire Operations ***** 15:42:21 +-------------------------------------------------------------+ Owner E ! ! ! Master Input Condition Addition ! -------- ! ! ------ C Condi ! Owner ==> EXAMPLE___ ! it _ E60-J ! Network ==> B60-FLOW__ Version ==> ! ! Condition ==> COND-1______________ ! ! Reference ==> RUN_____ ! +----------------------------------------------------------------------+ ! ! ! Input Condition depending on File ! ! ! ! Condition ==> COND-1 ! ! Run ==> ! ! ! ** ! Condition will be set to true, if on node 31 ! ** D ! File ==> ______________________________________________________ ! ! Member ==> __________ ! ! exists ==> Y (Y/N) ! Co ! ! ! PF1 Help PF3 End PF5 Save PF9 Delete ! +----------------------------------------------------------------------+ Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12--- Help Add End ACond Save Up Down Menu

3. Enter a file and a member name. The input fields are described in Fields: Input Condition File Existence.

   When finished, choose PF3 (End) to save data and return to the Master Input Condition window.

This section covers the following topics:

• Fields: Input Condition File Existence

• Rules for File Names and File Checking

• Special PF Keys

Fields: Input Condition File Existence

The input fields provided for a file existence check in the Input Condition depending on File window are described in the following table:

Field	Description
Condition will be set to true, if on node	This is the operating system server on which the file's existence is to be checked. The node used for the file check is always the job's execution node . Tip: If you must check a file on a different node, first create an additional dummy job, whose execution node is the same as the node with which the file is to be checked. This dummy job must be a predecessor of the main job.
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. Using a Wildcard in the File Name: A wildcard (*) can be used in all operating systems. For mainframe files, the wildcard may be set at the string end only. The condition is set (or not set) if at least one file is found. 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.
exists	Possible values:
	Y	The file (or member) must exist as a prerequisite to job submission.
	N	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.

Special PF Keys

You can perform the following function from the Input Condition depending on File window using this PF key:

PF Key	Name	Function
PF9	Delete	Delete input condition depending on file.

Input Condition: Mailbox

Mailboxes are defined to the system and assigned to user IDs by using the Mailbox Definition function of the System Administrator Services. 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

• Defining an Input Condition of the Type Mailbox

• Special PF Keys: Input Condition Mailbox

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 prompts a user to confirm completion of the action(s).

Each user linked to this mailbox sees this prompt whenever the Main Menu or the Active Jobs screen is invoked. A user can confirm the prompt by setting or resetting the requested condition. The condition is set only if a user confirms the condition setting in the mailbox list.

A user can be associated with up to ten mailboxes.

Defining an Input Condition of the Type Mailbox

To send a user prompt to a mailbox for an input condition that is not satisfied during network execution

1. In the Master Input Condition window, enter any character in the Mailbox field under the Depending on heading.

2. Press ENTER.

   An Input Condition: User Interaction window similar to the example below opens:

   16-09-20 ***** Entire Operations ***** 15:42:21 +-------------------------------------------------------------+ Owner E ! ! ! Master Input Condition Addition ! -------- ! ! ------ C Condi ! Owner ==> EXAMPLE___ ! it _ E60-J ! Network ==> B60-FLOW__ Version ==> ! ! Conditi +----------------------------------------+ ! ! Referen ! ! ! +--- ! ! Input Condition: User Interaction ! ! --+ ! ! Usage ( ! ! ! ! ! ! Must ! Condition ==> COND-1 ! ge: _ ! ! ! ! Activat ! Run ==> ! ! ! ! C ! ! ! ! ! ! ! Dependi ! If the condition is not satisfied ! ! ! ! ! Exit ! during the network execution, it ! ==> _ ! ! ** ! C ! File ! is to be prompted at a mailbox. ! ==> x ! ! ** D ! ! User ! ! ==> _ ! ! ! ! Job V ! ! ! ! ! ! ! Mailbox ==> __________ ! ! ! Co ! ! -PF1---P ! ! F12-- ! ! ! P ! Help A ! PF1 Help PF3 End PF5 Save PF9 Delete ! enu ! ! +--- +--------- +----------------------------------------+ --------+ --+ Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12--- Help Add End ACond Save Up Down Menu

3. In the Mailbox field, enter the name of the mailbox to which the prompt is to be sent and press ENTER.

   Or:
   Enter an asterisk (*) to select a name from a list of available mailboxes.

   A Mailbox Selection window opens with a list of mailboxes defined to Entire Operations.

   Type any character in the input field next to the required mailbox and press ENTER.

   The selected mailbox name appears in the Mailbox field.

4. Choose PF5 (Save) to save your entry.

5. Choose PF3 (End) to return to the Master Input Condition window.

Special PF Keys: Input Condition Mailbox

You can perform the following function from the Input Condition: User Interaction window using this PF key:

PF Key	Name	Function
PF9	Delete	Delete input condition depending on mailbox.

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

• Fields: Input Condition Symbol Value

• Nested Symbol Evaluation

• Special PF Keys: Input Condition Symbol Value

Defining an Input Condition of the Type Symbol Value

To define an input condition that depends on a symbol value

1. In the Master Input Condition window, enter any character in the Symbol Value field under the Depending on heading.

2. Press ENTER.

   An Input Condition depending on Symbol Value window similar to the example below opens:

   +----------------------------------------------------------------+ | | | Input Condition depending on Symbol Value | | | | Condition ==> E60-JOB2-O1 | | | | Condition will be set to true if: | | Symbol ________________________________________ | | in Symbol Table __________ Version __________ Instance A | | at Position ___ in Length ___ with Format _ | | is __ | | ________________________________________ | | ________________________________________ | | ________________________________________ | | | | PF1 Help PF3 End PF5 Save PF9 Delete | +----------------------------------------------------------------+

   In this window you can enter the symbol to be compared and further parameters to specify the symbol.

3. When finished, choose PF3 (End) to save data and return to the Master Input Condition window.

Fields: Input Condition Symbol Value

The input fields of the Input Condition depending on Symbol Value 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.
in 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. By using a wildcard, you can select a 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).
Instance	Instance of the symbol table where to perform the symbol value check. Valid values:
	A	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.)
	M	Perform symbol check in the master symbol table.
at 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. See also Note for Long Symbol Values.
in 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. See also Note for Long Symbol Values.
with Format	Format in which the substring of the symbol value is to be checked against the comparison string. Possible values:
	A	Alphanumeric.
	D	Date in the format YYYYMMDD. See also Date and Time Formats.
	N	Numeric (zoned).
is	Comparison operator. Specify a logical operator for the comparison of the defined symbol against the comparison string (see below). Possible values:
	=  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.
comparison string	Comparison string. In the input lines below is, 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.

Special PF Keys: Input Condition Symbol Value

You can perform the following function from the Input Condition depending on Symbol Value window using this PF key:

PF Key	Name	Function
PF9	Delete	Delete input condition dependent on symbol value.

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

• Fields: Input Condition User Switch

• Special PF Keys: Input Condition User Switch

Defining an Input Condition of the Type User Switch

To define an input condition that depends on a user switch

1. In the Master Input Condition window, enter any character in the User Switch field under the Depending on heading.

2. Press ENTER.

   An Input Condition depending on User Switch window similar to the following opens:

   +---------------------------------------------+ | | | Input Condition depending on User Switch | | | | Condition ==> USW-10 | | Run ==> | | | | Condition depends on | | User Switch ==> 10 | | of BS2000 User ID ==> SAG_____ | | | | PF1 Help PF3 End PF5 Save PF9 Delete | +---------------------------------------------+

   In this window you can enter a user switch and BS2000 user ID.

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

3. When finished, choose PF3 (End) to save data and return to the Master Input Condition window.

Fields: Input Condition User Switch

The input fields in the Input Condition depending on User Switch window are described in the following table:

Field	Description
User Switch	Number of a user switch.
of BS2000 User ID	BS2000 user ID to which the specified user switch belongs.

Special PF Keys: Input Condition User Switch

You can perform the following function from the Input Condition depending on User Switch window using this PF key:

PF Key	Name	Function
PF9	Delete	Delete input condition depending on user switch.

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

• Fields: Input Condition Job Variable (BS2000)

• Special PF Keys: Input Condition Job Variable (BS2000)

• Using Symbols

Defining an Input Condition of the Type Job Variable

To define an input condition that depends on a job variable

1. In the Master Input Condition window, enter any character in the Job Variable field under the Depending on heading.

2. Press ENTER.

   An Input Condition depending on Job Variable Contents window similar to the following opens:

   16-09-20 ***** Entire Operations ***** 18:07:07 +-------------------------------------------------------------+ Owner E ! ! ! Master Input Condition Addition ! -------- ! ! ------ C Condi ! Owner ==> EXAMPLE___ ! it _ E60-J ! Network ==> B60-FLOW__ Version ==> ! _ COND- +--------------------------------------------------------------------+ ! ! +--- ! Input Condition depending on Job Variable Contents ! ! ! ! ! ! Condition ==> COND-2 ! ! ! Run ==> ! ! C ! ! ! ! Condition will be set to true, if Job Variable ! ! ! ______________________________________________________ ! ** ! C ! at Position ___ in Length ___ with Format _ ! D ! ! is __ ! ! ! ________________________________________________________________ ! ! ! ________________________________________________________________ ! Co ! ! ________________________________________________________________ ! ! P ! ________________________________________________________________ ! +--- ! (Optional) Read Password ==> ! ! defined ==> no ! ! PF1 Help PF3 End PF5 Save PF9 Delete ! +--------------------------------------------------------------------+ Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12--- Help Add End ACond Save Up Down Menu

   In this window you can enter a job variable and further parameters to specify the input condition.

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

3. When finished, choose PF3 (End) to save data and return to the Master Input Condition window.

Fields: Input Condition Job Variable (BS2000)

The input fields provided in the Input Condition depending on Job Variable Contents window are described in the following table:

Field	Description
Condition will be set to true, if 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.
at Position	Enter the position of the substring of the job variable value to be checked. Possible values: 1 to 253.
in Length	Enter the length of the substring of the job variable value to be checked. Possible values: 1 to 253.
with Format	Specify the format in which the substring of the job variable value is to be checked against the comparison string. Possible values:
	A	Alphanumeric.
	N	Numeric (zoned).
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 values:
	=  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.
comparison string	In the input lines below is, 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.
(Optional) Read Password	(Optional field) If the job variable is read password-protected, specify the password here.

Special PF Keys: Input Condition Job Variable (BS2000)

You can perform the following function from the Input Condition depending on Job Variable Contents window using this PF key:

PF Key	Name	Function
PF9	Delete	Delete input condition dependent on job variable contents.

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

To list jobs linked to an input condition

1. On the Input Conditions Maintenance screen, type W in the line command input field of the required condition.

2. Press ENTER.

   A Condition window opens similar to the example below opens:

   17-04-14 ***** Entire Operations ***** 11:53:35 Input Conditions Maintenance Owner EXAMPLE Network E60-FLOW Version Job JOB-013 ------------------------------------------------------------------------------- C Condition Reference Type Sched.Dep. U ex. Library Exit w E60-J012-O RUN true Y +---------------------------------------------------------------------------+ ! ! ! Condition: E60-J012-O ! ! Output Condition of Input Condition for ! ! -----------------------------------+------------------------------------ ! ! Owner Network Job ! Owner Network Job ! ! EXAMPLE E60-FLOW JOB-012 ! EXAMPLE E60-FLOW JOB-013 ! ! EXAMPLE E60-FLOW JOB-013 ! ! ! ! ! ! ! ! ! ! ! ! ! ! Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10----- ! ! End Up Down ! +---------------------------------------------------------------------------+ Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12--- Help Add End ACond Save Up Down Menu

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

   • one list shows the jobs which use the condition as input condition;

   • one list shows the jobs which use the condition as output condition.

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

3. Choose PF3 (End) to close the window.

Deleting an Input Condition Definition

To delete an input condition definition

1. On the Input Conditions Maintenance screen, type D in the line command input field next to the condition you want to delete.

2. Press ENTER.

   A window prompts you to confirm the deletion.

3. Enter Y and press ENTER to delete the input condition definition.

Displaying Currently Active Conditions

To display currently active conditions

• Choose PF4 (ACond) on the Input Conditions Maintenance screen.

  An Active Conditions screen appears. This screen is described in the section Listing Active Conditions.

  For further information, refer to Listing Active Conditions in the section Active Job Networks.