JTOPTS

Purpose

The JTOPTS statement defines how operations behave at workstations and how they are submitted and tracked. This statement is used by a primary, backup, 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


1  JTOPTS?  ALEACTION (
2.1! 100
2.1 alert action limit
1 ,
2.1! 000
2.1 
2.1 nnn
1 )?  BACKUP (
2.1! 400
2.1 backup frequency
2.1 NO
1 )?  CONDSUB (
2.1! NO
2.1 YES
1 )?  CRITJOBS (
2.1! YES
2.1 NO
1 )?  CURRPLAN (
2.1! CURRENT
2.1 NEW
1 )?  DLIMFDBK (
2.1! 100
2.1 limit for deadline feedback
1 )?  DSMOOTHING (
2.1! 50
2.1 deadline smoothing factor
1 )?  DUAL (
2.1! NO
2.1 YES
1 )?  ERRRES (
2.1+ ,
2.1 error code
1 )?  ETT (
2.1! NO
2.1 YES
1 )?  ETTGENSEARCH (
2.1! YES
2.1 NO
1 ,
2.1 JOBONLY
2.1 SRONLY
1 )?  ETTNEWDEP (
2.1 YES
2.1! NO
1 )?  EVELIM (
2.1! 0
2.1 nnnn
1 )?  FIRSTFDBK (
2.1! NO
2.1 YES
1 )?  HIGHRC (
2.1! 4
2.1 highest no-error return code
1 )?  HOSTJSUB (
2.1! YES
2.1 NO
1 )

1?  ITOM (
2.1 YES
2.1! NO
1 )?  JOBCHECK (
2.1! YES
2.1 NO
2.1 SAME
1 )?  HIGHRC (
2.1! 4
2.1 highest no-error return code
1 )?  HOSTJSUB (
2.1! YES
2.1 NO
1 )?  ITOM (
2.1 YES
2.1! NO
1 )?  JOBCHECK (
2.1! YES
2.1 NO
2.1 SAME
1 )?  JOBSUBMIT (
2.1! YES
2.1 NO
1 )?  JTAPPLCNT (
2.1! 100000
2.1 no. of JT events
1 )?  JTAPPLMCP (
2.1! 18000
2.1 hundredths of seconds
1 )?  JTLOGS (
2.1! 5
2.1 nn
1 )?  LARGEUSERBUFFER (
2.1! YES
2.1 NO
1 )?  LIMFDBK (
2.1! 100
2.1 limit for duration feedback
1 )?  MAXJSFILE (
2.1! 0
2.1 maximum size of JS data set
2.1 NO
1 )?  MAXOCCNUM (
2.1! 32767
2.1 nnnnnnn
1 )?  MAXSTNUM (
2.1! 1000
2.1 nnnn
1 )?  MAXSTWAIT (
2.1! 10
2.1 nn
1 )?  MCPDATASPACE (
2.1! NO
2.1 YES
1 )?  NEWOILIMIT (
2.1! 30
2.1 days operator instructions are new
1 )

1?  NOERROR (
2.1+ ,
2.1 err code entry
1 )?  NOPWAIT (
2.1! NO
2.1 YES
1 )?  NOTSTARTCOMP (
2.1! NO
2.1 YES
1 )?  OFFDELAY (
2.1! 1
2.1 delay time
1 )?  OPIADEP (
2.1! YES
2.1 TIME
2.1 NO
1 )?  OPINFOSCOPE (
2.1! IP
2.1 ALL
1 )?  OPREROUTEDEFAULT (
2.1! Y
2.1 N
1 )?  OPRESTARTDEFAULT (
2.1! Y
2.1 N
1 )?  OPSUMWS (
2.1! Y
2.1 N
1 )?  OUTPUTNODE (
2.1! FINAL
2.1 ANY
1 )?  OVERCOMMIT (
2.1! 0
2.1 nnnn
1 )?  PLANSTART (
2.1! 6
2.1 planning period start
1 )?  PRTCOMPLETE (
2.1! YES
2.1 NO
1 )?  QUEUELEN (
2.1! 5
2.1 queue length
1 )?  RECCPCOMPL (
2.1! YES
2.1 NO
1 )?  RISKCONFIDENCE (
2.1 1 - 99
1 )?  SAVEJSUB (
2.1! NO
2.1 YES
1 )?  SHUTDOWNPOLICY (
2.1! 0
2.1 nnn
1 )?  SMOOTHCRITNET (
2.1! NO
2.1 YES
1 )?  SMOOTHING (
2.1! 50
2.1 smooth. factor
1 )?  SMOOTHSUBMISSION (
2.1 YES
2.1! NO
1 )?  SMOOTHSUBRATE (
2.1! 0
2.1 average num of operations to submit
1 )

1?  STATMSG (
2.1+ ,
2.1 CPLOCK
2.1 EVENTS
2.1 WSATASK
2.1 GENSERV
1 )?  STATIM (
2.1! 0
2.1 nn
1 )?  STEPINFO (
2.1! NO
2.1 YES
1 )?  SUBFAILACTION (
2.1! R
2.1 C
2.1 E
2.1 RH
2.1 XC
2.1 XE
2.1 XR
1 )?  TRKPLS (
2.1 minutes
2.1! 10
1 )?  VARSUB (
2.1! SCAN
2.1 YES
2.1 NO
1 )?  VARFAIL (
2.1 & % ?
1 )?  VARPROC (
2.1! NO
2.1 YES
1 )?  WAITREL (
2.1! 0
2.1 waiting time 
1 )?  NOERROR (
2.1+ ,
2.1 error code entry
1 )?  NOPWAIT (
2.1! NO
2.1 YES
1 )?  NOTSTARTCOMP (
2.1! NO
2.1 YES
1 )?  OFFDELAY (
2.1! 1
2.1 delay time
1 )?  OPIADEP (
2.1! YES
2.1 TIME
2.1 NO
1 )?  OPINFOSCOPE (
2.1! IP
2.1 ALL
1 )?  OPREROUTEDEFAULT (
2.1! Y
2.1 N
1 )?  OPRESTARTDEFAULT (
2.1! Y
2.1 N
1 )

1?  SUPPRESSACTION (
2.1! R
2.1 C
2.1 E
1 )?  SUPPRESSPOLICY (
2.1! 0
2.1 nnn
1 )?  TRACK (
2.1! ALL
2.1 OPCASUB
2.1 JOBOPT
1 ,
2.1! ANY
2.1 READYFIRST
2.1 READYONLY
1 )?  USINRC (
2.1! NO
2.1 YES
1 )?  UX001FAILACTION (
2.1! R
1 )?  WSCLASS (
2.1+ ,
2.1 wsname
1 )?  WSSYSAFF (
2.1+ ,
2.2.1 wsname:
2.2.1+ ,
2.2.1 system.destination
1 )?  WSFAILURE ( 
2.1! LEAVE
2.1 ERROR
2.1 RESTART
1 ,
2.1! LEAVE
2.1 REROUTE
1 ,
2.1! MANUAL
2.1 IMMED )?  WSOFFLINE ( 
2.1! LEAVE
2.1 ERROR
2.1 RESTART
1 ,
2.1! LEAVE
2.1 REROUTE
1 ,
2.1! IMMED
2.1 MANUAL )?  ZCENJSUB (
2.1! YES
2.1 NO
1 )?  ZCHIGHRC (
2.1! YES
2.1 NO
2.1 DEF (HIGHEST NO ERROR RC)
1 )

Parameters

ALEACTION (alert action limit 100,nnn 000)
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 parameter 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 possible after detecting that the operation is active longer than its estimated duration (a delay might occur for several reasons, for example heavy workload, Workstation Analyzer tasks, Event Manager tasks, or locking conditions).

A second parameter is available. The value ranges from 000 to 999, and it represents a lower boundary time expressed in seconds, below which the Long Duration messages (EQQE028I and EQQE038I) are not logged even if the long duration policy defined by the aleaction value is matched. For example, assuming that ALEACTION (500,060), and that the planned duration for job is equal to 10 seconds, because of the ALEACTION settings, that job is considered to have a long duration when its actual duration becomes at least 50 seconds long. Because of the second option, the Long Duration message is issued only if the actual duration exceeds 60 seconds.
Note: Both values of this parameter must be always specified in 3-digit form.
BACKUP (NO|backup frequency|400)
HCL Workload Automation for Z uses a primary and alternate data set for the current plan. HCL Workload Automation for Z 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 for the BACKUP parameter defines if the current plan should be automatically copied, and determines how frequently the automatic copy process occurs.

Specify a backup frequency if you want HCL Workload Automation for Z to perform the copy process automatically. The backup frequency value defines how many records are to be written to the job-tracking log before a copy process is performed. HCL Workload Automation for Z 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 HCL Workload Automation for Z 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 HCL Workload Automation for Z performs a copy process by using the BACKUP TSO command or the EQQUSIN or EQQUSINB subroutine, regardless of the value specified in the BACKUP parameter. For more information about the EQQUSIN and EQQUSINB subroutines, see Reporting events to HCL Workload Automation for Z.

If the copy process is performed automatically and you issue a BACKUP request, HCL Workload Automation for Z 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 HCL Workload Automation for Z system data sets. These copies occur regardless of the value specified for BACKUP.

CONDSUB (YES|NO)
Specify YES if conditional 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(NO) 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(NO) 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:
  1. Scrap the EQQJTABL log data set, if it is not empty.
  2. Restart the controller with CRITJOBS(YES).
  3. Submit a replan job to re-synchronize the critical job table with the current plan.
CURRPLAN (NEW|CURRENT)
This parameter defines from which current-plan data set HCL Workload Automation for Z starts. The default is that HCL Workload Automation for Z uses 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 HCL Workload Automation for Z is started for the first time after migration, HCL Workload Automation for Z 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 is done automatically if you have created a new plan while HCL Workload Automation for Z was inactive.

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

DLIMFDBK (limit for deadline feedback|100)
The limit for deadline feedback. This parameter 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 value 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 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 HCL Workload Automation for Z should perform dual logging of the job-tracking-log data sets (EQQJTnn). When it is started, HCL Workload Automation for Z opens 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 HCL Workload Automation for Z 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 HCL Workload Automation for Z-defined code
Note:
  1. HCL Workload Automation for Z 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'.
  2. The OSEQ error code is a special case and cannot be reset by ERRRES.
  3. 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.
  4. The ERRRES parameter applies also to operations that are run on z-centric agent workstations.
  5. The only valid error codes are those listed in the appendix of Managing the Workload.

For example, a user submits a job outside of HCL Workload Automation for Z for which an operation exists in the current plan. The job abends with code S806, which is specified in the ERRRES list. HCL Workload Automation for Z sets the operation to status A. If the user then resubmits the job after correcting the error, HCL Workload Automation for Z 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 is not resubmitted by HCL Workload Automation for Z even if SUBMIT=Y is specified for the operation. Therefore, if an operation that is normally submitted by HCL Workload Automation for Z is reset, manually change the status to R (ready) using the MCP dialog, or through PIF, if you want HCL Workload Automation for Z to submit the job again.

If you stop and restart HCL Workload Automation for Z, 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 HCL Workload Automation for Z is started. Specify NO if the ETT function should not be initially active. Note that you can activate or deactivate ETT while HCL Workload Automation for Z is running, using the Service Functions dialog.
ETTGENSEARCH (NO|YES, JOBONLY|SRONLY)
The ETTGENSEARCH contains two values:
  • The first value can be YES (default) or NO. Specify YES if the event-triggered-tracking function must search the SI file first for an exact match or for the best match hereafter. This is because the percent sign (%) or asterisk (*) can be used in the ETT criteria definition. Specify NO if the event-triggered-tracking function must search the SI file only for an exact match. Use this value when the SI file does not contain ETT criteria using the percent sign (%) or asterisk (*).
  • The second value is ignored if you specify NO as first keyword value. It defines whether the best generic match has to be applied only to the special resources events or only to the jobs events:
    JOBONLY
    The best generic match has to be applied only to job events.
    SRONLY
    The best generic match has to be applied only to special resource events.
    If the first value is YES and the second value is not specified, the best generic match is applied to both job events and special resource events.
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. ID does not apply to the resolution of mandatory successors (because the successor intervals are created before the predecessor occurrence is added).

Specify YES to have the scheduler use 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 to have the scheduler use 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 parameter defines how often statistic messages related to the STATMSG parameter 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 procname,EVELIM=nnnn.

FIRSTFDBK (YES|NO)

First feedback for duration. If you specify YES, every new job that you define in the AD database is updated with the actual duration at its first run, regardless of the estimated values. At the next run, the duration is updated according to the values that you set for LIMFDBK and SMOOTHING.

HIGHRC (highest no-error return code|4)
Defines the highest error code that can be generated in an HCL Workload Automation for Z job or started task without causing HCL Workload Automation for Z to process the operation as having ended in error.
Note: 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.
HOSTJSUB (NO|YES)
Specify YES if HCL Workload Automation for Z should submit jobs, start started tasks, and issue write-to-operator messages for WTO operations. Specify NO if HCL Workload Automation for Z should not perform these functions automatically. This parameter is incompatible with JOBSUBMIT.

The job-submit option can be changed through the Service Functions dialog while HCL Workload Automation for Z is running.

ITOM (YES|NO)
YES specifies that IBM Tivoli Output Manager and HCL Workload Automation for Z are integrated so that the job logs of operations run by HCL Workload Automation for Z can be viewed and managed with Tivoli Output Manager.
With this configuration setup, HCL Workload Automation for Z inserts a particular string in the log of every operation. The string contains a ><TWS OCCURRENCE heading followed by this information:
  • ID of the application
  • Number of the operation
  • Input arrival date and time
For example: 
//TWSEF020 JOB ACCT,TWS,CLASS=A,MSGCLASS=Q
//*><TWS OCCURRENCE-->DEVAPP 020 1311050201
This string is then located by Tivoli Output Manager, trimmed of the heading, and used as Output Manager archive name.

The integration must be configured also on Tivoli Output Manager. For details about how to enable HCL Workload Automation for Z to integrate with Tivoli Output Manager, see HCL Workload Automation for Z Managing the Workload.

JOBCHECK (NO|SAME|YES)
The JOBCHECK keyword specifies if and how HCL Workload Automation for Z checks the job card before submitting the job.
JOBCHECK(YES) means that HCL Workload Automation for Z checks the job card only for validity. If the job card is not valid, the job is not submitted. HCL Workload Automation for Z 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 HCL Workload Automation for Z operation, a warning message is written to the HCL Workload Automation for Z message log.

JOBCHECK(NO) means that the job card is not checked at all. HCL Workload Automation for Z submits the job without checking the job card.

Note: JOBCHECK(YES) and JOBCHECK(NO) allow HCL Workload Automation for Z to submit a job with a job name that does not match the job name in the current operation. This implies that HCL Workload Automation for Z is 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 HCL Workload Automation for Z operation. The job is submitted only if it has a valid job card with the job name matching that in the current operation.

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 HCL Workload Automation for Z should submit the jobs running on host, z-centric, dynamic, and remote engine workstations. Specify NO if HCL Workload Automation for Z should not automatically submit the jobs running on host, z-centric, dynamic, and remote engine workstations. This parameter is incompatible with HOSTJSUB and ZCENJSUB.

The job-submit option can be changed through the Service Functions dialog while HCL Workload Automation for Z is running.

JTAPPLCNT(number of JT events|100000)
How many JT events must be logged before HCL Workload Automation for Z issues message EQQN228I. The message is issued only only when re-applying the events.

The default is 100 000, the maximum value allowed is 9 999 999. A value of 0 is replaced with the default value.

JTAPPLMCP(hundredths of seconds|18000)
How much time (expressed in hundredths of seconds) must have been spent in executing MCP actions before HCL Workload Automation for Z issues message EQQN228I. The message is issued only when re-applying the events.

The default is 18 000 (3 minutes), the maximum value allowed is 9 999 999. A value of 0 is replaced with the default value.

JTLOGS(number of JT logs|5)
Specifies the number of auditing logs that HCL Workload Automation for Z must open when it is started. The number must be a value in the range from 2 to 99, the default value is 5.

The job-tracking log data sets are identified by the EQQJTnn ddname in the controller JCL procedure. If you use the extended auditing feature (by setting AMOUNT(EXTENDED) in the AUDIT statement), the extended auditing log data sets are identified by the EQQDBnn ddname in the controller JCL procedure.

HCL Workload Automation for Z attempts to open data sets starting with EQQJT01 or EQQDB01 and continue for the number specified in the JTLOGS keyword. For example, if you specify a value of 3 for JTLOGS, HCL Workload Automation for Z attempts to open logs EQQxx01, EQQxx02, and EQQxx03, where xx can be JT or DB.

LARGEUSERBUFFER(NO|YES)
The default value (YES) allocates memory buffers sized to 64KB in the common storage area (CSA) to improve the communication rate with the HCL Workload Automation for Z engine from all user interfaces (ISPF, DWC, or PIF). This improves performances when running sizeable queries on the plan, but be aware that 64KB are allocated for every connected user, and you must weight the impact of this on your environment (for example, 300 concurrent users consume 19MB of CSA).

Specify NO if you want to keep 32KB as the size of the allocated memory buffers. This is the size used by default until Version 8.6 SPEs.

LIMFDBK(limit for duration feedback|100)
Limit for duration feedback. This parameter is ignored for shadow jobs.

HCL Workload Automation for Z job tracking automatically monitors actual durations. These can be used to modify estimated operation durations in the application description database. HCL Workload Automation for Z 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 in the list of JTOPTS Parameters.

Limit for feedback examples shows examples of how the limit-for-feedback algorithm works.
Table 1. Limit for feedback examples
LF value Result
100 No new estimated duration are stored in the application-description database.
110 The new estimated duration is stored if the actual duration is approximately between 90% and 110% of the old estimated duration.
200 The new estimated duration is stored if the actual duration is between half and double the old estimated duration.
500 The new estimated duration is stored if the actual duration is between one-fifth and five times the old estimated duration.
999 The new estimated duration is stored if the actual duration is between one-tenth and 10 times the old estimated duration.
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)
HCL Workload Automation for Z uses a primary and alternate data set for the JCL repository. HCL Workload Automation for Z 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 HCL Workload Automation for Z 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 values produce 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, HCL Workload Automation for Z performs 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, HCL Workload Automation for Z 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 HCL Workload Automation for Z 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 HCL Workload Automation for Z 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 HCL Workload Automation for Z.

MAXOCCNUM(nnnnnnn|32767)
HCL Workload Automation for Z 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. Doubling the default value of MAXOCCNUM, setting it to 65534, should not cause any noticeable performance problems; however any change to values greater than this number must be done gradually. HCL Workload Automation for Z can start with a current plan exceeding the limit and also take over a plan exceeding the limit from daily planning.
MAXSTNUM(nnnn|1000)
Sets the number of jobs on a workstation for which a message EQQE039I is issued: when this number is reached, a summary message EQQE207I is issued. The valid range is 1 - 9999, the default is 1000.
MAXSTWAIT(nn|10)
The interval of time, in minutes, after which if a job that was started by the Z controller is not run, message EQQE039I is issued. The valid range is 1 - 90 minutes, the default is 10.
MCPDATASPACE(YES|NO)
Specify YES for the Modify Current Plan to load portions of the in-storage operations and occurrences into the data space, when performing MCP actions.

Setting this parameter to YES is particularly helpful when you modify operations and occurrences belonging to big networks, because it optimizes the use of storage. If the current plan was generated with BATCHOPT CPDATASPACE(YES), this parameter must also be set to YES.

With a current plan that includes more than one million operations, you must also allocate the following CP data sets as extended VSAM:
  • EQQACPDS
  • EQQCP1DS
  • EQQCP2DS
  • EQQNCPDS
  • EQQSCPDS
For more details, see Managing a current plan with more than one million operations.
NEWOILIMIT(days operator instructions are new|30)
Defines the number of days that HCL Workload Automation for Z 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, see the list of NOERROR Parameters.
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.
NOPWAIT (YES|NO)
Specify YES if an operation that you are NOPing will be actually NOPed after that time dependencies and special resources, if any, are resolved. The default is NO, meaning that the operation is NOPed immediately.
OFFDELAY(delay time|1)
The OFFDELAY parameter defines, in minutes, the time that HCL Workload Automation for Z delays actions that are 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 HCL Workload Automation for Z 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 HCL Workload Automation for Z 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 is set to OFFLINE status.
Note:
  1. 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 HCL Workload Automation for Z is started.
  2. If you have not installed APAR PH23439 and you set this parameter to 0, the default value 1 is assumed.

    If you have installed APAR PH23439 and you set this parameter to 0, the value is considered valid and HCL Workload Automation for Z does not delay the WSOFFLINE actions when a workstation changes status to offline.

NOTSTARTCOMP(YES|NO)
An alert is issued or an action is taken according to the value you set in the following fields at operation level:
Not started alert
If an operation has not started when the start day and time are reached, an alert message is issued in the EQQMLOG and system log.
Not started action
If an operation has not started when the start day and time are reached, an action is taken.
Deadline action
If an operation is still not completed when the deadline day and time are reached, an action is taken.
For details about how these fields are specified in the ISPF panels, see Specifying times, actions, and alerts for operations.
OPIADEP(YES|TIME1NO)
How HCL Workload Automation for Z uses the operation IA date and time to determine the predecessors:
YES
Operation IA is used to determine the matching predecessor. This is the default.
TIME
If the operation is time-dependent, the operation IA is not used to determine the matching predecessor; the occurrence IA is used instead.
NO
Operation IA is not used to determine the matching predecessor.

When you modify the OPIADEP value, to see the updated date for the dependencies resolution it is required that you run a long-term plan MODIFY ALL.

OPINFOSCOPE(ALL|IP)
Defines how HCL Workload Automation for Z 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 HCL Workload Automation for Z 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, HCL Workload Automation for Z chooses the operation by investigating these characteristics in the stated order:
  1. The operation has priority 9.
  2. Earliest latest start time.
  3. Priority 8-1.
  4. Input arrival time specified for the operation or the occurrence input arrival if the operation does not have input arrival specifically defined.
  5. Longest in Ready status.
Specify ALL if HCL Workload Automation for Z 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.
Note: After installing APARs PI79321 and PI80105, the OPSUMWS parameter will be no longer valid.
OUTPUTNODE(ANY|FINAL)
Defines whether HCL Workload Automation for Z 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 HCL Workload Automation for Z, 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 HCL Workload Automation for Z should set print operations to complete when a batch job is purged from the JES spool. Specify NO if HCL Workload Automation for Z 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 procname,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.

RISKCONFIDENCE(1-99)
The value of this keyword influences the trigger that sets the high risk level for a critical job.

When the confidence value of a critical job is lower than the RISKCONFIDENCE value, the critical path handler task sets the critical job to a high risk level and notifies it to the controller EQQMLOG. If this keyword is not specified, the critical path handler task sets the critical job to a high risk level when its estimated end time becomes later than the deadline.

Setting RISKCONFIDENCE to 50 generates the closest behavior to the versions earlier than V9.3, that is a high risk level is set when the estimated end time becomes later than the deadline.

SAVEJSUB (YES|NO)
Specify YES if, at controller startup, HCL Workload Automation for Z should use the latest values that were set for job submission (FTWJSUB, HOSTJSUB, and ZCENJSUB parameters). Default value is NO.
Note: The value you set for SAVEJSUB applies also to the setting for JOBSUBMIT, if any.
SHUTDOWNPOLICY(nnn|0)
The SHUTDOWNPOLICY value is a percentage in the range 0 to 999. It lets you specify whether HCL Workload Automation for Z 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, HCL Workload Automation for Z does 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.

The SHUTDOWNPOLICY value is also applied to the destinations specified with the WSSYSAFF(wsname:system.destination) parameter, to filter the list of systems by deleting those whose destinations do not pass the SHUTDOWNPOLICY check. As a consequence, the deleted systems are not added to the SYSAFF parameter of the job card. An additional check on the execution destinations is performed by using the workstation-open interval, if any, of the workstation (wsname). If the destination does not exist in the workstation definition, therefore no workstation-open interval is applicable, the SHUTDOWNPOLICY check is not performed and the system is added to the SYSAFF parameter of the job card.

If, after performing the SHUTDOWNPOLICY check, the list of execution systems results empty, the job execution is forced on the submission system. This means that the following SYSAFF parameter is added to the job card: 

 SYSAFF=*
SMOOTHCRITNET(NO|YES)
Set this parameter to YES to prioritize the submission of the operations belonging to the whole critical network. This setting is effective provided that SMOOTHSUBMISSION is set to YES. The default value is NO.
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 in the list of JTOPTS Parameters). This parameter is ignored for shadow jobs.
Note: When the controller has the Dynamic Critical Path feature active, any SMOOTHING value that is greater than 100 is internally managed as if the smoothing factor default value was set (50). For example, if the smoothing factor is set to 200 and the Dynamic Critical Path is active, the affected durations will be updated by applying the SMOOTHING default value 50.
HCL Workload Automation for Z 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.

Smoothing factor examples provides examples of how the smoothing factor algorithm works.

Table 2. Smoothing factor examples
Factor Result
0 There is no feedback.
10 The new estimated duration is the old estimated duration, plus one-tenth the difference between the actual and old estimated duration.
50 The new estimated duration is 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 is the old estimated duration, plus 10 times the difference between the actual and old estimated duration.
SMOOTHSUBMISSION(YES|NO)
Activates the Smooth Submission feature. By setting this parameter to YES, the submission of operations that are urgent (with priority 9) or belong to a critical path is prioritized. Moreover, if you set the SMOOTHSUBCONFLEVEL and SMOOTHSUBDELAY parameters in the BATCHOPT statement of the last DP batch run, the controller adds a random delay in submitting not urgent and not critical operations. The default is No.

For more detailed information, see Optimizing the workload through a smooth submission of the operations.

SMOOTHSUBRATE(average num of operations to submit|0)
The average number of operations to be submitted, in 1 minute, on computer automatic workstations, with the exception of the operations that are urgent (with priority 9).
To prioritize also the operations belonging to a critical path (that is, the submission rate is not applied to them), set SMOOTHSUBMISSION(YES). In this way, the following operations will also be excluded from the submission rate restrictions:
  • Operations belonging to a critical path.
  • Operations eligible for WLM assistance.

Valid range is from 1 to 99999. The default value is 0, meaning that this parameter is not set.

STATMSG(option list)
Defines the status message types that HCL Workload Automation for Z 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 procname,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 procname,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. HCL Workload Automation for Z 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 procname,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 procname,STATIM=nn.
STEPINFO(YES|NO)

If you specify YES, the primary controller stores the list of step events that was generated and sent by the tracker, enabling you to browse the information. STEPINFO(YES) is meaningful only if you set EWTROPTS STEPINFO(YES) on the tracker.

If you specify NO the list of step events is only logged on the primary controller, which, if a backup controller is configured, sends it to the backup controller, where the data is stored.

Set STEPINFO(YES) on the backup controller to ensure that when the backup controller takes over from the primary controller, you can browse the list of steps for all the jobs that are in plan.

SUBFAILACTION(C|E|R|RH|XC|XE|XR)
Defines what action HCL Workload Automation for Z 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 HCL Workload Automation for Z 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).
Note:
  1. HCL Workload Automation for Z considers the time buffer created by the SUPPRESSPOLICY keyword when deciding if a time-dependent operation is late.
Note:
SUPPRESSPOLICY(nnn|0)
Specifies how HCL Workload Automation for Z 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 HCL Workload Automation for Z does not try to start the operation if its input-arrival time has passed. If you specify a nonzero value, HCL Workload Automation for Z 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 is started. Otherwise, the operation is considered late and is not started by HCL Workload Automation for Z.

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 is 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 is 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 is taken.
TRACK(OPCASUB|JOBOPT|ALL, READYFIRST|READYONLY|ANY)
The TRACK parameter contains two keyword values:
  • The first value specifies which jobs or started tasks HCL Workload Automation for Z 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 HCL Workload Automation for Z. Such jobs are always tracked.

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

    Specify JOBOPT when some of your HCL Workload Automation for Z-planned jobs are submitted by HCL Workload Automation for Z and some are submitted outside of HCL Workload Automation for Z, but you always know in advance which are submitted by each method. You must ensure that:
    • Jobs submitted by HCL Workload Automation for Z have their SUBMIT option set to YES, and these jobs are not submitted outside of HCL Workload Automation for Z.
    • Jobs submitted outside of HCL Workload Automation for Z have their SUBMIT option set to NO.

    When you use JOBOPT, HCL Workload Automation for Z tracks jobs it submitted itself, and jobs that were submitted outside of HCL Workload Automation for Z but were defined with their SUBMIT option set to NO. JOBOPT causes HCL Workload Automation for Z 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 HCL Workload Automation for Z, the job is not tracked.

    Specify ALL when you do not know in advance if HCL Workload Automation for Z-planned jobs will be submitted by HCL Workload Automation for Z or outside of HCL Workload Automation for Z. All HCL Workload Automation for Z-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 HCL Workload Automation for Z selects the matching operation when a job or started task is submitted outside of HCL Workload Automation for Z. 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, HCL Workload Automation for Z selects the waiting operation with the earliest latest-start time. HCL Workload Automation for Z 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 HCL Workload Automation for Z.

    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.

USINRC(YES|NO)
Specify YES if you want that the ERROR_CODE field set by a status change program (for example, the EQQUSIN subroutine invoked by System Automation) is processed, even if the operation status was changed to C (Complete). The error code, when set, is used to evaluate any conditional dependency defined for the operation.

The default value is No, meaning that the ERROR_CODE field set by a status change program for a complete operation is always ignored.

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.

WSCLASS(wsname,...,wsname)
Use this parameter to force the class of the jobs submitted on the workstation identified by wsname. The value applied will be the class defined for the job in the current plan. Consider that if the job class in CP is set to blank, no class forcing is performed.

wsname identifies the name of the workstation where the job is submitted, included virtual workstations. Wildcard characters are not allowed.

WSSYSAFF(wsname:system.destination,...,wsname:system.destination)
Use this parameter to customize the SYSAFF keyword of the job card, so that a job submitted on wsname is forced to be executed on the system identified by system.destination, where:
wsname
Name of the workstation where the job is submitted, included virtual workstations. Started task workstations are not applicable.

The maximum length is 4 alphanumeric characters. Wildcard characters are not allowed.

system.destination
Name of the system within a SYSPLEX, followed by a period and the name of the destination, as specified in the workstation definition. The wildcard character asterisk (*) is allowed, meaning the local destination.

You can specify more than one couple system.destination for a single wsname, provided that those systems belong to the same SYSPLEX. Also, consider that a system can be associated with only one destination.

The system is inserted in the SYSAFF keyword of the job card only if the associated destination exists in the workstation definition and is available in terms of workstation-open intervals, parallel servers, workstation resources.
Note:
  1. If the destination does not exist in the workstation definition, therefore no availability checks can be performed, the system is anyway added to the SYSAFF keyword.
  2. If a SYSAFF parameter was already set in the job card, it is overwritten with this value.
  3. The SYSTEM parameter of the job card, if any, is deleted.

If no system pass the availability checks, the job will be forced to be executed on the system where it was submitted. This means that the SYSAFF keyword will be SYSAFF=*

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 HCL Workload Automation for Z 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.
    Note:
    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 dynamic and remote engine workstation types, this parameter supports only the value LEAVE. If you specify any other value, it is forced to LEAVE.
  • The second parameter 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.
  • The third parameter 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. HCL Workload Automation for Z issues an MLOG message to inform the operator that the event has been received.
WSOFFLINE(ERROR|RESTART|LEAVE, REROUTE|LEAVE, MANUAL|IMMED)

Defines the actions that are to be taken when a workstation offline situation occurs (unless the workstation is 'waiting for connection' at start and no previous offline situation occurred). This means 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 (having experienced a previous offline condition status) 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 parameter of ROUTOPTS.

Workstations that specify a user-defined destination ID are set to offline status when HCL Workload Automation for Z 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.
    Note:
    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 dynamic and remote engine workstation types, 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.
  • 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. HCL Workload Automation for Z issues 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.
ZCENJSUB (NO|YES)
Specify YES if HCL Workload Automation for Z should submit jobs running on z-centric, dynamic, and remote engine workstations. Specify NO if HCL Workload Automation for Z should not automatically submit jobs running on z-centric, dynamic, and remote engine workstations. This parameter is incompatible with JOBSUBMIT.

The job-submit option can be changed through the Service Functions dialog while HCL Workload Automation for Z is running.

ZCHIGHRC (NO|DEF (HIGHEST NO-ERROR RC)|YES)
The ZCHIGHRC keyword defines the highest error code that can be generated in an HCL Workload Automation for Z job that runs on z-centric or Dynamic Workstations without causing HCL Workload Automation for Z to set the operation in error. Negative return codes are not supported, in the same way as for HIGHRC keyword in the JTOPTS.
YES
Default value. All the jobs running on z-centric or dynamic workstations are handled the same way as z/OS® jobs, that is HCL Workload Automation for Z applies the value of the highest in JTOPTS to these non-z/OS® jobs unless a different value is specified at operation level.
NO
The HIGHRC feature is deactivated for jobs running on z-centric and dynamic workstations. Any nonzero return code is handled as an error condition, regardless of the value specified at operation level in the HIGHRC.
DEF (HIGHEST NO-ERROR RC)
The value specified is used as global HIGHRC for all the jobs running on z-centric and dynamic workstations, unless a different value is specified at operation level.
  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 HCL Workload Automation for Z starts.
3
If the operation completion code is greater than 0, the job or started task is treated as having ended in error.
4
HCL Workload Automation for Z 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
HCL Workload Automation for Z 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
HCL Workload Automation for Z 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.