JTOPTS

Purpose

The JTOPTS statement defines how operations behave at workstations and how they are submitted and tracked. This statement is used by a controller or standby controller.

JTOPTS is defined in the member of the EQQPARM library as specified by the PARM parameter on the JCL EXEC statement.

Format

>>-JTOPTS--+-----------------------------------------+---------->
           |               .-100----------------.    |
           '-ALEACTION--(--+-alert action limit-+--)-'
 
>--+--------------------------------+--+--------------------+--->
   |         .-400--------------.   |  |          .-NO--.   |
   '-BACKUP(-+-backup frequency-+-)-'  '-CONDSUB(-+-YES-+-)-'
             '-NO---------------'
 
>--+---------------------+--+-------------------------+--------->
   |           .-YES-.   |  |           .-CURRENT-.   |
   '-CRITJOBS(-+-NO--+-)-'  '-CURRPLAN(-+-NEW-----+-)-'
 
>--+---------------------------------------------+-------------->
   |           .-100-------------------------.   |
   '-DLIMFDBK(-+-limit for deadline feedback-+-)-'
 
>--+---------------------------------------------+-------------->
   |             .-50------------------------.   |
   '-DSMOOTHING(-+-deadline smoothing factor-+-)-'
 
>--+-----------------+--+------------------------------+-------->
   |       .-NO--.   |  |         .-,--------------.   |
   '-DUAL(-+-YES-+-)-'  |         V                |   |
                        '-ERRRES(-----error code---+-)-'
 
>--+----------------+--+-------------------------+-------------->
   |      .-NO--.   |  |               .-YES-.   |
   '-ETT(-+-YES-+-)-'  '-ETTGENSEARCH(-+-NO--+-)-'
 
>--+----------------------+--+--------------------+------------->
   |            .-NO--.   |  |         .-0----.   |
   '-ETTNEWDEP(-+-YES-+-)-'  '-EVELIM(-+-nnnn-+-)-'
 
>--+--------------------+--------------------------------------->
   |          .-YES-.   |
   '-FTWJSUB(-+-NO--+-)-'
 
>--+--------------------------------------------+--------------->
   |         .-4----------------------------.   |
   '-HIGHRC(-+-highest no-error return code-+-)-'
 
>--+----------------------+--+----------------------+----------->
   |           .-YES--.   |  |            .-YES-.   |
   '-JOBCHECK(-+-NO---+-)-'  '-JOBSUBMIT(-+-NO--+-)-'
               '-SAME-'
 
>--+------------------+----------------------------------------->
   |         .-5--.   |
   '-JTLOGS(-+-nn-+-)-'
 
>--+--------------------------------------------+--------------->
   |          .-100-------------------------.   |
   '-LIMFDBK(-+-limit for duration feedback-+-)-'
 
>--+----------------------------------------------+------------->
   |            .-0---------------------------.   |
   '-MAXJSFILE(-+-maximum size of JS data set-+-)-'
                '-NO--------------------------'
 
>--+--------------------------+--------------------------------->
   |            .-32767---.   |
   '-MAXOCCNUM(-+-nnnnnnn-+-)-'
 
>--+------------------------------------------------------+----->
   |             .-30---------------------------------.   |
   '-NEWOILIMIT(-+-days operator instructions are new-+-)-'
 
>--+-------------------------------------+---------------------->
   |          .-,--------------------.   |
   |          V                      |   |
   '-NOERROR(-----error code entry---+-)-'
 
>--+----------------------------+--+------------------------+--->
   |           .-1----------.   |  |              .-IP--.   |
   '-OFFDELAY(-+-delay time-+-)-'  '-OPINFOSCOPE(-+-ALL-+-)-'
 
>--+---------------------------+-------------------------------->
   |                   .-Y-.   |
   '-OPREROUTEDEFAULT(-+-N-+-)-'
 
>--+---------------------------+--+------------------+---------->
   |                   .-Y-.   |  |          .-|Y-.   |
   '-OPRESTARTDEFAULT(-+-N-+-)-'  '-|OPSUMWS|(-+-|N-+-|)-'
 
>--+-------------------------+--+------------------------+------>
   |             .-FINAL-.   |  |             .-0----.   |
   '-OUTPUTNODE(-+-ANY---+-)-'  '-OVERCOMMIT(-+-nnnn-+-)-'
 
>--+----------------------------------------+------------------->
   |            .-6---------------------.   |
   '-PLANSTART(-+-planning period start-+-)-'
 
>--+------------------------+----------------------------------->
   |              .-YES-.   |
   '-PRTCOMPLETE(-+-NO--+-)-'
 
>--+------------------------------+----------------------------->
   |           .-5------------.   |
   '-QUEUELEN(-+-queue length-+-)-'
 
>--+-----------------------+--+---------------------------+----->
   |             .-YES-.   |  |                 .-0---.   |
   '-RECCPCOMPL(-+-NO--+-)-'  '-SHUTDOWNPOLICY(-+-nnn-+-)-'
 
>--+-----------------------------------+------------------------>
   |            .-50---------------.   |
   '-SMOOTHING(-+-smoothing factor-+-)-'
 
>--+----------------------------+--+------------------+--------->
   |          .-,-----------.   |  |         .-0--.   |
   |          V             |   |  '-STATIM(-+-nn-+-)-'
   '-STATMSG(---+-CPLOCK--+-+-)-'
                +-EVENTS--+
                +-WSATASK-+
                '-GENSERV-'
 
>--+-------------------------+--+-------------------------+----->
   |                .-R--.   |  |                 .-R-.   |
   '-SUBFAILACTION(-+-C--+-)-'  '-SUPPRESSACTION(-+-C-+-)-'
                    +-E--+                        '-E-'
                    +-RH-+
                    +-XC-+
                    +-XE-+
                    '-XR-'
 
>--+---------------------------+-------------------------------->
   |                 .-0---.   |
   '-SUPPRESSPOLICY(-+-nnn-+-)-'
 
>--+---------------------------------------+-------------------->
   |        .-ALL-----.   .-ANY--------.   |
   '-TRACK(-+-OPCASUB-+-,-+-READYFIRST-+-)-'
            '-JOBOPT--'   '-READYONLY--'
 
>--+---------------------------+-------------------------------->
   |             .-OCCNAME-.   |
   '-TWSJOBNAME(-+-JOBNAME-+-)-'
                 +-EXTNOCC-+
                 '-EXTNAME-'
 
>--+--------------------------+--------------------------------->
   |                  .-R-.   |
   '-UX001FAILACTION(-+---+-)-'
 
>--+-----------------------------------------------------+------>
   |            .-LEAVE---.   .-LEAVE---.   .-MANUAL-.   |
   '-WSFAILURE(-+-ERROR---+-,-+---------+-,-+--------+-)-'
                '-RESTART-'   '-REROUTE-'   '-IMMED--'
 
>--+-----------------------------------------------------+-----><
   |            .-LEAVE---.   .-LEAVE---.   .-IMMED--.   |
   '-WSOFFLINE(-+-ERROR---+-,-+---------+-,-+--------+-)-'
                '-RESTART-'   '-REROUTE-'   '-MANUAL-'

Parameters

ALEACTION (alert action limit|100)

The limit to take an alert action for an operation in the current plan that is active for an unexpectedly long time (for more details, see the DURATION keyword in ALERTS). If you specify ALEACTION, its value is used to select the operations for which a long duration alert must be issued. If you do not specify ALEACTION, the value set for LIMFDBK is used instead.

The values for the alert action limit are in the range 100 through 999, or 0 if the alert action is to be taken as soon as the operation is active longer than its estimated duration.

BACKUP (NO|backup frequency|400)

Tivoli Workload Scheduler for z/OS uses a primary and alternate data set for the current plan. Tivoli Workload Scheduler for z/OS reorganizes the current-plan data set that is in use by copying it to the inactive data set and then switching to the newly copied data set. The value you specify on the BACKUP keyword defines if the current plan should be automatically copied, and determines how frequently the automatic copy process should occur.

Specify a backup frequency if you want Tivoli Workload Scheduler for z/OS to perform the copy process automatically. The backup frequency value defines how many records should be written to the job-tracking log before a copy process is performed. Tivoli Workload Scheduler for z/OS includes both tracked events and audit records when counting the number of records written to the job-tracking log.

Specify NO if you do not want Tivoli Workload Scheduler for z/OS to perform the copy process automatically. If you specify NO, ensure that you request backups at regular intervals, depending on the workload at your installation.

You can request that Tivoli Workload Scheduler for z/OS performs a copy process using the BACKUP command or EQQUSIN or EQQUSINB subroutine, regardless of the value specified on the BACKUP keyword. For more information about the BACKUP command, see Managing the Workload. For more information about the EQQUSIN and EQQUSINB subroutines, see Reporting events to Tivoli Workload Scheduler for z/OS.

Note:

If the copy process is performed automatically and you issue a BACKUP request, Tivoli Workload Scheduler for z/OS counts the number of records from the time of the requested backup before performing another automatic copy.

Copying of the current plan data sets also occurs when the controller is started or stopped, before and after daily planning, and during recovery of Tivoli Workload Scheduler for z/OS system data sets. These copies occur regardless of the value specified for BACKUP.

CONDSUB (YES|NO)

Specify YES if condition dependencies defined on status S (started) have to be evaluated as soon as the status of the conditional predecessor becomes S (started) without waiting for the job-start event reported by the tracker component.

Specify NO if conditional dependencies defines on status S (started) must wait for the job-start event reported by the tracker component before being evaluated. NO is the default value.

CRITJOBS(NO|YES)

Specify CRITJOBS(N) to prevent the creation of the critical job table and the start of the critical path handler task at controller startup, thus deactivating the critical path capability without resetting the critical operation option and running LTP and DP batch. Consider running with CRITJOBS(N) in the following conditions:

During recovery procedures.
When the critical path capability does not fit the current workload execution scenario.

To reactivate the critical path capability, perform the following steps:

Scrap the EQQJTABL log data set, if it is not empty.
Restart the controller with CRITJOBS(Y).
Submit a replan job to re-synchronize the critical job table with the current plan.

CURRPLAN (NEW|CURRENT)

This keyword defines from which current-plan data set Tivoli Workload Scheduler for z/OS will start. The default is that Tivoli Workload Scheduler for z/OS will use either the primary current-plan data set (ddname EQQCP1DS) or the alternate current-plan data set (ddname EQQCP2DS). If both of these data sets are damaged or contain logical errors, if the EQQCKPT data set has been reallocated, or when Tivoli Workload Scheduler for z/OS is started for the first time after migration, Tivoli Workload Scheduler for z/OS can be started from the new-current-plan data set (ddname EQQNCPDS). To do so, specify CURRPLAN(NEW). Starting from the new-current-plan data set will be done automatically if you have created a new plan while Tivoli Workload Scheduler for z/OS was inactive.

Use CURRPLAN(NEW) only when you cannot start Tivoli Workload Scheduler for z/OS using the primary or the alternate current-plan data set. Do not use CURRPLAN(NEW) when you start Tivoli Workload Scheduler for z/OS for the first time with all data sets empty.

DLIMFDBK (limit for deadline feedback|100)

The limit for deadline feedback. This keyword determines if the estimated deadline in the application description run cycle or operation is updated when an occurrence of the application reaches the complete status. The DLIMFDBK keyword value you set in this keyword is used only if you did not set a value in the application description.

Feedback values are in the range 100 through 999, or 0 if the deadline must be always updated, regardless of the estimated and actual values.

The feedback limits for ADL are calculated as follows:

Lower limit = ODL * 100/DLF
Upper limit = ODL * DLF/100

Where:

ADL: The actual deadline, considered as the elapsed minutes between the IA® and the completion time of the occurrence or operation.
ODL: The old deadline estimated for the run cycle or operation (considered as offset in minutes from the IA) currently stored in the application description database.
DLF: The limit for deadline feedback.

When the deadline feedback limit is set to 100, no new estimated deadline is stored in the application description database and no missed feedback record is generated. If the actual deadline lies within the feedback limits, a smoothing factor is applied before the application description is updated.

If the limit for deadline feedback is set to 0, the application description database is always updated, unless:

A feedback limit is specified also in the application
The smoothing factor does not allow the change

If the completion time occurs before the IA time, the deadline is not updated and a missed feedback record is generated.

When the occurrence is generated, an identifier of the run cycle that generates the occurrence is stored in the occurrence record. This identifier is used to determine which run cycle must be updated. If the application description or the occurrence input arrival was modified, the run cycle might no longer be matchable. In this case, the deadline is not updated and a missed feedback record is generated.

DSMOOTHING (deadline smoothing factor|50)

The deadline smoothing factor. It determines how much the actual deadline influences the new deadline estimated for a run cycle or operation in the application description database. The smoothing factor is applied only if the actual deadline lies within the deadline feedback limits. The DSMOOTHING keyword value is used only if you did not set a smoothing factor in the application description.

The smoothing factor is in the range 0 through 999. A value of 0 means that the deadline is not updated, a value of 100 means that the actual deadline replaces the existing estimated deadline.

The new deadline is calculated as follows:

NDL = ODL + ((ADL - ODL) * DSF/100)

Where:

NDL: The new deadline estimated for the run cycle or operation (considered as offset in minutes from the IA) to be stored in the application description database.
ODL: The old deadline estimated for the run cycle or operation (considered as offset in minutes from the IA) currently stored in the application description database.
ADL: The actual deadline, considered as the elapsed minutes between the IA and the completion time of the occurrence or operation.
DSF: The deadline smoothing factor.

DUAL (YES|NO)

Specify YES if Tivoli Workload Scheduler for z/OS should perform dual logging of the job-tracking-log data sets (EQQJTnn). When it is started, Tivoli Workload Scheduler for z/OS will open data sets pointed to by the EQQDLnn ddnames in the controller JCL procedure. The suffix nn is a number from 01 to 99. The number of EQQJTnn data sets and EQQDLnn data sets must be the same.

Specify NO if Tivoli Workload Scheduler for z/OS should not write job-tracking information to dual data sets. NO is the default value.

ERRRES (error code,...,error code)

Defines a list of error codes that, for job-tracking purposes, result in an automatic reset of an operation. The operation is reset to status A (arriving) and contains the message Error, automatically reset in its operation details panel.

An error code can be:

A 4-digit job or started-task return code (nnnn)
A system abend code (Sxxx)
A user abend code (Uxxx)
An IBM Tivoli Workload Scheduler for z/OS-defined code

Notes:

Tivoli Workload Scheduler for z/OS converts the decimal value of a user abend code to a hexadecimal error code. For example, user abend 123 is shown as error code X'U07B'.
The OSEQ error code is a special case and cannot be reset by ERRRES.
With PQ87904 APAR, the ERRRES logic does not apply if the error code is generated by the EQQCLEAN step, that is a step inserted into a restarted job by the Restart and Cleanup function.
The ERRRES keyword applies also to operations that are run on z-centric agent workstations.
The only acceptable error codes are those listed in Appendix E of Managing the Workload.

For example, a user submits a job outside of Tivoli Workload Scheduler for z/OS for which an operation exists in the current plan. The job abends with code S806, which is specified in the ERRRES list. Tivoli Workload Scheduler for z/OS sets the operation to status A. If the user then resubmits the job after correcting the error, Tivoli Workload Scheduler for z/OS again automatically tracks the job. The status of the operation is changed from A to S when the job is started.

An operation that has been automatically reset by ERRRES processing will not be resubmitted by Tivoli Workload Scheduler for z/OS even if SUBMIT=Y is specified for the operation. So if an operation that is normally submitted by Tivoli Workload Scheduler for z/OS is reset, manually change the status to R (ready) using the MCP dialog, or through PIF, if you want Tivoli Workload Scheduler for z/OS to submit the job again.

If you stop and then start Tivoli Workload Scheduler for z/OS, or if a new daily plan has been created, operations that have been reset will have their error reset indication removed and will be eligible for submission.

ETT (YES|NO)

Specify YES if the event-triggered-tracking function should be initially active when Tivoli Workload Scheduler for z/OS is started. Specify NO if the ETT function should not be initially active. Note that you can activate or deactivate ETT while Tivoli Workload Scheduler for z/OS is running, using the Service Functions dialog.

ETTGENSEARCH (NO|YES)

Specify YES if the event-triggered-tracking function should search the SI file first for an exact match or for the best match hereafter. This is because the % or the * characters can be used in the ETT criteria definition. Specify NO if the event-triggered-tracking function should search the SI file only for an exact match. Use this value when the SI file does not contain ETT criteria using the % or the * characters.

ETTNEWDEP (NO|YES)

Determines the input arrival time used by the scheduler when solving dependencies for occurrences that:

Are being added through ETT.
Correspond to applications defined with a run cycle referring to the period ETTRCY1. In this condition, to resolve dependencies the scheduler uses the input arrival time associated to the run cycle, instead of using the actual input arrival time, that is the time when the occurrence is added.

The ETTNEWDEP parameter affects the selection of any successor added in the current plan in the previous conditions.

Specify YES you want that the scheduler uses the ETTRCY1 input arrival time both for the occurrences that are being added to the current plan and the candidate successors, provided that the successor is an occurrence added through ETT and corresponding to an application with run cycle referring to ETTRCY1.

Specify NO if you want that the scheduler uses the ETTRCY1 input arrival time only for the occurrences that are being added to the current plan. In this case, for the candidate successors the scheduler uses the actual input arrival time.

EVELIM (nnnn)

This keyword defines how often statistic messages related to the STATMSG keyword are issued.

It is considered only if the value of STATIM is 0, and it defines the number of events that the event-manager task must process before issuing a new set of messages.

Valid values are from 0 to 9999.

If the current value of STATIM is 0 and the current value of EVELIM is 0, the statistics messages are issued every n events, where n is half the BACKUP value.

The value of EVELIM can be dynamically updated using the modify command, /F subsys,EVELIM=nnnn.

FTWJSUB (NO|YES)

Specify YES if Tivoli Workload Scheduler for z/OS should submit jobs on distributed agents. Specify NO if Tivoli Workload Scheduler for z/OS should not perform these functions automatically. The job-submit option can be changed through the Service Functions dialog while Tivoli Workload Scheduler for z/OS is running.

HIGHRC (highest no-error return code|4)

Defines the highest error code that can be generated in a Tivoli Workload Scheduler for z/OS job or started task without causing Tivoli Workload Scheduler for z/OS to process the operation as having ended in error.

Note:

With PQ87904 APAR, the HIGHRC logic does not apply when the error return code is generated by the EQQCLEAN step, that is a step inserted into a restarted job by the Restart and Cleanup function. In this case the operation status is set to ended in error.

JOBCHECK (NO|SAME|YES)

The JOBCHECK keyword specifies if and how Tivoli Workload Scheduler for z/OS checks the job card before submitting the job.

JOBCHECK(YES) means that Tivoli Workload Scheduler for z/OS checks the job card only for validity. If the job card is not valid, the job is not submitted. Tivoli Workload Scheduler for z/OS considers the job card to be valid if it is in the following format:

//jobname  JOB

jobname: Consists of 1 to 8 alphanumeric or national characters where the first character is alphabetic or national.
JOB: Must be preceded and followed by at least one blank. If the job card is valid but the job name is not the same as the job name in the current Tivoli Workload Scheduler for z/OS operation, a warning message is written to the Tivoli Workload Scheduler for z/OS message log.

JOBCHECK(NO) means that the job card is not checked at all. Tivoli Workload Scheduler for z/OS submits the job without checking the job card.

Note:

JOBCHECK(YES) and JOBCHECK(NO) allow Tivoli Workload Scheduler for z/OS to submit a job with a jobname that doesn't match the jobname in the current operation. This implies that IBM Tivoli Workload Scheduler for z/OS will be unable to track the status of the submitted operation correctly. Use JOBCHECK(SAME) if you need the status to be tracked.

JOBCHECK(SAME) means that the job card is checked for validity, and also checked to see that the job name is the same as the job name in the current Tivoli Workload Scheduler for z/OS operation. The job is submitted only if it has a valid job card with the job name matching that in the current operation.

Note:

No checking is performed for operations that run on a workstation with a user-defined destination ID connected through TCP/IP or APPC.

JOBSUBMIT(NO|YES)

Specify YES if Tivoli Workload Scheduler for z/OS should submit jobs, start started tasks, and issue write-to-operator messages for WTO operations. Specify NO if Tivoli Workload Scheduler for z/OS should not perform these functions automatically. The job-submit option can be changed through the Service Functions dialog while Tivoli Workload Scheduler for z/OS is running.

JTLOGS(number of JT logs|5)

Specifies the number of job-tracking logs that should be opened by Tivoli Workload Scheduler for z/OS when it is started. The number should be a value in the range 2 to 99. The default value is 5. The log data sets are identified by the EQQJTnn ddname in the controller JCL procedure. Tivoli Workload Scheduler for z/OS attempts to open data sets starting with EQQJT01 and continue for the number specified in the JTLOGS keyword. For example, if you specify a value of 3 for JTLOGS, Tivoli Workload Scheduler for z/OS attempts to open job-tracking logs EQQJT01, EQQJT02, and EQQJT03.

LIMFDBK(limit for duration feedback|100)

Limit for duration feedback. |This parameter is |ignored for shadow jobs.

Tivoli Workload Scheduler for z/OS job tracking automatically monitors actual durations. These can be used to modify estimated operation durations in the application description database. Tivoli Workload Scheduler for z/OS uses two factors, limit for duration feedback and duration smoothing, to control how actual durations are used.

The LIMFDBK value determines if estimated durations in the application description are updated when an occurrence of the application reaches complete status. The LIMFDBK keyword value is used only if no value is specified in the application description.

Feedback values are in the range 100 through 999, or 0 if the duration must be always updated, regardless of the estimated and actual values. The feedback limits are calculated as follows:

Limits for duration feedback

Lower limit = OD * 100/LF
Upper limit = OD * LF/100

where:

OD: The old estimated duration currently stored in the application description database.
LF: The limit for duration feedback.

If the limit for duration feedback is set to 0, the application description database is always updated, unless:

A feedback limit is specified also in the application
The smoothing factor does not allow the change

If an estimated duration lies within feedback limits, a smoothing factor is applied before the application description is updated. See the SMOOTHING keyword, which is described on page ***.

Table 3 shows examples of how the limit-for-feedback algorithm works.

Table 3. Limit for feedback examples
LF value	Result
100	No new estimated duration will be stored in the application-description database.
110	The new estimated duration will be stored if the actual duration is approximately between 90% and 110% of the old estimated duration.
200	The new estimated duration will be stored if the actual duration is between half and double the old estimated duration.
500	The new estimated duration will be stored if the actual duration is between one-fifth and five times the old estimated duration.
999	The new estimated duration will be stored if the actual duration is between one-tenth and 10 times the old estimated duration.

Note:

The feedback limit used to select the operations for which a long duration alert must be issued is the value specified for ALEACTION. If ALEACTION is not set, the value for LIMFDBK is used instead. In this case, the value for the feedback limit that you can optionally enter in the application description is ignored.

MAXJSFILE(NO|maximum size of JS data set|0)

Tivoli Workload Scheduler for z/OS uses a primary and alternate data set for the JCL repository. Tivoli Workload Scheduler for z/OS reorganizes the JCL repository data set that is in use by copying it to the inactive data set and then switching to the newly copied data set. The value you specify on the MAXJSFILE keyword defines whether the JCL repository should be automatically copied and determines how frequently the automatic copy process should occur.

|Specify a maximum size |if you want Tivoli Workload Scheduler for z/OS to copy automatically. This value also defines |how large the current JCL repository data set is allowed to become |before it is automatically copied to the alternate data set. The size |must be specified in megabytes (1MB equals 1,024 kilobytes). The maximum |value you can specify is 67 108 864 megabytes. Any greater |value will give unpredictable results. The value specified is converted |into cylinders and rounded to the next whole number. Any value equivalent |to less than 2 cylinders (other than the default value) is set to |2 cylinders. If you do not specify MAXJSFILE or specify the default |value 0, Tivoli Workload Scheduler for z/OS will perform a copy after the first 50 jobs have been |inserted since it was started. The size of the data set (converted |into cylinders) after this first copy, plus the equivalent of one |cylinder, is then used as the value for MAXJSFILE. After every 50 |inserts, Tivoli Workload Scheduler for z/OS checks the size of the JS file using an algorithm |that is based on the high_used_RBA. If the high_used_RBA is equal |to or greater than the value of MAXJSFILE, a copy is performed.

Specify NO if you do not want Tivoli Workload Scheduler for z/OS to copy automatically. If you specify NO, ensure that you request backups at regular intervals, depending on the workload at your installation.

You can request that Tivoli Workload Scheduler for z/OS performs a copy process using the BACKUP command or EQQUSIN or EQQUSINB subroutine, regardless of the value specified on the MAXJSFILE keyword. For more information about the BACKUP command, see Managing the Workload. For more information about the EQQUSIN and EQQUSINB subroutines, see Reporting events to Tivoli Workload Scheduler for z/OS.

MAXOCCNUM(nnnnnnn|32767)

Tivoli Workload Scheduler for z/OS maintains an upper limit on the number of occurrences in the current plan. When this limit is reached, no more occurrences can be added, either by dialog, the program interface, the event triggered tracking, or the automatic recovery. If the keyword is omitted, the limit is 32767 occurrences. It is advisable not to set the parameter to a larger number than required by actual workload needs, due to the increased overhead incurred. Tivoli Workload Scheduler for z/OS can start with a current plan exceeding the limit and also take over a plan exceeding the limit from daily planning.

NEWOILIMIT(days operator instructions are new|30)

Defines the number of days that Tivoli Workload Scheduler for z/OS considers an operator instruction record to be new after it is changed. The number of days between the occurrence input arrival and the last update of the operator instruction is calculated. If the result is less than the value specified for NEWOILIMIT, or if the occurrence input arrival is earlier than the last update of the operator instruction, the operator instruction is treated as a new instruction. New operator instructions are represented in tailorable lists by a plus character (+) in the OI column.

NOERROR(error code entry,...,error code entry)

Defines a list of error codes that, for job-tracking purposes, are treated as normal completion codes. You can also specify error codes on the NOERROR statement. See Purpose.

This parameter follows the same rule as the LIST parameter of the NOERROR statement. For a description of these rules, refer to page ***.

Note:

Do not use this parameter to dynamically rebuild the NOERROR table using a modify command with the NEWNOERR or NOERRMEM option. If you need to dynamically rebuild the NOERROR table, use the NOERROR statement as described in Purpose.

OFFDELAY(delay time|1)

The OFFDELAY parameter defines, in minutes, the time that Tivoli Workload Scheduler for z/OS delays actions defined in the WSOFFLINE parameter when a workstation changes status to offline. The status of the workstation changes immediately as a response to the offline event being received at the controller, but Tivoli Workload Scheduler for z/OS does not take reroute or restart actions until the time specified for OFFDELAY has elapsed. If an event that changes the status of the workstation to available is received during the delay time, no WSOFFLINE actions are performed.

OFFDELAY is used only when a workstation changes status to offline, not for a failure indication.

The OFFDELAY parameter also functions as the delay time for setting a workstation to offline during Tivoli Workload Scheduler for z/OS controller startup. The controller initially keeps the status of the workstation as it was when the controller subsystem was stopped. The OFFDELAY parameter defines the length of time that the controller waits for a tracker to establish communication. If it is not performed during the specified time, the workstation represented by this tracker will be set to OFFLINE status.

Note:

If you have workstations that specify a user-defined destination ID, ensure that the OFFDELAY keyword is set high enough to allow sufficient time to set the destination to active status when IBM Tivoli Workload Scheduler for z/OS is started.

OPINFOSCOPE(ALL|IP)

Defines how Tivoli Workload Scheduler for z/OS selects an operation when an event is created that updates the USERDATA field. The event can be created through an OPINFO TSO command, EQQUSIN or EQQUSINO subroutine, or API CREATE request.

Specify IP (in progress), which is the default, if Tivoli Workload Scheduler for z/OS should select the operation only from operations in status R, A, *, S, I, and E. If there is more than one operation that matches the selection criteria, Tivoli Workload Scheduler for z/OS chooses the operation by investigating these characteristics in the stated order:

The operation has priority 9.
Earliest latest start time.
Priority 8-1.
Input arrival time specified for the operation or the occurrence input arrival if the operation does not have input arrival specifically defined.
Longest in Ready status.

Specify ALL if Tivoli Workload Scheduler for z/OS should also check operations in status C and W, if no matching in-progress operation was found. The operation with the earliest latest-start-time is selected.

OPREROUTEDEFAULT(N|Y)

Defines the default for operations that have a blank value specified for the reroutable option in the operation details.

Specify N if operations that have reroutable set to blank are not eligible for rerouting if the workstation becomes inactive.

Specify Y if ready operations should be rerouted to the alternate workstation if a blank value is specified, and the installation default action allows operations to be rerouted when the workstation status is set to failed or offline. The default action can be specified in:

The MCP dialog when the workstation is manually varied to offline or failed.
The WSSTAT command or EQQUSIN or EQQUSINW subroutine when the workstation is set to offline or failed.
The second value of the WSOFFLINE or WSFAILURE keywords on the JTOPTS statement. This default applies to all workstations.

OPRESTARTDEFAULT(N|Y)

Defines the default for operations that have a blank value specified for the restartable option in the operation details.

Specify N if operations that have restartable set to blank are not eligible for automatic restart if the workstation becomes inactive.

Specify Y if started operations should restart on the alternate workstation if a blank value is specified, and the installation default action allows operations to be restarted when the workstation status is set to failed or offline. The default action can be specified in:

The MCP dialog when the workstation is manually varied to offline or failed.
The WSSTAT command or EQQUSIN or EQQUSINW subroutine when the workstation is set to offline or failed.
The first value of the WSOFFLINE or WSFAILURE keywords on the JTOPTS statement. This default applies to all workstations.

OPSUMWS(N|Y)

Determines which data is to be retrieved for Dynamic Workload Console.

Specify Y if you want to retrieve the data from the workstations’ statistics. Specify N if you want the query to be performed by reading all the operation records.

OUTPUTNODE(ANY|FINAL)

Defines whether Tivoli Workload Scheduler for z/OS should process A3P (JES2 job termination) events from any NJE node that job SYSOUT is spooled to, or from only the NJE node that is the final destination. The OUTPUTNODE keyword is valid only for JES2 environments.

Because you can send JES2 job SYSOUT, or parts of the SYSOUT, to several different NJE nodes, more than one job termination (A3P) event could be produced for the same job. Also, if the job completion checker (JCC) is used, each event can also have different job-completion-code information depending on the output sent to a particular node and the checking that the JCC performs at that node. The status assigned to the operation depends on which of the A3P events was first processed by the controller.

Specify FINAL if you use the JCC to scan SYSOUT and set error codes. Then, only the part of the SYSOUT that contains the JESYSMSG (previously $SYSMSGS, DSID=4), which has reached its final NJE node, is used to change the status of the corresponding computer operation from status S (started) to status C (complete) or E (ended in error). FINAL is the default value.

Specify ANY if the JCC is not used to scan SYSOUT and set error codes.

OUTPUTNODE defaults to FINAL if RCLEANUP(YES) is specified in the OPCOPTS statement.

If SYSOUT is routed to an NJE node that is not controlled by Tivoli Workload Scheduler for z/OS, the A3P event from the executing node is used to change the status of the corresponding operation, regardless of the value you specify for OUTPUTNODE.

OVERCOMMIT(nnnn|0)

Defines the number of job, started-task, and WTO operations that can be started on the automatically reporting workstations besides the number specified as the parallel server capacity for the workstation. For example, if a computer workstation has 10 parallel servers defined and OVERCOMMIT specifies 2, then up to 12 operations can be started for that workstation.

The workstation must use control on parallel servers for OVERCOMMIT to have meaning. The default value is 0, maximum 9999.

PLANSTART(planning period start|6)

Defines the time-of-day in hours when the daily planning period starts. This value must be the same as the value you specify for PLANHOUR on the BATCHOPT statement.

PRTCOMPLETE(NO|YES)

Specify YES if Tivoli Workload Scheduler for z/OS should set print operations to complete when a batch job is purged from the JES spool. Specify NO if Tivoli Workload Scheduler for z/OS should not set print operations to complete when a batch job is purged from JES. Here, print operations are set to complete only by print-end events.

Consider setting PRTCOMPLETE to YES if some of your jobs or started tasks conditionally create SYSOUT, or if FREE=CLOSE is specified on the DD statement.

QUEUELEN(queue length|5)

Defines the maximum number of ready operations that the workstation analyzer (WSA) subtask starts each time it has control of the current plan resource. The default value is 5. If you specify a value less than 5, the default value is used.

If you specify a high value for QUEUELEN and there are many ready operations, this could affect the performance of other tasks that use the current plan resource.

The value of QUEUELEN can be dynamically updated using the modify command, /F subsys,QUELEN=nnnn.

RECCPCOMPL(NO|YES)

Set RECCPCOMPL(N) to avoid path recalculation when an operation on the critical path completes and its successor on the same critical path has an uncompleted predecessor.

Use the default RECCPCOMPL(Y) to have the critical paths recalculated for all the available recalculation triggers.

SHUTDOWNPOLICY(nnn|0)

The SHUTDOWNPOLICY value is a percentage in the range 0 to 999. It lets you specify whether Tivoli Workload Scheduler for z/OS should start an operation when there is little time left before a workstation is closed. A workstation must have CONTROL ON SERVERS=Y for this keyword to have any effect.

The estimated duration of an operation is multiplied by the SHUTDOWNPOLICY percentage, and the result is compared to the time remaining in the workstation-open interval. If the result is greater than the time remaining in the open interval for the workstation and a nonzero factor is specified, Tivoli Workload Scheduler for z/OS will not start the operation.

The following examples show how SHUTDOWNPOLICY is used. In these examples, an operation has an estimated duration of 60 minutes, and the workstation it uses will close down in 45 minutes.

SHUTDOWNPOLICY(0): The operation is started regardless of the end of the current workstation-open interval.
SHUTDOWNPOLICY(50): The operation is started because 30 minutes (50% of 60 minutes) is less than the 45 minutes remaining in the workstation-open interval.
SHUTDOWNPOLICY(100): The operation is not started because 60 minutes (100% of 60 minutes) is greater than the time remaining in the workstation-open interval.
SHUTDOWNPOLICY(200): The operation is not started because 120 minutes (200% of 60 minutes) is greater than the time remaining in the workstation-open interval.

SMOOTHING(smoothing factor|50)

The smoothing factor determines how much the actual duration of an operation influences the new estimated duration that is stored in the application description database. The smoothing factor is applied only if the actual duration lies within the limits determined by feedback (see the LIMFDBK keyword on page ***). |This |parameter is ignored for shadow jobs.

Tivoli Workload Scheduler for z/OS uses the value you specify on the SMOOTHING keyword if you do not specify a smoothing factor in the details of an operation. The smoothing factor is in the range 0 to 999. A value of 0 means that the operation is not updated. A value of 100 means that the actual duration replaces the existing estimated duration of the operation. The new estimated duration is calculated as follows:

New estimated duration

ND = OD + ((AD - OD) * SF/100)

where:

ND: The new estimated duration to be stored in application description database.
OD: The old estimated duration currently stored there.
AD: The actual duration.
SF: The smoothing factor.

Table 4 provides examples of how the smoothing factor algorithm works.

Table 4. Smoothing factor examples
Factor	Result
0	There will be no feedback.
10	The new estimated duration will be the old estimated duration, plus one-tenth the difference between the actual and old estimated duration.
50	The new estimated duration will be the old estimated duration, plus one-half the difference between the actual and old estimated duration.
100	The actual duration replaces the old estimated duration.
999	The new estimated duration will be the old estimated duration, plus 10 times the difference between the actual and old estimated duration.

STATMSG(option list)

Defines the status message types that Tivoli Workload Scheduler for z/OS will produce. You can specify one or more of the these values:

CPLOCK

The event-manager subtask issues messages EQQE004I and EQQE005I, which describe how often different tasks have referenced the current-plan data set.

EVENTS

The event-manager subtask issues messages EQQE000I, EQQE006I, and EQQE007I, which describe how many events were processed and provide statistics for different event types.

WSATASK

The event manager task issues messages EQQE008I and EQQE009I, which describe statistic information collected by the WSA task.

All these messages are issued according to the following criteria:

If STATIM has been set to a value different from 0 (by specifying STATIM(n) in the JTOPS keyword, or by using the modify command /F subsys,STATIM=n), the message is issued approximately every n minutes, if any events have been processed.
Otherwise, if EVELIM has been set to a nonzero value (by specifying EVELIM(n) in the JTOPS keyword, or by using the modify command /F subsys,EVELIM=n), the message is issued approximately every n events.
Otherwise, the message is issued approximately once every n events, where n is half the JTOPTS BACKUP keyword value (default BACKUP value is 400).

GENSERV

The general-service subtask issues messages EQQG010I to EQQG013I, which describe how often different tasks have been processed and how long the general-service queue has been. Tivoli Workload Scheduler for z/OS issues these messages every 30 minutes, or every n minutes if the value of STATIM is nonzero (by specifying STATIM(n) in the JTOPTS keyword, or by using the modify command /F subsys,STATIM=n), if any requests have been processed.

For more information about any of these messages, refer to Messages and Codes.

STATIM(nn)

Defines the time interval, in minutes, to be used for issuing the statistic messages related to the STATMSG keyword. Valid values are from 0 to 99.

If this keyword is omitted, or if 0 is specified, the time interval is not used, and statistic messages are issued every n events, where n is the EVELIM values or half of the BACKUP value if EVELIM is set to 0.

The value for STATIM can be dynamically updated using the modify command, /F subsys,STATIM=nn.

SUBFAILACTION(C|E|R|RH|XC|XE|XR)

Defines what action Tivoli Workload Scheduler for z/OS should take if a failure occurs while retrieving the JCL during the submission of a job or the starting of a started task. Specify one of these actions:

C: The operation is set to complete. If EQQUX001 is called and returns an error code, then the error code is ignored.
E: The operation is set to ended-in-error with error code OSUF. If EQQUX001 is called and returns an error code, then the error code is ignored.
R: The operation remains on the ready list with status R (ready) and extended status E (error). If the failure was reported by the operation-initiation exit (EQQUX009), the operation remains on the ready list with status S (started) and extended status E (error). If EQQUX001 is called and returns an error code, then the error code is ignored.
RH: This acts in the same way as R, unless EQQUX001 is called and returns an error code different from '0000', in which case the operation is set to ready and manual hold.
XC: This acts in the same way as C, unless EQQUX001 is called and returns an error code different from '0000', in which case the operation ends in error with the error code returned by the user exit.
XE: This acts in the same way as E, unless EQQUX001 is called and returns an error code different from '0000', in which case the operation ends in error with the error code returned by the user exit.
XR: This acts in the same way as R, unless EQQUX001 is called and returns an error code different from '0000', in which case the operation ends in error with the error code returned by the user exit.

SUPPRESSACTION(C|E|R)

Defines what action Tivoli Workload Scheduler for z/OS should take if a suppress-if-late time-dependent operation becomes late. Specify one of these actions:

C: The operation is set to complete.
E: The operation is set to ended-in-error with error code OSUP.
R: The operation remains on the ready list with status R (ready) and extended status L (late).

The suppress actions are not all applicable to the operations defined on fault-tolerant workstations in an end-to-end with fault tolerance capabilities environment: for operations with the centralized script option, the applicable suppress actions are C, E, and R; for the other operations defined on fault-tolerant workstations, the applicable suppress action is only R. If a different value is specified, the default value R is used for these operations.

Notes:

For operations running on fault-tolerant workstations, status E is allowed only for centralized scripts. However, for the controller and fault-tolerant agent the status does not match until a batch DP job (Symphony Renew, CP extend, CP replan) is run.
Tivoli Workload Scheduler for z/OS considers the time buffer created by the SUPPRESSPOLICY keyword when deciding if a time-dependent operation is late.

Note:

SUPPRESSPOLICY(nnn|0)

Specifies how Tivoli Workload Scheduler for z/OS should control time-dependent operations with the suppress-if-late option. You can use SUPPRESSPOLICY to create an input-arrival buffer for these time-dependent operations rather than a specific input-arrival time.

The SUPPRESSPOLICY value is a percentage in the range 0 to 999. A value of 0 means that Tivoli Workload Scheduler for z/OS will not try to start the operation if its input-arrival time has passed. If you specify a nonzero value, Tivoli Workload Scheduler for z/OS multiplies the estimated duration of the operation by this percentage. If the resulting figure lies within the time remaining until the operation deadline, the operation will be started. Otherwise, the operation will be considered late and will not be started by Tivoli Workload Scheduler for z/OS.

The following examples show how SUPPRESSPOLICY is used. In these examples, an operation has become ready. The input-arrival time of the operation passed 15 minutes ago, and its deadline will expire in 45 minutes. The operation has an estimated duration of 60 minutes.

SUPPRESSPOLICY(0): The operation is considered late because the input-arrival time has passed. The action specified on the SUPPRESSACTION keyword will be taken.
SUPPRESSPOLICY(50): The operation is started because 30 minutes (50% of 60 minutes) is less than the 45 minutes remaining to the deadline.
SUPPRESSPOLICY(100): The operation is considered late because 60 minutes (100% of 60 minutes) is greater than the time remaining to the deadline. The action specified on the SUPPRESSACTION keyword will be taken.
SUPPRESSPOLICY(200): The operation is considered late because 120 minutes (200% of 60 minutes) is greater than the time remaining to the deadline. The action specified on the SUPPRESSACTION keyword will be taken.

The suppress-if-late option on operations defined on fault-tolerant workstations with no centralized script option and not using any special resource is not handled directly by the Controller, but is stored in the Symphony™ file as "until time", see the Tivoli® Workload Scheduler Reference Guide. The until time value is set using the SUPPRESSPOLICY with the same algorithm as for the other operations if the expected operation end time is earlier than the deadline time, otherwise it is set to the operation input arrival time plus one minute.

TRACK(OPCASUB|JOBOPT|ALL, READYFIRST|READYONLY|ANY)

The TRACK parameter contains two keyword values:

The first value specifies which jobs or started tasks Tivoli Workload Scheduler for z/OS tracks. If a job is tracked, it means that events for that job cause the current plan to be updated. The status of the operation in the current plan that represents the job is updated by events such as job start and job completion. For example, when a job ends execution on a system (computer workstation), the status of the corresponding operation in the current plan is changed from S (started) to C (completed).
If you use event-triggered tracking with job-name replace (J-type events with JR=Y), both operands of the TRACK parameter are ignored for jobs submitted from outside of Tivoli Workload Scheduler for z/OS. Such jobs are always tracked.

Specify OPCASUB when all your Tivoli Workload Scheduler for z/OS-planned jobs and started tasks are submitted by Tivoli Workload Scheduler for z/OS; that is, when they are all defined with the SUBMIT option set to YES. This is the recommended method of handling submission. Tivoli Workload Scheduler for z/OS tracks work that it submitted itself; work submitted outside of Tivoli Workload Scheduler for z/OS is not tracked, even if it corresponds to an operation that is defined in the current plan.

Specify JOBOPT when some of your Tivoli Workload Scheduler for z/OS-planned jobs are submitted by Tivoli Workload Scheduler for z/OS and some are submitted outside of Tivoli Workload Scheduler for z/OS, but you always know in advance which are submitted by each method. You must ensure that:
- Jobs submitted by Tivoli Workload Scheduler for z/OS have their SUBMIT option set to YES, and these jobs are not submitted outside of Tivoli Workload Scheduler for z/OS.
- Jobs submitted outside of Tivoli Workload Scheduler for z/OS have their SUBMIT option set to NO.
When you use JOBOPT, Tivoli Workload Scheduler for z/OS tracks jobs it submitted itself, and jobs that were submitted outside of Tivoli Workload Scheduler for z/OS but were defined with their SUBMIT option set to NO. JOBOPT causes Tivoli Workload Scheduler for z/OS to track jobs where the mode of submission correctly matches the SUBMIT option for the job. If you define a job with the SUBMIT option set to YES but the job is submitted outside of Tivoli Workload Scheduler for z/OS, the job is not tracked.

Specify ALL when you do not know in advance if Tivoli Workload Scheduler for z/OS-planned jobs will be submitted by Tivoli Workload Scheduler for z/OS or outside of Tivoli Workload Scheduler for z/OS. All Tivoli Workload Scheduler for z/OS-planned jobs are tracked, regardless of how they were submitted or what the job SUBMIT option is set to.
The second keyword value determines how Tivoli Workload Scheduler for z/OS selects the matching operation when a job or started task is submitted outside of Tivoli Workload Scheduler for z/OS. The product uses this value only when you specify JOBOPT or ALL for the first keyword value.
Specify READYFIRST to select the ready operation with the earliest latest-start time. If no ready operation is found, Tivoli Workload Scheduler for z/OS selects the waiting operation with the earliest latest-start time. Tivoli Workload Scheduler for z/OS sets the status of this operation to E (ended in error) with error code OSEQ.

Specify READYONLY to select the ready operation with the earliest latest-start time. If no ready operation is found, the job or started task is not tracked by Tivoli Workload Scheduler for z/OS.

Specify ANY to select the operation with the earliest latest-start time, which is in either waiting or ready status. ANY is the default value.

TWSJOBNAME(EXTNAME|EXTNOCC|JOBNAME|OCCNAME)

Defines the criterion used to generate the job name in the Symphony file.

If you set OCCNAME, the job name in the Symphony file is made up according to either of the following formats:

X_Num_ApplicationName: When the job is created.
X_Num_Ext_ApplicationName: When the job is deleted and re-created in the current plan.

where:

X

Can be one of the following values:

J, for normal operations
P, for jobs representing pending predecessors
R, for recovery jobs

Num

The operation number.

Ext

A sequential decimal number that is increased every time an operation is deleted and re-created

ApplicationName

The name of the occurrence to which the operation belongs.

If you set EXTNAME, EXTNOCC, or JOBNAME the job name in the Symphony file is made up according to either of the following formats:

X_Num_JobInfo: When the job is created.
X_Num_Ext_JobInfo: When the job is deleted and re-created in the current plan.

where:

X

Can be one of the following values:

J, for normal operations
P, for jobs representing pending predecessors
R, for recovery jobs

For jobs representing pending predecessors, the job name is in all cases generated by using the OCCNAME criterion. This is because, in the case of pending predecessors, the current plan does not contain the required information (excepting the name of the occurrence) to build the Symphony name according to the other criteria.

Num

The operation number.

Ext

The hexadecimal value of a sequential number that is increased every time an operation is deleted and re-created

JobInfo

Depends on the chosen criterion:

For EXTNAME: JobInfo is filled with the first 32 characters of the extended job name associated to that job (if it exists) or with the 8-character job name (if the extended name does not exist). Note that the extended job name, in addition to being defined in the database, must also exist in the current plan.
For EXTNOCC: JobInfo is filled with the first 32 characters of the extended job name associated to that job (if it exists) or with the application name (if the extended name does not exist). Note that the extended job name, in addition to being defined in the database, must also exist in the current plan.
For JOBNAME: JobInfo is filled with the 8-character job name.

The criterion used to generate a Tivoli Workload Scheduler job name will be maintained throughout the entire life of the job.

In order to choose the EXTNAME, EXTNOCC or JOBNAME criterion, the EQQTWSOU data set must have a record length of 160 bytes. Before using any of the above keywords, you MUST migrate the EQQTWSOU data set. Sample EQQMTWSO is available to migrate this data set from 120 to 160 bytes.

Limitations when using the EXTNAME and EXTNOCC criteria:

The job name in the symphony file can contain only alphanumeric characters, dashes and underscores. All the other characters accepted for the extended job name are converted into dashes. Note that a similar limitation applies also with JOBNAME: when defining members of partitioned data sets (such as the script or the job libraries), national characters can be used, but they are converted into dashes in the symphony file.
The job name in the symphony file must be in uppercase. All lowercase characters in the extended name are automatically converted to uppercase by Tivoli Workload Scheduler for z/OS®.

Note:

Using the job name (or the extended name as part of the job name) in the symphony file implies that it becomes a key for identifying the job. This means also that the extended name/jobname is used as a key for addressing all the events directed to the agents. For this reason, be aware of the following facts for the operations included in the symphony file:

Editing the Extended Name is inhibited for operations created when the TWSJOBNAME keyword was set to EXTNAME or EXTNOCC
Editing the Jobname is inhibited for operations created when the TWSJOBNAME keyword was set to EXTNAME or JOBNAME.

UX001FAILACTION(R)

This keyword is specified when the EQQUX001 exit is involved.

If EQQUX001 is called and returns an error code different from 0000, operations remain in ready list with extended status E. The only value of UX001FAILACTION is R. The UX001FAILACTION and SUBFAILACTION(XR/XE) keywords are exclusive.

WSFAILURE(ERROR|RESTART|LEAVE, REROUTE|LEAVE, IMMED|MANUAL)

Defines the actions to be taken when a workstation failure occurs. A workstation is set to failed status either when there is no communication with the z/OS system or if it is set manually in the Tivoli Workload Scheduler for z/OS dialogs. Workstations that specify a user-defined destination ID can have failed status reported by the WSSTAT command, or EQQUSIN or EQQUSINW subroutine.

The WSFAILURE parameter contains three keyword values:

The first keyword value defines the restart actions to be taken when a workstation fails and the started operation is restartable. Specify ERROR to set started operations to ended-in-error status. The error code will be OSSI, OSSQ, OSSS, or OSSC. Operations whose error code is OSSS have a stepcode of OSYS. Specify RESTART to immediately reset the started operations at this workstation to ready. Specify LEAVE to leave started operations on a failed workstation in started status; this is the default value.
Notes:
1. If you set the restartable option of an operation to NO, the operation is not processed. It remains in the started status.
2. Consider this note if you use a standby controller, running with the TAKEOVER(HOSTFAIL) parameter in the XCFOPTS statement. If you selected the WSFAILURE(RESTART,REROUTE,IMMED) options and the controller abnormally ends or is cancelled, while the LPAR that the controller is running on remains active, jobs might be submitted again even though they are currently running, resulting in the same job being run twice.
3. |For remote engine workstations, this keyword supports |only the value LEAVE. If you specify any other value, it is forced |to LEAVE.
The second keyword value defines reroute actions for workstation failure situations. Specify REROUTE to route operations, whose reroutable option is YES, to the alternate workstation. Specify LEAVE to leave operations to be scheduled on the original workstation; this is the default value. Rerouting does not occur for these operations.
|For |remote engine workstations, this keyword supports only the value LEAVE. |If you specify any other value, it is forced to LEAVE.
The third keyword value defines the action to be taken when a workstation becomes active again after a failure situation. Specify IMMED to automatically set the status of the workstation to available and withdraw any rerouting immediately when an event indicates that the workstation is operational. Specify MANUAL to indicate that the status of the workstation should be changed manually when a workstation available indication is received; this is the default value. IBM Tivoli Workload Scheduler for z/OS will issue an MLOG message to inform the operator that the event has been received.

WSOFFLINE(ERROR|RESTART|LEAVE, REROUTE|LEAVE, MANUAL|IMMED)

Defines the actions to be taken when a workstation offline situation occurs, meaning that the controller cannot communicate with the tracker at the destination defined for the workstation. This might occur because the tracker has not been started yet or has ended abnormally, or because the controller has not received an ID event from the destination for two consecutive pulse intervals. Pulse intervals are specified by the PULSE keyword of ROUTOPTS.

Workstations that specify a user-defined destination ID are set to offline status when Tivoli Workload Scheduler for z/OS is started. Offline status for these workstations can also be reported by the WSSTAT command or the EQQUSIN or EQQUSINW subroutine.

The WSOFFLINE parameter contains three keyword values:

The first keyword value defines restart actions for a workstation whose status has been changed to offline. Specify ERROR to set started operations, whose restartable option is YES, to ended-in-error status. The error code will be OFSI, OFSQ, OFSS, or OFSC. Operations whose error code is OFSS, have a stepcode of OFFL. Specify RESTART to immediately reset the started operations at this workstation to ready. Specify LEAVE to leave started operations at an offline workstation in started status; this is the default value.
Notes:
1. If you set the restartable option of an operation to NO, the operation is not processed. It remains in the started status.
2. Consider this note if you use a standby controller, running with the TAKEOVER(HOSTFAIL) parameter in the XCFOPTS statement. If you selected the WSOFFLINE(RESTART,REROUTE,IMMED) options and the controller abnormally ends or is cancelled, while the LPAR that the controller is running on remains active, jobs might be submitted again even though they are currently running, resulting in the same job being run twice.
3. |For remote engine workstations, this keyword supports |only the value LEAVE. If you specify any other value, it is forced |to LEAVE.
The second keyword value defines reroute actions for workstation offline situations. Specify REROUTE to route operations, whose reroutable option is YES, to the alternate workstation. Specify LEAVE to leave operations to be scheduled on the original workstation; this is the default value. Rerouting does not occur for these operations.
|For |remote engine workstations, this keyword supports only the value LEAVE. |If you specify any other value, it is forced to LEAVE.
The third keyword value defines the action to be taken when a workstation becomes active again. Specify MANUAL to indicate that the status of the workstation should be changed manually when a workstation available indication is received. Tivoli Workload Scheduler for z/OS will issue an MLOG message to inform the operator that the event has been received. Specify IMMED to automatically set the status of the workstation to available and withdraw any rerouting immediately when an event indicates that the workstation is operational; this is the default value.

Examples

  JTOPTS BACKUP(1000)                                1 
         ETT(YES)                                    2 
         HIGHRC(0)                                   3 
         JOBCHECK(SAME)                              4 
         NOERROR(U001,ABC123.*.*.0016,*.P1.S1.U*)    5 
         SHUTDOWNPOLICY(50)                          6 
         STATIM(25)                                  7 
         STATMSG(CPLOCK,EVENTS,WSTASK)               8 
         SUBFAILACTION(E)                            9 
         SUPPRESSACTION(C)                          10 
         SUPPRESSPOLICY(50)                         11 
         TRACK(JOBOPT)                              12 
         WSFAILURE(LEAVE,LEAVE,IMMED)               13 
         WSOFFLINE(LEAVE,LEAVE,IMMED)               14

In this example of a JTOPTS statement:

1

Whenever the number of records in the current plan data set reaches 1000, the data set is copied to the job-tracking log.

2

The event-triggered-tracking function is initially active when Tivoli Workload Scheduler for z/OS starts.

3

If the operation completion code is greater than 0, the job or started task is treated as having ended in error.

4

Tivoli Workload Scheduler for z/OS submits jobs only if they have a valid job card where the job name matches the operation name.

5

Any job or started task with user abend code U001 is not considered to be in error. Operation ABC123 is not considered to be in error if it has error code 0016. Any user abend code for any job or started task in procedure step P1, step S1, is not considered an error.

6

An operation is started if the time remaining in the workstation-open interval is not less than 50% of the estimated duration of the operation.

7

The statistics message will be issued approximately every 25 minutes.

8

The event-manager subtask issues messages showing:

How often different tasks have referenced the current plan data set
Which tasks have updated the current plan
How many events have been processed
Statistics collected by the WSA task

9

Tivoli Workload Scheduler for z/OS sets an operation to ended-in-error if a failure occurs during the submission of a job or the starting of a started task.

10

If a time-dependent operation becomes late (after the SUPPRESSPOLICY buffer has expired) and the suppress-if-late option is set to Y for this operation, the operation will be set to complete.

11

In the example, a time-dependent operation with the suppress-if-late option is started if the time remaining until its deadline is not less than 50% of the estimated duration of the operation.

12

Tivoli Workload Scheduler for z/OS tracks jobs only if the mode of submission matches the JOB SUBMIT option in the application description.

13

If the status of a workstation is changed to FAILED, started operations at the workstation are left in the started status. Ready operations are not rerouted to an alternate workstation. They will be scheduled on the original workstation when it becomes active again. When the workstation becomes active again, it is immediately made available.

14

If the status of a workstation is changed to OFFLINE, started operations at the workstation are left in the started status. Ready operations are not rerouted to an alternate workstation. They will be scheduled on the original workstation when it becomes active again. When the workstation becomes active again, it is immediately made available.