RUNIF – Run operations only if specific criteria are true

The RUNIF command can be run as the first operation in an occurrence to conditionally decide which operations are allowed to run, by moving the unwanted operations to a non-reporting workstation and optionally removing special resources and time dependencies.

RUNIF [USRF-EQ|NE(field=value)] [CRITERIA(<field-prefix>)]
        [DROPSR(YES|NO)] [DROPTIME(YES|NO)] [WSNAME(<workstation>)]
        [<common-keywords>]

where:

USRF: Specifies a user field and value to decide which operations to run. You can use the keyword comparators EQ and NE. When EQ is used, it runs only operations marked with the combination of field name and value. When NE is used, it runs only operations not marked with the combination of field name and value.
CRITERIA: Names a user field prefix to use for specifying date logic expressions against. The prefix is used to identify positive and negative rule user fields. For example, CRITERIA(RUNME) looks for user fields with the format RUNME-POS-nn and RUNME-NEG-nn to contain the date logic rules for each operation.
DROPSR(YES|NO): Instructs the RUNIF command to remove special resources from operations identified as being ineligible to run. If resources are not removed, the operations could wait for special resources, even if they were moved to a non-reporting workstation. This might even affect the availability of resources if the use OnComplete. The default is YES.
DROPTIME(YES|NO): Instructs the RUNIF command to remove any time dependency from any operations identified as being ineligible to run. If time dependencies are not removed the operation will wait until the time dependency has been satisfied, even if the operation was moved to a non-reporting workstation.
WSNAME: Specifies the workstation where the operations that are not required are moved by the RUNIF process. This must be a general non-reporting workstation.

All fields are optional, but you must specify at least one USRF and one CRITERIA . If both USRF and CRITERIA are specified, the USRF keyword is processed first, and only the operations that pass the USRF test have their CRITERIA fields processed.

When CRITERIA is used, the following considerations are made:

If an operation has no user fields matching the prefix-POS-nn or prefix-NEG-nn format, the operation is considered eligible to run.
If an operation has a user field matching the prefix-POS-nn format, the operation is considered eligible to run only if the expression contained within the user field is TRUE.
If an operation has a user field matching the prefix-NEG-nn format, the operation is considered ineligible to run if the expression contained within the user field is TRUE.

nn is expected to be a two-digit numeric value, to ensure that the fields are evaluated in the correct order, because updates to the current plan might inadvertently change the sequence of user fields. It does not matter if nn is not numeric, but it is important to understand that the sort sequence of each individual field name decides the order in which the CRITERIA rules are combined. Multiple prefix-POS-nn or prefix-NEG-nn fields are not processed individually, but they are evaluated as a single positive or a single negative rule, using normal continuation rules to combine each user field value.

The following example shows a basic RUNIF usage, where:

Operation 001 runs Monday to Friday
Operation 005 runs only Monday
Operation 010 runs Monday to Friday
Operation 015 runs only on Mondays during October
Operation 020 runs Monday, Tuesday, Thursday and Friday
Operation 255 runs Monday to Friday

An application runs Monday to Friday
Operation 001 – Command –
EQQ-SYSIN-01 = RUNIF CRITERIA(RUNME) WSNAME(NONR)
Operation 005 – User Field RUNME-POS-01 = @(MON) 
Operation 010 – No user fields
Operation 015 – User Field RUNME-POS-01 = @(MON) & @(OCT) 
Operation 020 – User Field RUNME-NEG-01 = @(WED) 
Operation 255

The contents of the CRITERIA user fields can contain Workload Automation Programming Language variables that can be set in the same operation as the RUNIF command. For substitution to take place, variable substitution must be activated in the same job as the RUNIF command.

The following example shows a basic RUNIF usage with variables as criteria, where:

Operation 001 runs Monday to Friday
Operation 005 runs Monday and Tuesday
Operation 010 runs Monday and Tuesday
Operation 015 runs Wednesday and Thursday
Operation 020 runs Wednesday and Thursday
Operation 255 runs Monday to Friday

An application runs Monday to Friday
Operation 001 – Command –
EQQ-SYSIN-01 = VARSUB SCAN
EQQ-SYSIN-02 = VARSETRULE1 = “@(MON) | @(TUE)”
EQQ-SYSIN-03 = VARSETRULE2 = “@(WEDE) | @(THU)”
EQQ-SYSIN-04 = RUNIF CRITERIA(RUNME) WSNAME(NONR)
Operation 005 – User Field RUNME-POS-01 = !RULE1
Operation 010 – User Field RUNME-POS-01 = !RULE1
Operation 015 – User Field RUNME-POS-01 = !RULE2
Operation 020 – User Field RUNME-POS-01 = !RULE2
Operation 255

The USRF keyword can be used to provide different execution routes through an application depending on the contents of a variable in a JCL variable table.

Varying the name of the user field to be used allows the same operation to be permissible on multiple routes through the application.

Both the variable value and presence of the RUNIF command can be varied at submission time if the application is added to the current plan dynamically.

Using the same user field name allows an application to be divided into sub applications, allowing the application to run as a whole if no RUNIF command is set, or only running a sub set of the operations if RUNIF is executed specifying a particular value for the user field.

The following example shows a basic RUNIF usage with variables to select the route, where:

When variable ROUTE in table MYTABLE is set to ROUTE1

Operation 001 runs
Operation 005 runs
Operation 010 runs
Operation 015 does not run
Operation 020 runs
Operation 025 does not run
Operation 255 does not run

When variable ROUTE in table MYTABLE is set to ROUTE2

Operation 001 runs
Operation 005 runs
Operation 010 does not run
Operation 015 runs
Operation 020 does not run
Operation 025 runs
Operation 255 does not run

An application runs Monday to Friday
Operation 001 – Command –
EQQ-SYSIN-01 = VARSUB SCAN(1) TABLE(MYTABLE)      
EQQ-SYSIN-02 = RUNIF USRF(!ROUTE=Y) WSNAME(NONR) 
Operation 005 – User Fields ROUTE1 = Y and ROUTE2 = Y
Operation 010 – User Fields ROUTE1 = Y and ROUTE2 = N
Operation 015 – User Fields ROUTE1 = N and ROUTE2 = Y
Operation 020 – User Fields ROUTE1 = Y and ROUTE2 = N
Operation 025 – User Fields ROUTE1 = N and ROUTE2 = Y
Operation 255 – No user fields, but already on workstation NONR

The following example shows a basic RUNIF usage with the RUNIF command being varied at submission time, where:

EQQ-SYSIN-02 contains a commented template of the RUNIF command to be replaced at submission time by a real version of the RUNIF command. When submitted unmodified, all operations will run.
When an occurrence is submitted as follows:
```
INSERT CPOC ADID(MYAPPL) 
MODIFY CPOP OPNO(001) 
MODIFY CPUSRF UFNAME(EQQ-SYSIN-02) 
              UFVALUE('RUNIF USRF(SUBAPPL=GRPA) WSNAME(NONR)')
```
- Operation 001 runs
- Operation 005 runs
- Operation 010 runs
- Operation 015 runs
- Operation 020 does not run
- Operation 025 does not run
- Operation 255 does not run
When an occurrence is submitted as follows:
```
INSERT CPOC ADID(MYAPPL) 
MODIFY CPOP OPNO(001) 
MODIFY CPUSRF UFNAME(EQQ-SYSIN-02) 
              UFVALUE('RUNIF USRF(SUBAPPL=GRPB) WSNAME(NONR)')
```
- Operation 001 runs
- Operation 005 does not run
- Operation 010 does not run
- Operation 015 does not run
- Operation 020 runs
- Operation 025 runs
- Operation 255 does not run

Operation 001 – Commands – 
EQQ-SYSIN-01 = VARSUB SCAN
EQQ-SYSIN-02 = /* RUNIF USRF(SUBAPPL=GRPx) WSNAME(NONR) */       
Operation 005 – User Field SUBAPPL = GRPA
Operation 010 – User Field SUBAPPL = GRPA
Operation 015 – User Field SUBAPPL = GRPA
Operation 020 – User Field SUBAPPL = GRPB
Operation 025 – User Field SUBAPPL = GRPB
Operation 255 – No user fields, but already on workstation NONR

Note: This command changes the workstation where operations run, alters the time dependency attribute, and removes special resources from operations. If the RUNIF criteria were specified incorrectly and a rerun is required, you need to restore the occurrence to its original state, either by submitting a new occurrence in its place, or manually restoring the workstation names, time dependency attributes, and special resources, according to the database definition of the application.