BATCHOPT

Purpose

The BATCHOPT statement defines run-time options for Tivoli Workload Scheduler for z/OS batch jobs. BATCHOPT is defined in its own member of the EQQPARM library. The member is referenced by Tivoli Workload Scheduler for z/OS batch jobs at run time.

Format

>>-BATCHOPT--+-------------------------------+------------------>
             |           .-DEFAULT-------.   |
             '-CALENDAR(-+-calendar name-+-)-'
 
>--+------------------------+--+------------------------+------->
   |              .-NO--.   |  |              .-NO--.   |
   '-CHECKSUBSYS(-+-YES-+-)-'  '-CKPTREFRESH(-+-YES-+-)-'
 
>--+-----------------------------------------------------------------+-->
   |                  .-this subsystem-.                             |
   '-CONTROLLERTOKEN(-+-subsystem name-+-)-+-----------------------+-'
                                           |             .-NO--.   |
                                           '-CRITOPMSGS(-+-YES-+-)-'
 
>--+----------------------------------------+------------------->
   |           .-YY/MM/DD---------------.   |
   '-DATEFORM(-+-date format in reports-+-)-'
 
>--+--------------------------+--------------------------------->
   |           .-STOP-----.   |
   '-DB2AVAIL(-+-CONTINUE-+-)-'
 
>--+--------------------------------+--------------------------->
   '-DB2SYSTEM(---DB2 subsystem---)-'
 
>--+---------------------------------------+-------------------->
   |        .-2------------------------.   |
   '-DPALG(-+-daily planning algorithm-+-)-'
 
>--+----------------------------------------+------------------->
   |         .-SYSPRINT-----------------.   |
   '-DPROUT(-+-daily plan report ddname-+-)-'
 
>--+-----------------------+--+-----------------------+--------->
   |             .-YES-.   |  |             .-NO--.   |
   '-DYNAMICADD(-+-NO--+-)-'  '-DYNAMICDEL(-+-YES-+-)-'
 
>--+------------------------+----------------------------------->
   |         .-GLOBAL---.   |
   '-GTABLE(-+-table ID-+-)-'
 
>--+-----------------------------------------+------------------>
   |       .- ---------------------------.   |
   '-HDRS(-+-list of report header lines-+-)-'
 
>--+------------------------+----------------------------------->
   |              .-|NO--.   |
   '-|IGNOREDEADL|(-+-|YES-+-|)-'
 
>--+---------------------------------------+-------------------->
   |              .-NO--.   .-STOP-----.   |
   '-JRUNHISTORY(-+-YES-+-,-+-CONTINUE-+-)-'
 
>--+-------------------------+---------------------------------->
   |               .-|NO--.   |
   '-|KEEPCOMPDEPS|(-+-|YES-+-|)-'
 
>--+---------------------------------------+-------------------->
   |        .-01-----------------------.   |
   '-LOGID(-+-ID on track log data set-+-)-'
 
>--+----------------------+------------------------------------->
   |            .-YES-.   |
   '-LTPDEPRES(-+-NO--+-)-'
 
>--+--------------------------------------+--------------------->
   |                 .-5000-----------.   |
   '-MAXHISTORYROWS(-+-number of rows-+-)-'
 
>--+--------------------------+--+---------------------+-------->
   |            .-32767---.   |  |           .-YES-.   |
   '-MAXOCCNUM(-+-nnnnnnn-+-)-'  '-NCPTROUT(-+-NO--+-)-'
 
>--+---------------------+--+-------------------+--------------->
   |           .-NO--.   |  |           .-N-.   |
   '-OCPTROUT(-+-YES-+-)-'  '-OPERDALL(-+-Y-+-)-'
               '-CMP-'
 
>--+------------------------+--+-------------------+------------>
   |              .-NO--.   |  |           .-N-.   |
   '-OPERHISTORY(-+-YES-+-)-'  '-OPERIALL(-+-Y-+-)-'
 
>--+---------------------------------------+-------------------->
   |           .-55--------------------.   |
   '-PAGESIZE(-+-page size for reports-+-)-'
 
>--+---------------------------------------+-------------------->
   |           .-6---------------------.   |
   '-PLANHOUR(-+-planning period start-+-)-'
 
>--+----------------------------------------------------+------->
   '-PREDWS(---default predecessor workstation name---)-'
 
>--+--------------------+--+-------------------------+---------->
   |          .-YES-.   |  |              .-NO--.    |
   '-PREVRES(-+-NO--+-)-'  '-RCLEANUP--(--+-YES-+--)-'
 
>--+------------------------+----------------------------------->
   |             .-0----.   |
   '-RETAINOPER(-+-days-+-)-'
 
>--+------------------------------+----------------------------->
   |         .-OPCA-----------.   |
   '-SUBSYS(-+-subsystem name-+-)-'
 
>--+--------------------------------------------------+--------->
   '-SUCCWS(---default successor workstation name---)-'
 
>--+-----------------------+--+-----------------------------+--->
   |             .-|NO--.   |  |           .-TPLGPARM----.   |
   '-|TIMEDEPCHK|(-+-|YES-+-|)-'  '-TPLGYPRM(-+-member name-+-)-'
 
>--+-------------------------+---------------------------------><
   |             .-ABEND-.   |
   '-VALEACTION(-+-END---+-)-'
                 '-WARN--'

Parameters

CALENDAR(calendar name|DEFAULT)

Defines the Tivoli Workload Scheduler for z/OS default calendar. You can specify a name, from 1 to 16 characters, referencing a calendar in the calendar database.

The Tivoli Workload Scheduler for z/OS planning functions use this calendar:

During long-term plan batch processing to determine run days for an application if no calendar is specified in the application description.
When extending the current plan if the specified input parameters indicate that only work days should be considered in the extension period.
During long-term plan processing and Mass Update to validate that the EVERY options specified for an application run cycle is consistent with the application calendar work day end time.

If no default calendar is specified, or if the specified calendar does not exist in the calendar database, a calendar with the name DEFAULT is used as the default calendar. If no calendar with the name DEFAULT exists, all days are considered work days and the work day end time is set to 00.00.

If the specified calendar does not exist in the calendar database, Mass Update does not check for the EVERY options.

CHECKSUBSYS(YES|NO)

Controls whether the daily planning program should check that it can synchronize with the processing in the controller address space.

The synchronization is performed using ENQ locking with scope SYSTEMS. The synchronization can fail because:

The controller is not started.
The controller is not executing within the same GRS complex as the daily planning program.
The SUBSYS keyword does not identify the correct controller.

If NO is specified or defaulted, the last two cases will result in a corrupt status record in the checkpoint file, and the new current plan will not be taken over by the controller. Manual recovery is then required, and the current plan files might be corrupted.

Specify YES for the daily planning program to end if the Tivoli Workload Scheduler for z/OS controller specified by the SUBSYS keyword cannot be reached when daily planning requests the subsystem to prepare for the planning process.

When NO is specified or defaulted, the daily planning program continues to process if the controller cannot be reached. Ensure this only occurs because the subsystem is not started.

CKPTREFRESH(YES|NO)

This parameter can be used to refresh the checkpoint data set during a daily plan extend or replan from the old entries that are not "in use" any more.

Note:

The default value is NO and the checkpoint data set keeps a record for each remote destination defined in the ROUTOPTS and connected at least once with the Controller. Thus, if you are going to add some new destinations or change some names already defined in the ROUTOPTS statements, it would be advisable to set this parameter to YES at least once, after completing the planned changes. Message EQQN036I can help to determine when the 1000 limit is getting close and suggest that it is time to refresh the checkpoint data set.

CONTROLLERTOKEN(subsystem name|this subsystem)

This parameter is used for the history function. The subsystem name is a key for the history information. When the current plan is extended, the BATCHOPT CONTROLLERTOKEN value is used to write the information. When the information is retrieved from the database, the OPCOPTS CONTROLLERTOKEN value is used, so you can rerun jobs initiated from another subsystem current plan (for example, when a standby system takes over) by specifying the correct token after takeover.

If you specify OPERHISTORY(NO) or omit the OPERHISTORY keyword, the CONTROLLERTOKEN keyword is ignored.

CRITOPMSGS(NO|YES)

This parameter is used to filter the messages that are issued for operations that are missing the deadline. Specify YES to issue missing deadline messages that refer only to operations with the CRITICAL field set to P or W. Specify NO to issue missing deadline messages that refer to any types of operation. The default is NO.

DATEFORM(date format in reports|YY/MM/DD)

Specifies the date format used in reports. You can specify any combination of century (CC), year (YY), month (MM), and day (DD). CC is optional. You can also use the day number (DDD) from the Julian calendar rather than month and day. The delimiter can be any character other than C, Y, M, or D. However, if you specify CCYYMMDD, in any order, you cannot use delimiters.

DB2AVAIL(CONTINUE|STOP)

This keyword is used for the history function. It specifies the action that Tivoli Workload Scheduler for z/OS takes if the DB2® subsystem is not available. If you specify STOP, Tivoli Workload Scheduler for z/OS writes a DB2 error message to the EQQMLOG data set and, if the current plan is being extended, stops with return code 8.

If you specify OPERHISTORY(NO) or omit the OPERHISTORY keyword, the DB2AVAIL keyword is ignored.

DB2SYSTEM(DB2 subsystem)

This keyword is required for the history function. It specifies the DB2 subsystem, as in the IEFSSNxx member of SYS1.PARMLIB.

If you specify OPERHISTORY(YES) but omit the DB2SYSTEM keyword, an error message is issued.

If you specify OPERHISTORY(NO) or omit the OPERHISTORY keyword, the DB2SYSTEM keyword is ignored.

DPALG(daily planning algorithm|2)

Determines how much an application's priority will influence the way it is planned. Acceptable values are 0 to 32 767.

A value of 0 means priority is disregarded; 2 gives a reasonable balance between priorities and operation slack times; and 32 767 means operations are ordered only on priority.

DPROUT(daily plan report ddname|SYSPRINT)

Specifies the ddname that Tivoli Workload Scheduler for z/OS uses when producing daily-planning reports.

DYNAMICADD(NO|YES)

DYNAMICADD determines if Tivoli Workload Scheduler for z/OS creates a special resource during planning if an operation needs a resource that is not defined in the special resource database.

Specify YES if you want Tivoli Workload Scheduler for z/OS to create a resource in the current plan. The special resource database is not updated.

Specify NO if Tivoli Workload Scheduler for z/OS should not dynamically create a resource. Tivoli Workload Scheduler for z/OS plans the operation as if it does not use the resource.

A dynamically created resource has these values:

Special resource

The name specified by the allocating operation.

Text

Blank.

Specres group ID

Blank.

Hiperbatch

No.

Used for

Both planning and control.

On error

Blank. If an error occurs, Tivoli Workload Scheduler for z/OS uses the value specified in the operation details or, if this field is blank, the value of the ONERROR keyword of RESOPTS.

Default values

The resource has these default values for quantity and availability:

Quantity: The amount specified in the first allocating operation. The quantity is increased if more operations plan to allocate the special resource at the same time. Tivoli Workload Scheduler for z/OS increases the quantity only for dynamically created resources to avoid contention.
Available: Yes.

Intervals

No intervals are created. The default values specify the quantity and availability.

Workstations

The resource has default value *, which means all workstations. Operations on all workstation can allocate the resource.

Also see the DYNAMICADD keyword of RESOPTS on page ***, which controls the dynamic creation of undefined special resources in the current plan.

DYNAMICDEL(YES|NO)

DYNAMICDEL determines if a special resource that has been dynamically added to the current plan can be deleted if the current plan is changed, without checking the normal conditions listed in the section "setting the global values" of the Managing the Workload manual.

Specify NO if dynamically added changes can be deleted when the current plan is changed.

Specify YES if dynamically added changes can be deleted when the current plan is changed, without further checking.

Note:

It is strongly recommended that DYNAMICDEL(YES) be specified by all users who use significantly the dynamic addition of special resources. If the records dynamically added are not deleted using this feature, the size of the dataspace continues to increase in time with an initial performance degradation that worsens until the space available is exhausted and the batch job terminates with Abend 01D.

GTABLE(table ID|GLOBAL)

Defines the name of the global variable table for the Tivoli Workload Scheduler for z/OS complex when you schedule in an end-to-end with fault tolerance capabilities environment. This table contains variable definitions that can be used for any operation within the Tivoli Workload Scheduler for z/OS complex. The global variable table is searched when a table (or variable within a table) that is referenced by an operation cannot be found. You must set this keyword to the same value as the GTABLE keyword in the OPCOPTS statement (for additional details see GTABLE ***). The value of this keyword is specified in the TABLES parameter of the SCRPTLIB VARSUB statement (for details, see the description about this statement in the Tivoli Workload Scheduler for z/OS: Scheduling End-to-end with Fault Tolerance Capabilities manual) and is processed during the execution of the daily planning batch jobs. It is ignored if you do not use the end-to-end scheduling with fault tolerance capabilities feature.

You can specify only one table ID for the Tivoli Workload Scheduler for z/OS complex. Tivoli Workload Scheduler for z/OS uses the default name GLOBAL if you do not specify a table ID.

HDRS(list of report header lines| )

Defines a list of character strings containing report headers. The maximum length of each report header is 120 bytes. The batch job does not use more than three report headers. represents a blank line and is the default report header.

If you use the Tivoli Workload Scheduler for z/OS Japanese language feature, you can specify report headers in DBCS format.

|IGNOREDEADL(YES|NO)

|When setting this keyword to YES, |any operation in the current plan will have the deadline forced to |the CP tail end date and time, (that is, after the planning end) |except operations that are set as critical or suppress-if-late jobs. |This implies that their deadlines are completely ignored in the calculation |of latest start times. The immediate consequence is that, in a critical |network, operations not set as suppress-if-late, will result being |late based on the deadline of the critical job. This parameter does |not affect occurrence deadlines because automatic setting occurs at |operation level. |

If you set this parameter to YES, |the same behaviour also applies to any dynamic change using modify |current plan (that is, dynamic occurrence addition, occurrence modification |and so on). To return to the previous behaviour, a new current plan |must be created specifying NO or using the default |value.

If the deadline is manually anticipated, this causes |a recalculation of the latest start time for eligible operations within |the occurrence (that is, affected operations and internal predecessors). |Eligible operations are ALL the operations, if IGNOREDEADL value is |set to NO, and critical jobs and suppress-if-late |jobs when IGNOREDEADL is set to YES. For performance |reasons, external predecessors are not affected by the deadline change |until DP batch runs.

Any attempt to manually change deadlines |for non eligible operations is ignored by MCP engine. For operations |that have their deadline forced to the CP tail end using the parameter |IGNOREDEADL, message EQQM225W will not be issued.

JRUNHISTORY(YES|NO, CONTINUE|STOP)

The JRUNHISTORY parameter contains two keyword values:

The first keyword value defines whether the daily planning batch process backs up the old current plan on Generation Data Group (GDG) data sets. Specify YES to request the backup, that is necessary to populate the history DB2 tables used by the Tivoli® Dynamic Workload Console reporting feature. Use the default value NO to skip the backup.
The second keyword value is ignored if you specify NO as first keyword value. It defines whether the daily planning job continues when an error occurs during the backup process:

CONTINUE

The daily plan batch job continues and a warning message is issued. The occurrences that were removed from the current plan will not be archived.

STOP

The daily plan batch job fails. This is the default.

|KEEPCOMPDEPS(NO|YES)

| |

This keyword determines the permanence of external dependencies |on a completed operation that belongs to occurrences that are still |active when a daily plan job is submitted (either extended or replanned). |When a plan or extended or a replan is performed, using this parameter, |you can maintain dependencies between two operations that belong to |different occurrences when the predecessor operation has completed. |Normally, the dependency is removed after the run of a plan job, even |though the completed operation is still in the plan because it belongs |to an active occurrence.

Example: Assume |you have Occurrence A with Operation1 and Operation2, and Occurrence |B with Operation1 and Operation2, where Operation1, in both occurrences, |is the predecessor of Operation2, and where Operation1 (Occurrence |A) is also a predecessor of Operation2 (Occurrence B), thereby creating |an external dependency. If Operation1 (Occurrence A) completes and |Operation2 (Occurrence A) is in error, then Occurrence A is in error |status. Assume also that Operation1 (Occurrence B) is waiting for |a time dependency. If you now run a daily plan job, both occurrences |remain in the new plan, but the external dependency is removed because |the predecessor (Operation1 - Occurrence A) is complete. Using the KEEPCOMPDEPS keyword |set to YES, the dependency is maintained in the new plan.

Valid |values are:

NO: The default. When the plan is extended, external dependencies |on a completed operation are removed, even if the occurrence is still |active. |
YES: When the plan is extended, external dependencies remain defined |on the operation. This facilitates a rerun operation because the dependency |does not need to be redefined. |

LOGID(ID on track log data set|01)

An identification placed in all records on the track log (EQQTROUT). The length is 2 characters. Valid values are in the numeric range from 01 to 99.

If you have specified the EQQTROUT data set in the daily planning JCL, the job-tracking archive data set (EQQJTARC) is copied to EQQTROUT. NCPTROUT and OCPTROUT keywords specify if current plan records are also copied. If more than one controller is active and the same EQQTROUT data set is used to collect job-tracking information, you can use LOGID to differentiate between the logs from the different controllers.

LTPDEPRES(NO|YES)

This keyword is used by the batch job that extends the long-term plan.

Specify YES if changes to Tivoli Workload Scheduler for z/OS databases should be reflected in both the extended part of the LTP and the existing part of the plan. The existing part of the LTP is from the time of the end of the current plan to the end of the LTP. Specify NO if only the extended part of the LTP should reflect changes to the databases. The existing part of the LTP will not be changed when the batch job is run to extend the LTP.

An LTP occurrence that has been modified through the dialogs or PIF is not affected by changes to the databases, even if you specify LTPDEPRES(YES).

LTPDEPRES does not affect the removal of completed occurrences from the LTP. Whenever you run a modify or extend batch job, all completed occurrences, whose input arrival precedes the day on which the earliest uncompleted occurrence exists, are removed from the LTP.

For more information about the long-term plan, see Managing the Workload

MAXHISTORYROWS(number of rows|5000

This keyword, if specified with a nonzero value, tells Tivoli Workload Scheduler for z/OS the maximum number of rows that can be retrieved from DB2 by using the HIST command. The default value is 5000. the maximum value is 999999. If you specify 0, all the rows are retrieved without limitations.

For example, by specifying 1000 you set 1000 as the maximum number of rows that can be retrieved by the HIST command processing. If less than 1000 rows are retrieved, the rows are shown in the requesting panel. If more that 1000 rows are retrieved, the HIST command processing is interrupted, an error message is issued, and no data is shown in the requesting panel. To reduce the amount of data to retrieve, set the appropriate filtering criteria.

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 exceeded during the extension of the plan or during its creation, the daily planning batch program fails and no new plan is created. 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. Occurrences coming from the old plan remain unaffected.

NCPTROUT(NO|YES)

This keyword defines whether Tivoli Workload Scheduler for z/OS should copy records from the new current plan to the data set referenced by the EQQTROUT ddname in the daily planning process. When NO is specified, tracklog records will not be created for the workstation, occurrence, and operation records updated by the daily planning process when a new current plan is created.

The default value, YES, results in the generation of tracklog records for the corresponding new current plan records.

OCPTROUT(YES|CMP|NO)

This keyword defines whether Tivoli Workload Scheduler for z/OS should copy records from the old current plan to the data set referenced by the EQQTROUT ddname in the daily planning process. When YES is specified, tracklog records will be created for old current plan record types 01, 02, 03, and 04. Type 03 records carried through to the new current plan for reporting purposes and for pending predecessor occurrences are not copied to the EQQTROUT file because these records will be copied in a subsequent daily plan.

When CMP is specified, the current-plan record type 03 for completed and deleted occurrences is copied, as are type 01 and type 04 records.

The default value, NO, defines that Tivoli Workload Scheduler for z/OS should not copy records from the old current plan to EQQTROUT during the daily planning process.

OPERDALL(Y|N)

This parameter is used by the long-term-planning batch jobs when determining the deadline date for an operation that has a deadline day offset greater than zero, relative to the application input-arrival date.

Y means that Tivoli Workload Scheduler for z/OS considers all days (work and free) when determining the deadline date for the operation. N means that only work days are considered.

Whether a day is a work day or a free day is determined from the calendar you specified in the application description. If you did not specify a calendar, the default calendar is used.

Note:

OPERDALL does not affect occurrence deadlines.

OPERHISTORY(YES|NO)

This keyword is required for the history function. It specifies that Tivoli Workload Scheduler for z/OS will store completed operation information in the DB2 database.

If you specify YES, you must also specify the DB2SYSTEM keyword.

If you specify NO or omit the keyword, but specify related keywords (such as DB2SYSTEM, CONTROLLERTOKEN, DB2AVAIL, or RETAINOPER) a warning message is issued to inform you that the history function is not active (and, therefore, that completed occurrences were not stored in DB2).

OPERIALL(Y|N)

This parameter is used by the long-term-planning batch jobs when determining the input-arrival date for an operation that has an input-arrival-day offset greater than zero, relative to the application input-arrival date.

Y means that Tivoli Workload Scheduler for z/OS considers all days (work and free) when determining the input-arrival date for the operation. N means that only work days are considered.

Whether a day is a work day or a free day is determined from the calendar specified in the application description. If no calendar is specified, the default calendar is used.

Note:

OPERIALL does not affect occurrence input arrival.

PAGESIZE(page size for reports|55)

Defines the number of lines per page in reports generated by Tivoli Workload Scheduler for z/OS. You can specify a numeric value from 30 to 500.

PLANHOUR(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 specified for PLANSTART on the JTOPTS statement.

PREDWS(default predecessor workstation name)

Defines a default predecessor workstation name that is used by daily planning to create an external dependency when a specific predecessor operation cannot be found. This might occur, for example, if an operation has been deleted or a workstation name has been changed. The highest operation number in the predecessor occurrence with a workstation name that matches the PREDWS definition is set up as the predecessor.

If PREDWS is not specified, or if there is no match on the workstation name, the end point in the predecessor occurrence is used to establish the dependency. If the predecessor occurrence contains multiple end points, the end point with the highest operation number is used. The daily planning generates a warning message to identify the occurrences involved in the dependency.

The workstation name can be specified generically.

PREVRES(NO|YES)

Defines whether Tivoli Workload Scheduler for z/OS should maintain data and produce reports for the previous 24 hours when a daily planning job is run. The default is to produce reports for the previous planning period.

RCLEANUP (YES NO)

The RCLEANUP value must match the RCLEANUP value in the controller OPCOPTS. It specifies if DP batch must create the CP records containing the list of the operinfo associated to the completed occurrence. The controller later deletes this operinfo when the turnover has completed, if RCLEANUP(YES) is specified in the controller OPCOPTS.

|RETAINBIND(days|7)

|After an operation is bound in the current plan, the controller |sends notifications with the bind result and with the status of the |job bound to the engine that requested the bind. On the controller |the request for the bind is stored in a bind request |record until the last status change is notified. If a notification |cannot be sent, the RETAINBIND keyword specifies |how many days the bind request record is to be kept after the instance |of the job bound is not included anymore in the current plan. The |default value is 7.

RETAINOPER(days|0)

This keyword is used for the history function. It specifies how many days an operation is to be kept in the history database.

Zero is the default. It means that, before Tivoli Workload Scheduler for z/OS inserts a new occurrence into a DB2 table, it deletes all occurrences that have the same application identifier and that belong to previous versions stored after a current plan extension or replan operation has completed.

If you specify a nonzero value, Tivoli Workload Scheduler for z/OS purges data that is older than that number of days. You can thus keep more than one occurrence of each operation.

If you specify OPERHISTORY(NO) or omit the OPERHISTORY keyword, the RETAINOPER keyword is ignored.

SUBSYS(subsystem name|OPCA)

Identifies the name of the controller subsystem for which the batch job is run.

Batch jobs of Tivoli Workload Scheduler for z/OS, for example daily planning or long-term planning, must run on the same system as the controller if global resource serialization (GRS) is not used. If your installation uses GRS, the batch jobs and the controller must run on systems in the same GRS complex.

SUCCWS(default successor workstation name)

Defines a default successor workstation name that is used by daily planning to create an external dependency when a specific successor operation cannot be found. This might occur, for example, if an operation has been deleted or a workstation name has been changed. The lowest operation number in the successor occurrence with a workstation name that matches the SUCCWS definition is set up as the successor.

If SUCCWS is not specified, or if there is no match on the workstation name, the starting point in the successor occurrence is used to establish the dependency. If the successor occurrence contains multiple start points, the start point with the lowest operation number is used. The daily planning program generates a warning message to identify the occurrences involved in the dependency.

The workstation name can be specified generically.

|TIMEDEPCHK (YES|NO)

|When setting this keyword to YES, |planned start time calculation for operations that are not time-dependent |starts from the beginning of the extend or re-plan interval instead |of starting from the Input Arrival Time. This affects the Dynamic |Critical Path feature (also known as, Workload Service Assurance), |as planned start and end times are used to initiate the estimated |start and end times that are responsible for the choice of the critical |path among all the possible predecessor paths that start from a critical |job. |

Moreover, if you specify YES, any new |entry added to the critical job table coming from a dynamic addition |to the current plan (no planned start time) will have the estimated |start time set based on the current date and time if the operation |is not time dependent, or on Input Arrival Time if the operation is |time dependent and the Input Arrival Time is later than the current |date. For example, if the Input Arrival Time is 10:00 AM and the current |date is 9:00 AM, the current date is used for operations that are |not time-dependent , while for time-dependent operations, the Input |Arrival Time is used.

The negative or default value (NO) corresponds to the previous behaviour that calculates |estimated start times from Input Arrival Times in any case. To return |to the previous behaviour, a new current plan must be created specifying NO for this parameter or using the default. When YES is specified and current date and time is used |as estimated start time, this value is saved as planned start time |in the operation record. The main reason of this choice is given by |the need of using it in the recovery scenarios (controller restart).

Consider |also that for any value of this parameter, in case of dynamically |added operations, estimated start and end times setting does not cause |any update in the estimated times of its predecessors and successors |in the critical job table. As soon as a new current plan is created, |all these times are recalculated without any additional processing |effort. This behavior reflects the original design of the feature |with the objective of keeping data updated without heavily affecting |performances.

TPLGYPRM (member name|TPLGPARM)

Specify this keyword if you want to activate the end-to-end scheduling with fault tolerance capabilities feature in the daily plan.

The specified member name is a member of the PARMLIB in which the fault-tolerant end-to-end options are defined by the TOPOLOGY statement.

VALEACTION(END|WARN|ABEND)

Defines what action a daily planning batch program should take when its validation code detects an inconsistency in the data.

Specify ABEND if an abnormal end should occur. ABEND is the default value. The daily planning job ends with error code S0C1, and a new current plan is not created. Error information is written to the diagnostic data set, EQQDUMP. The characters VALExxxx follow the invalid operation code (X'0000') and identify the module where the error occurred. The system dump produced at the time of the abend will be needed if the error is to be reported as a program defect.

Specify END if the daily planning job should end. Error information is written to the diagnostic data set, EQQDUMP. A new current plan is not created.

Specify WARN if the daily planning job, where possible, should bypass detected errors. Errors are described in messages that are written to the message log and diagnostic information that is written to EQQDUMP. If errors can be bypassed, a new current plan is created. Check the current plan as soon as possible because it might contain errors. For example, a dependency might not have been resolved.

Examples

 BATCHOPT SUBSYS(OPCB)                            1 
          CALENDAR(NSW)                           2 
          SUCCWS(CPU*)                            3 
          PREDWS(CPU*)                            4 
          DATEFORM('YY-MM-DD')                    5 
          HDRS('HEADER NUMBER 1',                 6 
               'HEADER 2       ',
               'THIS IS THE THIRD HEADER LINE')

In this example of a BATCHOPT statement:

1

The batch job is run against the OPCB subsystem.

2

The default calendar NSW is used.

3

Any operation that is executing on a workstation whose name starts with the characters CPU is eligible as a default successor.

4

Any operation that is executing on a workstation whose name starts with the characters CPU is eligible as a default predecessor.

5

The date format is year, month, and day, separated by a hyphen (-).

6

The report headers have this text:

HEADER NUMBER 1
HEADER 2
THIS IS THE THIRD HEADER LINE