Control-M for z/OS®

User Guide

Supporting
Version 7.0.00 of Control-M for z/OS

September 2010

www.bmc.com
 Contacting BMC Software
You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada
Address BMC SOFTWARE INC Telephone 713 918 8800 or Fax 713 918 8000
2101 CITYWEST BLVD 800 841 2031
HOUSTON TX 77042-2827
USA
Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000

Copyright 2010 BMC Software, Inc., as an unpublished work. All rights reserved.
BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent
and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and
logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the
property of their respective owners.
DB2 is a registered trademark of International Business Machines Corporation.
The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or
licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product
and to the proprietary and restricted rights notices included in the product documentation.

Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF
THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to
restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and
DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD,
HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.
 Customer support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or e-mail. To expedite your inquiry, please see “Before Contacting BMC Software.”

Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at
http://www.bmc.com/support_home. From this website, you can
■ read overviews about support services and programs that BMC Software offers
■ find the most current information about BMC Software products
■ search a database for problems similar to yours and possible solutions
■ order or download product documentation
■ report a problem or ask a question
■ subscribe to receive e-mail notices when new product versions are released
■ find worldwide BMC Software support center locations and contact information, including e-mail addresses, fax
numbers, and telephone numbers

Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or
send an e-mail message to [email protected]. Outside the United States and Canada, contact your local support center for
assistance.

Before contacting BMC Software

Before you contact BMC Software, have the following information available so that Customer Support can begin working
on your problem immediately:
■ product information
— product name
— product version (release number)
— license number and password (trial or permanent)
■ operating system and environment information
— machine type
— operating system type, version, and service pack or other maintenance level such as PUT or PTF
— system hardware configuration
— serial numbers
— related software (database, application, and communication) including type, version, and service pack or
maintenance level
■ sequence of events leading to the problem
■ commands and options that you used
■ messages received (and the time and date that you received them)
— product error messages
— messages from the operating system, such as file system full
— messages from related software

3
 License key and password information
If you have questions about your license key or password, contact BMC as follows:
■ (USA or Canada) Contact the Order Services Password Team at 800 841 2031, or send an e-mail message to
[email protected].
■ (Europe, the Middle East, and Africa) Fax your questions to EMEA Contracts Administration at +31 20 354 8702, or send
an e-mail message to [email protected].
■ (Asia-Pacific) Contact your BMC sales representative or your local BMC office.

4 Control-M for z/OS User Guide

Contents
About This Guide 33
Conventions Used in This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Information New to This Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Information Relating to Control-M/Restart Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 1 Introduction to Control-M 41

INCONTROL Products and IOA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
IOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
INCONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Functional Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Main Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Expanded Control-M Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Control-M Support for MAINVIEW Batch Optimizer. . . . . . . . . . . . . . . . . . . . . . . 58
Online User Interface to Control-M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Control-M Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
IOA Core and Control-M Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Date Definition Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Date Standards and Date Field Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Job Ordering and Job Forcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Rerun and Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Order ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
SYSDATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Handling of Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Prerequisite Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Quantitative and Control Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Job Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Automatic Job Flow Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Chapter 2 Online Facilities 81

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
IOA Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
General IOA Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
IOA Entry Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
IOA Primary Option Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Multi-Screen Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Fast Exit from the IOA Online Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Screen Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Contents 5
 Commands and PFKeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Online Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
AutoRefresh Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
IOA Under ISPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
IOA Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
IOA SET Command Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
IOA TSO Command Processor Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Scheduling Definition Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Accessing the Scheduling Definition Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Handling of Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Creating Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Creating Job Scheduling Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Performing Operations on Tables and Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Table List screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Job List Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Job Scheduling Definition Screen – Defining Schedules . . . . . . . . . . . . . . . . . . . . 131
Exiting the Scheduling Definition Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Ordering (Scheduling) Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Copying Jobs to Another Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Deleting Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Condition Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Displaying Graphic Jobflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Displaying a Job Scheduling Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Tracking and Control Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Active Environment Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Global View Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
View Graph Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Why screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Deleting a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Log Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Confirm Scheduling Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Confirm Rerun Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
§Restart§ Confirm Restart Window (Under Control-M/Restart). . . . . . . . . . . . . 231
§Restart§Rerun and/or Restart Window (Under Control-M/Restart) . . . . . . . . 231
Rerun Flow Job List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Step List Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
§Restart§Job Order Execution History Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
§Restart§ Sysout Viewing Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Statistics Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Job Dependency Network Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
History Environment Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Force OK Confirmation Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
CMEM Rule Definition Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Table List Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Rule List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Rule Definition Screen – Defining Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

6 Control-M for z/OS User Guide

 Entering Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Editing CMEM Rule Definitions in the Edit Environment . . . . . . . . . . . . . . . . . . 270
Exiting the CMEM Rule Definition Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Deleting Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Ordering CMEM Rule Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Copying Rules to Another Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
IOA Variables Database Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Database List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Values of Database Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Variable Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Condition and Resource Handling Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
IOA Conditions/Resources Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
IOA Manual Conditions Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
IOA Log Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
IOA Log Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
IOA Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Accessing the IOA Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Defining a regular/periodic calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Year List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Copying Years to Another Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Calendar Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Defining rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Selecting rule-based calendars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Deleting rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Renaming rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Copying rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Exiting the IOA Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Calendar Facility Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Exiting the Calendar Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Exiting the Year List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Exiting the Calendar List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Exiting the Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Utilities Under ISPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
IOA Online Utilities Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
I1: Add, Check, or Delete a Prerequisite Condition . . . . . . . . . . . . . . . . . . . . . . . . 334
M1: Issue a Job Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
M2: Perform an AutoEdit Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
M3: Prepare Simulation/Tape Pull List Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
M4: Parameter Prompting Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
M5: Quick Schedule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
M6: End-User Job Order Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
U1: Invoke DOCU/TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

Chapter 3 Job Production Parameters 379

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
General Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Basic Scheduling Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

Contents 7
 Runtime Scheduling Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Post-Processing Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Parameter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
ADJUST CONDITIONS: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
APPL: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
APPL FORM: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
APPL TYPE: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
APPL VER: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
§Restart§ AUTO-ARCHIVE: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . 404
CM VER: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
CONFCAL: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
CONFIRM: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
CONTROL: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
CTB STEP: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
D-CAT: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
DATES: Basic Scheduling Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
DAYS: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
DEFINITION ACTIVE: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . 436
DESC: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
DO Statement: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
DO COND: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
DO CTBRULE: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
DO FORCEJOB: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
§Restart§DO IFRERUN: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . 453
DO MAIL: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
DO NOTOK: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
DO OK: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
DO REMEDY: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
DO RERUN: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
DO SET: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
DO SHOUT: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
DO STOPCYCL: Post-Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
DO SYSOUT: Post-Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
DOC: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
DOCLIB: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
DOCMEM: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
DUE OUT: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
GROUP: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
TBL MAXWAIT: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
IN: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
INSTREAM JCL: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
INTERVAL: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
INTERVAL SEQUENCE: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . 523
MAXRERUN: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
MAXWAIT: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
MEMLIB: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
MEMNAME: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
MINIMUM: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
MONTHS: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

8 Control-M for z/OS User Guide

NJE NODE: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
ON Statements: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
ON TABLE-END: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
ON PGMST: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
ON SYSOUT: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
OUT: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
OVERLIB: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
OWNER: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
PDS: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
PIPE: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
§Restart§PREVENT-NCT2:General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
PRIORITY: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
RELATIONSHIP: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
RERUNMEM: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
RESOURCE: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
RETENTION: # OF DAYS TO KEEP: Post–Processing Parameter. . . . . . . . . . . . . . . 612
RETENTION: # OF GENERATIONS TO KEEP: Post–Processing Parameter . . . . . 614
RETRO: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
SAC: Run Time Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
SCHEDULE RBC: Basic Scheduling Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
SCHEDULE RBC ACTIVE: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . 625
SCHENV: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
SET VAR: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
SHOUT: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
SPECIFIC TIMES: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
STAT CAL: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
STEP RANGE: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
SYSOUT: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
SYSTEM ID: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
TASKTYPE: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
TIME + DAYS: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
TIME ZONE: Runtime Scheduling Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
WDAYS: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681

Chapter 4 CONTROL-M Event Manager (CMEM) 691

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Types of Events Managed by CMEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Types of Actions That CMEM Can Perform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
CMEM Rule Ordering, Triggering and Deactivation. . . . . . . . . . . . . . . . . . . . . . . 694
CMEM AutoEdit Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
On Spool Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Support for ON DSNEVENT and ON STEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
CMEM Support for FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
CMEM Support for IBM FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Rule Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Event Selection Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Action Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Parameter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

Contents 9
 DESCRIPTION: General Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
DO statement: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
DO COND: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
DO FORCEJOB: Action Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
DO RULE: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
DO SHOUT: Action Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
DO STOPJOB: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
GROUP: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
MODE: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
ON statement: Event Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
ON DSNEVENT: Event Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
ON JOBARRIV: Event Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
ON JOBEND: Event Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
ON STEP: Event Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
OWNER: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
RUNTSEC: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
THRESHOLD: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

Chapter 5 JCL and AutoEdit Facility 755

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
System variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Non-Date System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Date System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Special System Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
User-Defined Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Valid Characters in User-Defined Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
JCL Setup Operation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Rules of Variable Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Order of Precedence for Multiple Value Assignments. . . . . . . . . . . . . . . . . . . . . . 782
Control Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
%%GLOBAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
%%GOTO and %%LABEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
%%IF, %%ELSE, %%ENDIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
%%INCLIB and %%INCMEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
%%LIBSYM and %%MEMSYM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
%%RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
%%RESOLVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
%%SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
%%$CALCDTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
%%$GREG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
%%$JULIAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
%%$LEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
%%$WCALC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
%%$WEEK# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
%%$WEEKDAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799

10 Control-M for z/OS User Guide

 %%$YEARWK# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
%%CALCDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
%%SUBSTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
%%$LENGTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
%%$TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
%%$FUNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Testing AutoEdit Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
AutoEdit Usage in the Job Scheduling Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Date Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
ODATE, RDATE and DATE Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
How to Obtain Date Formats – 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
How to Obtain Date Formats – 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
How to Obtain Date Formats – 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
How to Obtain the Previous Month’s Last Business Date. . . . . . . . . . . . . . . . . . . 813
Automatic Job Order for the Next Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Tape Clearance System – Stage 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Tape Clearance System – Stage 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Tape Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Dynamic Job Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Controlling the Target Computer by Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Controlling the Target Computer by System Affinity . . . . . . . . . . . . . . . . . . . . . . 818
%%BLANKn Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
%%RANGE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
SYSIN Parameter Containing %%. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
%%INCLIB and %%INCMEM Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Boolean “IF” Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821

Chapter 6 Selected Implementation Issues 825

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Job Ordering Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Job Ordering Through Quick Submit Command CTMQSB . . . . . . . . . . . . . . . . . 827
Special Purpose Job Ordering From Special Environments: CTMAJO . . . . . . . . 829
Manual Conditions File and Maybe Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Loading the Manual Conditions File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Using the Manual Conditions File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Handling Manual Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Handling Unscheduled Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Handling Maybe Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Maybe Jobs in SMART Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
MAINVIEW Batch Optimizer Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Job-Related Considerations for Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Enhanced Runtime Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
System-Related Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Parameter Prompting Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Parameter Prompting Facility – Type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Parameter Prompting Facility—Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843

Contents 11
 Maintenance Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852

Chapter 7 Simulation and Forecasting Facility 853

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Simulation Procedure CTMSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Activating the Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Preparatory Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
CONTROL-M Exits and Simulation Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
Analyzing the Simulation Run. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Handling Manual Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
The CTMTAPUL Tape Pull List Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
Activating the Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
DD Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
JOB/SCAN, PRO/JCL, DOCU/TEXT Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Problem Determination for Tape Pull List Reports . . . . . . . . . . . . . . . . . . . . . . . . 870
Sample Tape Pull List Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871

Appendix A The Control-M Application Program Interface (CTMAPI) 875

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Environment and Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
1. Order or Force Existing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Order or Force under Batch, REXX or CLIST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Order or Force Using Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Order or Force Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Order or Force Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Order or Force Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Order or Force Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
2. Create, Order, or Force New Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Invoking Create, Order or Force New Tables Using Program . . . . . . . . . . . . . . . 884
Create, Order or Force Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Create, Order or Force Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Create, Order or Force Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . 885
Create, Order or Force Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
3. AJF Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
AJF Action under Batch, REXX or CLIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
AJF Action using Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
AJF Action Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
AJF Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
AJF Action Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
AJF Action Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
4. Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Search under Batch, REXX or CLIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Invoking Search from a Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889

12 Control-M for z/OS User Guide

 Search Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Search Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Search Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Search Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
5. Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Global Variables under Batch REXX or CLIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
6. Conditions and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
7. CTMAS Active Job Download Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
EMDOWNLD Action under Batch, REXX or CLIST . . . . . . . . . . . . . . . . . . . . . . . 893
EMDOWNLD Action Allocations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
EMDOWNLD Action Return Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
EMDOWNLD Action Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . 893
EMDOWNLD Action Security Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Conditional Requests and Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Performance Considerations for Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . 896
Search Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Conversational Mode using Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Input and Output Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Example – Invoking CTMAPI in BAPI mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
CTMBAPI DSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Status Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
The Status Reply DSECT (CTMBJSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Status Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Status Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Status Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Status Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Order Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Order Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Order Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Order or Force Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Order or Force Security Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
AJF Action Extension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Identifying the Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Defining the Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Action AJF Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Action Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Global Variable Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Global Variable Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Quantitative Resource Extension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Quantitative Resource Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Quantitative Resource Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Quantitative Resource Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Create and/or Order or Force a Table (BLT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
BLT Action Return Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
BLT Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
BLT Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916

Contents 13
 BLT Resource Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
CTMBAPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Date Format Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918

Appendix B CONTROL-M for z/OS Unix System Services (USS) 919

Implementation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
OS/390-Oriented Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Unix Oriented Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Integrating SAP R/3 running on USS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
CONTROL-M Support for SAP in the USS Environment . . . . . . . . . . . . . . . . . . . 923

Appendix C Editing Job Scheduling Definitions in the Edit Environment 927

Line Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Maintaining Valid Job Scheduling Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931

Appendix D Editing CMEM Rule Definitions in the Edit Environment 941

Line Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Maintaining Valid Rule Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944

Appendix E MVS Job Restart Without CONTROL-M/Restart 947

Index 951

14 Control-M for z/OS User Guide

Figures
Establishing Job Dependency by Prerequisite Conditions . . . . . . . . . . . . . . . . . . . . . . 73
IOA Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
IOA Primary Option Menu where only Control-M is Installed . . . . . . . . . . . . . . . . . . 90
IOA Primary Option Menu when all INCONTROL Products are Installed . . . . . . . 92
IOA Version Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
IOA Log Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
PFKey Assignment Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
IOA Help Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
IOA Editor Edit Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
IOA Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
IOA SET Command Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
IOA TSO Command Processor Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Control-M Scheduling Definition Facility - Entry Panel . . . . . . . . . . . . . . . . . . . . . . . 121
Control-M Scheduling Definition Facility - Entry Panel Search Window . . . . . . . . 124
Control-M Scheduling Definition Facility Table List Screen . . . . . . . . . . . . . . . . . . . 125
Control-M Scheduling Definition Facility Job List Screen . . . . . . . . . . . . . . . . . . . . . 128
Job Scheduling Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
General Job Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Basic Scheduling Parameters - Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Basic Scheduling Parameters - SMART Table Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Runtime Scheduling Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Post-Processing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
SMART Table Entity Scheduling Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Editing Job Scheduling Definitions in the Edit Environment Screen . . . . . . . . . . . . 148
Job Scheduling Definition DOC lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Save Documentation Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Job List Screen Exit Option Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Order and Force Confirmation Window (Tables) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Order and Force Confirmation Window (Jobs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Select SMART Table window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
The Double Confirmation Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Window for Copying Jobs to Another Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Delete Table Confirmation Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Condition Inheritance Confirmation Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Graphic Jobflow for Color Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Graphic Jobflow for Non-Color Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Job Scheduling Plan Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Job Scheduling Plan Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Control-M Active Environment Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Display Type D (Default) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Figures 15
 Display Type A (All Fields) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Display Filters Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Show Screen Filter Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Global View Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
View Graph Screen Format for Color Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
View Graph Screen Format for Non-Color Terminals . . . . . . . . . . . . . . . . . . . . . . . . . 211
Active Environment Why Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Why Screen Add Condition or Delete NOT-COND Confirmation Window . . . . . . 216
Active Environment Screen Delete Confirmation Window . . . . . . . . . . . . . . . . . . . . 219
Active Messages Log Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Control-M Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Zoom Screen for SMART Table Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Adding or Editing a Job Order Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Exiting the Zoom Screen Confirmation Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Active Environment Screen Confirm Rerun Window . . . . . . . . . . . . . . . . . . . . . . . . . 230
§Restart§ Active Environment Rerun and/or Restart Confirmation Window . . . . 232
§Restart§ Flow Rerun Options Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Rerun Flow Job List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Rerun Flow Job List Confirmation Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Rerun and/or Restart Step List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
§Restart§ Job Order Execution History Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
§Restart§ Sysout Viewing Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Active Environment Statistics Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Tape Device Usage Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Job Dependency Network Display Type N (Network) . . . . . . . . . . . . . . . . . . . . . . . . 250
History Environment Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Control-M Active Environment FORCE OK confirmation window . . . . . . . . . . . . . 255
CMEM Rule Definition Facility – Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
CMEM Definition Facility Table List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
CMEM Rule Definition Rule List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Rule Definition Screen - Defining Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
CMEM Rule Definition Event Selection Parameters - Example . . . . . . . . . . . . . . . . . 266
General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Rule Definition Screen Comment Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Rule List Screen Exit Option Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Rule Definition Facility Delete Table Confirmation Window . . . . . . . . . . . . . . . . . . . 273
Order and Force Confirmation Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Window for Copying Rules to Another Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
IOA Variable Database Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
IOA Variable Database Facility Database List Screen . . . . . . . . . . . . . . . . . . . . . . . . . 281
IOA Values of Database Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Variable Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
IOA Conditions/Resources Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
IOA Conditions/Resources COND Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
IOA Conditions/Resources DELETE Confirmation Window . . . . . . . . . . . . . . . . . . 295
IOA Conditions/Resources CHANGE Option Window . . . . . . . . . . . . . . . . . . . . . . . 296
Resource Analysis WHY Option Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
IOA Manual Conditions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
IOA Manual Conditions Screen NEW Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

16 Control-M for z/OS User Guide

IOA Manual Conditions Screen ERASE Confirmation Window . . . . . . . . . . . . . . . . 302
IOA Log Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
IOA Log Screen Display Filters Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
IOA Log Show Screen Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
IOA Log Show Screen Window at Sites where Multiple INCONTROL Products are
Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
IOA Calendar Facility – Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Calendar List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Year List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Calendar List Screen Copy Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Calendar Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Use of Reserved String “==PERIODIC==” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Periodic Calendar – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Periodic Calendar – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Calendar List Screen Delete Confirmation Window . . . . . . . . . . . . . . . . . . . . . . . . . . 326
List of RBC Calendars Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Rule-based calendar screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
RENAME AN RBC dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
SPECIFY DESTINATION LIBRARY AND CALENDAR NAME Window . . . . . . . 330
Year List Screen Exit Option Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
IOA Online Utilities Menu when all INCONTROL Products are Installed . . . . . . . 334
Prerequisite Condition Utility Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Job Request Utility Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Control-M AutoEdit Simulation Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Control-M Simulation and Forecasting Facility and Tape Pull List . . . . . . . . . . . . . 343
Parameters Prompting Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Parameter Prompting Facility (Type 1) Primary Menu . . . . . . . . . . . . . . . . . . . . . . . . 349
Define Parameters and Condition - New Master Table Screen . . . . . . . . . . . . . . . . . 351
Define Parameters/ and Conditions - Master Table Definition Screen . . . . . . . . . . 351
Define Parameters and Conditions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Define Parameters and Conditions Save Screen Window . . . . . . . . . . . . . . . . . . . . . 353
Update Parameters and Set conditions - Table Selection Screen . . . . . . . . . . . . . . . . 354
Table Selection Screen Delete Confirmation Window . . . . . . . . . . . . . . . . . . . . . . . . . 354
Update Parameters and Set Conditions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Update Parameters and Set Conditions - Confirm Parameter Update Actions . . . . 356
Parameter Prompting Facility (Type 2) Primary Menu . . . . . . . . . . . . . . . . . . . . . . . . 358
Primary Prompting Facility – Define or Update a Master Plan . . . . . . . . . . . . . . . . . 359
Parameter Prompting Facility – Master Plan Definition . . . . . . . . . . . . . . . . . . . . . . . 359
Define Parameters in the Master Plan Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Fetch a Plan Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Exec/Order a Plan (CTMEXEC) Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Plan Selection Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Update Parameters Values Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Control-M Quick Schedule Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Control-M Quick Search Schedule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Quick Schedule Definition Job List Screen Entered . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Quick Schedule Definition Facility Exit Option Window . . . . . . . . . . . . . . . . . . . . . . 375
Scheduling Definition Screen Quick Schedule Definition Example . . . . . . . . . . . . . 376
Job List Screen Entered Through the End-User Job Order Interface . . . . . . . . . . . . . 377

Figures 17
 Job Scheduling Date and FORCE Options Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Job Scheduling Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
SMART Table Entity Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
SMART Table Scheduling Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
ADJUST CONDITIONS Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
ADJUST CONDITIONS Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
APPL Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
APPL Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
APPL FORM Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
APPL TYPE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
APPL VER Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
§Restart§ AUTO-ARCHIVE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
§Restart§ AUTO-ARCHIVE Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
CM VER Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
CONFCAL Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Days When Job Scheduled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
CONFIRM Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
CONFIRM Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
CONTROL Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
CONTROL Parameter Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
CONTROL Parameter Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
CONTROL Parameter Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
CTB STEP Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
CTB STEP Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
DCAT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
DCAT Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
DATES Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
DATES Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
DAYS Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
DAYS Parameter Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
DAYS Parameter Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
DAYS Parameter Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
DAYS Parameter Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
DAYS Parameter Example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
DAYS Parameter Example 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
DAYS Parameter Example 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
DAYS Parameter Example 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
DAYS Parameter Example 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
DAYS Parameter Example 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
DEFINITION ACTIVE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
DESC Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
DESC Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
DO Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
DO COND Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Long DO COND Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
DO COND Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
DO CTBRULE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
DO CTBRULE Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
DO FORCEJOB Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

18 Control-M for z/OS User Guide

DO FORCEJOB Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
DO FORCEJOB Confirmation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
§Restart§ DO IFRERUN Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
§Restart§ DO IFRERUN Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
DO MAIL Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
DO MAIL Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
DO NOTOK Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
DO NOTOK Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
DO OK Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
DO OK Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
DO REMEDY Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
DO REMEDY Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
DO RERUN Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
DO RERUN Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
DO SET Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
DO SET Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
DO SHOUT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
DO SHOUT Subparameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
DO STOPCYCL Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
DO STOPCYCL Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
DO SYSOUT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Effect of Merging Multiple SYSOUT Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
DO SYSOUT Parameter – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
DO SYSOUT Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
DOC Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
DOC Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
DOCLIB Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
DOCLIB Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
DOCMEM Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
DOCMEM Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
DUE OUT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
DUE OUT Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
GROUP Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
GROUP Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
TBL MAXWAIT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
TBL MAXWAIT Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
IN Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Long IN Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
IN Parameter – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
IN Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
IN Parameter – Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
IN Parameter – Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
IN Parameter – Example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
IN Parameter – Example 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
INSTREAM JCL parameter format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
INTERVAL Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
INTERVAL Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
INTERVAL SEQUENCE Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
MAXRERUN Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

Figures 19
 MAXRERUN Parameter Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
MAXWAIT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
MAXWAIT Parameter Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
MAXWAIT Parameter Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
MEMLIB Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
MEMNAME Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
TABLE Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
MINIMUM Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
MINIMUM Parameter – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
MINIMUM Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
MONTHS Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
MONTHS Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
NJE NODE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
ON Statement Format Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
ON TABLE-END Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
ON TABLE-END Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
ON TABLE-END Confirmation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
ON Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
ON PGMST Parameter – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
ON PGMST Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
ON PGMST Parameter – Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
ON SYSOUT Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
OUT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Long OUT Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
OUT Parameter Example 1 – First Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
OUT Parameter Example 1 – Second Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
OUT Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
OUT Parameter – Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
OVERLIB Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
OVERLIB Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
OWNER Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
OWNER Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
PDS Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
PDS Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
PIPE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
PIPE Parameter Example – Job CTLIVPWR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
PIPE Parameter Example – Job CTLIVPRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
§Restart§ PREVENT-NCT2 Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
§Restart§ PREVENT-NCT2 Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
PRIORITY Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
RELATIONSHIP Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
RELATIONSHIP Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
RERUNMEM Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
RERUNMEM Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
RESOURCE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
RESOURCE Parameter – Example 1A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
RESOURCE Parameter – Example 1B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
RESOURCE Parameter – Example 1C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
RETENTION: # OF DAYS TO KEEP Parameter Format . . . . . . . . . . . . . . . . . . . . . . . 612

20 Control-M for z/OS User Guide

RETENTION: # OF DAYS TO KEEP Parameter Example . . . . . . . . . . . . . . . . . . . . . 613
RETENTION: # OF GENERATIONS TO KEEP Parameter Format ........... 614
RETENTION: # OF GENERATIONS TO KEEP Parameter Example . . . . . . . . . . . . 615
RETRO Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
RETRO Parameter – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
SAC Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
SAC Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
SCHEDULE RBC Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
SCHEDULE RBC Parameter – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
SCHEDULE RBC Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
SCHEDULE RBC ACTIVE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
SCHENV Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
SET VAR Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
SET VAR Parameter Example – 2A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
SET VAR Parameter Example 2B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
SHOUT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
SHOUT Parameter Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
SHOUT and DO SHOUT Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
SPECIFIC TIMES Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
STAT CAL Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
STEP RANGE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
STEP RANGE Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
SYSOUT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Merging SYSOUT and DO SYSOUT Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
SYSOUT Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
SYSTEM ID Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
TASKTYPE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
TASKTYPE Parameter – Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
TIME + DAYS Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
FROM TIME Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
TIME + DAYS Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
TIME ZONE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
WDAYS Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
WDAYS Parameter Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
WDAYS Parameter Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
WDAYS Parameter Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
WDAYS Parameter Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
WDAYS Parameter Example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
WDAYS Parameter Example 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
WDAYS Parameter Example 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
WDAYS Parameter Example 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
WDAYS Parameter Example 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
WDAYS Parameter Example 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
CMEM Rule Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
DESCRIPTION Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
DESCRIPTION Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
DO Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
DO COND Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
DO COND Parameter – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714

Figures 21
 DO COND Parameter – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
DO FORCEJOB Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
DO FORCEJOB – Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
DO FORCEJOB – Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
DO RULE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
DO RULE Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
DO SHOUT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
DO SHOUT Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
DO STOPJOB Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
DO STOPJOB Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
GROUP Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
GROUP Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
MODE Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
MODE Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
ON Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
ON DSNEVENT Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
ON DSNEVENT Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
ON JOBARRIV Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
ON JOBARRIV Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
ON JOBEND Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
ON JOBEND Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
ON STEP Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
ON STEP Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
OWNER Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
OWNER Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
RUNTSEC Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
RUNTSEC Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
THRESHOLD Parameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
THRESHOLD Parameter Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Illustration 1A: How CONTROL-M Formerly Handled A New Tape . . . . . . . . . . . 838
Illustration 1B: Steps Formerly Performed by the User . . . . . . . . . . . . . . . . . . . . . . . . 839
Illustration 2A: How CONTROL-M Now Handles A New Tape . . . . . . . . . . . . . . . 840
Illustration 2B: Single Step Now Performed by the User . . . . . . . . . . . . . . . . . . . . . . 841
Parameter Prompting Facility Type 2: Definition Phase . . . . . . . . . . . . . . . . . . . . . . . 843
Parameter Prompting Facility Type 2: Fetch Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Parameter Prompting Facility Type 2: EXEC Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
The FETCH A PLAN Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
The EXEC / ORDER A PLAN Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
PPF2DEL Utility Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
CONTROL-M Simulation Exit Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Sample Tape Pull List Report 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Sample Tape Pull List Report 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Sample Tape Pull List Report 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
Sample Tape Pull List Report 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
JCL for USS Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
CONTROL-M Architecture for Unix-Oriented MVS Implementation . . . . . . . . . . . 921
Architecture of SAP R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
Communication with the R/3 Application Layer - DB/2 Database . . . . . . . . . . . . . 924
Communication with the R/3 Application - SAP/R3 Database . . . . . . . . . . . . . . . . 925

22 Control-M for z/OS User Guide

The Edit Environment in The Job Scheduling Definition Screen . . . . . . . . . . . . . . . . 927
Example - Inserting A DO Statement - Before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
Example - Inserting A DO Statement - After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
Example - Deleting A Block - Before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
Example - Deleting A Block - After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Example - Moving Statements - Before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935
Example - Moving Statements - After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936
Example - Copying Statements - Before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
Example - Copying Statements - After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Example - Inserting A Line - Before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Example - Inserting A Line - After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
The Edit Environment in The Rule Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . 941
Example - Repeating A DO Block - Before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Example - Repeating A DO Block - After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Example - Automatic Restart - CONTROL-M Only . . . . . . . . . . . . . . . . . . . . . . . . . . 949

Figures 23
24 Control-M for z/OS User Guide
Tables
List of INCONTROL Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Job Scheduling Definition Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Runtime Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Conditions and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
NJE Network Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Event Types Handled by CMEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
KSL Report Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
IOA Core Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Date Definition Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Gregorian Date Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Supported Gregorian Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Julian Date Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
SMART Table Handling Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Prerequisite Condition Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Runtime Scheduling Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Prefixing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Masking Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
INCONTROL Shared IOA Functions and Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Control-M Functions and Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
IOA Primary Option Menu Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
IOA Transfer Control Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Basic IOA Screen Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Common PFKey Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Additional Key Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Scrolling Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Scrolling Amounts in the SCROLL Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
ISPF Commands that must be defined for PFKeys . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
PFKey Functions Within the IOA Editor Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
IOA Editor Command Line Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
IOA Editor Row Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Scheduling Definition Facility Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Scheduling Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Options of the Table List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Commands of the Job List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Options of the Job List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Parameters of the Job Scheduling Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . 133
General Job Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Basic Scheduling Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Runtime Scheduling Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Post-Processing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Tables 25
 Parameters of the SMART Table Entity Scheduling Definition Screen . . . . . . . . . . . 145
Commands of the Job Scheduling Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Save Documentation Window Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Commands for Exiting the Job Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Options for Manually Ordering Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Order and Force Confirmation Window Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Fields in the Window for Copying Jobs to Another Table . . . . . . . . . . . . . . . . . . . . . 163
Color Change Options on Graphic Jobflow Window . . . . . . . . . . . . . . . . . . . . . . . . . 169
Job Scheduling Plan Window Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Job Scheduling Plan Screen Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Default Colors for Active Missions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Predefined Display Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Fields in the Default Display Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Fields for Each Job Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Other Information in the STATUS Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Fields in the All Fields Display Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Commands of the Active Environment Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Options of the Active Environment Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Job Statuses for the Active Environment screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
SMART Table Entity Statuses for the Active Environment Screen . . . . . . . . . . . . . . 195
Field of the Display Filters Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Options of the Display Filters window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Fields of the Show Screen Filter Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Show Screen Filter Window Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Show Screen Filter Window - Closing Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Fields of the Global View Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Fields of the View Graph Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Job Status Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Fields of the View Graph Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Job Graph Status Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Fields of the Add Condition or Delete NOT-COND Confirmation Window . . . . . 216
Fields of the Job Scheduling Definition Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . 222
Commands of the Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Fields of the Confirm Rerun Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
§Restart§ Fields of the Active Environment Rerun and/or Restart Confirmation
Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
§Restart§ Fields of the Flow Rerun Options Window . . . . . . . . . . . . . . . . . . . . . . . . . 237
Fields of the Rerun Flow Job List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Options of the Rerun and/or Restart Step List Window . . . . . . . . . . . . . . . . . . . . . . . 241
§Restart§ Default Display Type Fields of Job Order Execution History Screen . . . 242
§Restart§ Fields in the Job Order Execution History Screen . . . . . . . . . . . . . . . . . . . . 243
§Restart§ Commands of the Sysout Viewing Screen . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Statistics Screen Individual Execution Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Statistics Screen SMART Table Entity Execution Statistics . . . . . . . . . . . . . . . . . . . . . 247
Fields of the Job Dependency Network Display Type N (Network) . . . . . . . . . . . . . 250
Parameter of the REFRESH Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Rule Definition Facility Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Fields of the Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Options of the Table List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

26 Control-M for z/OS User Guide

Fields of the Rule List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Commands of the Rule List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Options of the Rule List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
CMEM Rule Definition Event Selection Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
CMEM Rule Definition General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
CMEM Rule Definition Action Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Commands of the Rule Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Commands for Exiting the Rule Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Options for Ordering Rule Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Fields in the Window for Copying Rules to Another Table . . . . . . . . . . . . . . . . . . . . 277
IOA Variable Database Facility Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Fields of the IOA Values of Database Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Options of the Values of Database Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Display Types of the Variable Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Options of the Variable Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Fields of the IOA Conditions/Resources Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
IOA Conditions/Resources Retrieval Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
IOA Conditions/Resources ADD Command Formats . . . . . . . . . . . . . . . . . . . . . . . . 293
Options of the IOA Conditions/Resources Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
IOA Conditions/Resources DELETE Confirmation Window Options . . . . . . . . . . 295
COUNT Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Fields of the WHY Option Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Fields of the IOA Manual Conditions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Retrieval Criterion for IOA Manual Conditions Screen . . . . . . . . . . . . . . . . . . . . . . . 299
Options of the IOA Manual Conditions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Fields of the IOA Manual Conditions Screen ERASE Confirmation Window . . . . 302
Fields of the IOA Log Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Commands of the IOA Log Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
IOA Log Screen Predefined Display Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Fields of the Display Filters Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Options of the Display Filters Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Fields of the IOA Log Show Screen Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
IOA Log Show Screen Window Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
IOA Log Show Screen window - Closing Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
IOA Calendar Facility Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Calendar types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Regular/periodic job parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Options for Calendar List screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Commands of the Year List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Options of the Year List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Fields of the Calendar List Screen Copy Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Fields of the Calendar Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Rule-based (RBC) parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Options for List of RBC Calendars screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Rule-based calendar screen parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Commands for Exiting the Calendar Definition Screen . . . . . . . . . . . . . . . . . . . . . . . 331
Prerequisite Condition Utility Screen Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Parameters of the Job Request Utility Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
JCL Library Mode Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Tables 27
 Scheduling Library Mode Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
AutoEdit Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Fields of the Control-M Simulation and Forecasting and Tape Pull List Screen . . . 344
Define Parameters and Conditions Screen – Format . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Define Parameters and Conditions Screen – Options . . . . . . . . . . . . . . . . . . . . . . . . . 353
Fields of the Update Parameters and Set Conditions Screen . . . . . . . . . . . . . . . . . . . 355
Fields of the Define Parameters in the Master Plan Screen . . . . . . . . . . . . . . . . . . . . . 360
Options of the Define Parameters in the Master Plan Screen . . . . . . . . . . . . . . . . . . . 362
Define Parameters in the Master Plan Screen - Exit Screen Commands . . . . . . . . . . 362
Fetch Plan Screen OVERRIDE DAILY PLAN Values . . . . . . . . . . . . . . . . . . . . . . . . . 363
Format of the Update Parameter Values Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Quick Schedule Definition Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Fields of the Control-M Quick Schedule Definition Screen . . . . . . . . . . . . . . . . . . . . 369
Prerequisite Condition Format Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Formats for Prerequisite Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Fields that Affect Prerequisite Conditions Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Fields in the Job List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Options of the Job List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Category A, B, C, and D Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Runtime Scheduling Parameter Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Final Job Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Parameters Performed When the Job Ends OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Conditional Processing Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Return and Cyclic Post-Processing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
SMART Table Entity Post-Processing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
ADJUST CONDITIONS Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
§Restart§ AUTO-ARCHIVE Subparameter Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Optional CONFCAL Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Optional CONFIRM Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Mandatory CONTROL Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Optional CONTROL Subparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Optional CTB STEP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
DAYS Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Non-Periodic Scheduling Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Periodic Scheduling Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
DEFINITION ACTIVE Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
DO Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Relationship of DO Statements with Other Statements . . . . . . . . . . . . . . . . . . . . . . . . 441
DO COND Mandatory Subparameter Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
DO CTBRULE Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
DO FORCEJOB Subparameter Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
§Restart§ DO IFRERUN Subparameter Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
DO MAIL Subparameter Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
DO REMEDY Subparameter Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
DO SET Subparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
DO SHOUT Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
DO SYSOUT Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Varying Effect of SYSOUT Handling Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

28 Control-M for z/OS User Guide

TBL MAXWAIT Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
IN Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Date Reference Values – Example 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
INTERVAL Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
INTERVAL SEQUENCE Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
MAXWAIT Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
MEMLIB Parameter Values for Non-Started Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
MEMLIB Parameter Formats for Started Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
MONTHS Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
ON Statement types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
ON TABLE-END Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
ON PGMST Parameter Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
ON PGMST Parameter CODES Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
ON PGMST Parameter Code Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
ON SYSOUT Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
OUT Mandatory Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
OVERLIB Parameter: Algorithm for LIbraries Used when Option J (JCL) is Specified
582
§Restart§ PREVENT-NCT2 Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
RELATIONSHIP Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
RELATIONSHIP Parameter Scheduling Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Mandatory RESOURCE Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Optional RESOURCE Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
RETENTION: # OF DAYS TO KEEP Parameter Values . . . . . . . . . . . . . . . . . . . . . . . 612
RETENTION: # OF GENERATIONS TO KEEP Values . . . . . . . . . . . . . . . . . . . . . . . 614
RETRO Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
SAC Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
SCHEDULE RBC ACTIVE Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
SHOUT Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
SPECIFIC TIMES Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
STEP RANGE Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
SYSOUT Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
TASKTYPE Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
TASKTYPE Basic Type Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
WDAYS Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Non-Periodic Scheduling Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Periodic Scheduling Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Events handled by CMEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
CMEM AutoEdit Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
CMEM Event Selection Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
CMEM General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
CMEM Action Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
DO Parameter Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
DO COND Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
DO FORCEJOB Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
DO RULE Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
DO SHOUT Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
DO SHOUT OPER Subparameter Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
MODE Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

Tables 29
 ON Parameter Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
DSNEVENT Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Valid STEPRC Code Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
ON JOBARRIV Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
JOBEND Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
ON STEP Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
ON STEP Subparameter STEPRC Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Valid RUNTSEC Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
AutoEdit Control Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Non-Date AutoEdit System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Date AutoEdit System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
4 Character Year Date AutoEdit System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Special AutoEdit System variable resolved after a SMART Table is ordered but
before job submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Special AutoEdit System Variables Resolved after Job End . . . . . . . . . . . . . . . . . . . . 766
Special AutoEdit System Variable Resolved after Job Submission . . . . . . . . . . . . . . 767
IOA Global Variable Database Structure Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Chart for Determining Priorities of Value Assignment Sources . . . . . . . . . . . . . . . . 783
%%RESOLVE Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
AutoEdit Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Date Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Alternative Job Ordering Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Parameter Prompting Facility Type 2: Use of CLISTS . . . . . . . . . . . . . . . . . . . . . . . . . 846
The FETCH A PLAN Screen: Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
The EXEC / ORDER A PLAN Screen: Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
Files Used as Input during Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Files Produced as Output of Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Parameters Passed to the Utility by DASIMPRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Online Simulation Environment File Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
Overrides To Be Specified on IOALDNRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Overrides To Be Specified on ADDMNCND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
Override To Be Specified for Simulation Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
CTMTAPUL Subparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
DD statements used by CTMTAPUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Order or Force Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Files Accessed during the Order or Force Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Create and/or Order or Force New Tables Return Codes . . . . . . . . . . . . . . . . . . . . . 885
Files Accessed during the Create, Order or Force Process . . . . . . . . . . . . . . . . . . . . . 885
AJF Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Files Accessed during the AJF Action Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Search Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Files Accessed during the AJF Action Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Selection Criteria Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
Selection Criteria Parameter Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Files Accessed during the AJF Action Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Contents of Registers on Input to CTMAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Fixed Part Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Status Extension Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
Statuses Returnable under the Status Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905

30 Control-M for z/OS User Guide

Status Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Files Accessed during the AJF Action Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Order Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Order Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
AJF Action Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
AJF Action BAPIAACT Field Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
CTMAPI Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Global Variable Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Global Variable Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
CTMAPI Quantitative Resource Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
CTMAPI Quantitative Resource Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
CTMAPI Quantitative Resource File Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
BLT Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
CTMAPI Quantitative Resource File Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
CTMAPI Reply Mechanism Trigger Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Subjects of Line Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Line Editing Commands - Delete Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Line Editing Commands - Copy Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Line Editing Commands - Move Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Line Editing Commands - Repeat Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Line Editing Commands - Insert Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Line Editing Commands - Location Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Line Editing Commands - Delete Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Line Editing Commands - Copy Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Line Editing Commands - Move Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Line Editing Commands - Repeat Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Line Editing Commands - Insert Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Line Editing Commands - Location Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944

Tables 31
32 Control-M for z/OS User Guide
About This Guide
Control-M is a component member of the INCONTROL™ by BMC Software family
of products. The Control-M for z/OS User Guide is the main publication that describes
the components and usage of Control-M software.

This guide is designed for use by everyone who defines job schedules or who uses
Control-M to actively control jobs in the production environment.

This guide provides detailed information on all Control-M functions and facilities. It
contains the following chapters:

Chapter 1–Introduction

Control-M introduction and overview. This chapter briefly describes the main
components of Control-M from a functional perspective, and introduces the user to
Control-M facilities and features, concepts and logic. INCONTROL and IOA
components and concepts are also described.

It is highly recommended that all users read this chapter before reading other
chapters in the guide.

Chapter 2–Online Facilities

Guide to using Control-M and IOA online facilities. Control-M and IOA screens are
illustrated and discussed in logical sequence.

Chapter 3–Job Production Parameters

Detailed description, accompanied by examples, of the parameters and statements in

the Control-M Job Scheduling Definition screen.

Chapter 4–Control-M Event Manager (CMEM)

Overview of Control-M Event Manager logic and a detailed description of the

parameters and statements in CMEM rule definitions. This facility enables Control-M
to respond to external events (that is, events in the MVS environment that occur
outside of Control-M's direct control).

About This Guide 33

Conventions Used in This Guide

Chapter 5–JCL and AutoEdit Facility

Guide to the Control-M AutoEdit facility, and its application to JCL. Usage of
AutoEdit terms in the JCL can eliminate the need for manual changes to the JCL prior
to job submission.

Chapter 6–Selected Implementation Issues

Provides concepts, hints, and procedures for successful implementation and

maintenance of Control-M.

Chapter 7–Simulation and Forecasting Facility

Guide to simulating the effects of operations and procedures in your production

environment and forecasting the potential impact of proposed changes.

Appendix A–Editing Job Scheduling Definitions in the Edit Environment

Usage of the IOA Edit environment for editing job scheduling definitions.

Appendix B–Editing CMEM Rule Definitions in the Edit Environment

Usage of the IOA Edit environment for editing CMEM rule definitions.

Appendix C–MVS Job Restart Without Control-M/Restart

Instructions for using Control-M to perform an MVS restart (for sites that do not have
Control-M/Restart installed).

Index

Conventions Used in This Guide

Notational conventions that may be used in this guide are explained below.

Standard Keyboard Keys

Keys that appear on the standard keyboard are identified in boldface, for example,
Enter, Shift, Ctrl+S (a key combination), or Ctrl S (a key sequence).

34 Control-M for z/OS User Guide

 Conventions Used in This Guide

WARNING
The commands, instructions, procedures, and syntax illustrated in this guide presume that the
keyboards at your site are mapped in accordance with the EBCDIC character set. Certain
special characters are referred to in this documentation, and you must ensure that your
keyboard enables you to generate accurate EBCDIC hex codes. This is particularly true on
keyboards that have been adapted to show local or national symbols. You should verify that

$ is mapped to x'5B'
# is mapped to x'7B'
@ is mapped to x'7C'

If you have any questions about whether your keyboard is properly mapped, contact your
system administrator.

Preconfigured PFKeys

Many commands are preconfigured to specific keys or key combinations. This is

particularly true with regard to numbered PF keys, or pairs of numbered PFKeys. For
example, the END command is preconfigured to, and indicated as, PF03/PF15. To
execute the END command, press either the PF03 key or the PF15 key.

Instructions to enter commands may include

■ only the name of the command, such as, enter the END command
■ only the PF keys, such as, press PF03/PF15
■ or both, such as, press PF03/PF15, or enter the END command

Command Lines and Option Fields

Most screens contain a command line, which is primarily used to identify a single
field where commands, or options, or both, are to be entered. These fields are usually
designated COMMAND, but they are occasionally identified as COMMAND/OPT or
COMMAND/OPTION.

Option field headings appear in many screens. These headings sometimes appear in
the screen examples as OPTION, or OPT, or O.

Names of Commands, Fields, Files, Functions, Jobs, Libraries, Members,

Missions, Options, Parameters, Reports, Subparameters, and Users

The names of commands, fields, functions, jobs, libraries, members, missions,

options, parameters, reports, subparameters, users, and most files, are shown in
standard UPPERCASE font.

About This Guide 35

Conventions Used in This Guide

User Entries

In situations where you are instructed to enter characters using the keyboard, the
specific characters to be entered are shown in this UPPERCASE BOLD text, for
example, type EXITNAME.

Syntax Statements

In syntax, the following additional conventions apply:

■ A vertical bar ( | ) separating items indicates that you must choose one item. In the
following example, you would choose a, b, or c:

a | b | c

■ An ellipsis ( . . . ) indicates that you can repeat the preceding item or items as many
times as necessary.

■ Square brackets ( [ ] ) around an item indicate that the item is optional. If square
brackets ( [ ] ) are around a group of items, this indicates that the item is optional,
and you may choose to implement any single item in the group. Square brackets
can open ( [ ) and close ( ] ) on the same line of text, or may begin on one line of text
and end, with the choices being stacked, one or more lines later.

■ Braces ({ }) around a group of items indicates that the item is mandatory, and you
must choose to implement a single item in the group. Braces can open ( { ) and
close ( } ) on the same line of text, or may begin on one line of text and end, with the
choices being stacked, one or more lines later.

Screen Characters

All syntax, operating system terms, and literal examples are

presented in this typeface. This includes JCL calls, code examples, control
statements, and system messages. Examples of this are:

■ calls, such as
CALL ’CBLTDLI’

■ code examples, such as

FOR TABLE owner.name USE option, . . . ;

■ control statements, such as

36 Control-M for z/OS User Guide

 Information New to This Version

//PRDSYSIN DD * USERLOAD PRD(2) PRINT

■ system messages, both stand-alone, such as You are not logged on to

database database_name, and those embedded in text, such as the message
You are not logged on to database database_name, are displayed on
the screen.

Variables

Variables are identified with italic text. Examples of this are:

■ In syntax or message text, such as

Specify database database_name
■ In regular text, such as
replace database database_name1 with database database_name2 for the current
session
■ In a version number, such as
EXTENDED BUFFER MANAGER for IMS 4.1.xx

Special elements

This book includes special elements called notes and warnings:

NOTE
Notes provide additional information about the current subject.

WARNING
Warnings alert you to situations that can cause problems, such as loss of data, if you do not
follow instructions carefully.

Information New to This Version

Additional information that is new to this version is described in Appendix A of the
INCONTROL for z/OS Upgrade Guide and What’s New section of the INCONTROL for
z/OS Release Notes.

About This Guide 37

Information Relating to Control-M/Restart Users

Information Relating to Control-M/Restart

Users
Certain information presented in the Control-M for z/OS User Guide is relevant only to
Control-M users who have Control-M/Restart installed at their site.

NOTE
Control-M/Restart was called Control-R in earlier versions.

Control-M/Restart information is identified in this guide by the §Restart§ symbol,

which is shown at the beginning of the Control-M/Restart information. This symbol
is shown using the following guidelines:

■ If an entire topic level is dedicated to Control-M/Restart material, the heading of

that topic begins with the §Restart§ symbol. Similarly, if there are lower level topics
within that level that are also dedicated to Control-M/Restart material, the
headings of those lower level topics will also begin with the §Restart§ symbol.

This provision also applies to Control-M/Restart paragraphs, each of which will

begin with the §Restart§ symbol, or, on occasion, to single sentences, or even
phrases or words, if they exclusively pertain to Control-M/Restart material.

■ The same §Restart§ symbol is placed at the conclusion of each unbroken block of
text material that contains Control-M/Restart material, regardless of whether the
material spans more than one heading level, paragraph, or sentence. For example,
if a first level Control-M/Restart topic includes second and/or third and/or fourth
and/or fifth level topic headings, with no intervening material that is not related to
Control-M/Restart, the §Restart§ symbol will be placed at the end of the text in the
lowest level sentence of unbroken Control-M/Restart material.

■ If a figure or table is used exclusively to identify or explain Control-M/Restart

material, the following statement will appear immediately preceding the figure
title or the table title:

§Restart§ The following (figure)(table) is for users who have Control-M/Restart

installed at their site.

■ If Control-M/Restart material is included only in part of a figure or table otherwise

used to illustrate standard Control-M material, the §Restart§ symbol will be used
within the figure or table to identify the information relevant only to
Control-M/Restart users.

If Control-M/Restart is not installed at your site, you can skip any material in this
guide that is identified with the §Restart§ symbol.

38 Control-M for z/OS User Guide

 Related Publications

Related Publications
Control-M for z/OS Getting Started Guide

Explanation of Control-M facilities. Online, step-by-step instructions are provided.

INCONTROL for z/OS Administrator Guide

Information for system administrators about customizing and maintaining

INCONTROL products.

INCONTROL for z/OS Installation Guide

A step-by-step guide to installing INCONTROL products using the INCONTROLTM

Installation and Customization Engine (ICE) application.

INCONTROL for z/OS Messages Manual

A comprehensive listing and explanation of all IOA and INCONTROL messages and
codes.

INCONTROL for z/OS Security Guide

A step-by-step guide to implementing security in INCONTROL products using the

ICE application.

INCONTROL for z/OS Utilities Guide

Describes utilities designed to perform specific administrative tasks that are available
to INCONTROL products.

About This Guide 39

Related Publications

40 Control-M for z/OS User Guide

 Chapter

1
1 Introduction to Control-M
This chapter includes the following topics:

INCONTROL Products and IOA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

IOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
INCONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Functional Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Main Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Expanded Control-M Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Control-M Support for MAINVIEW Batch Optimizer. . . . . . . . . . . . . . . . . . . . . . . 58
Online User Interface to Control-M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Control-M Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
IOA Core and Control-M Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Date Definition Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Date Standards and Date Field Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Job Ordering and Job Forcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Rerun and Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Order ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
SYSDATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Handling of Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Prerequisite Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Quantitative and Control Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Job Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Automatic Job Flow Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Chapter 1 Introduction to Control-M 41

INCONTROL Products and IOA

INCONTROL Products and IOA

The Control-M Automated Production Control and Scheduling System is a
component member of the INCONTROL family of products, a fully integrated suite
designed to automate, manage and streamline operations on the OS/390 or z/OS
mainframes. The INCONTROL family also includes client and server products that
facilitate the automation of other platforms.

IOA
The Integrated Operations Architecture (IOA) is at the heart of the INCONTROL
family of products. IOA has a common core of shared code as the foundation of its
architecture design. INCONTROL's IOA environment has several inherent design
advantages, including a common user interface and a shared data repository. A key
feature of the IOA environment is its integrated application design, which includes:

■ Integrated User Notification

■ Management by Exception
■ Integrated Scheduling
■ Interdependency and Interrelationship Handling
■ Common Help Facility
■ Integrated Management Reporting
■ Common Method for Sharing Information
■ Unified Installation and Maintenance
■ Unified Security Implementation
■ Open Interface Design

INCONTROL
The INCONTROL family of products includes:

Table 1 List of INCONTROL Products (part 1 of 2)

Product Description
Control-M Automated Production Control and Scheduling System
Manages and automates the setup, scheduling and execution
of jobs in the data center.
Control-M/Restart Restart Management System
Automates the activities that must be performed when
restarting failed jobs, including the scratching and
uncataloging of data sets created by failed jobs.

42 Control-M for z/OS User Guide

 Functional Approach

Table 1 List of INCONTROL Products (part 2 of 2)

Product Description
Control-M/Tape Removable Media Management System
Increases utilization of removable media and controls
retention periods. Prevents misuse of media, and provides
tape library and vault control.
Control-M/Analyzer Automated Information Integrity System
Performs in-stream validation, accuracy, and reasonability
checks on information used by data center production tasks
(for example, reports, databases).
Control-D Output Management System Automatically schedules and
controls every aspect of report processing and distribution,
including report decollating, bundling, printing, online
viewing, and archiving.
Control-V Quick Access Archive Viewing System
Provides online access to archived reports and documents by
indexed data retrieval.
Control-D/ Report Retrieval and Display System
Page On Demand Enables end users to retrieve and view pages of reports that
reside on mainframe storage in real time. Indexed reports can
be retrieved by index name and value. AFP and XEROX
reports can also be retrieved and displayed using
Control-D/WebAccess Server or Control-D/Page On Demand
API.
Control-D/ Image Image Output Management System
Enables output from commercial imaging equipment to be
imported into either Control-D or Control-V for decollation,
distribution and viewing, and into Control-V for archiving and
indexed retrieval.
Control-O Console Automation System and Desired State Monitoring
System
Monitors and automatically responds to messages, commands,
and data set events, as well as various other system events.

The Control-O/COSMOS feature allows for status monitoring

while maintaining all critical system objects in a desired and
ideal status.

Functional Approach
Control-M automates job processing in your data center.

■ It performs virtually all the job handling tasks of computer operators.

■ It provides an interface that enables the user to intervene in the process of

production management.

Chapter 1 Introduction to Control-M 43

Main Components

■ It provides continual data and status information regarding job processing.

Control-M contains many facilities and components. Working together, they

automate the data center. This chapter introduces the Control-M facilities and
components from a functional perspective, beginning with the major components
that comprise the heart of Control-M and progressing to the more minor components
that enhance the functionality of Control-M.

Main Components
The following components are essential to Control-M:

■ Job scheduling definitions

■ Active Jobs file
■ Control-M monitor

Job Scheduling Definitions

A job scheduling definition specifies criteria that identify decisions to be made, and
actions to be taken, regarding the handling of a particular job. Each job scheduling
definition contains the following sections:

Table 2 Job Scheduling Definition Sections

Section Description
General Parameters General information about the job (for example, identifies the
library and member in which the JCL is stored).
Basic Scheduling Criteria according to which Control-M schedules the job.
Parameters
Runtime Scheduling Runtime requirements that must be satisfied before Control-M
Parameters submits the job.
Post-processing Parameters Actions Control-M performs after the job ends, depending
upon the outcome of job execution. For example, Control-M
performs one set of actions if the job ends OK, but another set
of actions if an abend occurs.

Job scheduling definitions only need be defined once for each job in the production
environment. The mechanism used to define job scheduling definitions is discussed
in Chapter 2, “Online Facilities.” Once defined, a job scheduling definition is saved. It
can be modified later if required, and the changes saved.

Job scheduling definitions are stored in members in partitioned data sets (libraries),
as follows:

44 Control-M for z/OS User Guide

 Expanded Control-M Functionality

■ Job scheduling definitions for related applications are generally placed in a single
member, called a table.

■ Multiple tables are stored in partitioned data sets, called scheduling libraries.

■ Multiple scheduling libraries can be defined.

Active Jobs File

As mentioned above, each job scheduling definition contains criteria that determine
whether the job must be scheduled on a given day. If based on these criteria a job
must be scheduled, a copy of its job scheduling definition is placed in a file called the
Active Jobs file. The mechanism by which job scheduling definitions are placed in the
Active Jobs file is discussed in “Job Ordering and Job Forcing” on page 68.

Only jobs in the Active Jobs file are candidates for submission by the Control-M
monitor.

Control-M Monitor
The Control-M monitor handles and controls job processing:

■ It checks the runtime requirements specified in each job scheduling definition in

the Active Jobs file, monitors available resources and conditions in the
environment, and if it determines that the conditions and resources required by a
job are available, it allocates the resources and submits the job.

■ It monitors the execution of the job.

■ It implements post-processing decisions based on instructions in the job

scheduling definition and the results of the job execution.

The Control-M monitor operates continually. It evaluates the production

environment and implements decisions.

Expanded Control-M Functionality

This section describes facilities, features and capabilities of Control-M which
supplement the main components of the program.

Automating Job Scheduling: New Day Processing

One of the main purposes of Control-M is to automate job scheduling.

Chapter 1 Introduction to Control-M 45

Expanded Control-M Functionality

We have already explained that basic scheduling criteria for each job are defined in its
job scheduling definition, and that a copy of the job scheduling definition is placed in
the Active Jobs file when the basic scheduling criteria are satisfied.

The mechanism used to place job scheduling definitions automatically in the Active
Jobs file is called New Day processing.

At a set time each day (defined during installation as the start of day at the site),
Control-M performs New Day processing, during which:

■ Control-M performs a number of maintenance and cleanup functions that the

operator would otherwise have to perform manually.

■ Job scheduling definitions are selected from the tables (based on their basic
scheduling criteria) and are placed in the Active Jobs file. These jobs can then be
submitted and tracked by the Control-M monitor.

The implementation of automated job scheduling and New Day processing, and the
components of New Day processing, are discussed in detail in the INCONTROL for
z/OS Administrator Guide.

Automatic JCL Update: JCL and AutoEdit Facility

In the production environment, JCL must often be manually modified prior to
submission of a job, as in the following cases:

■ changing a parameter or a date card

■ supplying tape numbers in JCL procedures
■ eliminating steps under different run conditions, for example, when end of month
processing differs from normal daily run

Manual modification of the JCL is inconvenient at best, and it can be error-prone and
lead to serious problems. The JCL and AutoEdit facility offers an automated
alternative to manual JCL update.

The JCL and AutoEdit facility permits AutoEdit terms, such as AutoEdit variables,
functions, and control statements, to be specified in the JCL in place of values that
change from job submission to job submission. AutoEdit terms are prefixed by %%,
which distinguishes them from non-AutoEdit terms. For example, the term
%%ODAY is recognized as an AutoEdit term.

The values of user-defined variables that have been defined as Sysplex-wide, using
the XAE facility, remain both in memory and in a Coupling facility. These values can
be used for additional triggering of the same job or other Control-M jobs, in the same
computer or in different computers of the same Sysplex.

46 Control-M for z/OS User Guide

 Expanded Control-M Functionality

At time of job submission, AutoEdit terms in the JCL are resolved to their actual
values.

The inclusion of AutoEdit terms into the job stream and job scheduling definitions
can eliminate the need to change JCL once it is defined. AutoEdit usage can be further
simplified and enhanced through the Parameter Prompting facility, which is
described in “M4: Parameter Prompting Facilities” on page 347 and “Parameter
Prompting Facilities” on page 837.

As of version 6.1.00, Control-M/eTrigger can be used as an alternative to the

Parameter Prompting Facility. AutoEdit parameter values can be passed together
with the job scheduling definition when using the Control-M/Enterprise Manager to
order an unscheduled job. If this is done, these AutoEdit parameter values are
substituted for those already in the job scheduling definition prior to submission.

For more information on Control-M/eTrigger, see the Control-M/eTrigger

Administrator Guide.

The JCL and the AutoEdit facility is described in detail in Chapter 5, “JCL and
AutoEdit Facility.”

Automated Job Submission

Once a job has been placed in the Active Jobs file, the Control-M monitor does not
submit the job unless all its runtime scheduling criteria, as defined in the job
scheduling definition, are satisfied. Several types of runtime criteria can be defined.

Examples

Table 3 Runtime Criteria

Criteria Description
Time Submission must occur during a defined time range.
Priority Jobs can be assigned internal priorities, so that if two jobs are ready for
submission at the same time, the higher-priority job is submitted first.
Due Out If two jobs with the same priority are ready for submission, the job with
the earlier due out time is submitted first.

Workload Management
The purpose of Workload Management is to enable the user to define a set of global
rules at the enterprise level for a table of jobs which is separated from the individual
jobs’ definitions. This grouping is referred to as a Workload Entity and is essentially a
container containing jobs with similar attributes which have the global rules enforced
upon them.

Chapter 1 Introduction to Control-M 47

Expanded Control-M Functionality

With Workload Management the user can:

■ change resource allocation in a dynamic environment for specific applications

according to time periods

■ increase resource utilization by giving the user greater control over the resource
instances in the production environment

■ reduce the time required for the user to define and enforce execution attributes
relating resource consumption for groups of jobs

The Control-M Workload Manager enables the user to divide the load of jobs that run
under Control-M into smaller groups of jobs that share common characteristics. These
groups of jobs are called Workload Entities. A Workload Entity can be defined with a
set of rules called a Workload Policy. These user-defined rules can control resource
utilization and job execution of a workload. This is referred to as the logical side of
workload management.

Workload Policies are enforced on active jobs at order time before submission.
Modifications of a Workload definition affects the Active Jobs File (AJF) after all the
calculations of the Control-M/Server have taken place.

Users can monitor the production environment from one or more workload
perspectives or monitor all the workloads using the Workload Monitor.

Workload Entities are defined in the Control-M/Enterprise Manager GUI and

Control-M Desktop. For more information see Control-M User Guide.

Workload entities

A Workload entity is comprised of scheduling entities which are defined by a filter.

The rules of a Workload policy can control the utilization of resources by the
workload and manage the execution of the jobs in the workload from a single
interface. Workload policy rules and constraints are optional. A Workload entity may
be defined without a policy.

Workload filter

Jobs contain individual scheduling attributes. Jobs are included in a workload if they
contain the attributes defined in the Workload filter. The jobs in the filter contain one
or more shared scheduling attributes. All definable scheduling attributes in the filter
are optional, but at least one attribute must be defined to establish a pattern for the
workload’s jobs. Jobs can be included in more than one Workload.

To define the Workload filter, see the Control-M User Guide.

48 Control-M for z/OS User Guide

 Expanded Control-M Functionality

Limiting quantitative resources used by jobs workloads

A workload’s quantitative resources can be limited so that a workload does not take
ownership over all of the resource instances, preventing other jobs from using them.
This option is used to balance quantitative resource utilization among workloads.
The date and time this limitation is applied can also be defined.

Limiting simultaneous jobs running on Control-Ms

A user can define the maximum number of concurrently running jobs for a specific
Control-M. This option can be used to balance the load on execution hosts among
workloads. Different limits can be defined according to the submission date and time
of the workload.

Monitoring of Resources
Three types of runtime criteria require Control-M to monitor the existence of
conditions and the availability of resources system-wide. These conditions and
resources are mentioned briefly below and are discussed in greater detail in
“Control-M Concepts” on page 63:

Table 4 Conditions and Resources

Condition or Resource Description
Quantitative resources Quantity of a resource required by the job. For example, a job
may require two tape drives.
Control resources Mode (exclusive or shared) in which a resource is required. For
example, a backup job may require exclusive access to a
specified data set.
Prerequisite conditions User-defined conditions that must exist before a job is
submitted. A major use of prerequisite conditions is to
establish job dependencies.

The condition and resource requirements of a job are defined in the job scheduling
definition.

Prerequisite conditions are tracked by the IOA Conditions file. Existing and available
Quantitative resources and Control resources are tracked by the Control-M Resources
file. Prior to version 6.0.00, conditions and resources were stored in a single file, the
Conditions/Resources file.

When the prerequisite conditions and resources required by a job are available, the
job can be submitted by the monitor, if all other runtime scheduling criteria are
satisfied.

Chapter 1 Introduction to Control-M 49

Expanded Control-M Functionality

Immediate Detection and Notification of Problems: Shout

Facility
When a problem or an unexpected situation or delay occurs, Control-M can notify the
appropriate personnel. These situations and problems are detected by analysis of a
job sysout.

Notification is issued by the Shout facility, which can send messages to a variety of
destinations including the operator console, a TSO user, and the IOA Log file.

Control-M can also be instructed to issue a SHOUT message in the event an exception
occurs at time of job submission and/or during job execution, such as when a job
completes before, or later than, its anticipated completion time.

History Jobs File

During New Day processing, jobs that have ended OK or whose retention period has
expired according to job scheduling definition parameters are deleted from the Active
Jobs file.

These jobs can be placed in the History Jobs file during New Day processing. This is
an optional feature that can be activated by the INCONTROL administrator.
Activation of this feature is described under the HIST parameter in the INCONTROL
for z/OS Administrator Guide.

Jobs in the History Jobs file can by request be restored to the Active Jobs file, for
subsequent restart.

Jobs remain in the History Jobs file until they are deleted according to criteria defined
in the job scheduling definition.

The contents of the History Jobs file can be viewed from the History Environment
screen, which is described in Chapter 2, “Online Facilities.”

Journaling and Restoration Capability

The Control-M Journal file collects data about changes occurring in the Control-M
Active Jobs file, the IOA Conditions file and the Control-M Resources file during the
Control-M working day. This permits forward recovery of the Control-M
environment to any time of the day you may choose.

The Journal file is initialized each day during New Day processing. From that point
on, for the rest of the working day, the Control-M monitor records in the Journal file
all job processing activities that impact the Control-M Active Jobs file, and all
prerequisite condition additions to and deletions from the IOA Conditions file and
the Control-M Resources file.

50 Control-M for z/OS User Guide

 Expanded Control-M Functionality

If the Control-M Active Jobs file, and optionally the IOA Conditions file and the
Control-M Resources file, need to be restored, for example, following a system crash,
the CTMRSTR utility can be run to restore the files. The utility uses data from the
Journal file to restore the files to the status they had at any specific time after the last
run of the New Day procedure.

The Control-M Journal file is initialized each day during New Day processing.
Therefore, the time at which the New Day procedure initialized the Journal file is the
earliest time to which the Control-M Active Jobs file, the Control-M Resources file, or
the IOA Conditions file can be restored.

Journaling and Restoration is an optional feature that can be activated by the

INCONTROL administrator. It is described in the INCONTROL for z/OS Administrator
Guide. Activation of this feature is described under the JRNL parameter in the
INCONTROL for z/OS Installation Guide.

IOA Log Facility

Messages issued by Control-M are written to the IOA Log file. The IOA Log file is a
repository for messages issued by all INCONTROL products. Through the IOA Log
facility, the user can examine messages issued by Control-M during the processing of
a job.

Automated Job Post-Processing

Once the job has executed, the Control-M monitor implements the post-processing
instructions defined in the job scheduling definition. Post-processing instructions can
be defined for virtually any situation, such as job ended successfully, job abended, a
particular condition code occurred in a particular step, and so on.

As part of post-processing, Control-M can do the following:

■ add a prerequisite condition to, or delete a prerequisite condition from, the IOA
Conditions file

This can trigger or prevent the submission of a job in the Active Jobs file.

■ force the placement of a job scheduling definition into the Active Jobs file,
regardless of the basic scheduling criteria of the job

■ set AutoEdit variables

■ send (shout) a specified message to a specified location through the SHOUT

facility or by electronic mail

■ send a message by mail to the recipient identified by the mail name prefix

Chapter 1 Introduction to Control-M 51

Expanded Control-M Functionality

■ change the final status of a job to OK or NOTOK

■ handle the job SYSOUT

This includes changing its class, deleting it, rerouting it to another node, releasing
it for printing, or copying it to another location.

■ if Control-M/Analyzer is active, invoke a Control-M/Analyzer rule

■ rerun a job

■ perform an MVS job restart; for more information, see “OUT: Post–Processing
Parameter” on page 571

■ §Restart§ if Control-M/Restart is active, perform a Control-M/Restart job restart

■ §Restart§ if Control-M/Restart is active, automatically archive certain portions of

the job output

■ stop recycling of cyclic jobs

Utilities
Utilities provided with Control-M are used to perform a variety of management
functions and generate reports that assist in the efficient use of Control-M. Batch
utilities are described in the INCONTROL for z/OS Utilities Guide. Online utilities are
described in Chapter 2, “Online Facilities.”

Handling Jobs in the NJE Network

The Control-M monitor handles the control of complex distributed production
environments where jobs may be routed for execution to different nodes of the NJE
network according to the business needs of the enterprise.

Control-M differentiates between host and remote nodes in the NJE network as
follows:

Table 5 NJE Network Nodes

Node Description
Host node NJE network node under which the Control-M monitor is active and the
NJE job is submitted to MVS/JES by the monitor.
Remote node NJE network node to which a job was sent from the host node.

52 Control-M for z/OS User Guide

 Expanded Control-M Functionality

An NJE job is a job submitted by the Control-M monitor for execution on a remote
node. Control-M can detect the status of jobs running on a remote node so that once
these jobs finish executing, Control-M can assign a status to them.

Handling External Events: CMEM Facility

External events are events in the system that occur outside the control of the
Control-M monitor, such as the submission of a job. The Control-M Event Manager
(CMEM) facility enables Control-M to respond to and handle such events.

Through rules defined online through the CMEM Rule Definition facility, which is
described in Chapter 2, “Online Facilities,” the user specifies actions Control-M must
perform in response to external events.

The following types of events are handled by the CMEM facility:

Table 6 Event Types Handled by CMEM

Event Description
Job Arrival Arrival of a job on the JES spool, from any source.
Job End Completion of a job, regardless of its source.
Dataset Event Either the setting of a data set disposition at deallocation time or the
occurrence of a NOT CATLGD 2 event.
Step Termination of a procedure (and optionally, a program) step.

The following actions can be performed by the CMEM facility:

■ force one or more Control-M jobs

For more information, see “Job Ordering and Job Forcing” on page 68.

■ add prerequisite conditions to, or delete prerequisite conditions from, the IOA
Conditions file and the Control-M Resources file

■ stop the job in which the event occurs

■ invoke a Control-O rule, if Control-O is active at the site

■ send a message to a specified location using the Control-O SHOUT facility, if

Control-O is active at the site

■ bring under the control of the Control-M monitor a job submitted outside the
control of the Control-M monitor, such as a job submitted by a TSO user

Such a job is called an On Spool job, and the control of On Spool jobs is one of the
most important functions of CMEM.

Chapter 1 Introduction to Control-M 53

Expanded Control-M Functionality

The CMEM facility, and On Spool jobs, are described in Chapter 4, “CONTROL-M
Event Manager (CMEM).”

Using Calendars to Schedule Jobs: IOA Calendar Facility

Specification of scheduling criteria for jobs can be simplified by using calendars. A
calendar is a defined schedule that can be applied to jobs, such as Mondays through
Fridays in each week in each month.

Calendars are defined in the Calendar facility. Each calendar is assigned a unique
name that can be specified in job scheduling definitions. A particular calendar (that is,
schedule) need only be defined once.

Specifying the name of a calendar in job scheduling definitions causes that calendar
to be used to schedule those jobs.

Three types of calendars can be defined:

■ regular
■ periodic
■ rule-based

Regular Calendars

Regular calendars consist of scheduling dates or days of the week that can be defined
according to monthly patterns.

For example

■ WEEKDAYS – schedules jobs each Monday through Friday in each month.

■ WEEKENDS – schedules jobs on every Saturday and Sunday in each month.

■ QUARTERLY – schedules jobs on the last date in each quarter: March 31, June 30,
September 30, December 31.

Regular calendars are especially useful when many jobs have the same schedule.
Defining the schedule once in a calendar, and entering the calendar name in the job
scheduling definition of the jobs with that schedule, makes it unnecessary to
individually define that schedule in each job scheduling definition.

Periodic Calendars

Periodic calendars are especially useful when scheduling dates do not easily conform
to fixed date or day of the week or month patterns.

54 Control-M for z/OS User Guide

 Expanded Control-M Functionality

For example

■ PAYCAL – Calendar used for jobs that are scheduled every other Wednesday
(such as payroll jobs). Scheduling occurs on the first, third, and (if there is one) fifth
Wednesday of some months. Scheduling may occur on the second and fourth
Wednesday of other months.

Rule-based Calendars (RBC)

Rule-based calendars schedule jobs according to pre-defined rules and can be

referred to from any job definition. RBCs identify the set of scheduling criteria defined in
the SMART Table Entity or IOA Calendar Facility that can be used to schedule the job. This
criteria can be applied to any given year.

The IOA Calendar facility is described in Chapter 2, “Online Facilities.”

Accumulating Statistics: Statistics Facility

As part of the post-processing for each job, Control-M determines the elapsed run
time of the job. All accumulated information regarding job execution, including the
elapsed run time, is written to the IOA Log file.

Periodically, a statistics utility may be used to scan and analyze the IOA Log file. This
utility gathers information about the start time of each job, its elapsed run time, CPU
utilization time, and so on. The utility places this information in the Statistics file,
where averages of these values can be maintained for each job.

Statistics facility averages may be used for several purposes:

■ to determine if the execution time of a job falls outside of a statistically normal

range of time, which would indicate an execution delay or problem)

■ to calculate DUE-IN time for use by the Deadline Scheduling facility, which is
discussed under “Automatic Job Flow Adjustment” on page 77

■ to determine when a shout message must be issued based on the elapsed time of
the job

■ to simulate job executions and forecast the impact of changes to the system
(described briefly below)

■ to determine if a job can complete execution before the Control-M planned

shutdown time (QUIESCE command)

Chapter 1 Introduction to Control-M 55

Expanded Control-M Functionality

Simulating Job Execution and Forecasting Resource Usage:

Simulation and Forecasting Facility
Using statistics accumulated by the Statistics facility, the Simulation and Forecasting
facility simulates the actions of the Control-M monitor under the conditions specified
in simulation parameters.

The Simulation and Forecasting facility enables you to forecast anticipated job load
for a specified time in the future, and to forecast the effects of possible changes to the
system, such as the impact of:

■ removing four tape drives

■ increasing CPU power by 30%
■ changing the time at which certain jobs are executed

The Simulation and Forecasting facility can improve the efficiency of your site. It can
help with resource and configuration decisions, and it can help with the planning of
workload scheduling to achieve maximum utilization of resources.

Automatic Tape Adjustment

The Automatic Tape Adjustment facility collects and analyzes statistics regarding
tape drive usage, and automatically allocates the appropriate number of tape drives
at job order time. This facility, which can be implemented by your INCONTROL
administrator, overrides any tape drive Quantitative resource value specified in the
job scheduling definition. For more information, see “Statistics Screen” on page 245
and “RESOURCE: Runtime Scheduling Parameter” on page 605.

Reporting Facility
Control-M supports a comprehensive reporting facility, which can produce the
following types of reports:

Table 7 KSL Report Types

Reports Description
Keystroke Language These are reports generated with the Keystroke Language (KSL).
Reports KSL is a general purpose reporting language, based on the Online
facility, capable of producing numerous reports from the database,
and is described in the KeyStroke Language (KSL) User Guide.
Special Purpose These reports include the Job Flow reports that are generally used to
Reports track the dependencies between jobs, and the Job Plan reports that
are used to anticipate which jobs are scheduled each day.

56 Control-M for z/OS User Guide

 Expanded Control-M Functionality

Sample reports are provided in the IOA SAMPLE library. The Reporting facility is
described in the KeyStroke Language (KSL) User Guide.

Minus-One Support
Minus-One support is provided as part of Control-M and enhances Parallel Sysplex
support (CTMPLEX). With Minus-One support, Control-M users that implement
several Control-M monitors in a Sysplex environment can run several installations of
Control-M with different maintenance releases or different versions, in parallel. This
enables Control-M users to implement installation and upgrade procedures without
having to shut down their entire complex.

Minus-One support is available even at sites that are not operating in a Sysplex
environment.

WARNING
When upgrading a specific Control-M instance to a new release, you must not utilize features
of the new release until all other components (members of the Sysplex, application servers,
and so on) are similarly migrated. Doing so may lead to unpredictable results on Control-Ms
which have not been migrated.

Control-M interface to the IBM Health Checker

When the Control-M interface to the IBM Health Checker facility is enabled, the
Control-M monitor communicates with IBM Health Checker to run appropriate
checks to ascertain the status of various Control-M components, subtasks and
repositories. The Control-M monitor then alerts the user to any potential Control-M
problems via Health Checker reporting facilities. For more information on the IBM
Health Checker, see the IBM Health Checker for z/OS User's Guide (for z/OS 1.8 or
above).

The following checks are available:

■ Job processing delay - reports when one of various Control-M components or

subtasks (Submitter, Selector, Spyer) are not responding or experiencing undue
delays during job processing.

■ Active Jobs File (AJF) status - exception messages are issued when the Control-M
AJF utilization threshold has been reached or exceeded.

■ CTMPARM synchronization - reports inconsistencies between the values set in the

CTMPARM member of the IOA PARM library and the in-memory values of the
CTMPARM parameters.

■ DORMANT jobs check - exception messages are issued, when one or more jobs are
sitting in the Active Jobs file (AJF) for more than the defined number of days.

Chapter 1 Introduction to Control-M 57

Control-M Support for MAINVIEW Batch Optimizer

The Control-M interface to the IBM Health Checker is controlled by parameters set in
the CTMPARM member of the IOA PARM library. These parameters specify whether
to enable the health checker interface, whether to enable each of the health checks,
and the time interval at which the health checks should be run. All of these
parameters may be dynamically changed without restarting the Control-M monitor.
For more information on setting and modifying these parameters, see the
INCONTROL for z/OS Installation Guide.

Control-M Support for MAINVIEW Batch Optimizer

Control-M provides scheduling support for jobs that use pipes at sites that have
MAINVIEW Batch Optimizer (MVBO)/Job Optimizer Pipes installed. A pipe is a
processor storage buffer that enables data to be passed between applications without
using DASD or tape.

MVBO/Job Optimizer Pipes uses pipes to replace sequential job processing with
parallel processing wherever feasible. Jobs and job steps normally run sequentially
because they depend on data files that become available only after the application
that creates them completes execution. When pipes are used, an application does not
need to finish running before the data it generates is available to other applications.
This significantly reduces I/O operations and delays, and speeds up processing,
because pipes enable movement of data using processor storage instead of writing
and reading data to and from external storage.

Control-M scheduling support for MVBO/Job Optimizer Pipes consist of the

following components:

■ job scheduling definition support

■ enhanced runtime scheduling algorithm

These are described in the following paragraphs.

Job Scheduling Definition Support

A PIPE statement can be specified in the Control-M job scheduling definition for each
pipe accessed by the job. Each PIPE statement contains the pipe (data set) name. The
job scheduling definition of a participant includes a PIPE statement for each pipe
accessed by the job.

58 Control-M for z/OS User Guide

 Online User Interface to Control-M

Enhanced Runtime Scheduling Algorithm

Jobs sharing a pipe are called “pipe participants.” Control-M recognizes each set of
interrelated pipes and participants as a single, comprehensive unit called a
Collection. All pipe participants are submitted concurrently, after verification that all
required resources, such as prerequisite conditions or Quantitative resources, are
available. This method ensures that participants do not wait for other participants to
start executing, for example, at synchronization points.

For more information, see “MAINVIEW Batch Optimizer Considerations” on

page 835

Online User Interface to Control-M

Until now, we have seen how Control-M automates the production environment and
we have discussed a number of available facilities that enhance the functionality of
Control-M.

However, as mentioned earlier, Control-M provides an online user interface that

enables the user to:

■ interface with most of the previously described facilities

■ intervene in the process of production management
■ immediately access up-to-date information from the production environment

The online user interface is provided through online facilities that are accessed
through the IOA Primary Option menu.

Certain online facilities are unique to Control-M, and other facilities are shared by
many or all products.

All IOA and Control-M online facilities are discussed in detail in Chapter 2, “Online
Facilities.” They are all outlined briefly on the following pages.

NOTE
Your INCONTROL administrator can limit the options displayed on a user-by-user basis and
can modify option numbers and customize option descriptions. Default options are discussed
in this overview.

Chapter 1 Introduction to Control-M 59

Online User Interface to Control-M

Scheduling Definition Facility

The Control-M Scheduling Definition facility is accessed through option 2 of the
Primary Option menu. It is the main online facility for creating, defining, modifying,
and deleting

■ tables
■ scheduling definitions

In addition, this facility can be used to

■ edit the JCL of a job

■ produce a job (scheduling) plan
■ display job statistics
■ copy a job definition
■ graphically display a job flow of the jobs in a table
■ manually order or force jobs

NOTE
Ordering places the requested job in the Active Jobs file only if its basic scheduling criteria
are met. Forcing places the requested job in the Active Jobs file regardless of its basic
scheduling criteria.

Active Environment (Status) Screen: Online Tracking and

Control Facility
The Online Tracking and Control facility is accessed through option 3 of the IOA
Primary Option menu. It is the main user interface to the monitoring of the jobs
scheduled for the day. This facility consists of a number of screens, each providing
the user with relevant information and options.

The main screen of this facility is the Active Environment screen. (Prior to version
6.0.00, this screen, which displays the status of each job order in the Active Jobs file,
was referred to as the Status screen.) All screens and windows available in the Online
Tracking and Control facility are accessed through the Active Environment screen. In
the Online Tracking and Control facility, you can perform the following functions:

■ view the status of each job order in the Active Jobs file

■ place a job in HELD status or free a HELD job

■ delete a job order

■ obtain a statistical overview of the status of jobs in the Active Environment screen

60 Control-M for z/OS User Guide

 Online User Interface to Control-M

■ see why a job in the Active Jobs file has not been submitted. If job submission is
held up due to missing prerequisite conditions, you can optionally add those
conditions manually

■ display the Log file of a job to view all messages issued for the job

■ zoom in on the parameters of a job order

This includes not only the job scheduling definition parameters, but also
parameters determined by the Control-M monitor at runtime. Manual update of
some of these parameters for the job order is permitted.

■ view the documentation of a job

■ add notes to a job, for example, to document actions that were taken

■ confirm the scheduling, rerun, or restart (if Control-M/Restart is active), of a job

that has been defined as requiring manual confirmation

■ §Restart§ view the execution history of all orders of a job, and view the job order
sysouts

■ view the accumulated statistics of job executions

■ view the list of job dependencies for a specific job, that is, the predecessor and
successor jobs of the selected job, and perform manual job flow adjustment, such as
priority adjustment

You can filter which jobs in the Active Jobs file are displayed in the Active
Environment screen.

CMEM Rule Definition Facility

The CMEM Rule Definition facility is accessed through option C of the INCONTROL
Primary Option menu. CMEM rules enable Control-M to respond to external events.
The CMEM Rule Definition facility is an online facility that enables the user to create,
define, modify and delete

■ CMEM rule tables

■ CMEM rules

The user can load rule tables to memory from the CMEM Rule Definition facility.
Rule tables can also be loaded to memory by an operator command.

Chapter 1 Introduction to Control-M 61

Online User Interface to Control-M

IOA Conditions/Resources Screen

The IOA Conditions/Resources screen is accessed through option 4 of the IOA
Primary Option menu. It displays information from the IOA Conditions file, which
contains the list of all existing prerequisite conditions, and the Control-M Resources
file, which contains the list of Quantitative resources and Control resources. The IOA
Conditions/Resources screen enables the user to

■ view IOA prerequisite conditions

■ view Control-M Quantitative resources
■ add or delete prerequisite conditions and/or resources
■ change the available quantity of Quantitative resources

IOA Log Screen

The IOA Log screen, accessed through option 5 of the IOA Primary Option menu,
displays the IOA Log file. The IOA Log file contains messages that record every
significant event in the life of all jobs or started tasks, rules, missions, and other
functions that are under the control of IOA products. This includes messages
generated for normal processing, such as job submitted, error conditions (if any)
encountered during processing, and messages directed to the Log file from the
SHOUT facility.

The user can filter IOA Log file contents displayed in the IOA Log screen.

IOA Manual Conditions Screen

The IOA Manual Conditions screen is accessed through option 7 of the IOA Primary
Option menu. It displays the IOA Manual Conditions file, which contains the list of
prerequisite conditions that must be added manually. These are IN conditions that
are required by scheduled jobs but are not added by scheduled jobs, that is, these
conditions are not listed as OUT conditions or DO COND actions in the Active Jobs
file.

These conditions fall into the following categories:

■ conditions that are never automatically added by scheduled jobs because manual
confirmation is always desired, for example, TAPE-ARRIVED

■ conditions that are normally added automatically by scheduled jobs, but the jobs
that add them are not scheduled

For the conditions listed in the Manual Conditions screen to be added to the IOA
Conditions file, manual intervention is required.

62 Control-M for z/OS User Guide

 Control-M Concepts

The Manual Conditions list is described in Chapter 6, “Selected Implementation

Issues.”

The IOA Manual Conditions screen enables the user to:

■ view the list of Manual Conditions

■ select and add listed conditions, as desired, to the IOA Conditions file

IOA Calendar Facility

The IOA Calendar facility is accessed through option 8 of the IOA Primary Option
menu. IOA calendars allow definition of common scheduling patterns that simplify
the entering of basic scheduling criteria in job scheduling definitions.

The IOA Calendar facility enables the user to create, define, modify and delete IOA
calendars.

Online Utility Screens (Under ISPF)

When Control-M and other INCONTROL products (if any) are active under ISPF, a
number of utilities and facilities can be activated online. The IOA Online Utilities
menu is accessed through option 6 of the IOA Primary Option menu (under ISPF).
The IOA Online Utilities menu displays available utilities from which the desired
utility or facility can be selected.

Control-M Concepts
Having discussed Control-M from a functional viewpoint, and having briefly
outlined the online user interface to Control-M, it is now worthwhile to discuss
certain important concepts in Control-M functioning.

IOA Core and Control-M Repository

A differentiation is made between files belonging to a particular INCONTROL
product such as Control-M, and IOA files that are shared among INCONTROL
products.

Chapter 1 Introduction to Control-M 63

IOA Core and Control-M Repository

Shared IOA files are collectively referred to as the IOA Core. The IOA Core consists of
the following files:

Table 8 IOA Core Files

File Description
IOA Log file File in which all events related to job processing are recorded.
IOA Conditions filea File that lists the available conditions identified and tracked by the
Control-M monitor.
IOA Manual File listing prerequisite conditions that must be added manually, that
Conditions file is, prerequisite conditions required by jobs that have been ordered to
the Active Jobs file and which are not automatically added by other
jobs in the Active Jobs file.
IOA Calendar tables Files containing IOA calendar definitions.
Dynamic Destination File containing a list of destinations for messages issued by the IOA
table Shout facility.
Mail Destination table File containing a list of mail destinations for messages issued by the
IOA Shout facility.
Files belonging to a particular INCONTROL product are called the repository of that
product. The Control-M Repository consists of the following files:
Active Jobs file File used to hold copies of the job scheduling definitions of those jobs
that have been ordered that working day.
Control-M Resources File that lists the available resources identified and tracked by the
filea Control-M monitor.
Scheduling tables Files containing job scheduling definitions.
CMEM Rule tables Files containing CMEM rule definitions.
Job Statistics file File containing the execution statistics of all jobs.
Job Network file File containing dependency information about the jobs in the Active
Jobs file.
History Jobs file File containing jobs that ended OK or expired.
Journal file File containing data about changes to the Control-M Active Jobs file,
the Control-M Resources file, and the IOA Conditions filea, and
which can be used for Restoration purposes.
a
Prior to version 6.0.00, conditions and resources were stored in a single file, the IOA
Conditions/Resources file.

64 Control-M for z/OS User Guide

 Date Definition Concepts

Date Definition Concepts

INCONTROL recognizes the following types of date definitions. Depending on the
INCONTROL product, either all of them, or some of them, are relevant. All these
types are relevant for Control-M:

Table 9 Date Definition Types

Date Definition Description
System date Date as supplied by the operating system. This date must be the
actual calendar date starting and ending at midnight.
Working date Many sites do not use midnight as the formal time for changing to a
new date. A site, for example, may determine that all processing
performed between the hours of midnight and 6:00 a.m. “belongs to”
the previous day. In this case, the installation working date at the site
changes at 6:00 a.m., not at midnight.

The working date, that is, the time at which the date changes at the
site, is defined in the Control-M installation parameters. New Day
processing generally begins at the start of the new working date.
Original scheduling Job orders and prerequisite conditions managed by Control-M are
date assigned an original scheduling date, which is referred to as ODATE.
For the full implications of using ODATE, see “ODATE” on
page 158. For details of the enhanced meaning of ODATE as of
version 6.1.00, see “Enhanced Definition of ODATE” on page 66.

Example 1

A computer is down for repairs on February 2nd and 3rd. When it is brought up on
February 4th, a two-day backlog of jobs must be run in addition to the jobs of the
current day.

When the New Day procedure scans tables on February 4th, it places job orders in the
Active Jobs file for all three days. Jobs that ought to have run on February 2nd are
assigned an ODATE of February 2nd, jobs for February 3rd are assigned an ODATE
of February 3rd, and so on.

In this manner, each job is executed as if it had run on the working date on which it
was originally scheduled.

Example 2

ODATES are calculated according to the working date, and not the calendar date.

If you define a job to run on 5 December at 3 A.M., and the working day begins (and
the New Day procedure operates) at 5 A.M., the job will not run until 3 A.M. on
6 December, because that is still part of the working day of 5 December.

Chapter 1 Introduction to Control-M 65

Date Definition Concepts

Enhanced Definition of ODATE

As of version 6.1.00, ODATE has an enhanced definition. ODATE can also be one of
the runtime criteria, such as IN conditions, that must be satisfied before a job can be
submitted. Runtime criteria are explained in “Automated Job Submission” on page 47
and “Monitoring of Resources” on page 49.

While prior to version 6.1.00 the ODATE was only a VALUE date, it can now be both
a RUN date and a VALUE date.

ODATE with the Attribute VALUE

In most cases, ODATE by default has the attribute VALUE. This means that it is a
VALUE date, and is not one of the runtime criteria.

When ODATE has the attribute VALUE, it has the following characteristics:

■ ODATE is a logical date that is used by Control-M when adding jobs to the Active
Jobs file for execution. The ODATE is assigned to a job by manual order or by
operation of the New Day procedure.

■ The ODATE is a 24 hour period. It begins at the New Day time. During the 24 hour
period that follows that New Day time, all job scheduling is based on the ODATE,
which corresponds to the calendar date at that New Day time, rather than the
calendar date at the time when the job runs.

■ The ODATE can coincide with, precede, or follow the calendar date. If no value is
set for the DAYTIMEM parameter in the CTMPARM member, the ODATE
coincides with the calendar date. If the DAYTIMEM parameter is set using a -
(Minus) sign, the ODATE precedes the calendar date by the number of hours and
minutes specified in that parameter. If a + (Plus) sign is used, the ODATE follows
the calendar date in a similar manner.

For more information on the DAYTIMEM parameter, see the description of

operational parameters in the Control-M chapter of the INCONTROL for z/OS
Installation Guide.

■ When a job is eligible to be ordered on an ODATE, it is placed in the Active Jobs

file, and is immediately eligible for submission as soon as all its runtime criteria,
such as TIME FROM and TIME UNTIL, have been met.

■ When the end of the ODATE arrives, the New Day procedure may remove jobs
with that ODATE from the Active Jobs file, depending on the setting of the
MAXWAIT parameter of the specific job. Jobs removed in this way cease to be
eligible for submission.

66 Control-M for z/OS User Guide

 Date Standards and Date Field Formats

ODATE with the Attribute RUN

Although by default ODATE has the attribute VALUE, it may also have the attribute
RUN, if either set by the user, or the New Day procedure. In such cases, a job can only
run when its ODATE is the same as, or after, the Control-M logical date. In other
words, the ODATE becomes a runtime criteria.

In this context, runtime criteria are the criteria that determine the eligibility
“window” for the submission of the job, that is, the period of time during which the
job can be submitted. This eligibility window is determined by the ODATE and the
TIME ZONE parameter setting.

For information on changing the attribute of ODATE from VALUE to RUN, see the
description of the Time Zone feature in the INCONTROL for z/OS Administrator Guide,
and the description of the CTMJOB utility in the INCONTROL for z/OS Utilities Guide.

Date Standards and Date Field Formats

Date standards and date field formats use either Gregorian or Julian dates.

Gregorian Dates
Gregorian dates are indicated in the guide by the following symbols:

Table 10 Gregorian Date Notation

Symbol Description
dd Day of the month (01 – 31)
mm Month (01 – 12)
yy Last two digits of the yeara
yyyy Four digits of the year
a
If the last two digits in the specified year are a number less than 56, IOA presumes that the
year is in the 21st century; for example, if yy=15, the year 2015 would be presumed.
Otherwise, IOA presumes that the year is in the 20th century; for example, if yy=80, the year
1980 would be presumed.

Whether a field holds a 4-character date (month and day), a 6-character date (month,
day and 2-digit year) or an 8-character date (month, day and 4-digit year) depends on
the field definition. However, the format of the 4-character, 6-character or 8-character
date depends on the date standard defined during installation.

INCONTROL products support three date standards for Gregorian dates. Each
standard has an 8-character format, a 6-character format and a 4-character format.
Only one Gregorian date standard is defined at any site.

Chapter 1 Introduction to Control-M 67

Job Ordering and Job Forcing

These supported Gregorian date standards are described in the chart below.

Table 11 Supported Gregorian Dates

Standard 4-Character Date 6-Character Date 8-Character Date
MDY mmdd mmddyy mmddyyyy
DMY ddmm ddmmyy ddmmyyyy
YMD mmdd yymmdd yyyymmdd

Julian Dates
Julian dates (also supported by INCONTROL products) are indicated in the guide by
the following symbols:

Table 12 Julian Date Notation

Symbol Description
jjj or ddd Day of the year (001 – 365 or 366, as appropriate for the year)
yy Last two digits of the year
yyyy Four digits of the year

Julian date fields have either three, five, or seven characters. Whether a Julian date
field holds a 3-character date (day of year only), 5-character date (day of year and
2-digit year) or a 7-character date (day of year and 4-digit year) depends on the field
definition. However, the format of the date depends on the installation-defined date
standard.

For example, the Julian date for the calendar date of 28 February 2001 would be
represented in jjj or ddd format as 059, in yyjjj or yyddd format as 01059, and in
yyyyjjj or yyyyddd format as 2001059.

Job Ordering and Job Forcing

Job ordering is the placing of a job scheduling definition in the Active Jobs File when
the basic scheduling criteria of the job are satisfied.

Most production jobs are automatically ordered during New Day processing.
However, jobs can be manually ordered, as well.

Job forcing is the placing of a job scheduling definition in the Active Jobs file
regardless of the basic scheduling criteria of the job.

Although any job can be forced, job forcing is generally requested for special purpose,
or exception, jobs that are not normally scheduled:

68 Control-M for z/OS User Guide

 Rerun and Restart

■ Jobs can be automatically forced as part of the post-processing of another job. For
example, a particular job may be required only if a certain other job abends. In this
case, it is forced during the post-processing for the abended job.

■ Jobs can also be forced manually. For example, a routine job that is generally
ordered automatically according to its scheduling criteria can be manually forced,
if required, on a day it is not normally scheduled.

Rerun and Restart

Rerun and restart are two distinct, though related, concepts.

Rerun is the re-execution of a job from the beginning. Job rerun is a Control-M
feature.

Restart is the re-execution of a job from a predefined step. Restart is usually

performed from the step that failed, although it can be performed from an earlier
step, if necessary. Restart utilizes the successful steps from the failed job execution,
thereby limiting the amount of processing required to complete successful job
execution. This results in lower CPU overhead, and can make a big difference in the
timely completion of processing.

A basic MVS restart capability is available, and is described in “OUT: Post–Processing

Parameter” on page 571. BMC Software do not recommend this method. This type of
restart starts execution of the job from the failed step. However, no auxiliary restart
functions are performed.

§Restart§ By contrast, at sites in which Control-M/Restart is installed, restart under

Control-M/Restart is available. In addition to performing restart from the desired
step, with the capability of automatic step rollback when necessary,
Control-M/Restart automatically performs auxiliary restart functions. These include
the cataloging and scratching of data sets, prevention of NOT CATLGD 2 errors, and
so on.

§Restart§ Instructions for rerun and restart can be defined in the job scheduling
definition. Rerun is defined with the DO RERUN statement. Restart is defined with
the DO IFRERUN statement. They can be defined to be performed automatically or to
be performed upon manual confirmation. For more information, see “DO RERUN:
Post–Processing Parameter” on page 469, “§Restart§DO IFRERUN: Post–Processing
Parameter” on page 453, and the Control-M/Restart User Guide. §Restart§

Chapter 1 Introduction to Control-M 69

Order ID

Order ID
Control-M can handle multiple orders of the same job. To distinguish between the job
orders, Control-M assigns each job order a unique order ID. Therefore, it is not
uncommon to see the same job name with multiple order IDs, each representing a
different job order, in the Active Environment screen.

SYSDATA
SYSDATA is the term used to designate the data in three job sysout data sets:

■ job log (console messages)

■ expanded JCL
■ system output messages

SYSDATA data sets are usually produced for each execution of a job or started task.
However, not all three data sets are necessarily present in all cases. For example, in
JES2, if a job is canceled by the operator before execution, the system output messages
data set might not be produced.

For jobs, the output class for this data is defined by one of the following:

■ MSGCLASS parameter on the job card, which is added or overwritten by

Control-M during job submission

■ JCL job-level //OUTPUT statement using the JESDS subparameter

■ default values defined in JES initialization parameters

■ for started tasks, in JES initialization parameters

When Control-M/Restart is installed, it uses the SYSDATA to analyze the execution

of a job order, beginning with the archived SYSDATA of the most recent
non-restarted run.

Handling of Jobs
Normally, jobs in a table are processed independently of each other—each job is
handled only according to the parameters in its own job scheduling definition.

70 Control-M for z/OS User Guide

 Handling of Jobs

However, you can define a SMART Table in the Scheduling Definition facility which
supports handling the set of jobs in the table as a unit. The scheduling definitions of
the jobs as a unit are defined in the SMART Table Entity. Each job in the SMART
Table is handled according to the relationship between the basic scheduling criteria of
the job and the basic scheduling criteria of the SMART Table Entity. These include:

Table 13 SMART Table Handling Criteria

Criteria Description
Basic Scheduling criteria Scheduling criteria to be applied to jobs in the SMART Table.
Runtime Scheduling criteria Required runtime criteria for all scheduled jobs in the SMART
Table.
Post Processing actions Actions to be performed when all scheduled jobs in the
SMART Table have finished executing with the appropriate
status.

When jobs are ordered, you will be able to monitor the status of the jobs in and
perform actions on the jobs individually. In addition, when a SMART Table is
ordered, you will be able to monitor the status of and perform actions on the table.
For example, just as you can define post-processing tasks that Control-M should
perform when a job successfully ends, you can define post-processing tasks that
Control-M should perform when all the jobs in a SMART Table successfully end.

NOTE
The tables that appear in the active environment were defined as SMART Tables.

Dynamic SMART Table Insert

When a SMART Table is ordered, some or all of its jobs and the SMART Table Entity
are placed in the Active Jobs file. The Dynamic SMART Table Insert facility makes it
possible to insert additional jobs into the SMART Table that is already in the Active
Jobs File.

The additional jobs must be jobs may be any defined job. If the jobs belong to the
SMART Table, they may be either or both of the following:

■ jobs that were not scheduled at the current time

■ additional copies of jobs that are already in the Active Jobs file

For more information about using the Dynamic SMART Table Insert facility, see the
description of the job ordering facility CTMJOB in the Control-M Utilities chapter of
the INCONTROL for z/OS Utilities Guide.

Chapter 1 Introduction to Control-M 71

Prerequisite Conditions

Prerequisite Conditions
The prerequisite condition concept is one of the key concepts of Control-M
production control.

Prerequisite conditions enable the establishment of job dependencies and, when a job
normally requires manual intervention, such as determination that a cartridge
arrived on-site, ensures that the manual conditions are satisfied before the job is
submitted.

A prerequisite condition is a user-defined, descriptive name given to a certain

situation or condition. Prerequisite conditions can be specified in any of three types of
statements in a job scheduling definition:

Table 14 Prerequisite Condition Statements

Statement Description
IN statements These statements must be satisfied (that is, the prerequisite condition
must exist) before the job can be submitted.
OUT statements These statements are performed, that is, the prerequisite conditions
are added or deleted, only when the job ends OK.
DO COND Whether these statements are performed (that is, the prerequisite
statements conditions are added or deleted) depends on the execution results of
the job.

DO statements in a job scheduling definition accompany ON

statements. The ON statements define step and code criteria. If the
specified code criteria are satisfied for the specified steps, the
accompanying DO statements are performed.

In its most basic form, a prerequisite condition is defined in an IN statement in one

job, and as an OUT (or DO COND) statement in another job. This makes the
execution of the one job dependent on the execution of the other job.

72 Control-M for z/OS User Guide

 Prerequisite Conditions

Example

Figure 1 Establishing Job Dependency by Prerequisite Conditions

Payroll-calculating job PAYCALC must be run before Payroll-check-printing job

PRINTPAY. To create the necessary job dependency, a prerequisite condition is
defined as follows:

■ Prerequisite condition PAYCALC-ENDED-OK is defined as a runtime scheduling

criteria in the job scheduling definition for job PRINTPAY.

■ Prerequisite condition PAYCALC-ENDED-OK is defined as a post-processing

parameter for job PAYCALC, only when job PAYCALC terminates successfully.

Because the condition required by job PRINTPAY is not created unless job PAYCALC
terminates successfully, the dependency of job PRINTPAY on job PAYCALC is
established.

Job dependencies do not have to be as simple as the above example illustrates. An

almost unlimited number of conditions and job dependencies can be created:

■ jobs can be dependent on more than one prerequisite condition

■ jobs can add and/or delete more than one prerequisite condition

■ the same prerequisite condition can be added by more than one job (caution must
be used)

Chapter 1 Introduction to Control-M 73

Prerequisite Conditions

■ the same prerequisite condition can be used as an IN condition for more than one
job

In SMART Tables (described in “Handling of Jobs” on page 70), prerequisite

conditions can be defined as the following SMART Table parameters: IN, OUT
and/or DO COND statements. In this case, they apply to the entire set of scheduled
jobs.

Prerequisite Condition Dates

IN, OUT, and DO COND statements provide a field for specifying a date to
accompany each prerequisite condition. An OUT or DO COND prerequisite
condition that is added with a particular date cannot satisfy the same IN prerequisite
condition if the IN statement specifies a different date.

Example

JOB_A and JOB_B each run daily, and JOB_B is dependent on JOB_A.

(JOB_A has prerequisite condition JOB_A_ENDED_OK as an OUT condition, and

JOB_B has the same condition as an IN condition.)

The date associated with a condition is important because it is absolutely necessary

that, on a given day, JOB_B not be triggered by an occurrence of the condition
JOB_A_ENDED_OK from a previous day.

Certain Date keywords can be specified in place of, and resolve to, actual date values.
For example, keyword ODAT is automatically replaced by the original scheduling
date of the job.

Another important keyword for use in place of an actual date is STAT. STAT is used
as a date reference for conditions that are static, that is, not date-dependent.

For example, condition IMS_ACTIVE is added when IMS is brought up, and only
deleted if IMS is brought down. The date of the condition is irrelevant to jobs
requiring that condition. Therefore, this condition would be referenced with a date
value of STAT.

NOTE
Before STAT was introduced, date 0101 was recommended to be used in conditions that were
not date-dependent. Unlike 0101, STAT is not a date, and it operates differently. Always use
STAT when defining conditions that are not date-dependent.

74 Control-M for z/OS User Guide

 Prerequisite Conditions

Deleting Conditions
The last job to require a particular prerequisite condition, that is, in an IN statement,
can also mark that condition for deletion, that is, in an OUT statement. The deletion of
unnecessary conditions can serve the following purposes:

It can eliminate unnecessary clutter from the IOA Conditions file and the Control-M
Resources file, and the IOA Conditions/Resources screen.

When dependent jobs are scheduled multiple times each day, it can prevent the
execution of the earlier scheduled “predecessor” job from incorrectly causing the
submission of the later scheduled “successor” job.

Conditions Requiring Manual Intervention

Prerequisite conditions can be used to ensure that a required manual operation has
been performed. The following example illustrates such a condition.

Example

The job scheduling definition of JOB-A specifies prerequisite condition

TAPE-ARRIVED as runtime scheduling criteria. When the operator sees that JOB-A is
waiting for this condition to be satisfied, the operator can verify that the required
external tape has arrived at the site, and then use the online facility to manually add
the condition to the IOA Conditions file (through the Manual Conditions screen, the
IOA Condition/Resources screen, or the Why screen). The job can then be submitted
by Control-M.

Maybe Jobs
In some cases, job dependencies created by prerequisite conditions are desired only if
the predecessor jobs are scheduled. If the predecessor jobs are not scheduled, ignore
the dependencies.

Such dependencies are called Maybe dependencies, and the unscheduled predecessor
jobs that are ignored if they are not scheduled are called Maybe jobs. Conditions set
by unscheduled Maybe jobs appear in the Manual Conditions file.

The Manual Conditions file and the handling of Maybe jobs are discussed in
Chapter 6, “Selected Implementation Issues.”

Chapter 1 Introduction to Control-M 75

Quantitative and Control Resources

Quantitative and Control Resources

To prevent bottlenecks and help guarantee successful execution of jobs, Control-M
provides tools to ensure that a job is not submitted for execution until all resources
required by the job are available.

Quantitative Resources
Specification of Quantitative resource requirements for a job provides a solution for
the allocation of quantitative computer resources, such as cartridge drives, CPU
utilization, and database access-rate. It increases computer throughput by controlling
access to these resources, thus preventing execution bottlenecks.

Control-M maintains a continuously updated status of the Quantitative resources of

the site in the Control-M Resources file.

When a Quantitative resource is specified for a job, Control-M determines if a

sufficient quantity of the specified resource is available before submitting the job.
When the job is submitted, the specified quantity of resource is allocated to that job
and is unavailable to other jobs. When the job finishes executing, the resource is made
available to other jobs.

The quantity of each resource that is available in the data center is specified using
Control-M utilities. An authorized user can dynamically change these quantities
manually from the IOA Conditions/Resources screen.

Control Resources
Specification of resource control requirements for a job provides a solution for the
problem of resource sharing between different jobs. The mode (Exclusive or Shared)
in which a resource is required by a job can be specified.

For example, a job that reads a database without performing updates can access the
database in Shared mode; any other job requiring read-only access to the database
can access the database at the same time. Conversely, a job that updates the database
may require Exclusive control of the database at the time of update such that no other
jobs can share the database.

In the example just presented, the database can be defined as a Control resource, and
the type of control required by the job (Exclusive or Shared) can be specified for the
resource.

Control-M considers the mode of resource usage required when allocating Control
resources and prevents jobs whose resource usage is incompatible from executing
simultaneously.

76 Control-M for z/OS User Guide

 Job Priority

Job Priority
The job scheduling definition may include a specification of an internal priority for
the job. When competing for the same resource, jobs with higher priority take
precedence over jobs with lower priority. Users can also assign a “critical path”
priority to jobs that must be submitted with the least delay possible. A job with
critical path priority is allocated required resources as the resources become available.
When all its required resources are available, the job is submitted.

Noncritical jobs are not allocated resources until all required resources are available
at the same time.

Automatic Job Flow Adjustment

Predecessor and successor job flows are established through the use of prerequisite
conditions that are defined in the job scheduling definition. Successor and
predecessor jobs are identified as either “immediate” or “eventual,” relative to a
specified job:

■ An immediate predecessor and successor relationship exists between jobs when

one job is directly dependent on prerequisite conditions added by the other job.

■ An eventual predecessor and successor relationship exists between jobs if their

dependency is indirectly established through a “chain” of immediate predecessor
and successor jobs.

From the network of predecessor and successor jobs, critical paths can be identified.
A critical path is a chain of jobs that must be executed in their appropriate sequence in
order for a specified job to run. A job can have more than one critical path, if different
jobs set the same OUT condition, or if a job has OR logic in its IN conditions.

The Job Dependency Network screen, accessed through the Active Environment
screen, enables you to view the network of predecessor and successor jobs for a
specified job and determine the critical paths for the job.

Although it is prerequisite conditions that define predecessor and successor job

relationships, the actual job flow along a critical path can be greatly impacted by the
following runtime scheduling criteria in the job scheduling definition:

Table 15 Runtime Scheduling Criteria

Criteria Description
PRIORITY As mentioned earlier in “Job Priority,” a PRIORITY value affects the
selection order of the job (relative to other jobs).
DUE OUT The date and time by which the job must finish executing.

Chapter 1 Introduction to Control-M 77

Automatic Job Flow Adjustment

In some cases, it may become desirable to adjust the priorities or due out dates and
times of certain job orders.

Examples

■ A high priority successor job is waiting for the submission (and completion) of a
lower priority predecessor job.

■ A predecessor job cannot terminate early enough for a successor job to terminate
by the due out date and time of the successor.

Both types of job flow adjustments can be requested from the Job Dependency
Network screen:

■ Priority Propagation

The priority value of each non-Held predecessor and successor job is checked and
(if necessary) modified so all jobs in the chain have a priority, and no job has a
lower priority than any of its successor jobs.

■ Deadline Adjustment

Starting with the latest eventual successor job in the job flow, the anticipated
elapsed time (that is, anticipated execution time) is subtracted from the DUE OUT
date and time to determine DUE OUT date and time of the immediate
predecessors of that job.

This process of subtracting elapse times of a job to determine the DUE OUT date
and time of the immediate predecessor jobs are repeated until the DUE OUT date
and time of the initial or current job is determined.

■ If the user entered an ELAPSE time value in the Online Tracking and Control
facility Zoom screen, this value is used for the above calculation.

■ If the user did not enter an ELAPSE time value, the anticipated elapse time is
determined by the average runtime taken from the Control-M Statistics file.

Note the following points:

■ By subtracting the ELAPSE time of a job from its DUE OUT date and time, the
Control-M monitor calculates a DUE IN date and time (that is, the date and time by
which the job must be submitted) for each job. The DUE IN time, ELAPSE time,
and DUE OUT time are also displayed in the Job Dependency Network screen.

■ The ELAPSE time, DUE OUT date and time, DUE IN date and time, and
PRIORITY values for a job are also displayed in the Zoom screen, which is
accessed through the Active Environment screen.

78 Control-M for z/OS User Guide

 Automatic Job Flow Adjustment

■ DUE OUT date and time, ELAPSE time and PRIORITY values can also be
manually modified in the Zoom screen, but it is recommended that this not be
done, and that automatic job flow adjustment be requested instead.

Deadline adjustment will work correctly only if all the jobs have the same time zone,
or all the jobs have no time zone.

Chapter 1 Introduction to Control-M 79

Automatic Job Flow Adjustment

80 Control-M for z/OS User Guide

 Chapter

2
2 Online Facilities
This chapter includes the following topics:

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
IOA Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
General IOA Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
IOA Entry Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
IOA Primary Option Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Multi-Screen Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Fast Exit from the IOA Online Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Screen Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Commands and PFKeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
AutoRefresh Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
IOA Under ISPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
IOA Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
IOA SET Command Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
IOA TSO Command Processor Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Scheduling Definition Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Accessing the Scheduling Definition Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Handling of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Creating Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Creating Job Scheduling Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Performing Operations on Tables and Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Table List screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Job List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Job Scheduling Definition Screen – Defining Schedules . . . . . . . . . . . . . . . . . . . . 131
Exiting the Scheduling Definition Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Ordering (Scheduling) Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Copying Jobs to Another Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Deleting Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Condition Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Displaying Graphic Jobflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Displaying a Job Scheduling Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Tracking and Control Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Active Environment Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Chapter 2 Online Facilities 81

 Global View Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
View Graph Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Why screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Deleting a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Log Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Confirm Scheduling Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Confirm Rerun Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
§Restart§ Confirm Restart Window (Under Control-M/Restart). . . . . . . . . . . . . 231
§Restart§Rerun and/or Restart Window (Under Control-M/Restart) . . . . . . . . 231
Rerun Flow Job List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Step List Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
§Restart§Job Order Execution History Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
§Restart§ Sysout Viewing Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Statistics Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Job Dependency Network Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
History Environment Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Force OK Confirmation Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
CMEM Rule Definition Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Table List Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Rule List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Rule Definition Screen – Defining Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Entering Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Editing CMEM Rule Definitions in the Edit Environment . . . . . . . . . . . . . . . . . . 270
Exiting the CMEM Rule Definition Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Deleting Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Ordering CMEM Rule Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Copying Rules to Another Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
IOA Variables Database Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Database List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Values of Database Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Variable Zoom Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Condition and Resource Handling Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
IOA Conditions/Resources Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
IOA Manual Conditions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
IOA Log Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
IOA Log Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
IOA Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Accessing the IOA Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Defining a regular/periodic calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Year List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Copying Years to Another Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Calendar Definition Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Defining rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Selecting rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Deleting rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

82 Control-M for z/OS User Guide

 Renaming rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Copying rule-based calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Exiting the IOA Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Calendar Facility Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Exiting the Calendar Definition Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Exiting the Year List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Exiting the Calendar List Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Exiting the Entry Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Utilities Under ISPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
IOA Online Utilities Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
I1: Add, Check, or Delete a Prerequisite Condition . . . . . . . . . . . . . . . . . . . . . . . . 334
M1: Issue a Job Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
M2: Perform an AutoEdit Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
M3: Prepare Simulation/Tape Pull List Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
M4: Parameter Prompting Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
M5: Quick Schedule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
M6: End-User Job Order Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
U1: Invoke DOCU/TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

Chapter 2 Online Facilities 83

Overview

Overview
The Online facility is the basic means of communication between the user and
Control-M for z/OS.

Online job scheduling definition gives users the ability to define and modify job
production parameters in the Control-M production environment.

Online tracking displays the current status of all variables relating to a specific job, a
table of jobs or all jobs scheduled under Control-M.

Online control enables authorized users to modify variables relating to a specific job,
a table of jobs or all jobs scheduled under Control-M.

The following pages describe the main features available under the Online facility.

IOA Features
This section discusses the IOA features common to all INCONTROL products.

General IOA Features

General IOA features include:

■ Customization
■ Environment Support
■ Terminal Support
■ Special Character Usage on Terminals
■ Color Support
■ Prefixing
■ Character Masking

Customization
IOA screens, constants, messages, colors, commands, and PFKey definitions can be
site-modified to adapt them to local needs. For further details, see the INCONTROL
for z/OS Installation Guide.

84 Control-M for z/OS User Guide

 General IOA Features

INCONTROL products can be customized globally, that is, for the whole site, using
the INCONTROL Installation and Customization Engine (ICE), according to profile
variables defined during installation.

In addition, INCONTROL products can be customized to respond differently to

individual users if these profile variables are specified in user profile members.

For example, depending on the setting of a variable in a particular user profile

member, upon exit from a screen in which changes have been requested, this
INCONTROL product may either perform the requested changes automatically or
display a confirmation window before performing the changes.

Customization issues are discussed in the INCONTROL for z/OS Installation Guide.

NOTE
Due to customization, the screens and examples illustrated in this guide may differ from the
ones used at your site. The $$ACTDOC member of the IOA MSG library contains information
that is useful for customizing the Control-M Active Environment screen and creating and
modifying display types for screens 3, 3.N, 3.G and the History Environment screen.

Environment Support
The Online facility can be activated under the following environments:

■ TSO (native)
■ TSO/ISPF
■ ROSCOE/ETSO
■ CICS
■ VTAM
■ IMS/DC
■ IDMS/DC
■ COM-PLETE

Cross memory interfaces (to the Online monitor) are optional under native TSO,
TSO/ISPF, and ROSCOE/ETSO. They are always used under the other
environments.

There are slight differences in the operation of the Online facility under the different
environments. Special notes are provided in this guide where applicable.

Chapter 2 Online Facilities 85

General IOA Features

Terminal Support
IOA supports the following models of IBM 3270 terminals:

■ Model 2 – 24 lines, 80 columns

■ Model 4 – 43 lines, 80 columns
■ Model 3 – 32 lines, 80 columns
■ Model 5 – 27 lines, 132 columns

NOTE
When using the IOA online facility under IMS/DC and IDMS/DC, all model types display 24
lines and 80 columns.

IOA adjusts to the screen size in order to use the maximum available data area on the
screen.

Special Character Usage on Terminals

In certain cases, special keyboard characters, such as $, # , and @, are assigned special
meanings. The characters specified appear on standard American terminals but may
not be available on other keyboards. In addition, some special characters on your
keyboard may be assigned different hexadecimal values than the ones recognized by
IOA. Special keyboard mapping requirements, and a complete discussion of the
conventions used in this guide, are shown in “Conventions Used in This Guide” on
page 34.

Color Support
When INCONTROL products are activated from a screen with extended seven-color
support, they make extensive use of the color attributes of the screen. The concept of
management by color is emphasized in INCONTROL screens.

Like all screen attributes, the color attribute for each field is defined externally to the
program and can be locally modified by the site.

NOTE
IOA does not automatically recognize IMS/DC and IDMS/DC terminals as supporting
extended color attributes. If your IMS/DC or IDMS/DC terminal supports extended color
attributes and you want IOA to recognize this, refer to the INCONTROL for z/OS Administrator
Guide for more information.

At this time, IOA does not support extended color attributes under COM-PLETE.

86 Control-M for z/OS User Guide

 General IOA Features

Due to ISPF characteristics, color changes cannot occur in adjacent columns but must
be separated by an attribute byte without color, that is, black. Therefore, some IOA
screens have a different appearance under ISPF than under other online
environments, such as native TSO and CICS.

Prefixing
For fields that automatically support prefixing, selection strings are always treated as
prefixes. Selection is made if a segment of the text beginning with the first letter, that
is, any prefix, matches the selection criteria.

Examples

Assume the following names exist: A3, A4, M, M01, M03, M12, M13, M22, M23, M30,
M33, M103, M135, M301.

Table 16 Prefixing Examples

Entry Matching Value
blank All of the above values
A A3, A4
M M, M01, M03, M12, M13, M22, M23, M30, M33, M103, M135, M301
M1 M12, M13, M103, M135
M13 M13, M135

If a field supports prefixing, this fact is indicated in its description.

Character Masking
For fields that support masking, mask characters function as follows:

■ * represents any number of characters, including no characters

■ ? represents any one character

For fields that do not automatically support prefixing, a prefix value can be specified
by ending the selection string with an asterisk.

Chapter 2 Online Facilities 87

IOA Entry Panel

Examples

Assume the following names exist: A3, M, M3, M01, M03, M13, M23, M33, M103,
M435, M2243.

Table 17 Masking Examples

Entry Matching values
* All the above values
M?3 M03, M13, M23, M33
M?3* M03, M13, M23, M33, M435
M??3 M103
M*3 M3, M03, M13, M23, M33, M103, M2243
M* M, M3, M01, M03, M13, M23, M33, M103, M435, M2243

Since the last character in this example is *, M is treated as a prefix.

If a field supports masking, this fact is indicated in its description.

IOA Entry Panel

Enter the IOA Online facility according to the instructions of your INCONTROL
administrator. Upon entering the IOA Online facility, the IOA entry panel may be
displayed.

NOTE
Display of the IOA Entry Panel is optional. If your INCONTROL administrator determined
that the entry panel is bypassed, the IOA Primary Option menu, which is discussed in the
following section, is displayed.

88 Control-M for z/OS User Guide

 IOA Primary Option Menu

Figure 2 IOA Entry Panel

--------------------------- IOA ENTRY PANEL -------------------------------

+-----------------------------------------------------------+
| |
| USER ID ===> |
| |
| PASSWORD ===> |
| |a
| NEW PASSWORD ===> ===> |
| |
+-----------------------------------------------------------+

PLEASE FILL IN USER ID AND PASSWORD AND PRESS ENTER 18.30.18

Type your user ID and password and press Enter. If you enter a correct user ID and
password, the IOA Primary Option menu is displayed.

The IOA Online facility allows three attempts to enter a valid user ID and password
combination. After the third unsuccessful attempt, the program is terminated.

To change a password, type the new password twice: Once in the NEW PASSWORD
field and once in the confirmation field to the right of the NEW PASSWORD field.

IOA Primary Option Menu

The IOA Primary Option menu is the primary interface to functions available under
the various INCONTROL products. The options displayed in the menu depend on
the INCONTROL products installed at the site, and the functions and facilities that
have been authorized to you.

If only Control-M is installed at your site, and you are authorized to access all
functions and facilities, the following screen is displayed:

NOTE
When the Online facility is activated as an ISPF application, option 6 is displayed as “6
UTILITIES Online Utilities.” In this case, option 6 activates the Online utilities under ISPF.
When the Online facility is not activated under TSO or TSO/ISPF, option 6 is inactive.

Chapter 2 Online Facilities 89

IOA Primary Option Menu

Figure 3 IOA Primary Option Menu where only Control-M is Installed

--------------------- IOA PRIMARY OPTION MENU ------------------(1)
OPTION ===> USER N22A
DATE 19.08.01

2 JOB SCHEDULE DEF CTM Job Scheduling Definition

3 ACTIVE ENV. CTM Active Environment Display
C CMEM DEFINITION CTM Event Manager Rule Definition
4 COND-RES IOA Conditions/Resources Display
5 LOG IOA Log Display
6 TSO Enter TSO Command
7 MANUAL COND IOA Manual Conditions Display
8 CALENDAR DEF IOA Calendar Definition
IV VARIABLE DATABASE IOA Variable Database Definition Facility

COMMANDS: X - EXIT, HELP, INFO OR CHOOSE A MENU OPTION 17.59.32

To select an option, type the option number or letters in the OPTION field and press
Enter. Alternatively, for a number option, press the PFKey with the same number.
For example, to select the LOG option, press PF05/PF17.

NOTE
Your INCONTROL administrator can limit the options displayed on a user-by-user basis, and
can alter option numbers and customize option descriptions. Product-supplied default
options are discussed in this guide.

Certain IOA commands, functions, and facilities (options) are shared by all
INCONTROL products. These shared IOA commands, functions and facilities are
described later in this chapter, and outlined in Table 18.

Table 18 INCONTROL Shared IOA Functions and Facilities (part 1 of 2)

Option Function Description
4 COND/RES Display and update the status of the IOA Conditions
file and the Control-M Resources file.
5 LOG View audit trail information about jobs, missions, and
rules scheduled under the supervision of INCONTROL
products.
6 TSOa Perform TSO commands.
7 MANUAL COND Display the list of prerequisite conditions that must be
confirmed manually by operations personnel.
8 CALENDAR DEF Define scheduling calendars.

90 Control-M for z/OS User Guide

 IOA Primary Option Menu

Table 18 INCONTROL Shared IOA Functions and Facilities (part 2 of 2)

Option Function Description
X EXIT Exit the Online facility.
INFO INFO Display a window in the IOA Primary Option Menu.
The window contains information about installed
INCONTROL products. For more details on the
information displayed by this command, see “IOA
Version Information” on page 93.
a
When the Online facility is activated as an ISPF application, option 6 is displayed as “6
UTILITIES Online Utilities.” In this case, option 6 activates the Online utilities under ISPF.
When the Online facility is not activated under TSO or TSO/ISPF, option 6 is inactive.

NOTE
Entering =1 in the command line of any other screen returns you to the IOA Primary Option
Menu that is displayed at your site.

The following commands, functions, and facilities (options) are applicable to

Control-M:

Table 19 Control-M Functions and Facilities

Option Function Description
IV VARIABLE DATABASE Define, display, and update IOA Database
variables.
2 JOB SCHEDULE DEF Define and modify job production
parameters.
3 JOB STATUS Display and update status of jobs
scheduled under Control-M.
C CMEM DEFINITION Define and modify CMEM rules.

The following IOA Primary Option menu is displayed at sites supporting all
currently available INCONTROL mainframe products.

NOTE
Option OK (KOA Recorder facility) is available only under IOATSO, and not under IOAISPF
or IOAMON.

When the IOA online facility is activated as an ISPF application, option 6 is displayed
as “6 UTILITIES Online Utilities.” In this case, option 6 activates the Online utilities
under ISPF. When the online facility is not activated under TSO or TSO/ISPF, option
6 is inactive.

Chapter 2 Online Facilities 91

IOA Primary Option Menu

Figure 4 IOA Primary Option Menu when all INCONTROL Products are Installed
--------------------- IOA PRIMARY OPTION MENU ------------------(1)
OPTION ===> USER N06

IOA CONTROL-D/V CONTROL-O

4 COND-RES A MISSION STATUS OR RULE DEFINITION

5 LOG M MISSION DEF OM MSG STATISTICS
6 TSO R REPORT DEF OS RULE STATUS
7 MANUAL COND T RECIPIENT TREE OL AUTOMATION LOG
8 CALENDAR DEF U USER REPORTS OA AUTOMATION OPTS
IV VARIABLE DATABASE F PC PACKET STATUS OC COSMOS STATUS
DO OBJECTS OK KOA RECORDER

CONTROL-M & CTM/Restart CONTROL-M/Analyzer CONTROL-M/Tape

2 JOB SCHEDULE DEF BB BALANCING STATUS TR RULE DEFINITION

3 ACTIVE ENV. BM MISSION DEF TP POOL DEFINITION
C CMEM DEFINITION BV DB VARIABLE DEF TV VAULT DEFINITION
BR RULE DEFINITION TI INQ/UPD MEDIA DB
BA RULE ACTIVITY TC CHECK IN EXT VOL

COMMANDS: X - EXIT, HELP, INFO OR CHOOSE A MENU OPTION 16.20.21

NOTE
Entering =1 in the command line of any other screen returns you to the IOA Primary Option
Menu that is displayed at your site.

For a description of the options for other INCONTROL products, see the user guides
of the respective products.

Additional options available on the IOA Primary Option Menu when operating
Control-M with other INCONTROL products are listed in Table 20.

Table 20 IOA Primary Option Menu Options (part 1 of 2)

Option Name Description
A MISSION STATUS Display and update active mission status.
M MISSION DEF Define migration, printing, backup, and
restore missions.
R REPORT DEF Define decollating missions (including
indexing).
T RECIPIENT TREE Display and update the recipient tree.
U USER REPORTS Display and update the status of user reports.
View reports online.
F PC PACKET STATUS Display the status of reports (packets)
scheduled for transfer from the mainframe to
a PC.

92 Control-M for z/OS User Guide

 IOA Primary Option Menu

Table 20 IOA Primary Option Menu Options (part 2 of 2)

Option Name Description
DO OBJECTS Manage Control-D objects.
Note: Options A, M, R, T, U, F, and DO are available only at sites where Control-D or
Control-V are installed.
BB BALANCING STATUS Display and update the status of active
balancing missions.
BM MISSION DEF Define balancing missions.
BV DB VARIABLE DEF Define, display and update Database
variables.
BR RULE DEFINITION Define balancing rules.
BA RULE ACTIVITY Display rule activity and the result of
invoking Control-M/Analyzer rules.
Note: Options BB, BM, BV, BR, and BA are available only at sites where
Control-M/Analyzer is installed.
OR RULE DEFINITION Define rules.
OM MSG STATISTICS View message statistics.
OS RULE STATUS View Rule Status screen.
OL AUTOMATION LOG Display commands, messages and/or traces.
OA AUTOMATION OPTS Display available operator productivity tools.
OC COSMOS STATUS Display or modify the status of
COSMOS-controlled objects and databases.
OK KOA RECORDER Record VTAM scripts.
Note: Options OR, OM, OS, OL, OA, OV, OC, and OK are available only at sites where
Control-O is installed.
TR RULE DEFINITION Define rules.
TP POOL DEFINITION Define pools.
TV VAULT DEFINITION Define vaults.
TI INQ/UPD MEDIA DB Display the Inquire/Update screen.
TC CHECK IN EXT VOL Check in external volumes.
Note: Options TR, TP, TV, TI, and TC are available only at sites where Control-M/Tape is
installed.

IOA Version Information

Enter INFO (or I) in the OPTION field of the IOA Primary Option menu to display the
IOA Version Information window, as illustrated in Figure 5. This window lists the
version and level of each INCONTROL product installed at the site, plus the CPU ID
and current system date. The IOA Version Information window also identifies the
unique IOA QNAME assigned to the site. For further information about the IOA

Chapter 2 Online Facilities 93

Multi-Screen Control

QNAME, see the IOA operational parameters step, the IOAPLEX parameters step,
and the adding IOA structures to the CFRM step, all in the INCONTROL for z/OS
Installation Guide. Press Enter or END (PF03/PF15) to exit the window and return to
the IOA Primary Option menu.

Figure 5 IOA Version Information

--------------------- IOA PRIMARY OPTION MENU ------------------(1)
OPTION ===> USER N06

IOA CONTROL-D/V CONTROL-O

+----------------------------------------------+
4 COND-RES | IOA VERSION INFORMATION | EFINITION
5 LOG | | ATISTICS
6 TSO | IOA Version 6.1.00 | TATUS
7 MANUAL CON | IOAGATE Version 6.1.00 | TION LOG
8 CALENDAR D | CONTROL-M Version 6.1.00 | TION OPTS
IV VARIABLE D | CONTROL-M/RESTART Version 6.1.00 | STATUS
| CONTROL-M/ANALYZER Version 6.1.00 | CORDER
| CONTROL-M/TAPE Version 6.1.00 |
| CONTROL-D Version 6.1.00 |
CONTROL-M & CTM | CONTROL-V Version 6.1.00 | ape
| CONTROL-O Version 6.1.00 |
2 JOB SCHEDU | | EFINITION
3 ACTIVE ENV | | EFINITION
C CMEM DEFIN | DATE 19.08.01 CPUID 02078D 7060 | DEFINITION
| IOA QNAME IOAR610 | D MEDIA DB
| | IN EXT VOL
+----------------------------------------------+

COMMANDS: X - EXIT, HELP, INFO OR CHOOSE A MENU OPTION 17.00.29

Multi-Screen Control
It is not necessary to return to the IOA Primary Option menu to move from one
online facility to another.

To speed up transfer of control between screens of different facilities and to enable

you to manage several online facilities at the same time, transfer control commands
can be specified. Transfer commands take you directly from your current screen to
the requested screen. Transfer commands can be used to reach any screen that can be
accessed by the IOA Primary Option menu at your site.

Each transfer control command consists of an equal sign immediately followed by

one of the options of the IOA Primary Option menu, which represents the target
screen of the transfer. For example, from any screen, enter:

94 Control-M for z/OS User Guide

 Fast Exit from the IOA Online Facility

Table 21 IOA Transfer Control Commands

Command Description
=5 to access the IOA Log screen
=4 to access the IOA Conditions/Resources screen
=1 to access the IOA Primary Option menu

If you use a transfer command to reach another screen, the state of the current screen
remains unchanged when you return to it by another transfer command.

The INCONTROL administrator can globally deactivate any or all of the transfer
commands.

Fast Exit from the IOA Online Facility

To exit immediately from the IOA Online facility, type =X on the command line and
press Enter.

In most cases, the =X command has the same effect as pressing END (PF03/PF15) in all
open screens and then entering X (Exit) in the IOA Primary Option menu. Any
window, such as the Exit Option window, that would be displayed when exiting an
open screen is displayed when the =X command is entered.

However, when the =X command is entered while definition screens such as the
Calendar Definition screen are open, changes to the open definition screens are
cancelled. Changes currently in definition facility list screens, for example, changes to
previously closed definition screens, are not cancelled. Those screens and all other
open screens are treated as if END (PF03/PF15) has been entered.

NOTE
The =X command is intentionally not supported on certain screens.

Chapter 2 Online Facilities 95

Screen Layout

Screen Layout
Most IOA screens are divided into four basic areas. The example used in this section
is the IOA Log screen.

Table 22 Basic IOA Screen Areas

Screen Area Description
Screen Description This line at the top of the screen describes the purpose of the screen
and Message Line (in the example screen, “IOA Log”). A screen identifier may appear
in the upper right corner (in the example screen, 5). This line is also
used to display messages.
Screen Header and This area is used for online commands, and, where applicable,
Command Area headings of the screen data.
Data Area On some screens, the data area can be scrolled. For more
information, see “Scrolling Commands” on page 99.
Screen Bottom This area of the screen usually contains a list of available commands
or options (In the example screen, SHOW, TABLE, CATEGORY, and
SHPF), or a brief explanation about screen usage. The current time is
displayed in the lower right corner.

Figure 6 IOA Log Screen

FILTER: ---------------- IOA LOG -------------------------------(5)
COMMAND ===> SCROLL===> CRSR
SHOW LIMIT ON ==> DATE 291201 - 010102
DATE TIME ODATE USERID CODE ------ M E S S A G E --------------------
311201 184915 311201 K48 SUB13AI JOB K48RUN1 / OID=005W9 SUBMITTER STARTED
PROCESSING JOB ON SYSTEM: OS35
311201 184915 311201 K48 SUB133I JOB K48RUN1 K48RUN /27255 OID=005W9
SUBMITTED FROM LIBRARY (P) K48.LIB.JOB
311201 184918 311201 K48 SPY28GI JOB K48RUN1 K48RUN /27255 OID=005W9 TAPE
DRIVE UNITS USED=00 00
311201 184918 311201 K48 SPY281I JOB K48RUN1 K48RUN /27255 OID=005W9 START
01365.1849 STOP 01365.1849 CPU 0MIN
00.05SEC SRB 0MIN 00.00SEC 0.00 4AOS35
311201 184918 311201 K48 SPY254I JOB K48RUN1 K48RUN /27255 OID=005W9
SCANNED
311201 184918 311201 K48 SEL216W JOB K48RUN1 K48RUN /27255 OID=005W9
UNEXPLAINED COND CODE 0015 STEP EXEC /
311201 184918 311201 K48 SEL214I JOB K48RUN1 K48RUN /27255 OID=005W9 RERUN
NEEDED
311201 184918 311201 K48 SEL205I JOB K48RUN1 K48RUN /27255 OID=005W9 RERUN
IN PROCESS USING MEM K48RUN1
311201 184918 311201 K48 SEL286I JOB K48RUN1 K48RUN /27255 OID=005W9
WAITING FOR CONFIRMATION
CMDS: SHOW, table, CATEGORY, SHPF 08.57.11

96 Control-M for z/OS User Guide

 Commands and PFKeys

Commands and PFKeys

Commands are entered by typing a command in the COMMAND field and then
pressing Enter, or by pressing a predefined PFKey, or a combination of both.

It is not necessary to enter the full command name; the shortest unique abbreviation
of the command is sufficient. If the abbreviation is ambiguous, an appropriate
message is displayed in the message area.

IOA commands are flexible; you can change command syntax or provide aliases
(synonyms) to suit your site. If you want to add or change a command syntax, consult
BMC Software Customer Support. The examples provided in this chapter exhibit the
original command syntax supplied with this INCONTROL product.

PFKey command assignments can be site-customized. It is possible to assign PFKeys

differently for each screen. To change PFKey command assignments, see your
INCONTROL administrator.

Supplied PFKey definitions are consistent throughout most of the screens. For
example: PF08/PF20 is used to scroll down (forward) on all INCONTROL screens
where scrolling is possible.

Table 23 Common PFKey Definitions (part 1 of 2)

PFKey Description
PF01/PF13 HELP
PF02/PF14 SHOW (where applicable)
Note: When the IOA Online facility is activated in ISPF mode (as an
ISPF application), PF02/PF14 are usually assigned the ISPF SPLIT
command. For more information, see “IOA Under ISPF” on
page 105.
PF03/PF15 END – exit current screen and go back one level
PF04/PF16 RESET (where applicable)
PF05/PF17 FIND (where applicable)
PF06/PF18 =6 – transfer to TSO screen/application or to UTILITIES screen
Note: Disabled under ROSCOE/ETSO, CICS, VTAM, IMS/DC,
IDMS/DC, COM-PLETE, and TSO cross memory option.
PF07/PF19 UP – scroll backward
PF08/PF20 DOWN – scroll forward
PF10/PF22 LEFT or PREV (where applicable)
PF11/PF23 RIGHT or NEXT (where applicable)

Chapter 2 Online Facilities 97

Commands and PFKeys

Table 23 Common PFKey Definitions (part 2 of 2)

PFKey Description
PF12 RETRIEVE – retrieves a sequence of commands and options entered
by the user during the current session. These commands and options
are displayed in reverse order on the command line of the current
screen.
PF24 SHPF

To see the PFKey assignment of the screen with which you are working, type
reserved command SHPF in the command line and press Enter. A window describing
the current PFKey assignment appears on the screen. Press Enter again to close the
window.

Figure 7 PFKey Assignment Window

FILTER: ---------------- IOA LOG -------------------------------(5)
COMMAND ===> SCROLL===> CRSR
SHOW LIMIT ON ==> DATE 291201 - 010102
DATE TIME ODATE USERID CODE ------ M E S S A G E --------------------
311201 184915 311201 K48 SUB13AI JOB K48RUN1 / OID=005W9 SUBMITTER STARTED
PROCESSING JOB ON SYSTEM: OS35
311201 184915 311201 K48 SUB133I JOB K48RUN1 K48RUN /27255 OID=005W9
SUBMITTED FROM LIBRARY (P) K48.LIB.JOB
311201 184918 311201 K48 SPY28GI JOB K48RUN1 K48RUN /27255 OID=005W9 TAPE
DRIVE UNITS USED=00 00
311201 184918 311201 K48 SPY281I JOB K48RUN1 K48RUN /27255 OID=005W9 START
+----------------------------------------------------------------------------+
| |
| ENTER ENTER PF13 HELP |
| PF01 HELP PF14 SHOW |
| PF02 SHOW PF15 END |
| PF03 END PF16 RESET |
| PF04 RESET PF17 FIND |
| PF05 FIND PF18 =6 |
| PF06 =6 PF19 UP |
| PF07 UP PF20 DOWN |
| PF08 DOWN PF24 SHPF |
| PF12 RETRIEVE |
+----------------------------------------------------------------------------+

If you type text in the COMMAND field and press a PFKey, the text in the
COMMAND field is treated as a subparameter of the command assigned to the
PFKey.

98 Control-M for z/OS User Guide

 Commands and PFKeys

Two additional key definitions are:

Table 24 Additional Key Assignments

Key Description
PA1 ABORT – forced exit

If you press PA1 while in AutoRefresh mode (described on

page 105), AutoRefresh mode is canceled.
PA2 Under native TSO and ROSCOE, the first time you press this key, the
screen is refreshed. The second consecutive time, a copy of the screen
is sent to be printed, or to a file, using a PRTDBG DD statement. For
terminal models supporting PA3, the PA3 key is defined in exactly
the same way as PA2.

When the IOA online facility is activated as an ISPF application, PA2

is controlled by ISPF, and only refreshes the screen. To print the
screen, see “IOA Under ISPF” on page 105. Under other online
environments, such as CICS and VTAM, PA2 serves as a refresh
only. Usually one of the PA keys is assigned a local print function.

For information on changing IOA PFKey definitions, see the appendix in the
INCONTROL for z/OS Administrator Guide, which deals with modifying IOA Online
Facility Commands.

Scrolling Commands
Scrolling conventions are very similar to the ISPF conventions of IBM. Two basic
commands are used for scrolling:

Table 25 Scrolling Commands

Command PFKey Description
UP (PF07/PF19) Scroll up (backward)
DOWN (PF08/PF20) Scroll down (forward)

The commands can be entered by typing the command in the COMMAND field or by
pressing the predefined PFKey.

The scrolling amount is determined by the content of the SCROLL field in the right
corner of the screen header. Valid scrolling amounts are:

Table 26 Scrolling Amounts in the SCROLL Field (part 1 of 2)

Scrolling Amount Description
PAGE Scroll a full page.
HALF Scroll a half page.

Chapter 2 Online Facilities 99

Commands and PFKeys

Table 26 Scrolling Amounts in the SCROLL Field (part 2 of 2)

Scrolling Amount Description
CRSR Scroll by cursor position. If the cursor is outside the data area, a full
page is scrolled.
MAX Scroll maximum available; for example, UP MAX scrolls to the top.

It is only necessary to type the first letter of the new amount in the SCROLL field in
order to change the scrolling amount.

A scrolling amount other than that shown in the SCROLL field can be used by
entering the amount directly after the scroll command itself, or by entering the scroll
amount in the COMMAND field and pressing the appropriate scrolling PFKey. The
scrolling amount in the SCROLL field remains unchanged.

Example

If PAGE is the value in the SCROLL field, to scroll to the bottom, type M (MAX) in the
COMMAND field and press PF08 (DOWN).

LOCATE Command
The LOCATE command, and its abbreviation, L, can be used to search for items in the
NAME field in all “directory type” screens that contain scrollable data, such as the
Calendar List screen. The syntax of the command is

LOCATE string

where string is the search string. Apostrophes (‘single quotes’) or quotation marks
(“double quotes”) are not required.

The search proceeds from the top of the list to the first item in the list that starts with
the specified string. The cursor is positioned on the OPTION field at the beginning of
the line containing the string, if found, or on the OPTION field of the alphabetically
closest preceding value if the specified value is not found.

FIND Command
The FIND command, and its abbreviation, F, can be used in all screens that contain
scrollable data to find and display the next occurrence of a character string. The
syntax of the command is

FIND string [fromcol] [tocol] [PREV]

100 Control-M for z/OS User Guide

 Commands and PFKeys

where:

■ string is the search string

Mandatory.

■ fromcol is the first column in the search range

Optional.

■ tocol is the last column in the search range

Optional.

■ PREV is the indicator that the search must move backward, instead of forward,
from the current cursor position
Optional.

General Rules

If the string contains blanks, enclose the string with apostrophes (‘single quotes’) or
quotation marks (“double quotes”). For example:

FIND 'WAIT SCHEDULE'

The column range searched can be limited by entering fromcol or tocol values, or by
entering both fromcol and tocol values.

The search for the string proceeds from the current cursor position forward, or
backward if PREV is entered. If the string is found, the cursor is positioned at the start
of the string.

To repeat the find, to the next or previous occurrence of the string, press PF05/PF17.

NOTE
The following situations outline where the FIND command can, or should, be further
modified to enhance its functionality.

■ Some screens enable the user to limit the number of lines searched by a FIND
command. This is discussed in the relevant screen descriptions.

■ In some screens, the FIND command does not detect information that is to the
right or left of the information displayed in the monitor. To ensure detection of the
desired string, the screen must be displayed in wraparound mode, when available,
before executing the FIND command.

Chapter 2 Online Facilities 101

Commands and PFKeys

Text String Searches

The FIND command can also be used to search for text strings, in which case the
command will find all instances of the string, regardless of whether the characters
within the string are lowercase, uppercase, or mixed case. To search for a text string,
include the letter T immediately before a quoted string.

For example,

FIND T'WAIT SCHEDULE'

will find WAIT SCHEDULE, and it will also find wait schedule, and Wait Schedule, and
any other case variant.

Text string searches are the default. If your system default is for text strings, You do
not need to include the T if you perform a text string search. Your INCONTROL
administrator can change the default to character string. In this case you do not need
to include the C if you perform a character string search.

Character String Searches

The FIND command can be used to search for character strings, in which case the
command will find all instances of the string, but only where the string contains
characters that match the case specified. To search for a character string, include the
letter C immediately before a quoted string.

For example,

FIND C'WAIT SCHEDULE'

will find WAIT SCHEDULE, but it will not find wait schedule, or Wait Schedule, or any
other case variant.

CANCEL and RESET Commands

CANCEL and RESET commands are entered in the COMMAND field.

The CANCEL command cancels changes made in a definition screen, such as the IOA
Calendar Definition screen, and exits the screen.

The RESET command (PF04/PF16) cancels Edit environment options specified in a

definition screen. It does not cancel changes already made and it does not exit the
screen or cancel Edit environment mode. For more information about the Edit
environment, see Appendix A, “The Control-M Application Program Interface
(CTMAPI).”

102 Control-M for z/OS User Guide

 Online Help

The RESET command (PF04/PF16) can also be used in most windows, for example, the
Show Screen Filter window, to cancel changes and close the window.

Online Help
The following types of online help are available for INCONTROL screens:

Screen help
Provides information about the entire screen. This help is available on all
INCONTROL screens and is accessed by pressing the HELP key (PF01/PF13) while the
cursor is positioned on the COMMAND field in the screen.

Line-Sensitive Help
Provides information about the fields on a particular line on a screen. This help is
available on several INCONTROL screens. It is accessed by pressing the HELP key
(PF01/PF13) while the cursor is positioned on the desired line of the screen.

If line-sensitive help is not supported in a screen, pressing the HELP key (PF01/PF13)
from anywhere in the screen displays the beginning of the Help panel.

Figure 8 IOA Help Screen

------------------------------ IOA HELP SCREEN --------------------- (CTMHDT2 )
COMMAND ===> SCROLL===> CRSR

Calendar List Screen

====================

The Calendar List screen displays a list of calendars (members) in the

specified library. This screen can be entered directly from the entry
panel or upon exiting the Year List screen.

By default, only calendar names are listed in the screen. However, if

the default has been modified at time of installation, statistical
information is displayed for each calendar name.

Use the scrolling PFKeys to scroll forward (PF08/PF20) and backward

(PF07/PF19) on the Calendar List.

To return to the entry panel, press END (PF03/PF15).

Options of the Calendar List Screen

-----------------------------------
To request one of the following options, specify the option in the OPT
ENTER END OR PF03/PF15 TO EXIT THE HELP SCREEN 08.55.40

Help can be scrolled using standard scrolling conventions.

Chapter 2 Online Facilities 103

AutoRefresh Mode

To return to the original screen, use the END command (PF03/PF15).

The Help member name appears on the right in the Help screen header. Members
containing the Help descriptions can be found in the IOA MSG library.

AutoRefresh Mode
Certain INCONTROL screens, as noted in this chapter where appropriate, support
AutoRefresh mode. A screen display in AutoRefresh mode is automatically updated
periodically with the most current data.

AutoRefresh mode can only be activated under native TSO or under ISPF.
AutoRefresh mode is activated by the AUTO command. The format of the command
is

AUTO n

where n is any number of seconds from 1 through 99.

The screen is updated when the AUTO command is issued, and then periodically
updated according to the interval (in seconds) specified in the AUTO command. A
counter at the top of the screen displays the number of times the screen has been
refreshed.

NOTE
Issuance of the AUTO command may be controlled via the IOA security interface. See the
INCONTROL for z/OS Security Guide for further details.

Example

The AUTO 5 command refreshes the screen every 5 seconds.

Cancelling AutoRefresh Mode

Under native TSO, the recommended method of cancelling AutoRefresh mode is as
follows:

■ For short interval values – Press Enter. Whenever Enter is pressed, or a command
is issued, AutoRefresh mode is automatically cancelled at the end of the current
interval.

104 Control-M for z/OS User Guide

 IOA Under ISPF

■ For long interval values – Press Attn (PA1) once.

Under ISPF, press Attn (PA1) or Esc once to cancel AutoRefresh mode.

IOA Under ISPF

The IOA Online facility can be activated as an ISPF application. As such, it can work
in ISPF split screen mode like any other ISPF application.

WARNING
Multiple calls to the IOA ISPF interface can be performed in ISPF split screen mode as long as
all invocations are for the same IOA environment. Otherwise, the results may be
unpredictable.

The command line of the IOA Online facility is controlled by IOA. It is not possible to
enter ISPF commands in an IOA screen. Two ISPF commands must be defined to
PFKeys:

Table 27 ISPF Commands that must be defined for PFKeys

Command PFkey
SPLIT (usually PF02/PF14)
SWAP (usually PF09/PF21)

The rest of the PFKeys are controlled by IOA PFKey definitions, which are in the IOA
PARM library.

It is possible to assign TSO/ISPF commands such as PRINT to PFKeys, or to change

PFKey definitions by performing the following steps:

1 Exit from IOA and ISPF to the READY prompt.

2 Type the following command and press Enter:

ISPSTART PANEL(ISR@PRIM) NEWAPPL(CTM)

This command brings you to ISPF.

3 Type the KEYS command and press Enter. A set of key definitions is displayed.

4 Modify the key definitions as desired and exit from ISPF.

Chapter 2 Online Facilities 105

IOA Editor

NOTE
ISPF KEY definitions for the following ISPF commands take precedence over IOA PFKey
definitions: SPLIT, SWAP, KEYS, PRINT, PFSHOW. For example, if PF02 is defined as
SPLIT in ISPF, an IOA definition for PF02 is ignored in online screens.

For all other ISPF commands, such as UP or DOWN, the key definitions in ISPF are ignored
and the PFKey is interpreted according to the definition in the IOA Online facility.

Under ISPF, IOA Option 6 activates the Online Utilities panel, which is described
in “IOA Online Utilities Menu” on page 333. For more information about these
utilities, see the INCONTROL for z/OS Utilities Guide.

For more information on changing IOA PFKey definitions, see the appendix in the
INCONTROL for z/OS Administrator Guide that deals with modifying IOA Online
Facility Commands.

IOA Editor
The IOA Editor enables you to edit members of a partitioned data set (PDS) using an
editor similar to the ISPF editor. Enter EDMEM in the command line of any screen to
display the Edit Entry Panel window, as shown in Figure 9.

Figure 9 IOA Editor Edit Entry Panel

--------------------- IOA PRIMARY OPTION MENU ------------------(1)
OPTION ===> USER N06

IOA CONTROL-D/V CONTROL-O

4 COND/RES A MISSION STATUS OR RULE DEFINITION

5 +--------------------------------------------------------------+ICS
6 | EDIT ENTRY PANEL |
7 | |LOG
8 | LIBRARY ==> |OPTS
IV | |US
| MEMBER ==> |R
| |
| FILL IN PARAMETERS AND PRESS ENTER TO CONTINUE OR PF3 TO EXIT|
CONTR| |
+--------------------------------------------------------------+
2 JOB SCHEDULE DEF BB BALANCING STATUS TR RULE DEFINITION
3 ACTIVE ENV. BM MISSION DEF TP POOL DEFINITION
C CMEM DEFINITION BV DB VARIABLE DEF TV VAULT DEFINITION
BR RULE DEFINITION TI INQ/UPD MEDIA DB
BA RULE ACTIVITY TC CHECK IN EXT VOL

COMMANDS: X - EXIT, HELP, INFO OR CHOOSE A MENU OPTION 19.12.05

106 Control-M for z/OS User Guide

 IOA Editor

To create a new member or edit an existing member, fill in the LIBRARY and
MEMBER parameters and press Enter. The IOA Editor screen is opened for editing, as
shown in Figure 10.

NOTE
If the member already exists in the specified library, the member is displayed for editing in the
IOA Editor. Similarly, if you accessed the IOA Editor screen from line option J in either screen
2 or screen 3, the member in the library referred to in the schedule definition member will be
displayed for editing.

Figure 10 IOA Editor

---------------------------- I O A E D I T O R ------------------- (EDMEM)
COMMAND ===> SCROLL===> CRSR
ROW PROD.V610.DEMO(TEST) COL 001 072

......
......
......
......
......
......
......
......
......
......
************************ B O T T O M O F D A T A **************************

OPTIONS: I INSERT D DELETE R REPEAT C COPY M MOVE UC/LC UPPER/LOWER CASE

IOA Editor PFKey Functions

While working within the IOA Editor, PFKeys perform the functions shown in
Table 28:

Table 28 PFKey Functions Within the IOA Editor Screen (part 1 of 2)

PFKeys Description
PF01/PF13 Activates online help.
PF02/PF14 Saves the current member.
PF03/PF15 Terminates the editing session. If the edited member has been
changed the member will be saved automatically.
PF04/PF16 Cancels the editing session without saving changes.
PF05/PF17 Invokes the Find facility.
PF07/PF19 Scrolls forward.

Chapter 2 Online Facilities 107

IOA Editor

Table 28 PFKey Functions Within the IOA Editor Screen (part 2 of 2)

PFKeys Description
PF08/PF20 Scrolls backward.
PF10/PF22 Scrolls left.
PF11/PF23 Scrolls right.

Commands of the IOA Editor Screen

Table 29 describes editing commands that can be executed by entering the command
in the COMMAND line.

Table 29 IOA Editor Command Line Commands

Command Description
SAVE Saves all new data without terminating the edit session.
CANCEL Terminates the edit session without saving new data.
COPY Enables you to import a member from a specific library.

Table 30 describes editing commands that can be executed by entering the command
in the left-most position of the applicable row.

Table 30 IOA Editor Row Commands (part 1 of 2)

Command Description
I Inserts a new line below the current line.
To insert more than one line for new data, enter Inn, where nn
indicates the number of new lines to be inserted below the current
line.
D Deletes the current line.
To delete more than one line, enter Dnn, where nn indicates the
number of lines to be deleted below the current line.
You can delete a block of lines by typing DD at the beginning of the
first line of the block, and then entering DD at the beginning of the
last line of the block.
R Repeats the current line.
To repeat a single line one or more times, enter Rnn, where nn
indicates the number of times the current line is to be repeated.
You can repeat a block of lines by typing RR at the beginning of the
first line of the block, and then entering RR at the beginning of the
last line of the block.
C Identifies the source line for a copy operation.
To copy more than a single line, enter Cnn, where nn indicates the
number of lines to be copied.
You can also copy a block of lines by typing CC at the beginning of
the first line of the block, and then entering CC at the beginning of
the last line of the block.

108 Control-M for z/OS User Guide

 IOA SET Command Panel

Table 30 IOA Editor Row Commands (part 2 of 2)

Command Description
M Identifies the source line for a move operation.
To move more than a single line, enter Mnn, where nn indicates the
number of lines to be moved.
You can also move a block of lines by typing MM at the beginning of
the first line of the block, and then entering MM at the beginning of
the last line of the block.
A Identifies the destination of a copy or move operation.
When a line or block of lines has been selected for copying or
moving, enter A at the point after which the copied lines are to be
inserted.
B Identifies the destination of a copy or move operation.
When a line or block of lines has been selected for copying or
moving, enter B at the point before which the moved lines are to be
inserted.
LC Changes text in a line from uppercase to lowercase.

To change text in more than a single line to lowercase, enter LCnn,

where nn indicates the number of lines to be changed to lowercase.
UC Changes text in a line from lowercase to uppercase.

To change text in more than a single line to uppercase, enter UCnn,

where nn indicates the number of lines to be changed to uppercase.

IOA SET Command Panel

The IOA SET Command Panel enables you to set and stop TRACE levels, choose the
language that is used in online screens and to set a dollar sign representation that will
be used in online screens for system variables of type %%$VAR. Enter SET in the
command line of any screen to display the SET Command Panel window, as shown
in Figure 11.

Chapter 2 Online Facilities 109

IOA SET Command Panel

Figure 11 IOA SET Command Panel

+-----------------------------------------------------------------------------------+
| SET Command Panel |
| |
| |
| TRACE level , ON (Trace level 001-512, ON or OFF) |
| |
| |
| LANGUAGE ENG - English |
| FRA - French |
| GER - German |
| JPN - Japanese |
| |
| |
| SPECIAL CHARACTERS: Dollar Current representation is "$"(X'5B') |
| |
| |
| FILL IN PARAMETERS AND PRESS ENTER TO CONTINUE OR PF3 TO EXIT |
| |
+-----------------------------------------------------------------------------------+

The process of setting TRACE levels and turning off a particular TRACE, and the
process of setting language preferences for online screens and messages, begins in the
SET Command Panel.

Using the SET Command Panel to set and end TRACE Levels
Setting the TRACE level can help you monitor certain IOA Online facility and
INCONTROL functions, such as security checks.

The following steps explain how to set or turn off a TRACE level:

1 Type a TRACE level number, from 1 through 256, in the TRACE level field of the
SET Command Panel.

2 In the (Trace level 1-256, ON or OFF) field, type ON to set a TRACE level, or OFF to
turn off a TRACE level.

3 Press Enter to confirm the setting, in which case the following message is
displayed:

CTMA2AI TRACE LEVEL nnn WAS SET xxx

where

■ nnn is the TRACE level number

■ xxx indicates whether the TRACE level was set ON or turned OFF

110 Control-M for z/OS User Guide

 IOA SET Command Panel

NOTE
TRACE level settings take effect immediately.

Using the SET Command Panel to set a dollar sign

representation
Setting the dollar sign representation influences how System variables are shown in
online screens.

The following steps explain how to set the dollar sign representation:

1 Type a $ character in the Dollar field using your keyboard.

2 Press Enter to confirm the setting, in which case the following message is
displayed:

CTMA2DI THE NEW DOLLAR REPRESENTATION IS "c"(X'yy')

where

■ c is $ character you set

■ yy is the EBCDIC hexadecimal code for $

NOTE
There are differences in the EBCDIC hexadecimal code for the $ (dollar sign) character on
keyboards that have been adapted to show local or national symbols.

Using the SET Command Panel to set Language preferences

Setting the LANGUAGE influences the online screens and messages in subsequent
sessions.

The following steps explain how to set language preferences:

1 In the LANGUAGE field, type one of the following sets of characters to select a
language preference:

■ ENG, to set English as the preferred language

■ FRA, to set French as the preferred language
■ GER, to set German as the preferred language
■ JPN, to set Japanese as the preferred language

Chapter 2 Online Facilities 111

IOA TSO Command Processor Screen

2 Press Enter to confirm the setting, in which case the following message is
displayed:

CTMA27I THE NEW LANGUAGE WILL BE USED FROM THE NEXT LOGON
TO IOA

NOTE
Language preference settings do not take effect until your next logon to the system.

IOA TSO Command Processor Screen

The IOA TSO Command Processor screen can be entered only when the IOA Online
facility is activated as a TSO application. It cannot be entered when the IOA Online
facility is activated as an ISPF application or activated under a non-TSO environment.

The TSO screen enables activation of any TSO command without exiting the IOA
Online facility. For example, a typical program activated under the TSO screen is
ISPF. Therefore all ISPF/PDF facilities and functions, such as editing a member or
scanning job output, can be activated while you are working under the IOA Online
facility.

To activate a TSO command, type the command in the COMMAND field and press
Enter.

Figure 12 IOA TSO Command Processor Screen

-------------------------- IOA TSO COMMAND PROCESSOR -----------------------(6)
COMMAND ===> ISPF

PLEASE ENTER TSO COMMAND 15.32.52

112 Control-M for z/OS User Guide

 IOA TSO Command Processor Screen

NOTE
CLISTs cannot be activated from the TSO screen. To activate a CLIST, first activate ISPF and
then execute the CLIST under ISPF.

TSO commands can also be activated directly from any IOA online screen by typing
TSO in the COMMAND field.

Transfer of Control Between the TSO Application and the

IOA Online Facility
You can return to the IOA Online facility from the TSO application by simply exiting
the TSO application in a normal manner. However, this method can be time
consuming and inconvenient if an ISPF application or a similar TSO application is
activated.

If the TSO application can issue a TSO command, it is possible to transfer control to
the IOA Online facility, and vice versa, without exiting the TSO application.

While working under the TSO application, for example, under ISPF, issue the
command:

TSO CTMTTRA {n | =n}

where n is the online screen number.

The requested screen is displayed as it was when you transferred from it.

To return to the TSO application, use the =6 command (PF06/PF18). The application
remains in the same state as when you transferred from it.

It is recommended that you simplify transfer between screens by permanently

assigning one of your PFKeys under ISPF (or SDSF, and so on) to the command TSO
CTMTTRA. Once this key assignment is made, you no longer need to type the full
transfer command. Instead, you merely type the IOA option number or code in the
COMMAND field and press the assigned PFKey. You are transferred to the desired
screen.

NOTE
You must activate ISPF under the IOA Online facility if you want to use the control transfer
feature.

Chapter 2 Online Facilities 113

Scheduling Definition Facility

Scheduling Definition Facility

The Control-M Scheduling Definition facility enables you to create, view, or modify
scheduling definitions for the jobs in your environment. A scheduling definition
consists of parameters that correspond to the decisions and actions of the operator
when handling the scheduling, submission, and post-processing of a job or set of jobs.

The job scheduling definition for a job needs to be defined only once. After the job
definition is defined, the definition is saved and used as necessary for managing job
processing. Job scheduling definitions can be modified or deleted as required.

Job scheduling definitions are stored in members called tables. Any number of tables
can be defined, and each table can contain any number of job scheduling definitions.

In many production environments, related applications are scheduled together as a

unit. In these cases, it is common to store job scheduling definitions of all related
applications in members called SMART Tables, and to define scheduling parameters
for the set of jobs. This is accomplished by defining the scheduling parameters in the
SMART Table Entity.

Tables (members) are stored in scheduling libraries. You can define any number of
scheduling libraries. The number of tables in a library, the number of scheduling
definitions in a table, and the size of each scheduling definition, are all calculated
dynamically.

NOTE
The Control-M Scheduling Definition facility does not support members that have been
compressed using the ISPF PACK option.

Accessing the Scheduling Definition Facility

The Scheduling Definition facility contains the following screens:

Table 31 Scheduling Definition Facility Screens (part 1 of 2)

Screen Definition
Scheduling Facility Enables specification of parameters that determine which screen is
entry panel displayed.
Table List screen Displays the list of tables (members) in the specified scheduling
library.

114 Control-M for z/OS User Guide

 Handling of Tables

Table 31 Scheduling Definition Facility Screens (part 2 of 2)

Screen Definition
Job List screen Displays the list of jobs (job scheduling definitions) in the selected
table. For SMART Tables, the Job List screen includes the SMART
Table Entity (scheduling definition for the set of jobs in the SMART
Table).
Job Scheduling Displays the parameters of the selected scheduling definition of the
Definition screen job or the SMART Table. This is the main screen of the facility.
(Screen 2)

To enter the Scheduling Definition facility, select option 2 on the IOA Primary Option
menu. The Scheduling Definition Facility entry panel is displayed.

Handling of Tables
A set of jobs whose processing (for example, scheduling, submission, and post
processing) is handled as a unit, is defined in a SMART Table. This table must be
created as a SMART Table by selecting Y in the Scheduling Definition facility entry
panel.

At the time of creation of a SMART Table, a scheduling definition for the set of jobs,
called the SMART Table Entity, is created. The SMART Table Entity is used to define
processing criteria for the set of jobs in the SMART Table. These include:

Table 32 Scheduling Criteria (part 1 of 2)

Criterion Description
Basic Scheduling Any number of sets of basic scheduling criteria can be specified in
Criteria the SMART Table Entity. At least one of these sets must be satisfied
before any job in the SMART Table, can be scheduled.

Each set of basic scheduling criteria in the SMART Table Entity is

assigned a unique name called a Schedule RBC.

These Schedule RBC names can be entered in job scheduling

definitions in the table. When a set of basic scheduling criteria in the
SMART Table Entity is satisfied, job scheduling definitions that
specify the corresponding Schedule RBC are scheduled that day.

Job scheduling definitions can also contain their own basic

scheduling criteria, and be scheduled according to those criteria,
provided that the basic scheduling criteria in the SMART Table
Entity is satisfied.

Chapter 2 Online Facilities 115

Creating Tables

Table 32 Scheduling Criteria (part 2 of 2)

Criterion Description
Runtime Scheduling Before any job in a SMART Table can be considered for submission,
Criteria all SMART Table runtime scheduling criteria specified in the
SMART Table Entity must be satisfied. After these are satisfied, a job
is submitted only if its own specified runtime scheduling criteria are
satisfied.
Post-processing Post-processing actions can be defined for the SMART Table Entity.
Actions These are performed after the table has finished processing (that is,
all jobs in the table have terminated).

These actions can be made conditional upon whether all submitted

jobs in the SMART Table ended OK, or whether at least one job did
not end OK.

The SMART Table Entity also contains a field (ADJUST CONDITIONS) that enables
job dependencies based on prerequisite conditions to apply only if predecessor jobs in
the SMART Table are scheduled.

Control-M internally tracks each SMART Table and the jobs in the SMART Table.
Each order of each SMART Table is identified as a unit.

The status of each SMART Table that has been ordered can be viewed using option T
(Table) of the Job Status screen (Active Environment screen).

NOTE
When the IN conditions of the SMART Table Entity, are satisfied (for example, they have
been added to the IOA Conditions file), the jobs in the SMART Table begin execution,
assuming that their other runtime criteria are satisfied.

By default, if jobs in a SMART Table have already begun execution and an IN condition for
the SMART Table is deleted from the IOA Conditions file, this change does not affect the
processing of the jobs in the SMART Table; the jobs continue execution as if all the IN
conditions were still satisfied. This default is overridden if the TBLRECHK parameter in the
CTMPARM member in the IOA PARM library is set to Yes, in which case IN conditions
SMART Table Parameters are checked before each job is selected.

Creating Tables
Tables can be created in either of the following ways:

■ by typing the new table name in the entry panel and pressing Enter

The name of a new job scheduling definition for the new table can also be entered.

116 Control-M for z/OS User Guide

 Creating Tables

■ by using the SELECT command to choose the new table name in the Table List
screen and pressing Enter

The name of a new job scheduling definition for the new table can also be entered.

The SELECT command is described in “SELECT Command” on page 127.

When you create a table (press Enter) using either of the above methods, a skeletal job
scheduling definition is displayed in the Job Scheduling Definition screen. Fill in and
save this job scheduling definition. The table is created and the job scheduling
definition is the first and only job scheduling definition in the Job list of the table. As
additional job scheduling definitions are created in the table (described below), they
are added to the Job list.

When you create a SMART Table (press Y) using either of the above methods, a
skeletal scheduling definition, SMART Table Entity, is displayed in the Scheduling
Definition panel. Fill in and save this scheduling definition. As you add job
scheduling definitions to the table (described below), they are added to the Job list.

NOTE
The PTBLEMPT profile variable controls whether empty SMART Tables (without a job
scheduling definition) may be created.

Valid values are:

■ Y (Yes) – empty SMART Tables may be created
■ N (No) – empty SMART Tables may not be created. All SMART Tables must be created
with at least one job scheduling definition. Default.

When PTBLEMPT=Y, the SMART Table is created and only the SMART Table Entity
is in the Job List of the SMART Table. Adding a job scheduling definition to this
SMART Table is described in “Creating Job Scheduling Definitions” on page 118.

When PTBLEMPT=N, a skeletal job scheduling definition is displayed in the Job

Scheduling Definition screen. Fill in and save this job scheduling definition. The
SMART Table is created and the SMART Table Entity and the job scheduling
definition are in the Job list of the SMART Table. As additional job scheduling
definitions are created in the SMART Table (described below), they are added to the
Job list.

NOTE
Upon exiting the Job List screen, if changes were made in at least one job scheduling
definition, an Exit Option window is displayed. One field of the window displays the table
name. This value can be changed to a new table name. This creates a new table in which the
job scheduling definitions are saved.

Under ISPF, tables can also be created using the M5 online utility. This method is described in
“M5: Quick Schedule Definition” on page 367, and is not included in this discussion.

Chapter 2 Online Facilities 117

Creating Job Scheduling Definitions

Creating Job Scheduling Definitions

Job scheduling definitions can be created using two basic methods:

■ A skeletal job scheduling definition can be created by typing the name of a new job
scheduling definition in the entry panel. The table specified in the entry panel can
be either a new table if PTBLEMPT=N or an existing table if PTBLEMPT=Y. In this
case, virtually all fields of the job scheduling definition are empty.

■ A copy of an existing job scheduling definition can be created using the INSERT
option in the Job List screen, described in “Options of the Job List Screen” on
page 374. In this case, most fields of the new job scheduling definition have the
same values as the fields in the copied job scheduling definition.

NOTE
Under ISPF, job scheduling definitions can also be created using the M5 online utility. This
method is described in “M5: Quick Schedule Definition” on page 367, and is not included in
this discussion.

Performing Operations on Tables and Jobs

Many operations can be performed on tables and on the job scheduling definitions in
them. These operations are performed through commands and options in the various
screens of the Scheduling Definition facility.

Some of the major operations possible within the facility are described in the
following pages. Options and commands that have not yet been explained are
explained in detail following the summary.

Accessing (Editing or Browsing) a Table and its Jobs

A table (that is, the job scheduling definitions in the table) can be browsed or edited.

When browsed, the table cannot be modified or updated. When the table is edited,
new job scheduling definitions can be added and existing job scheduling definitions
can be modified or deleted.

Browsing, however, has advantages:

■ Access and exit are quicker than in editing.

■ Job lists and job scheduling definitions that are in use by another user can be
viewed.

118 Control-M for z/OS User Guide

 Performing Operations on Tables and Jobs

■ Access for browsing might be granted, even though access for editing might be
denied due to site security requirements.

NOTE
Users who request Edit mode, but do not have edit authority, can be automatically forced
to the Browse mode by the IOA Administrator. See the IOA Administrators Guide, Chapter
10, exit IOA032 for further information.

To browse a table (and its job list and job scheduling definitions) use the BROWSE
option in the Table List screen.

Entering the table name in the entry panel or using the SELECT option in the Table
List screen provides edit access.

Depending on user profile definitions, if the table requested for editing is in use,
either access is granted in Browse mode or access is not granted.

Accessing the JCL of a Job

When IOA is activated under ISPF, the member containing the JCL of a job can be
accessed by the JCL command in the Job List screen. Whether the member can be
modified and updated depends on whether the Job List screen was accessed in
Browse or Edit mode.

Copying a Job to Another Table

Jobs can be copied from one table to another by the COPY option in the Job List
screen. For more information, see “Options of the Job List Screen” on page 374.

Deleting a Table or a Job

Unneeded jobs can be deleted using the DELETE option in the Job List screen. For
more information, see “Options of the Job List Screen” on page 374. Unneeded tables
can be deleted by the DELETE option in the Table List screen. For more information,
see “Deleting Tables” on page 164.

NOTE
In order to delete the last (or only) job scheduling definition from a SMART Table, profile
variable PTBLEMPT must be set to Y.

Chapter 2 Online Facilities 119

Performing Operations on Tables and Jobs

Displaying Jobflow in Graphic Format

The job flow of jobs in a table can be displayed in graphic format by the GRAPHIC
FLOW option in the Table List screen. For more information, see “Displaying Graphic
Jobflow” on page 168.

Displaying Job Statistics

The statistics for a job can be displayed by performing any of the following:

■ Typing S (STAT) next to the job name in the Active Environment screen.
■ Typing T (JOBSTAT) next to the job name in the Job List screen.
■ Typing the primary command JOBSTAT in the Job Scheduling Definition screen
(or the Active Environment screen).

Manually Scheduling Jobs

Manually ordering a job results in the job being scheduled only if its basic scheduling
criteria are satisfied. Manually forcing a job results in its being scheduled even if its
basic scheduling criteria are not satisfied.

■ To manually order all the jobs in a table, type O (ORDER) for the table in the Table
List screen. Multiple tables can be ordered.

■ To manually force all the jobs in a table, type F (FORCE) for the table in the Table
List screen. Multiple tables can be forced.

■ To manually order specific jobs in a table, type O (ORDER) for the jobs in the Job
List screen.

■ To manually force specific jobs in a table, type F (FORCE) for the jobs in the Job
List screen.

For more information, see “Ordering (Scheduling) Jobs” on page 155.

Displaying the Schedule Plan of a Job

The schedule of a job for a specified period of time, based on the basic scheduling
criteria of the job, can be displayed in calendar format by PLAN option in the Job List
screen. For more information, see “Displaying a Job Scheduling Plan” on page 170.

120 Control-M for z/OS User Guide

 Entry Panel

Simulating the action of the Control-M submission

mechanism for a job
A job's JCL member can be tested for proper auto-edit resolution by typing %
(AutoEdit simulation) next to the job name in the Job List screen, or next to the job
name in the Active Environment screen (after the job is ordered). For more
information, see the % option in Table 35 and Table 58.

Saving Modifications
All changes made to a table and its job scheduling definitions are kept in memory
until the table is exited. Upon exiting the table, you can choose to save or cancel the
changes. For more information, see “Exiting the Scheduling Definition Facility” on
page 153.

Entry Panel
The entry panel is displayed upon entering the Scheduling Definition facility (Option
2 in the IOA Primary Option menu).

Figure 13 Control-M Scheduling Definition Facility - Entry Panel

----------- CONTROL-M SCHEDULING DEFINITION FACILITY - ENTRY PANEL ---------(2)
COMMAND ===>

SPECIFY LIBRARY, TABLE, JOB

LIBRARY ===> CTM.PROD.SCHEDULE

TABLE ===> (Blank for table selection list)
JOB ===> (Blank for job selection list)

SMART TABLE (new tables only) ===> (Y - for new SMART Table)

SHOW JOB DOCUMENTATION ===> N (Y/N)

AUTO-SAVE DOCUMENTATION ===> N (Y/N)

USE THE COMMAND SHPF TO SEE PFK ASSIGNMENT 23.00.04

To open the desired display, fill in Entry Panel fields LIBRARY, TABLE, and JOB as
described below. To create a table do one of the following:

■ Press Enter to create a table that will handle jobs individually

Chapter 2 Online Facilities 121

Entry Panel

■ Press Y to create a table which will apply scheduling definitions to the set of jobs in
the table as a unit (SMART Table).

If you are not creating a new table, the SMART Table field is ignored and all tables are
displayed.

Type Y (Yes) or N (No) in the SHOW JOB DOCUMENTATION field to determine

whether job documentation lines appear when the Job Scheduling Definition screen is
displayed. Type Y (Yes) or N (No) in the AUTO-SAVE DOCUMENTATION field to
determine whether changes made to documentation are automatically saved when
updating the job scheduling definition.

■ To display the list of tables in a library, do the following:

■ sssssss

1. Type the library name.

2. Either leave the table name blank, or type part of a table name together with
mask characters (* and ?).

3. Press Enter.

■ To display the list of jobs of a specific table, do the following:

1. Type the library name.

2. Type the table name.

3. Press Enter.

If the table does not exist, the screen for defining a new job in the table is displayed.

■ To display the details of a specific job (Job Scheduling Definition screen), do the
following:

1. Type the library name.

2. Type the table name.

3. Type the job name.

4. Press Enter.

If the table does not exist, or the job for the specified table does not exist, the screen
for defining a new job in the table is displayed.

122 Control-M for z/OS User Guide

 Entry Panel

NOTE
If you enter the screen for defining a new job and want to leave the screen without defining
a job, use the CANCEL command.

■ To display the Search Window (described below), do the following:

1. Type the library name.

2. Type the job name.

3. Either leave the table name blank, or type part of a table name together with
mask characters (* and ?).

4. Press Enter.

■ To create a new table, do the following:

1. Type a new table name.

2. Type the table type.

3. Press Enter.

The Job Scheduling Definition screen, for defining the first job in the new table, is
displayed.

Search Window

The Search window enables you to search for the specified job in tables in the
specified library. Tables in which the job has been found are then displayed in the
Table List screen.

Chapter 2 Online Facilities 123

Entry Panel

Figure 14 Control-M Scheduling Definition Facility - Entry Panel Search Window

----------- CONTROL-M SCHEDULING DEFINITION FACILITY - ENTRY PANEL --------(2)
COMMAND ===>

SPECIFY LIBRARY, TABLE, JOB

LIBRARY ===> CTM.PROD.SCHEDULE

TABLE ===> (Blank for table selection list)
JOB ===> CTMCLRES (Blank for job selection list)
+------------------------------------------+
SMART TABLE ===> | |
| PLEASE SELECT ONE OF THE FOLLOWING: |
| |
| 1 - STOP SEARCH IMMEDIATELY |
| 2 - ASK AGAIN AFTER 000010 TABLES |
SHOW JOB DOCUMENTATION ===> N| 3 - UNCONDITIONAL SEARCH |
AUTO-SAVE DOCUMENTATION ===> N| |
| NUMBER OF TABLES IN LIBRARY: 000015 |
| NUMBER OF SEARCHED TABLES: 000000 |
| NUMBER OF SELECTED TABLES: 000000 |
| |
+------------------------------------------+
USE THE COMMAND SHPF TO SEE PFK ASSIGNMENT 12.11.54

To close the Search Window without performing any action, press END (PF03/PF15).

NOTE
If you use the selection list fields, their values are not erased until you exit the entry panel by
pressing END (PF03/PF15).

To perform a search, select one of the following choices and press Enter:

3 – UNCONDITIONAL SEARCH

Searches all tables in the specified library.

The search continues uninterrupted unless and until you select Option 1 (Stop Search
Immediately).

2 – ASK AGAIN AFTER number TABLES

Searches the specified number of tables in the specified library, and then pauses. The
search number can be modified. Default: 10.

■ Continue the search by pressing Enter.

■ Stop the search by selecting option 1 (Stop Search Immediately).

If any tables are found, the Table List is displayed listing those tables.

124 Control-M for z/OS User Guide

 Table List screen

During the search, the following information is displayed at the bottom of the
window:

■ Number of tables in library. Lists the total number of tables in the specified library.

■ Number of searched tables. Lists the cumulative number of tables searched. For
example, if you perform three searches with a specified number of 10, the figure
displayed is 30.

■ Number of selected tables. Lists the cumulative number of tables selected that
contain the job being searched.

If any tables are selected during the search, the Table List is displayed listing those
tables. If no tables are selected, the Search Window is closed and a message is
displayed.

Table List screen

The Table List screen displays a list of tables (members) in the specified library. This
screen can be entered directly from the entry panel or upon exiting the Job List screen.

By default, only table names are listed in the screen. However, if the default has been
modified at time of installation, statistical information is displayed for each table
name, as shown in the following screen example.

Figure 15 Control-M Scheduling Definition Facility Table List Screen

LIST OF TABLES IN CTM.PROD.SCHEDULE -------------(2)
COMMAND ===> SCROLL===> CRSR
OPT NAME ------------ VV.MM CREATED CHANGED SIZE INIT MOD ID
ADABAS 01.00 01/02/14 01/06/12 00:50 70 70 0 O01
APPLNTN 01.00 01/02/14 01/06/12 00:50 180 180 0 O01
APPLPRDI 01.00 01/02/14 01/06/12 00:50 41 41 0 O01
ARCNIGHT 01.00 01/02/14 01/06/12 00:50 5 5 0 S07
ASMBTR1 01.00 01/02/14 01/06/12 00:50 9 9 0 S07
ASMBTR2 01.00 01/02/14 01/06/12 00:50 14 14 0 S07
BACKUP 01.00 01/02/14 01/06/12 00:50 5 5 0 S07
CICSJOBS 01.00 01/02/14 01/06/12 00:50 70 70 0 O01
CICSPROD 01.00 01/02/14 01/06/12 00:50 180 180 0 O01
CICSTEST 01.00 01/02/14 01/06/12 00:50 41 41 0 O01
CICSUPT 01.00 01/02/14 01/06/12 00:50 5 5 0 S07
CLIENTS 01.00 01/02/14 01/06/12 00:50 9 9 0 S07
DB2EXE 01.00 01/02/14 01/06/12 00:50 14 14 0 S07
DLOAD 01.00 01/02/14 01/06/12 00:50 5 5 0 S07
MAINDAY 01.00 01/02/14 01/06/12 00:50 180 180 0 O01
MAINT 01.00 01/02/14 01/06/12 00:50 41 41 0 O01
MAINTPL 01.00 01/02/14 01/06/12 00:50 5 5 0 S07
ONSPOOL 01.00 01/02/14 01/06/12 00:50 9 9 0 S07
ONSPOOLT 01.00 01/02/14 01/06/12 00:50 14 14 0 S07
OPERCLN 01.00 01/02/14 01/06/12 00:50 5 5 0 S07
OPTIONS S SELECT O ORDER F FORCE G GRAPHIC FLOW B BROWSE D DELETE 15.38.37

Chapter 2 Online Facilities 125

Table List screen

■ To scroll down the Table list, press PF08/PF20. To scroll up the Table list, press
PF07/PF19.

■ To return to the entry panel, press END (PF03/PF15).

Options of the Table List Screen

To request one of the following options, type the option in the OPT field to the left of
the table names and press Enter.

Table 33 Options of the Table List Screen

Option Description
S (SELECT) Display the list of jobs in the table for any purpose, including
editing and modification. Only one table can be selected at a time.
B (BROWSE) Display a list of jobs in a table for browsing. Only one table can be
browsed at a time.
O (ORDER) Order all the jobs in the table, provided that their basic
scheduling criteria, as described in “Basic Scheduling
Parameters” on page 135, are satisfied. Multiple tables can be
ordered.

When ordering multiple tables from the Table List Screen

with one confirmation window for all tables (that is,
ASK FOR EACH ONE =N), the user must exit from Screen 2.o for
each table to ensure that all the requested tables are ordered.
F (FORCE) Order all the jobs in the table, regardless of their basic scheduling
parameters, which are described in “Basic Scheduling
Parameters” on page 135. Multiple tables can be forced.
G (GRAPHIC) FLOW Display a graphic presentation of the job flow of the jobs in the
table, as described in “Displaying Graphic Jobflow” on page 168.
Only one table at a time can be selected for graphic display.
D (DELETE) Delete the table (member) from the library. Multiple tables can be
deleted, as described in “Deleting Tables” on page 164.

NOTE
If your access to options has been limited by the INCONTROL administrator, you can only
access the BROWSE option.

Commands of the Table List Screen

The following command can be entered in the COMMAND field of the Table List
screen and pressing <ENTER>.

126 Control-M for z/OS User Guide

 Job List Screen

SELECT Command

The SELECT command can be used to create a new table in the library. The format of
the command is:

SELECT tablename [SMART]

Type SELECT tablename SMART – For a table that will apply scheduling definitions
to the set of jobs in the table as a unit.

NOTE
If the SELECT command is entered for an existing table, it acts like the S (SELECT) line option,
which is described in Table 33, and displays the list of jobs in the table.

If there are no jobs currently in the table, that is, the command is being used to create
a new table, the Job List screen is not displayed. Instead, one of the following is
displayed in the Jobs Scheduling Definition screen:

■ A skeletal job scheduling definition.

■ A skeletal table scheduling definition for the set of jobs in a SMART Table.

Job List Screen

The Job List screen displays the list of jobs in a table in a specified library. This screen
can be entered directly from the entry panel or the Table List screen, or upon exiting
from the Job Scheduling Definition screen.

NOTE
The names displayed on the Job List screen are the names of the members that contain the JCL
of the jobs, which is specified in the MEMNAME parameter in the job scheduling definition,
or, in the case of started tasks, the name of the STC.

If the S (Select) option was entered in the Table List screen for a table that is currently in use
(“selected”) by another user, either the Job List screen is not displayed and the Table List
screen remains displayed (the default), or the Job List screen is displayed in Browse mode (if a
user profile definition overrides the default). In either case, an appropriate message is
displayed.

Chapter 2 Online Facilities 127

Job List Screen

Figure 16 Control-M Scheduling Definition Facility Job List Screen

JOB LIST LIB: CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
OPT NAME --- TYP --- DESCRIPTION ----- TABLE: TBLWK1 ----------------------
STARTBKP G START OF DAILY BACKUP
BACKPL01 J DAILY BACKUP OF DATA SETS FROM APPL-L
BACKPL02 J DAILY BACKUP OF SPECIAL FILES FROM APPL-L
BACKPLW1 J WEEKLY BACKUP OF FILES FROM APPL-L #1
BACKPLW2 J WEEKLY BACKUP OF FILES FROM APPL-L #2
BACKPLW3 J WEEKLY BACKUP OF FILES FROM APPL-L #3
BACKPLW4 J WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-L +
DASDRPT1 J DASD REPORTS AFTER BACKUPS FOR APPL-L
DASDRPT2 J DASD STATISTICS REPORT AFTER BACKUP FOR APPL-L
ENDPLBKP J END OF BACKUP INDICATION FOR APPL-L
BACKAC01 J DAILY BACKUP OF DATA SETS FROM APPL-ACCOUNT
BACKAC02 J DAILY BACKUP OF SPECIAL FILES FROM APPL-ACCOUNT
BACKACW1 J WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #1
BACKACW2 J WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #2
BACKACW3 J WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #3
BACKACW4 J WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-ACC +
DASDRPT3 J DASD REPORTS AFTER BACKUPS FOR APPL-ACCOUNT
DASDRPT4 J DASD REPORTS AFTER BACKUP FOR APPL-ACCOUNT
ENDACBKP J END OF BACKUP INDICATION FOR APPL-ACCOUNT
BACKDD01 J DAILY BACKUP OF DATA SETS FROM APPL-DD
OPTIONS S SEL D DEL I INS O ORDER F FORCE J JCL C COPY P PLN T JOBSTAT 15.37.39

Format of the Job List Screen

Next to each job name in the Job list, certain information can be displayed. The type
and format of this information depends on whether the screen is displayed in DESC
format, in DATA format or in STAT format, and whether the list is displayed for a
SMART Table, as follows:

■ In DESC format, the description of the job, taken from the DESC field of the job
scheduling definition, is displayed. Default.

■ In DATA format, the application and table names of the job, taken from the APPL
and TABLE fields of the job scheduling definition, are displayed.

■ In STAT format, ISPF-like statistical information about the job is displayed.

■ If the Job list is displayed for a SMART Table, the type of job scheduling definition
is also displayed in the DESC, DATA, and STAT formats. Valid values are:

— T – SMART Table Entity; this is always the first entry in the Job list of a SMART
Table. (Type information is not displayed for tables defined to handle
individual jobs.)

— J – Job

By default, the job list is displayed in DESC format. To change formats, use the DESC,
DATA or STAT commands, described below.

128 Control-M for z/OS User Guide

 Job List Screen

The order in which the jobs are displayed in the Job List screen can be sorted by the
SORT command (described below).

Commands of the Job List Screen

The following commands can be entered in the COMMAND field of the Job List
screen:

Table 34 Commands of the Job List Screen

Command Description
DESC Command DESC displays the job description next to the job name.
The description is taken from the DESC field in the job scheduling
definition.
DATA Command DATA displays the Application name and Table name of
the job next to the job name. The Application name and Table name
are taken from the corresponding fields in the job scheduling
definition.
STAT Command STAT displays (next to the job name) the following ISPF-
like statistical information about the job: version and modification
numbers, creation date, last modification date, and user ID.
SORT Command SORT sorts the list of jobs in the Job List screen according
to specified criteria. Format of the command is:

SORT key

Where key is one of the following values:

■ J (Job) – Sorted according to job name.

■ T (Table) – Sorted according to table name.
■ A (Application) – Sorted according to application name.

Options of the Job List Screen

To request one of the following options, type the option in the OPT field to the left of
the job name and press Enter.

NOTE
Option O (Order) is not available if the Job List screen is displayed for a SMART Table.

Options I (Insert) and J (JCL) are not available for SMART Table Entities.

If the Job List screen is displayed in Browse mode, options D (Delete) and I (Insert) are not
available.

Chapter 2 Online Facilities 129

Job List Screen

Table 35 Options of the Job List Screen (part 1 of 2)

Option Description
S (SEL) Display the Job Scheduling Definition screen, with details of the
selected job. Only one job can be selected at a time.

If the Job List screen is not displayed in Browse mode, the job
scheduling definition can be edited and updated. If the Job List
screen is displayed in Browse mode, the job scheduling definition
can only be browsed; it cannot be modified.
D (DEL) Delete a job from the Job list (member). Multiple jobs can be selected.

See “Condition Inheritance” on page 165 for a description of an

optional feature in Control-M that automatically adjusts all the jobs
in the table so that the jobs that are waiting for the deleted job's OUT
conditions will inherit its IN conditions.
I (INS) Insert a new job in the list (member). The Job Scheduling Definition
screen appears, with the same details of the job marked “I”, but the
MEMNAME and DESCRIPTION parameters are empty for you to
fill in. The new job is added after the job marked “I”. Only one new
job can be inserted at a time.
O (ORDER) Order a job provided that its basic scheduling criteria, as described
in “Basic Scheduling Parameters” on page 135, are satisfied. Multiple
jobs can be selected.
F (FORCE) Force a job order regardless of the basic scheduling criteria of the job,
as described in “Basic Scheduling Parameters” on page 135. Multiple
jobs can be selected.
J (JCL) Edit the member that contains the JCL of the job. Entering this option
brings you directly into the JCL member in ISPF Edit mode. By
default, if the JCL member exists in the OVERLIB library, that
member is edited. If the JCL member does not exist in the OVERLIB
library, the member is edited in the MEMLIB library. You can only
edit the JCL of one job.

For more information on the OVERLIB and MEMLIB libraries, see

“OVERLIB: General Job Parameter” on page 580 and “MEMLIB:
General Job Parameter” on page 532.

In ISPF Edit mode, if the name in the MEMNAME parameter

contains a mask character (for example, if it is a generic name such as
PRODJOB*), using the J option displays all PDS members in the
library with names that match the mask.
C (COPY) Copy the job to another table. Multiple jobs can be selected. For more
information, see “Copying Jobs to Another Table” on page 162.
P (PLN) Display a schedule plan for the job. You can only display the
schedule plan of one job. For more information, see “Displaying a
Job Scheduling Plan” on page 170.
T (JOBSTAT) Displays the statistics for the job in the Control-M Statistics screen,
described in “Statistics Screen” on page 245.

130 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

Table 35 Options of the Job List Screen (part 2 of 2)

Option Description
% (AUTOEDIT Simulates the action of the Control-M Submission mechanism for the
SIMULATION) member and JCL library specified in the MEMNAME and MEMLIB
parameters of the job scheduling definition. This option operates in
the same way as the % option in the Active Environment screen (see
Table 58 on page 186 for full details).
Note: When requesting the '%' option, a prompt for the simulation
ODATE is displayed.

Job Scheduling Definition Screen – Defining Schedules

The Control-M Job Scheduling Definition screen is used to define, display and modify
production parameters of a specific job. This screen can be entered directly from the
entry panel or from the Job List screen. Update of parameters is not permitted in
Browse mode.

NOTE
The format of the Job Scheduling Definition screen for SMART Table Entities is slightly
different than the format shown below and is described in “Scheduling Definition for SMART
Table Entities” on page 142.

Chapter 2 Online Facilities 131

Job Scheduling Definition Screen – Defining Schedules

Figure 17 Job Scheduling Definition Screen

JOB: BACKPL02 LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME BACKPL02 MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL APPL-L TBL BKP-PROD-L RBC
DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
OVERLIB CTM.OVER.JOBLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM BACKPL02 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS ALL DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN START-DAILY-BACKUP ODAT
CONTROL
RESOURCE INIT 0001 CART 0001
PIPE CTM.PROD.PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT BAKCKPL02-ENDED-OK ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST PROCST CODES A/O
DO
ON SYSOUT FROM 001 TO 132 A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
===========================================================================
APPL TYPE APPL VER
APPL FORM CM VER
INLINE JCL: N
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.27.41

NOTE
The PIPE parameter is displayed only if MAINVIEW Batch Optimizer (MVBO) is installed.

RETENTION parameters # OF DAYS TO KEEP and # OF GENERATIONS TO KEEP are

displayed only at sites that use the History Jobs file.

132 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

The job scheduling definition occupies more than one screen.

To delete a parameter on the screen, simply erase it with the EOF key or blank it out.
If additional action is required, Control-M issues appropriate instructions.

Parameters of the Job Scheduling Definition Screen

The Job Scheduling Definition screen is divided into the following sections.

Table 36 Parameters of the Job Scheduling Definition Screen

Parameter Description
General Job In this section, you can enter specific information about the job itself
Parameters – in which member and library the JCL is found, who is the owner of
the job, and so on.
Basic Scheduling In this section, you can enter scheduling criteria (for example, the
Parameters days of the week or month on which the job must be submitted).
Runtime Scheduling In this section, you can enter submission criteria including
Parameters conditions that must be fulfilled (generally, successful completion of
a preceding job) before submission of the job, resources required by
the job, and time limitations on job submission.
Post-Processing In this section, you can enter fixed or conditional actions to perform
Parameters upon job completion, or upon the execution of specified job steps.
For example, you can set conditions that trigger the submission of
other jobs, you can send messages to the operator console, or you can
rerun the job.

These sections are divided by a delimiter line.

A brief description of all parameters in each section of the Job Scheduling Definition
screen is provided on the following pages. A detailed explanation of these parameters
is provided in Chapter 3, “Job Production Parameters.”

NOTE
Parameters marked with the symbol M can have multiple occurrences. Whenever you fill in
the last occurrence of the parameter on the screen, Control-M adds a new empty occurrence of
the parameter that you may fill in. The only limit to the number of occurrences is the region
size available for the application.

Chapter 2 Online Facilities 133

Job Scheduling Definition Screen – Defining Schedules

General Job Parameters

Figure 18 General Job Parameters
+----------------------------------------------------------------------------+
MEMNAME BACKPL02 MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL APPL-L TBL BKP-PROD-L RBC
DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
OVERLIB CTM.OVER.JOBLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM BACKPL02 DOCLIB CTM.PROD.DOC
============================================================================

Table 37 General Job Parameters (part 1 of 2)

Parameter Description
MEMNAME Name of the member that contains the JCL of the job, or name of the
started task.
MEMLIB Name of the library that contains either the JCL of the job or
identifying information and parameters of the started task.
OWNER ID of a user who requests Control-M services. This field is used for
security purposes.
TASKTYPE Type of task to be performed by Control-M (for example, job – JOB,
started task – STC).
§Restart§ Indicator (Y/N/F/L) specifying whether (and how) to perform data
PREVENT-NCT2 set cleanup prior to the original job submission.

The subparameter DFLT is a protected field that indicates the

PREVENT-NCT2 default value at this site.
APPL Name of the application to which the table of the job belongs.
TABLE Name of the table to which the job belongs, such as BACKUPS,
RESERVATIONS, INVENTORY, and so on.
DESC Description of the job (free text) that is displayed next to the job
name in the Job List screen.
OVERLIB Name of a library that overrides the library specified in MEMLIB.
STAT CAL Name of a periodic calendar that will be used to gather average
runtime statistics for the job, based on a period.
SCHENV Name of the workload management scheduling environment to be
associated with the job.
SYSTEM ID In JES2, the identity of the system in which the job must be initiated
and executed.

In JES3, the identity of the processor on which the job must be

executed.
NJE NODE Identifies the node in the JES system at which the job must execute.

134 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

Table 37 General Job Parameters (part 2 of 2)

Parameter Description
SET VARM Statement assigning a value to an AutoEdit variable, which can be
used in the submitted job.
CTB STEP Control-M/Analyzer definition to be activated as the first or last (as
entered) step of the job. The type of Control-M/Analyzer definition
(rule or mission) and its name are also entered.
DOCMEM Name of a member in which the job documentation resides.
DOCLIB Name of the library in which the job documentation member resides.
DOC Detailed job documentation.
INSTREAM JCL Whether Control-M for z/OS submits a JCL stream defined within
the job scheduling definition.
The following General parameters are in the SMART Table Entity only:
ADJUST Allows conditions to be removed from job orders if the predecessor
CONDITIONS jobs that set the conditions are not scheduled.
TBL MAXWAIT Number of additional days after the original scheduling date that the
SMART Table Entity can remain in the Active Jobs file if it does not
have a status of ENDED OK (and none of its jobs currently appear in
the Active Jobs file).

Basic Scheduling Parameters

Figure 19 Basic Scheduling Parameters - Job
===============================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL

Figure 20 Basic Scheduling Parameters - SMART Table Entity

===============================================================================
SCHEDULE RBC LEVEL TBL
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL WORKDAYS SHIFT RETRO N MAXWAIT 04
SCHEDULE RBC ACTIVE FROM UNTIL

Chapter 2 Online Facilities 135

Job Scheduling Definition Screen – Defining Schedules

Table 38 Basic Scheduling Parameters (part 1 of 2)

Parameter Description
M
SCHEDULE RBC Rule-based calendars that identify sets of scheduling criteria defined
in the SMART Table Entity or IOA Calendar Facility that can be used
to schedule the job.

■ If the Schedule RBC’s level is set to TBL, the rule-based calendar

is defined in the SMART Table Entity.

■ If the Schedule RBC’s level is set to CTM, the rule-based calendar

is defined in the IOA Calendar Facility.
RELATIONSHIP And/Or indicator that determines whether or not the criteria of the
specified schedule RBC and the basic scheduling criteria of the
individual job must both be satisfied.
DAYS Days of the month to schedule the job. A maximum of two lines can
be entered. Subparameters are:

■ DCAL – identifies a DAYS calendar containing predefined

scheduling dates

■ AND/OR – conjunctional subparameter used to link the DAYS

and WDAYS parameters when both are scheduled
WDAYS Days of the week to schedule the job. A maximum of two lines can be
entered.

The WCAL subparameter identifies a calendar containing working

days on which a job can be scheduled.
MONTHS Months to run the job.
DATES Specific dates in the year to run the job.
CONFCAL Name of a calendar used to confirm job scheduling dates.

The optional subparameter SHIFT indicates when and if a job must

be scheduled.
RETRO Yes or No (Y/N) indicator specifying whether the job is to be
scheduled (retroactively) after the original scheduling date has
passed.
MAXWAIT Number of extra days within which to try to execute a job in the
Active Jobs file if the date of the job has passed.
D-CAT Name of a Control-D report decollating mission category. If
specified, the report decollating mission is scheduled whenever the
job is scheduled under Control-M.
MINIMUM Minimum number of free tracks required by the library specified in
the PDS parameter. The job is executed if the number of free tracks is
less than the minimum.
PDS Name of a partitioned data set to be checked for free space. If the
PDS has less than the minimum number of required free tracks, as
specified in the MINIMUM parameter, the job is executed. Not
supported for PDSE-type libraries.

136 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

Table 38 Basic Scheduling Parameters (part 2 of 2)

Parameter Description
The following parameters apply only when defining individual jobs. For more information
on these parameters, see Chapter 3, “Job Production Parameters.”
DEFINITION When a date is entered in this field within a job scheduling
ACTIVE FROM definition, the job will only be ordered if the current date is later than
that date. Valid values are:

■ Date in the format ddmmyy, or mmddyy, or yymmdd,

depending on your site format, as set by the DATETYP
parameter in the IOAPARM member in the IOA PARM library.

■ ‘ ‘ (Blank)
DEFINITION When a date is entered in this field within a job scheduling
ACTIVE UNTIL definition, the job will only be ordered if the current date is earlier
than that date. Valid values are:

■ Date in the format ddmmyy, or mmddyy, or yymmdd,

depending on your site format, as set by the DATETYP
parameter in the IOAPARM member in the IOA PARM library.

■ ‘ ‘ (Blank)
The following parameters apply only when defining a SMART Table Entity. For more
information on how these parameters are applied to jobs in SMART Tables, see Chapter 3,
“Job Production Parameters.”
RBC Definition Level ■ TBL - rule-based calendars that are managed using the SMART
table definition and are defined on the table level.

■ CTM - rule-based calendars that are defined from the Calendar

Manager in the Control-M/Desktop of the IOA Calendar
Facility. These calendars are referred to by name and are not
included in the scheduling definitions.
SCHEDULE RBC A job which refers to this Schedule RBC will only be ordered if the
ACTIVE FROM current date is later than the specified date. Valid values are:

■ Date in the format ddmmyy, or mmddyy, or yymmdd,

depending on your site format, as set by the DATETYP
parameter in the IOAPARM member in the IOA PARM library.

■ ‘ ‘ (Blank)
SCHEDULE RBC A job which refers to this Schedule RBC is only ordered if the current
ACTIVE UNTIL date is earlier than the specified date. Valid values are:

■ Date in the format ddmmyy, or mmddyy, or yymmdd,

depending on your site format, as set by the DATETYP
parameter in the IOAPARM member in the IOA PARM library.

■ ‘ ‘ (Blank)

Chapter 2 Online Facilities 137

Job Scheduling Definition Screen – Defining Schedules

Runtime Scheduling Parameters

Figure 21 Runtime Scheduling Parameters
===========================================================================
IN START-DAILY-BACKUP ODAT
CONTROL
RESOURCE INIT 0001 CART
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================

Table 39 Runtime Scheduling Parameters

Parameter Description
INM Prerequisite conditions for the job.
CONTROLM Shared or exclusive control over resources required for the job.
M
RESOURCE Quantitative resources required for the job.
PIPE Name of a data set replaced by a pipe during the run of the job.
Available only at sites in which MAINVIEW Batch Optimizer
(MVBO) is installed.
TIME + DAYS Time limit (FROM, UNTIL) for job submission.
PRTY Job priority in receiving Control-M services or critical path priority.
CONFIRM Yes or No indicator (Y/N) specifying whether manual confirmation
is required before the job can be submitted.
DUE OUT + DAYS Time by which the job must finish executing.
SAC Enables scheduled runs of a job that was converted from another job
scheduling product, such as CA-7, to be shifted to their proper
scheduling days.
TIME ZONE Enables automatic adjustment of the times specified in the job
definition to the corresponding times in a different time zone.

Post-Processing Parameters
Figure 22 Post-Processing Parameters
===========================================================================
OUT BAKCKPL02-ENDED-OK ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES C0008 U0048 A/O
DO

138 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

Table 40 Post-Processing Parameters (part 1 of 2)

Parameter Description
M
OUT Prerequisite conditions to be added and/or deleted when the job
finishes OK.
§Restart§ Yes or No indicator (Y/N) specifying whether to automatically
AUTO-ARCHIVE archive SYSDATA. Subparameters are:

■ SYSDB – Yes or No indicator specifying whether to archive

SYSDATA of jobs to a common data set (Y) or to unique data sets
(N)

■ MAXDAYS – maximum number of days (from 00 through 98, or

99) to retain archived SYSDATA of jobs that ended NOTOK

■ MAXRUNS – maximum number of runs (from 000 through 999)

for which the archived SYSDATA must be retained for jobs that
ended NOTOK
RETENTION Either of the following subparameters (but not both) can be used to
specify how long the job must remain in the History Jobs file:

■ # OF DAYS TO KEEP – number of days the job must be retained

■ # OF GENERATIONS TO KEEP – number of runs of the job that

must be retained
SYSOUT Action to perform with the job sysout when the job finishes OK.
MAXRERUN Maximum number of reruns to be performed for the job, if DO
RERUN is requested. (Called RERUN – MAXRERUN prior to
version 6.0.00.)
RERUNMEM Name of member to be submitted in case of a DO RERUN request.
(Called RERUN – RERUNMEM prior to version 6.0.00.)
INTERVAL Amount of time, in minutes, to wait between reruns or between
cycles of a cyclic job.
STEP RANGEM Step range (FROM or TO PGMST, and optionally PROCST) name to
be referenced by ON statements.
ONM Step and code event criteria that determine if the accompanying DO
actions are performed

■ PGMST/PROCST – program step (and optionally the procedure

step) to check for the specified code criteria

■ CODESM – execution event codes, such as U0234, SB37, and

C0004

■ A/O – AND/OR conjunctional parameter that opens (and links)

additional ON statements

Chapter 2 Online Facilities 139

Job Scheduling Definition Screen – Defining Schedules

Table 40 Post-Processing Parameters (part 2 of 2)

Parameter Description
DO actionM Actions to be performed when the ON step/code event criteria are
satisfied. Valid DO actions are described in “DO Actions” below.
SHOUTM Message to be sent to a specified destination in a specified situation:

■ WHEN – Situations under which to send the message.

■ TO – Destination of the message.
■ URGN – Urgency of message.
■ MS – The message, in free text. Control-M AutoEdit System
variables are supported.

DO Actions

The following are a description and example of each of the DO actions.

DO COND – Add or delete a prerequisite condition.

ON PGMST UPDATE PROCST CODES S*** U**** A/O

DO COND PL-BACKOUT-REQUIRED ODAT +
DO

DO CTBRULE – Invoke the Control-M/Analyzer Runtime environment and execute

the specified Control-M/Analyzer rule, which performs the balancing operations
defined in the rule on SYSDATA. Arguments can be passed to Control-M/Analyzer.
Available only at sites in which Control-M/Analyzer is active.

ON PGMST ANYSTEP PROCST CODES OK A/O

DO CTBRULE = BALKPL ARG DOREPORT,UPDATEDB
DO

DO FORCEJOB – Force (schedule) a job under Control-M.

ON PGMST UPDATE PROCST CODES S*** U**** A/O

DO FORCEJOB TABLE PLPROD JOB PLBCKOUT DATE ODAT
LIBRARY GENERAL
DO

§Restart§ DO IFRERUN – Perform a restart under Control-M/Restart when the job is

manually or automatically rerun. This DO action is available if you have
Control-M/Restart installed at your site.

ON PGMST ANYSTEP PROCST CODES S0C1 A/O

DO IFRERUN FROM GLSTEP01 . GLPROC02 TO GLSTEP05 . GLPROC03 CONFIRM N
DO

DO MAIL – Send an e-mail message to the specified recipients.

140 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

ON PGMST UPDATE PROCST CODES C0000 A/O

DO MAIL
TO ACCT-SMITH
CC
SUBJ VERIFICATION
TEXT CHECK OK
DO

DO NOTOK – Define the termination status of the job as NOTOK.

ON PGMST UPDATE PROCST CODES C0004 A/O

DO NOTOK
DO

DO OK – Define the event within the job as OK.

ON PGMST ANYSTEP PROCST CODES C0008 U0048 A/O

DO OK
DO

DO REMEDY – Open a Remedy Help Desk ticket.

ON PGMST STEP1 PROCST CODES C0012 A/O

DO REMEDY URGENCY U
SUMM JOB %%JOBNAME ON NODE %%$NODEID ENDED WITH RETURN CODE %%COMPSTAT
DESC CONTROL-M JOB %%JOBNAME RUN %%RN ENDED ON NODE %%$NODEID RETURN
CODE %%COMPSTAT: APPLICATION: %%APPL, TABLE: %%TABLE

NOTE
To close the ticket, the Control-M user will have to access the Remedy online services.

DO RERUN – Indicate that a job must be rescheduled for a rerun.

ON PGMST ANYSTEP PROCST CODES S0C1 A/O

DO IFRERUN FROM GLSTEP01 . GLPROC02 TO GLSTEP05 . GLPROC03 CONFIRM N
DO RERUN
DO

DO SET – Assign a value to a Control-M AutoEdit variable.

ON PGMST ANYSTEP PROCST CODES C0008 U0048 A/O

DO SET VAR= %%RUNTYPE=CHK
DO

Chapter 2 Online Facilities 141

Job Scheduling Definition Screen – Defining Schedules

NOTE
Since DO SET values are dependent upon fulfillment of ON step or codes criteria, the values
are assigned after job execution and used for subsequent cyclic runs and rerun.

DO SHOUT – Message to be sent to specified location.

ON PGMST UPDATE PROCST CODES S*** U**** A/O

DO SHOUT TO OPER2 URGENCY R
= A BACKOUT OF FILE-XXXX IS GOING TO RUN SOON
DO SHOUT TO USER-DBA URGENCY R
= ABEND OF THE UPDATE STEP, PLEASE CHECK IT
DO

DO STOPCYCL – Stop recycling a cyclic task.

ON PGMST ANYSTEP PROCST CODES >C0008 A/O

DO STOPCYCL
DO

DO SYSOUT – Action to perform with the job sysout.

ON PGMST UPDATE PROCST CODES S*** U**** A/O

DO SYSOUT OPT C PRM P FRM
DO

Scheduling Definition for SMART Table Entities

A SMART Table Entity must be defined for each SMART Table before the job
scheduling definitions in the table can be defined.

A skeletal scheduling definition for a SMART Table Entity is automatically displayed

when creating a SMART Table.

The scheduling definition for a SMART Table Entity can also be entered directly from
the Entry Panel or from the Job List screen.

The job scheduling definition for SMART Table Entities varies somewhat from the job
scheduling definition for jobs.

The parameters of the SMART Table Entity are used to define basic scheduling
criteria, runtime scheduling criteria, and post-processing actions to be performed, for
the jobs in the SMART Table.

During New Day processing, if at least one set of basic scheduling criteria in the
SMART Table Entity is satisfied, a copy of the SMART Table Entity is placed in the
Active Jobs file, and the jobs in the SMART Table become eligible for scheduling.

142 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

The final status of the SMART Table Entity job order is assigned after all scheduled
jobs in the SMART Table have been terminated. This SMART Table Entity status is
determined by the execution results of those jobs:

■ If all the scheduled jobs in the SMART Table ended OK, the SMART Table Entity is
assigned an end status of OK.

■ If at least one scheduled job in the SMART Table did not end OK, the SMART
Table Entity is assigned an end status of NOTOK.

The performance of post-processing actions defined in the SMART Table Entity is

directly affected by the end status of the SMART Table Entity.

Figure 23 SMART Table Entity Scheduling Definition Screen

TBL ACCOUNTS_TABLE CTM.PROD.SCHEDULE(TBL)
COMMAND ===> SCROLL===> CRSR
+-------------------------------------------------------------------------------+
TABLE ACCOUNTS TABLE ACCOUNTS_TABLE
OWNER N04B
APPL
DESC
ADJUST CONDITIONS N TBL MAXWAIT STAT CAL
SET VAR
DOCMEM ACCOUNTS DOCLIB CTM.PROD.DOC
==============================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL

Chapter 2 Online Facilities 143

Job Scheduling Definition Screen – Defining Schedules

WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00
SCHEDULE RBC ACTIVE FROM UNTIL
=============================================================================
SCHEDULE RBC
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00
SCHEDULE RBC ACTIVE FROM UNTIL
=============================================================================
IN
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
=============================================================================
OUT
ON TABLE-END NOTOK
DO COND ACCTS-CHK-REQUIRED ODAT +
SHOUT WHEN TIME + DAYS TO URGN
MS
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 18.19.14

The SMART Table Entity scheduling definition supports the same commands and
PFKey conventions as any job scheduling definition.

Parameters of the SMART Table Entity Scheduling

Definition Screen
The parameters of the SMART Table Entity scheduling definition are almost identical
in appearance and usage as those in a regular job scheduling definition, which are
described briefly in “Parameters of the Job Scheduling Definition Screen” on
page 133.

Differences in the parameters of the SMART Table Entity scheduling definitions are
described below.

144 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

Table 41 Parameters of the SMART Table Entity Scheduling Definition Screen

(part 1 of 2)
Parameter Description
GROUP Name of the group. This parameter also appears in regular job
scheduling definitions. Jobs only inherit the value of the GROUP
parameter from the SMART Table when the GROUP parameter of
the job is left blank. When the GROUP parameter of the table is
blank, the blank is inherited by the job.
TABLE In a SMART Table Entity, this field does not indicate a member
name. Instead, it is used to indicate an abbreviated table name. This
abbreviated table name is then displayed, when appropriate, in other
screens, such as the Active Environment screen.
ADJUST Yes or No indicator specifying whether prerequisite conditions
CONDITIONS normally set by predecessor jobs are removed from job orders if the
relevant predecessor jobs are not scheduled. This parameter only
appears in the SMART Table Entity, and applies to all jobs in the
table awaiting prerequisite conditions from unscheduled jobs. Use of
this parameter can simplify the handling of Maybe jobs.
TBL MAXWAIT Number of extra days beyond the original scheduling date the
SMART Table Entity can be maintained in the Active Jobs file if it
does not have a status of ENDED OK.

However, if one of its jobs remains in the Active Jobs file beyond this
number of days, the SMART Table Entity remains in the Active Jobs
file as long as the job remains there.
SCHEDULE RBC Unique identifier to be applied to the accompanying set of
scheduling criteria. Multiple sets of scheduling criteria can be
defined, each with its own rule-based calendar.

A set of criteria defined in a SMART Table Entity can be applied to a

job by specifying the identifying rule-based calendar in the job
scheduling definition.

At least one set of basic scheduling criteria in the SMART Table

Entity must be satisfied before the jobs in that SMART Table become
eligible for scheduling on any day.
Basic Scheduling The SMART Table Entity does not contain parameters D–CAT, PDS,
Parameters and MINIMUM, which are found in job scheduling definitions.
Runtime Scheduling These parameters, IN, TIME FROM/UNTIL, PRIORITY, DUE OUT,
Parameters and CONFIRM, apply to all scheduled jobs in the SMART Table.

All runtime scheduling criteria in the SMART Table Entity must be

satisfied before any of the scheduled jobs are eligible for submission.
Any runtime criteria defined for a particular job must also be
satisfied before the job can be submitted.

Chapter 2 Online Facilities 145

Job Scheduling Definition Screen – Defining Schedules

Table 41 Parameters of the SMART Table Entity Scheduling Definition Screen

(part 2 of 2)
Parameter Description
Post-Processing Non-conditional Post-processing parameters (OUT, SHOUT) are
Parameters performed only if all scheduled jobs in the table have ended OK.

ON TABLE-END
SMART Table Entity end status indicator. This parameter appears
only in the SMART Table Entity. DO statements immediately
following this parameter are performed only if the SMART Table
Entity is assigned the indicated status. Valid values are:

■ OK – Subsequent DO actions are performed for each job in the

SMART Table only if the end status of the SMART Table Entity is
OK (that is, all scheduled jobs in the SMART Table ended OK).

■ NOTOK – Subsequent DO actions are performed for each job in

the SMART Table if the end status of the SMART Table Entity is
NOTOK (that is, at least one job in the SMART Table ended
NOTOK).

Commands of the Job Scheduling Definition Screen

The following commands can be entered in the COMMAND field of the Job
Scheduling Definition screen.

Table 42 Commands of the Job Scheduling Definition Screen (part 1 of 2)

Command Description
EDIT Alternately places the job scheduling definition in, and removes the
job scheduling definition from, an ISPF-like Edit environment.

For a brief overview, see “Editing Job Scheduling Definitions in the

Edit Environment” on page 148. For more complete details, see
Appendix A, “The Control-M Application Program Interface
(CTMAPI).”
DOC Alternately displays and hides the job documentation.

For more information, see “Job Documentation” on page 149.

PLAN Enables display of the job's scheduling plan.

When the PLAN command is entered, a window for entering the

date range of the plan is displayed. When the date range is entered,
the scheduling plan for the job is displayed in the Job Scheduling
Plan screen.

For more information, see “Displaying a Job Scheduling Plan” on

page 170.

146 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

Table 42 Commands of the Job Scheduling Definition Screen (part 2 of 2)

Command Description
JOBSTAT Displays the Statistics screen, which provides statistics for the job.

To display statistics for the currently displayed job, type:

JOBSTAT (abbreviated J)

To display statistics for any job other than the current job, format of
the command is:

JOBSTAT jobname tablename

Entering a table name is optional, but if no table name is entered,

statistics are displayed only for jobs not belonging to any table.

For more information, see “Statistics Screen” on page 245.

CHANGE Replaces an existing string with a new string.

The format of the command is:

CHANGE oldstring newstring

where:

■ oldstring is the existing string to be replaced

■ newstring is the string that replaces the existing string
NEXT The NEXT command (PF11/PF23) keeps the changes to the current
job scheduling definition in memory and automatically displays the
next job scheduling definition in the table.

For more information, see “Exiting the Job Scheduling Definition

Screen” on page 153.
PREV The PREV command (PF10/PF22) keeps the changes to the current
job scheduling definition in memory and automatically displays the
previous job scheduling definition in the table.

For more information, see “Exiting the Job Scheduling Definition

Screen” on page 153.

If a string contains embedded spaces, enclose the string in apostrophes (') or

quotation marks (").

To repeat a CHANGE command, press PF09/PF21.

Chapter 2 Online Facilities 147

Job Scheduling Definition Screen – Defining Schedules

Editing Job Scheduling Definitions in the Edit Environment

Job scheduling definition parameters can be edited, that is, moved, copied, deleted, or
repeated, by performing IOA Line Editing commands, similar to standard ISPF line
commands, from within the Control-M Edit environment.

The Edit Environment in the Job Scheduling Definition screen is accessed by typing
EDIT in the COMMAND field and pressing Enter.

Figure 24 Editing Job Scheduling Definitions in the Edit Environment Screen

JOB: BACKP02 LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+------------------------------------------------------------------------------+
__ MEMNAME BACKP02 MEMLIB CTM.PROD.JOBLIB
__ OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
__ APPL APPL-L TBL BKP-PROD-L RBC
__ DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
__ OVERLIB CTM.OVER.JOBLIB STAT CAL
__ SCHENV SYSTEM ID NJE NODE
__ SET VAR
__ CTB STEP AT NAME TYPE
__ DOCMEM BACKP02 DOCLIB CTM.PROD.DOC
__ ===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
__ ===========================================================================
__ IN START-DAILY-BACKUP ODAT
__ CONTROL
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

A 2-character Line Editing command field, marked by underscores, is displayed for

each line on the screen.

Editing commands are typed directly onto these underscores.

Specified Line Editing commands are processed when Enter is pressed.

Details and examples of the editing of job scheduling definitions in the Edit
environment are provided in Appendix C, “Editing Job Scheduling Definitions in the
Edit Environment.”

148 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

Job Documentation

Display and Non-Display of Documentation

Depending on the value of the Show Job Documentation field in the scheduling facility
entry panel, job documentation, in the form of DOC lines, is either displayed or
hidden when you first enter the Job Scheduling Definition screen:

■ If the Show Job Documentation field is set to Y, job documentation is displayed

upon entry to the Job Scheduling Definition screen.

■ If the Show Job Documentation field is set to N, documentation is hidden upon

entry to the Job Scheduling Definition screen.

DOC Command

Within a table, the DOC command toggles (alternately displays and hides) the table.
Within a job the DOC command toggles the job documentation.

NOTE
Within a table, the DOC command only affects tables. Within jobs, the DOC command only
affects jobs.

The DOC command remains in effect for the duration of an IOA online session.

Below is an example of the Job Scheduling Definition screen with the documentation
(DOC lines) displayed.

Figure 25 Job Scheduling Definition DOC lines

JOB: BACKPL02 LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+------------------------------------------------------------------------------+
MEMNAME BACKPL02 MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL APPL-L TBL BKP-PROD-L RBC
DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
OVERLIB CTM.OVER.JOBLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM BACKPL02 DOCLIB CTM.PROD.DOC
===========================================================================
DOC THIS JOB BACKS UP SPECIAL "L" FILES. IT PERFORMS THE FOLLOWING STEPS:
DOC 1: VERIFY SPACE REQUIREMENTS
DOC 2-5: BACKUP THE FILES
DOC 6: RECATALOG THE NEW FILES
DOC 7: PRINT THE SHORT-VERSION LISTING REPORT
DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O

Chapter 2 Online Facilities 149

Job Scheduling Definition Screen – Defining Schedules

DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

NOTE
If DOCU/TEXT is installed at your site, you can specify a DOCU/TEXT library and member
with up to 132 characters per line.

Editing Documentation
Documentation can be edited when the DOC lines of the Job Scheduling Definition
screen are displayed. Modify the DOC lines as desired. When you fill in the last DOC
line and press Enter, a new DOC line is displayed.

When modifying DOC lines, text must be left in at least one DOC line in order to save
the modifications. Changes resulting in an empty DOCMEM member are not saved.

Job documentation is written to the library and member specified in the DOCLIB and
DOCMEM fields on the Job Scheduling Definition screen. Therefore, it is also possible
to edit the documentation member directly through ISPF. This is recommended when
documentation is lengthy or the editing required is very complex.

Edit/Browse Mode Considerations

In general, a documentation member is entered in edit mode unless any of the
following is true, in which case the member will be entered in browse mode:

■ The user has entered the table in browse mode (via option B).

■ The documentation library has a record length greater than 80.

■ There are non-blank characters in a documentation line beyond column 71. In

addition, the displayed line is truncated.

■ The documentation library is a Panvalet or Librarian library.

■ There are non-displayable characters in the documentation member.

■ Another user is viewing or editing the same documentation member. If profile

variable SSCHBRO is set, see the chapter about IOA Administration in the
INCONTROL for z/OS Administrator Guide for details.

150 Control-M for z/OS User Guide

 Job Scheduling Definition Screen – Defining Schedules

Security access authorization to the documentation library does not determine or

limit the mode (edit/browse) in which the documentation member is entered (similar
to ISPF member checking).

Auto-Save and Saving Documentation

Documentation changes can be saved upon exiting the Job Scheduling Definition
screen. When there are documentation changes, a Save Documentation window may
be displayed depending on the value of the AUTO-SAVE DOCUMENTATION field in
the Scheduling Facility entry panel:

■ If the AUTO-SAVE DOCUMENTATION field was set to Y, documentation changes

are automatically saved and the Save Documentation window is not displayed.

■ If the AUTO-SAVE DOCUMENTATION field was set to N, documentation changes

are not automatically saved and the Save Documentation window is displayed.
This window lets you save or cancel the documentation changes.

Chapter 2 Online Facilities 151

Job Scheduling Definition Screen – Defining Schedules

Figure 26 Save Documentation Window

JOB: PRUPDT02 LIB CTM.PROD.SCHEDULE TABLE: PRPROD
COMMAN +--------------------------------------------------------+ ===> CRSR
+----- | | --------+
MEMN | SAVE DOCUMENTATION ==> (Y/N) |
OWNE | |
APPL | LIBRARY CTM.PROD.DOC |
DESC | MEMBER PRUPDT02 |
OVER | |
SCHE +--------------------------------------------------------+
SET
CTB STEP AT NAME TYPE
DOCMEM DOCLIB
========================================================================
DOC PROGRAMMER RESPONSIBLE - JOHN SMITH
DOC MODIFICATIONS:
DOC 1. NEW DD CARD ADDED 'INP002' FOR NEW INPUT FILE - FEB. 2001
DOC 2. ADDITIONAL REPORT CREATED IN STEP 04 - MAR. 2001
DOC
========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

The following parameters can be specified in the Save Documentation window:

Table 43 Save Documentation Window Fields

Field Description
SAVE Valid values are:
DOCUMENTATION
■ Y (Yes) – save documentation changes
■ N (No) – do not save documentation changes
LIBRARY Name of the library containing the documentation member.
MEMBER Name of the member containing the documentation.

Modify the LIBRARY and MEMBER values if desired, and type Y or N in the SAVE
DOCUMENTATION field; then press Enter.

If there are no documentation changes, the Save Documentation window is not

displayed.

152 Control-M for z/OS User Guide

 Exiting the Scheduling Definition Facility

Exiting the Scheduling Definition Facility

When exiting the Scheduling Definition facility, screens are exited in the following
sequence:

■ Job Scheduling Definition screen

■ Job List screen
■ Table List screen

NOTE
If the Table List screen was bypassed when you entered the Scheduling Definition facility, that
is, if you entered a TABLE value in the entry panel, the Table List screen is not displayed upon
exiting the Job List screen; instead, the entry panel is displayed.

Entry Panel
The commands and options available when exiting screens depend on the screen
being exited and on whether changes have been made. If changes have been made,
the selected exit options and commands determine whether the changes are saved.
Exit options and commands are discussed below on a screen-by-screen basis.

Exiting the Job Scheduling Definition Screen

Use any of the following commands, or press the corresponding PFKey, to exit the
Job Scheduling Definition screen:

Table 44 Commands for Exiting the Job Definition Screen (part 1 of 2)

Command Description
CANCEL Cancel the changes made to the job scheduling definition and return to
the Job List screen.
Note: The following exit commands retain changes to the job scheduling definition in
memory. To permanently save the changes to disk, you must request that the changes be
saved when you exit the Job List screen:

■ If documentation changes have been made, the Save Documentation window, described
in “Auto-Save and Saving Documentation” on page 151, may be displayed.
■ For a job: If the JOB parameter in a DO FORCEJOB request is blank, a confirmation
panel, described in “DO FORCEJOB: Post–Processing Parameter” on page 450, may be
displayed.
■ For a table: If the JOB parameter in a DO FORCEJOB request is blank, a confirmation
panel, described “ON TABLE-END: Post–Processing Parameter” on page 548, may be
displayed.
END (PF03/PF15) Keep changes to the job scheduling definition in memory and exit to the
Job List screen.

Chapter 2 Online Facilities 153

Exiting the Scheduling Definition Facility

Table 44 Commands for Exiting the Job Definition Screen (part 2 of 2)

Command Description
NEXT Keep changes to the job scheduling definition in memory and display the
(PF11/PF23) next job scheduling definition from the Job list.
PREV Keep changes to the job scheduling definition in memory and display the
(PF10/PF22) previous job scheduling definition from the Job list.

Exiting the Job List Screen

Press END (PF03/PF15) to exit the Job List screen. If changes made to at least one job
scheduling definition have been kept in memory, as discussed in the preceding
section, “Exiting the Job Scheduling Definition Screen”, and/or if changes have been
made to the Job List screen, the Exit Option window is displayed.

Figure 27 Job List Screen Exit Option Window

JOB LIST LIB: CTMP.V610.SCHEDULE TABLE: BACKUP
COMMAN +-----------------------------------------------------------+ ===> CRSR
OPT N | PLEASE SELECT EXIT OPTION | ---------
S | |
B | SAVE CREATE |
B | |
B | LIBRARY CTMP.V610.SCHEDULE |
B | TABLE ZEMER1 |
B | | <<< =====
B +-----------------------------------------------------------+
D
DASDRPT2 DASD STATISTICS REPORT AFTER BACKUP FOR APPL-L
ENDPLBKP END OF BACKUP INDICATION FOR APPL-L
BACKAC01 DAILY BACKUP OF DATA SETS FROM APPL-ACCOUNT
BACKAC02 DAILY BACKUP OF SPECIAL FILES FROM APPL-ACCOUNT
BACKACW1 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #1
BACKACW2 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #2
BACKACW3 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #3
BACKACW4 WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-ACC +
DASDRPT3 DASD REPORTS AFTER BACKUPS FOR APPL-ACCOUNT
DASDRPT4 DASD REPORTS AFTER BACKUP FOR APPL-ACCOUNT
ENDACBKP END OF BACKUP INDICATION FOR APPL-ACCOUNT
BACKDD01 DAILY BACKUP OF DATA SETS FROM APPL-DD
OPTIONS S SEL D DEL I INS O ORDER F FORCE J JCL C COPY P PLN T JOBSTAT 08.07.23

The LIBRARY and TABLE fields indicate the library and table in which the job
scheduling definitions will be saved. The specified values can be modified, for
example, to save the job scheduling definitions in a new or different table.

154 Control-M for z/OS User Guide

 Ordering (Scheduling) Jobs

Fill in the Exit Option window as follows:

■ To save all changes currently in memory and exit the Job List screen, type Y (Yes)
after the word SAVE or CREATE:

— Type Y after SAVE if a table with the same name already exists in the specified
library.

— Type Y after CREATE if a table with the same name does not exist in the
specified library.

NOTE
If you create a new table, the table name does not appear in the Table List screen upon
exiting the Job List screen; it first appears when you reenter the Table List screen from the
entry panel.

■ To cancel changes currently in memory and exit the Job List screen, type N (No)
after the word SAVE or CREATE.

■ To close the Exit Option window and remain in the Job List screen, with the
changes remaining in memory, press RESET (PF04/PF16).

Exiting the Table List Screen

Press the END key (PF03/PF15) to exit the Table List screen.

Exiting the Entry Panel

Press the END key (PF03/PF15) to exit the entry panel.

Ordering (Scheduling) Jobs

Although job scheduling in the production environment is generally handled by
Control-M automatically (for more information, see Chapter 6, “Selected
Implementation Issues”), Control-M provides several mechanisms for scheduling
jobs manually. Among these are options to manually request job scheduling from the
Table List screen and the Job List screen.

■ When manually requesting job scheduling from the Job List screen, specific jobs
are selected. Multiple jobs can be specified.

Chapter 2 Online Facilities 155

Ordering (Scheduling) Jobs

■ When manually requesting job scheduling from the Table List screen, tables are
selected and each request applies to all the jobs in the selected tables. Multiple
tables can be specified.

Either of two options, O (Order) and F (Force), can be used in either of these screens
to manually request job scheduling. These options work as follows:

Table 45 Options for Manually Ordering Jobs

Option Description
O (ORDER) Basic scheduling parameters of the jobs are checked against the
requested scheduling date. If the job must be scheduled for that day,
a job order is placed on the Active Jobs file.
F (FORCE) Basic scheduling parameters of the jobs are not checked. A job order
is placed on the Active Jobs file that day even if the scheduling
criteria of the job are not satisfied.

NOTE
With one exception, options O (Order) and F (Force) can be used for tables in both the Job List
screen and Table List screen.

The exception is: Option O (Order) cannot be entered for individual jobs in SMART
Tables.

When you use the O and F options, a confirmation window is displayed. The default
confirmation window in the case where the O option has been entered for tables in
the Table List screen is illustrated in Figure 28.

156 Control-M for z/OS User Guide

 Ordering (Scheduling) Jobs

Figure 28 Order and Force Confirmation Window (Tables)

LIST OF TABLES IN CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
OPT NAME ---------------------------------------------------------------------
STARTBKP +-------------------------------------------------+
O BACKPL01 <----------| CONFIRM ODATE 210205 WAIT FOR ODATE N HOLD |
BACKPL02 +-------------------------------------------------+
BACKPLW1
BACKPLW2 WEEKLY BACKUP OF FILES FROM APPL-L #2
BACKPLW3 WEEKLY BACKUP OF FILES FROM APPL-L #3
BACKPLW4 WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-L +
DASDRPT1 DASD REPORTS AFTER BACKUPS FOR APPL-L
DASDRPT2 DASD STATISTICS REPORT AFTER BACKUP FOR APPL-L
ENDPLBKP END OF BACKUP INDICATION FOR APPL-L
BACKAC01 DAILY BACKUP OF DATA SETS FrROM APPL-ACCOUNT
O BACKAC02 DAILY BACKUP OF SPECIAL FILES FROM APPL-ACCOUNT
BACKACW1 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #1
BACKACW2 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #2
BACKACW3 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #3
BACKACW4 WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-ACC +
DASDRPT3 DASD REPORTS AFTER BACKUPS FOR APPL-ACCOUNT
DASDRPT4 DASD REPORTS AFTER BACKUP FOR APPL-ACCOUNT
O ENDACBKP END OF BACKUP INDICATION FOR APPL-ACCOUNT
BACKDD01 DAILY BACKUP OF DATA SETS FROM APPL-DD
OPTIONS S SELECT O ORDER F FORCE G GRAPHIC FLOW B BROWSE D DELETE 10.23.58

If the O or the F option is entered for jobs in the Job List screen, a window similar to
that in Figure 29 appears.

Figure 29 Order and Force Confirmation Window (Jobs)

JOB LIST LIB: CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
OPT NAME --------------------------------------------------------------------
STARTBKP +----------------------------------------------------------+
BACKPL01 | CONFIRM y ODATE 2210003 WAIT FOR ODATE N HOLD |
0 BACKPL02 <---| Dynamic insert job into table s DUPLICATE Y |
BACKPLW1 | (S - Select, R - Recent, N - New, A-alone - default |
BACKPLW2 WEE+----------------------------------------------------------+
BACKPLW3 WEEKLY BACKUP OF FILES FROM APPL-L #3
BACKPLW4 WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-L +
DASDRPT1 DASD REPORTS AFTER BACKUPS FOR APPL-L
DASDRPT2 DASD STATISTICS REPORT AFTER BACKUP FOR APPL-L
ENDPLBKP END OF BACKUP INDICATION FOR APPL-L
BACKAC01 DAILY BACKUP OF DATA SETS FROM APPL-ACCOUNT
O BACKAC02 DAILY BACKUP OF SPECIAL FILES FROM APPL-ACCOUNT
BACKACW1 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #1
BACKACW2 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #2
BACKACW3 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #3
BACKACW4 WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-ACC +
DASDRPT3 DASD REPORTS AFTER BACKUPS FOR APPL-ACCOUNT
DASDRPT4 DASD REPORTS AFTER BACKUP FOR APPL-ACCOUNT
O ENDACBKP END OF BACKUP INDICATION FOR APPL-ACCOUNT
BACKDD01 DAILY BACKUP OF DATA SETS FROM APPL-DD
OPTIONS S SEL D DEL I INS O ORDER F FORCE J JCL C COPY P PLN T JOBSTAT 15.37.39

Chapter 2 Online Facilities 157

Ordering (Scheduling) Jobs

The default confirmation window contains the following fields:

Table 46 Order and Force Confirmation Window Fields (part 1 of 3)

Field Description
CONFIRM Whether to process the Order or Force request.

Valid values are:

■ Y (Yes) – Process the Order or Force request.

■ N (No) – Cancel the request.
ODATE Scheduling date of the job or table, in mmddyy, ddmmyy or
yymmdd format, depending on the site standard. The specified date
can be modified.
Note: The job is only ordered if the basic job scheduling criteria are
satisfied at the ODATE. However, the job is not necessarily executed
on the ODATE. If the job is ordered, it becomes eligible for execution
immediately when its run-time criteria have been satisfied.
ODATE has the following additional functions:

■ If an IN or OUT condition uses a relative dateref (for example if

the value of dateref is ODAT, PREV, or NEXT), ODATE is used to
set the dateref. For more information on IN and OUT conditions,
see “IN: Runtime Scheduling Parameter” on page 507 and “OUT:
Post–Processing Parameter” on page 571.

■ The calculation of the MAXWAIT of a job is based on the

ODATE of the job, and not on the actual date on which the job is
ordered. For more information on the MAXWAIT parameter, see
“MAXWAIT: Basic Scheduling Parameter” on page 528.

■ It is used by the WAIT FOR ODATE option (as described in this

table).

For more information on the meaning of ODATE, see the discussion

of Time Zone support in the Control-M chapter of the INCONTROL
for z/OS Administrator Guide.
WAIT FOR ODATE Whether to wait for a specific date, or process the Order or Force
request immediately.

Valid values are:

■ Y (Yes) – The Order or Force request is not executed before the

date set in the ODATE field, even if all required conditions and
resources are available.

■ N (No) – The Order or Force request is processed immediately.

Default.

158 Control-M for z/OS User Guide

 Ordering (Scheduling) Jobs

Table 46 Order and Force Confirmation Window Fields (part 2 of 3)

Field Description
HOLD Whether or not jobs should be held immediately after being ordered.

Valid values are:

■ Y – Jobs will be held immediately after being ordered.

■ N – Jobs will not be held. Default.
Dynamic insert job Enables you to insert a job into a SMART Table. Valid values are:
into SMART Table
■ A - Order or FORCE the job. Default.
■ S - Opens a window with a list of SMART Tables. For more
information, refer to “Selecting Dynamic Jobs” on page 161.
■ R - Adds the job to the SMART Table Entity that was most
recently ordered into the AJF. The insertion to the AJF is done as
FORCE.
■ N - Force a job, and its SMART Table, to the AJF.
Notes:

■ If an attempt is made to use option "R" (recent) to add a job to a

deleted SMART Table, error message JOB53BE is displayed.
Also, if an attempt is made to use option "R" (recent) to add
multiple jobs (ASK FOR EACH ONE=N), only the first job is
ordered.
■ If the "T" (SMART Table) option is entered for the SMART Table,
the added job is displayed after the SMART Table Entity and not
at the end of the list.
DUPLICATE Determines whether you can dynamically insert duplicate jobs
(meaning, jobs that already exist in the SMART Table Entity of the
AJF). Valid values are:

■ Y - A duplicate job can be inserted. Default

■ N - A duplicate job can not be inserted. Attempting to insert a
duplicate job results in the display of an error message

This parameter is only valid if the Dynamic Insert Job into SMART
Table parameter is set to S or R.

Chapter 2 Online Facilities 159

Ordering (Scheduling) Jobs

Table 46 Order and Force Confirmation Window Fields (part 3 of 3)

Field Description
ASK FOR EACH This line is displayed only if more than one order or force option is
ONE requested. It determines whether individual confirmation is required
for each order or force request.

Valid values are:

■ Y (Yes) – Individual confirmation is required for each order or

force request. The specified CONFIRM value (Y or N) applies
only to the current order or force request.

■ N (No) – Individual confirmation is not required for each order

or force request. The specified CONFIRM operation is applied to
all order or force requests. If CONFIRM is Y, all order or force
requests are processed; if CONFIRM is N, no order or force
requests are processed.

Fill in the confirmation window and press Enter. If at least one order or force request
has been specified for a table or job, the original list screen disappears and a message
screen is displayed. This screen displays messages that contain the following
information about the jobs that were scheduled.

JOB name ODATE date ID=ordered PLACED ON ACTIVE JOBS FILE-descr

Each iteration of the message screen displays job information for one table only. Press
END (PF03/PF15) to exit the message display for that table. If multiple tables, or jobs in
multiple tables, have been scheduled, the messages for the next table are displayed.
When messages for all tables have been displayed, pressing END displays the Table
or Job list screen.

160 Control-M for z/OS User Guide

 Ordering (Scheduling) Jobs

Selecting Dynamic Jobs

Entering the value S in the Dynamic Insert Job into SMART Table parameter opens
the Select SMART Table window (Figure 30).

Figure 30 Select SMART Table window

Filter: ------ CONTROL-M Dynamic Ins Job/Tbl ------ UP <D> - (3)
COMMAND ===> SCROLL===> CRSR
O NAME Owner ----Odate Jobname JobID Typ ----------- Status ---------
========= >>>>>>>>>>>>>> Top of Jobs List <<<<<<<<<<< ====
MEM1 CONTROLM 301104 TBL Held (Ordering) Table=OPHIR3
OrderID=000FY
MEM1 CONTROLM 291104 TBL Active Table=OPHIR3
OrderID=00007
TBLADJUS K30 161204 TBL Held (Ordering)
Table=TBL_WM3012 OrderID=000UN
TBLADJUS K30 161204 TBL Held (Ordering)
Table=TBL_WM3012 OrderID=000UQ

S - Select this table

To select the SMART Table Entity into which you force the job into the AJF, enter S on
the relevant line.

NOTE
All other commands in this screen are invalid. Note that the status of the SMART Table may
change as a result of adding the job to the SMART Table.

The Double Confirmation Window

Any request to order or force a job can, if you prefer, only be processed if it has been
confirmed twice. This option is selected by means of the SSCHTBO parameter.

The SSCHTBO parameter is one of the parameters set in the Presentation Modes
minor step in the Profile Variables major step of the Customize option (Option 6) of
the INCONTROL Installation and Customization Engine (ICE). The default setting is
N (No), meaning that when a table is ordered or forced, a regular confirmation
window is opened, and not a double confirmation window.

The SSCHTBO parameter can be modified at any time. If the setting of the SSCHTBO
parameter is modified to Y (Yes), a window that requires double confirmation is
opened in response to any order or force request. An example of this window is
shown in Figure 31.

Chapter 2 Online Facilities 161

Copying Jobs to Another Table

NOTE
If you change the setting of the parameter, you must exit and then reenter the IOA online
environment before the change can take effect.

Figure 31 The Double Confirmation Window

LIST OF TABLES IN CTMP.BKUP.SCHEDULE -------------(2)
COMMAND ===> SCROLL===> CRSR
OPT NAME -------------VV.MM CREATED CHANGED SIZE INIT MOD ID
BACKPER0 01.01 00/12/12 01/10/16 15:20 180 25 0 K33
BACKPER1 01.07 00/12/12 01/10/16 15:25 143 53 0 K33
O BACKPER2 02.60 00/12/12 01/10/16 15:30 74 28 0 K33
+--------------------------------------------------------------+
| |
| +------------------------------------------------------+ |
| | ALL OF THE JOBS IN TABLE BACKPL02 | |
| | WILL BE ORDERED. PLEASE CONFIRM | |
| | ------------------------------------------------ | |
| | ORDER ALL JOBS IN TABLE BACKPL02 | |
| | ODATE 120601 CONFIRM AGAIN WAIT FOR ODATE N | |
| +------------------------------------------------------+ |
| |
+--------------------------------------------------------------+
BACKACC1 01.09 00/12/12 01/10/16 15:35 57 10 0 K33
BACKACC2 01.02 00/12/12 01/10/16 15:37 25 21 0 K33
BACKACC3 02.43 00/12/12 01/10/16 15:41 127 29 0 K33
BACKACC4 01.12 00/12/12 01/10/16 15:43 36 18 0 K33
BACKADM1 01.06 00/12/12 01/10/16 15:18 23 21 0 K33
BACKADM2 01.12 00/12/12 01/10/16 15:16 27 25 0 K33
OPTIONS S SEL D DEL I INS O ORDER F FORCE J JCL C COPY P PLN T JOBSTAT 15.37.39

Copying Jobs to Another Table

To copy one or more jobs from the current table to another table, type C (Copy) in the
OPT column of the Job List screen, next to the job names, and press Enter. The
following window is displayed:

162 Control-M for z/OS User Guide

 Copying Jobs to Another Table

Figure 32 Window for Copying Jobs to Another Table

JOB LIST LIB: CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
OPT NAME -------- DESCRIPTION ------------------------------------------------
STARTBKP START OF DAILY BACKUP
BACKPL01 DAILY BACKUP OF DATA SETS FROM APPL-L
BACKPL02 DAILY BACKUP OF SPECIAL FILES FROM APPL-L
BACKPLW1 WEEKLY BACKUP OF FILES FROM APPL-L #1
BACKPLW2 +-----------------------------------------------------------+
BACKPLW3 | |
C BACKPLW4 | SPECIFY DESTINATION LIBRARY,TABLE AND JOB NAME |
DASDRPT1 | |
DASDRPT2 | LIBRARY : CTM.PROD.SCHEDULE |
ENDPLBKP | TABLE : |
BACKAC01 | JOB : BACKPLW4 |
BACKAC02 | |
BACKACW1 | PRESS END/RESET TO CANCEL ENTER TO PERFORM THE COPY |
BACKACW2 +-----------------------------------------------------------+
BACKACW3 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #3
BACKACW4 WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-ACC +
DASDRPT3 DASD REPORTS AFTER BACKUPS FOR APPL-ACCOUNT
DASDRPT4 DASD REPORTS AFTER BACKUP FOR APPL-ACCOUNT
ENDACBKP END OF BACKUP INDICATION FOR APPL-ACCOUNT
BACKDD01 DAILY BACKUP OF DATA SETS FROM APPL-DD
OPTIONS S SEL D DEL I INS O ORDER F FORCE J JCL C COPY P PLN T JOBSTAT 15.37.39

The window contains the fields shown in the following table. Some fields contain
default values that can be modified.

Table 47 Fields in the Window for Copying Jobs to Another Table

Field Description
Library Library containing the table into which the jobs must be copied.
Must be an existing library. Default is the current library.
Table Name of the table into which the job must be copied.
Notes: A job can only be copied to another table. It cannot be copied
to its own table (even if the job is renamed).

If the specified table does not exist, the table is created when the
request is performed.
Job Name of the job to be copied. If multiple jobs are selected, the
window initially display with the first selected job. As each request
is performed or canceled, the next requested job name is displayed.

To perform a request, press Enter.

To cancel a request, press END (PF03/PF15) or RESET (PF04/PF16).

SMART Table Entities cannot be copied. If a job in a SMART Table is copied to a table
that handles jobs individually, it is copied as a regular job; rule-based calendars are
dropped from the job scheduling definition. If a job in a SMART Table is copied to a
nonexisting table, the table that is created will handle jobs individually.

Chapter 2 Online Facilities 163

Deleting Tables

NOTE
When a job from a table that handles jobs individually is copied to a SMART Table, the job
retains its basic scheduling criteria and an empty SCHEDULE RBC field is inserted in the job
scheduling definition.

When a job from a SMART Table is copied to a SMART Table, the job retains its original rule-
based calendar.

Deleting Tables
Tables can be deleted from the Table List screen.

To delete tables, type D (Delete) by the table names in the Table List screen and press
Enter.

The confirmation window illustrated below is displayed, in sequence, for each table
selected for deletion.

Figure 33 Delete Table Confirmation Window

LIST OF TABLES IN CTM.PROD.SCHEDULE -------------(2)
COMMAND ===> SCROLL===> CRSR
OPT NAME --- +--------------------------+ E INIT MOD ID
ADABAS | CONFIRM DELETE OPTION | 0 70 0 O01
D APPLNTN <-----------| (Y/N) | 0 180 0 O01
APPLPRDI +--------------------------+ 1 41 0 O01
ARCNIGHT 01.00 01/02/09 01/06/07 00:50 5 5 0 S07
ASMBTR1 01.00 01/02/09 01/06/07 00:50 9 9 0 S07
D ASMBTR2 01.00 01/02/09 01/06/07 00:50 14 14 0 S07
BACKUP 01.00 01/02/09 01/06/07 00:50 5 5 0 S07
CICSJOBS 01.00 01/02/09 01/06/07 00:50 70 70 0 O01
CICSPROD 01.00 01/02/09 01/06/07 00:50 180 180 0 O01
CICSTEST 01.00 01/02/09 01/06/07 00:50 41 41 0 O01
CICSUPT 01.00 01/02/09 01/06/07 00:50 5 5 0 S07
CLIENTS 01.00 01/02/09 01/06/07 00:50 9 9 0 S07
DB2EXE 01.00 01/02/09 01/06/07 00:50 14 14 0 S07
DLOAD 01.00 01/02/09 01/06/07 00:50 5 5 0 S07
MAINDAY 01.00 01/02/09 01/06/07 00:50 180 180 0 O01
MAINT 01.00 01/02/09 01/06/07 00:50 41 41 0 O01
MAINTPL 01.00 01/02/09 01/06/07 00:50 5 5 0 S07
ONSPOOL 01.00 01/02/09 01/06/07 00:50 9 9 0 S07
D ONSPOOLT 01.00 01/02/09 01/06/07 00:50 14 14 0 S07
OPERCLN 01.00 01/02/09 01/06/07 00:50 5 5 0 S07
OPTIONS S SELECT O ORDER F FORCE G GRAPHIC FLOW B BROWSE D DELETE 15.38.37

Type Y (Yes) in the window to confirm the delete request.

Type N (No) in the window to cancel the delete request.

164 Control-M for z/OS User Guide

 Condition Inheritance

A message is written to the IOA Log file for each table deleted.

NOTE
If PDSMAN is operational at your site, $$$SPACE members are not deleted.

Condition Inheritance
When a job is deleted, there is an optional feature in Control-M that automatically
adjusts the jobs in the table so that all the jobs that are waiting for a deleted job's OUT
conditions will inherit its IN conditions.

When a job that is part of a table is deleted, and profile variable SSCHCDJ=Y, the
following window is displayed:

Figure 34 Condition Inheritance Confirmation Window

JOB LIST LIB: CTMP.V700.SCHEDULE TABLE: CICS
COMMAND ===> SCROLL===> CRSR
OPT NAME ------- DESCRIPTION ------------------------------- ------ --------
CICSPRD1 CICSPRD1
CICSPRD2 CICSPRD2
CICSTST1 CICSTST1
CICSTST2 CICSTST2
SYSTST1 SYSTST1
SYSTST2 +------------------------------------------+
D PROD1 <--------| CONFIRM DELETE OPTION (Y/N) |
PROD2 | |
PROD3 | AUTO INHERIT JOBS IN-CONDITIONS N (Y/N) |
USER1 +------------------------------------------+
USER2 USER2
USER3 USER3
SYSPROD1 SYSPROD1
SYSPROD2 SYSPROD2
SYSPROD3 SYSPROD3
LOG1 LOG1
LOG2 LOG2
LOG3 LOG3
LOG4 LOG4
LOG5 LOG5
OPTIONS S SEL D DEL I INS O ORDER F FORCE J JCL C COPY P PLN T JOBSTAT 08.34.31

The default value of the confirm delete option is blank.

The default value of the auto inherit job's in-conditions option is N.

When the confirm delete option is blank or N, the job is not deleted.

When the confirm delete option is Y and the auto inherit job's in-conditions option
is N, the job is deleted as usual.

Chapter 2 Online Facilities 165

Condition Inheritance

When the confirm delete option is Y and the auto inherit job's in-conditions option
is Y, all the jobs that are waiting for the deleted job's OUT conditions will inherit its
IN conditions.

A message is written to the IOA log file for each job deleted.

NOTE
If PDSMAN is operational at your site, $$$SPACE members are not deleted.

Limitations
Condition inheritance applies to one table only. Relationships between tables are
ignored.

Unusual job definition 1

This enhancement does not handle "unusual" job definitions. For example, assume
that three jobs are present in a table:

Under normal conditions, jobs B and C would never run. However, if job B is deleted
using the condition inheritance feature, job C will incorrectly run every Sunday.

166 Control-M for z/OS User Guide

 Condition Inheritance

Unusual job definition 2

If job B deletes condition 1, job C will never run. However, if job B is deleted using the
condition inheritance feature, job C will incorrectly run.

Unusual job definition 3

Assume that job B deletes output condition X. If job B is deleted using the condition
inheritance feature, the deletion of output condition X will be lost.

Other feature limitations

■ Parentheses are rearranged

In order to use the condition inheritance feature, Control-M formats must be

converted to standard Boolean format, manipulated, and then converted back to
Control-M format. In this case, the parentheses are rearranged, although the
functionality remains the same. For example:

Control-M format: A (|B |C)

becomes

Control-M format after manipulations: |(A B) |(A C)

Chapter 2 Online Facilities 167

Displaying Graphic Jobflow

■ Adjust condition is ignored

The Adjust Condition feature for a SMART Table is ignored.

■ DO COND is ignored

Output conditions that are associated with a DO COND statement are ignored.

■ Manual conditions

Manual conditions are treated the same way as regular conditions. This may lead
to incorrect results.

Displaying Graphic Jobflow

The Graphic Jobflow screen provides a graphic presentation of the job flow
dependencies in a given table. It is displayed when option G (Graphic Flow) is
specified for a table in the Table List screen.

Use the shifting PFKeys to shift the Graphic Jobflow right (PF11/PF23) and left
(PF10/PF22).

The FIND command (PF05/PF17), described in “FIND Command” on page 100, is

supported in the Graphic Jobflow screen.

To return to the Table list, press the END key (PF03/PF15).

Two formats for the Graphic Jobflow screen are available, one for color displays and
one for non-color displays.

Graphic Jobflow for Color Terminals

Figure 35 Graphic Jobflow for Color Terminals
------------------- GRAPHIC JOBFLOW - TABLE PRODYH --------------------- (2.G)
COMMAND ===> SCROLL===> CRSR

PRODYJCL ---> PRODYHTK -------------------> PRODYHST

PRODTHC2 ---> PRODYBCK ---> PRODYIDK ---> ---> PRODYBTL

---> PRODYIZN ---> PRODYEND

PROJYFOT ---> PROJYMRG ---> PROJYMTI

---> PROJYHO1 ---> PROJYHO2

168 Control-M for z/OS User Guide

 Displaying Graphic Jobflow

---> PROJYDPY ---> PROJYDTK ---> PROYH11 ---

---> PROJYDLI --->

PRESS END TO RETURN. LEFT AND RIGHT TO SEE MORE. COLUMNS: 001 - 080 15.38.44

NOTE
Size limits for the online display are narrower than the size limits for the printed chart. The
online display is limited to 15 levels of dependencies. If the chart cannot be displayed online
because it is too large, it can still be printed. For more information, see the description of the
CTMRFLW utility in the Control-M chapter of the INCONTROL for z/OS Utilities Guide.

On color terminals, the colors used to display the boxes and arrows can be changed
by request. Available colors are sequenced in a loop. Each request changes to the next
color in the sequence. Colors can be changed as follows:

Table 48 Color Change Options on Graphic Jobflow Window

Option Description
Change the color of the boxes Press PF04/PF16
Change the color of arrows Type ARROW in the COMMAND field and press Enter.a
a
PF05/PF17, which used to change the color of arrows, now performs the FIND command.

Graphic Jobflow for Non-Color Terminals

Figure 36 Graphic Jobflow for Non-Color Terminals
-------------------- GRAPHIC JOBFLOW - TABLE PRODYH --------------------- (2.G)
COMMAND ===> SCROLL===> CRSR
.----------. .----------. .----------.
| PRODYJCL |--->| PRODYHTK |--->--->--->--->--->| PRODYHST |
`----------' `----------' | |
.----------. .----------. .----------. | | .----------.
| PRODTHC2 |--->| PRODYBCK |--->| PRODYIDK |--->| |--->| PRODYBTL |
`----------' `----------' | | `----------' `----------'
| | .----------. .----------.
| |--->| PRODYIZN |--->| PRODYEND |
`----------' `----------' `----------'
.----------. .----------. .----------.
| PROJYFOT |--->| PROJYMRG |--->| PROJYMTI |
`----------' | | `----------'
| | .----------. .----------.
| |--->| PROJYHO1 |--->| PROJYHO2 |
| | `----------' `----------'
| | .----------. .----------. .----------.
| |--->| PROJYDPY |--->| PROJYDTK |--->| PROYH11 |--
`----------' | | `----------' | |
| | .----------. | |
| |--->| PROJYDLI |--->| |
| | `----------' `----------'
PRESS END TO RETURN. LEFT AND RIGHT TO SEE MORE. COLUMNS: 001 - 080 15.38.44

Chapter 2 Online Facilities 169

Displaying a Job Scheduling Plan

NOTE
Size limits for the online display are narrower than the size limits for the printed chart. If the
chart cannot be displayed online because it is too large, it may still be printed. For more
information, see the KeyStroke Language (KSL) User Guide.

Displaying a Job Scheduling Plan

To display the scheduling plan of a job or SMART Table Entity in calendar format,
either type P (Plan) by the job or SMART Table Entity name in the Job List screen and
press Enter, or enter command PLAN in the Job Scheduling Definition screen. The
following window is displayed:

Figure 37 Job Scheduling Plan Window

JOB LIST LIB: CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
OPT NAME ----- DESCRIPTION ---------------------------------------------------
STARTBKP START OF DAILY BACKUP
BACKPL01 DAILY BACKUP OF DATA SETS FROM APPL-L
BACKPL02 DAILY BACKUP OF SPECIAL FILES FROM APPL-L
BACKPLW1 WEEKLY BACKUP OF FILES FROM APPL-L #1
BACKPLW2 WEEKLY BACKUP OF FILES FROM APPL-L #2
BACKPLW3 WEEKLY BACKUP OF FILES FROM APPL-L #3
BACKPLW4 WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-L +
DASDRPT1 DASD REPORTS AFTER BACKUPS FOR APPL-L
DASDRPT2 DASD STATISTICS REPORT AFTER BACKUP FOR APPL-L
ENDPLBKP +---------------------+
BACKAC01 | FROM DATE 050101 |
P BACKAC02 | TO DATE 053101 |
BACKACW1 +---------------------+
BACKACW2
BACKACW3 WEEKLY BACKUP OF FILES FROM APPL-ACCOUNT #3
BACKACW4 WEEKLY BACKUP OF FILES AFTER DAILY FROM APPL-ACC +
DASDRPT3 DASD REPORTS AFTER BACKUPS FOR APPL-ACCOUNT
DASDRPT4 DASD REPORTS AFTER BACKUP FOR APPL-ACCOUNT
ENDACBKP END OF BACKUP INDICATION FOR APPL-ACCOUNT
BACKDD01 DAILY BACKUP OF DATA SETS FROM APPL-DD
OPTIONS S SEL D DEL I INS O ORDER F FORCE J JCL C COPY P PLN T JOBSTAT 15.37.39

The window contains the following fields with default values that can be modified:

Table 49 Job Scheduling Plan Window Fields

Field Description
FROM DATE First date to be included in the job scheduling plan. Default is current
working date.
TO DATE Last date to be included in the job scheduling plan. Default is one
day less than one month after the current working date.

170 Control-M for z/OS User Guide

 Displaying a Job Scheduling Plan

To display the plan, modify the defaults if desired. Press Enter. The Job Scheduling
Plan screen is displayed.

To close the window without displaying the plan, press END (PF03/PF15) or RESET
(PF04/PF16).

Job Scheduling Plan Screen

For each month in the requested date range, beginning with the first month in the
range, the Job Scheduling Plan screen displays a calendar that indicates the schedule
of the job.

NOTE
The months (within the date range) in which the job (or jobs for a table schedule) is not
scheduled are not displayed.

The dates within the date range on which the job is scheduled, according to its basic
scheduling criteria, are marked with an asterisk.

Enter NEXT (PF08/PF11/PF20/PF23) or PREV (PF07/PF10/PF19/PF22) in the COMMAND

field, or press the appropriate PFKey, to see the next or previous calendar month in
the date range.

Press the END key (PF03/PF15) to exit the Job Scheduling Plan screen and return to the
Job List screen.

Figure 38 Job Scheduling Plan Screen

JOB NAME: BACKPL02 JOB SCHEDULING DATES : 010601 - 300601
COMMAND ===> SCROLL===>
06 2001 MON TUE WED THU FRI SAT SUN
01 02 03

04 05 06 07 08 09 10
* * * * *

11 12 13 14 15 16 17
* * * * *

18 19 20 21 22 23 24
* * * * *

25 26 27 28 29 30
* * * * *

CMDS: NEXT, PREV, END 19.30.51

Chapter 2 Online Facilities 171

Tracking and Control Facility

The screen indicates the following:

Table 50 Job Scheduling Plan Screen Fields

Field Description
Job Name of the job for which the schedule is requested.
Range Requested date range, in mmddyy, ddmmyy, or yymmdd format,
depending on the site standard.
Month/Year Month and Year currently displayed.
Calendar Calendar (day of the week and date) for the currently displayed month.
Schedule An asterisk under a date indicates that the job is scheduled on that day.

Tracking and Control Facility

The Tracking and Control facility provides relevant information about the status of
each job and task in the Active environment and enables you to manually intervene in
the processing of jobs.

The Active environment contains all the jobs in the Active Jobs file, that is, all jobs
that have recently executed, are currently executing, or are scheduled for possible
execution in the near future.

The main screen of the Tracking and Control facility is the Active Environment
screen, which displays a list of all jobs and their statuses in the Active environment.

The Active Environment screen is accessed by requesting option 3 on the IOA

Primary Option menu.

From the Active Environment screen you can request specific actions in relation to a
job, or request the display of other screens that provide additional information and
capabilities. Possible requests include

■ Change the screen display type to display different information about the jobs in
the Active environment.

■ View only jobs belonging to a specific table name.

■ View statistical information about all jobs in the Active environment.

■ Display the reasons why a job has not executed.

■ Place a job in Hold status.

■ Delete a job from the Active environment.

172 Control-M for z/OS User Guide

 Active Environment Screen

■ Delete a SMART Table Entity and all the jobs in the SMART Table from the Active
environment.

■ Undelete a job that has been deleted from the Active environment.

■ Free a held job.

■ Display the log messages of a job.

■ Zoom in on the scheduling details of a job and modify certain parameters.

■ Rerun a job.

■ Confirm the restart and/or rerun of a job.

■ View the list of all runs (job orders) of a particular job, and view the sysout of any
or all of those job orders.

■ Display the execution statistics of a job.

■ Display and edit the JCL of a job.

■ Display the list or network of predecessor and successor jobs of a specific job, and
display critical path information.

■ Force END OK termination of a job that has not been submitted or that ended
NOTOK.

■ Reactivate a job that has “disappeared” or that has failed with status “Reason
Unknown”.

■ Display the list of archived jobs (in the History file) and restore desired archived
jobs to the Active environment.

Active Environment Screen

To enter the Tracking and Control facility, select option 3 on the IOA Primary Option
menu. The Active Environment screen is displayed.

Chapter 2 Online Facilities 173

Active Environment Screen

Figure 39 Control-M Active Environment Screen

Filter: ------- CONTROL-M Active
Environment ------ UP <D> (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ------------ Status -----------
CICSPROD M22 060601 CICSPROD/04368 CST Executing (Run 1)
CICSTEST M22 060601 CICSTEST/04372 CST Executing (Run 2)
BRIVPCC IVP 060601 TBL Active
BRCC0001 IVP 060601 BRCC0001/04382 JOB Held Wait Schedule
BRCC0002 IVP 060601 BRCC0002/04383 JOB Held Ended "OK" (Run3)
Prior Run: Ended "OK"
BRCCIND IVP 060601 BRCCIND /04385 JOB Ended "OK"
BRUPDT02 IVP 060601 BRUPDT02/04387 JOB Ended "OK"
BRREP002 IVP 060601 BRREP002/04389 JOB Ended "OK"
BRIVPCCE IVP 060601 / JOB Wait Schedule
CRCCEND IVP 060601 / JOB Wait Schedule
INTR0001 M22 060601 / JOB Ended- Not "OK" Due to CC -
Rerun Needed (Run 3)
Prior Run: Ended- Not "OK" Due
to CC - Rerun was Needed
INTR0003 M22 060601 / JOB Wait Schedule
BRREP003 IVP 060601 BRREP003/04391 JOB Ended "OK"
BRREP004 IVP 060601 BRREP004/04393 JOB Ended "OK"
INTR0004 M22 060601 INTR0004/04397 JOB Ended- Not "OK" - Abended
Commands: OPt DIsplay Show HIstory RBal REFresh Auto Jobstat SHPF Note Table
OPt command toggles between Commands and Options display 15.15.48

It is assumed that you want to see the most recently ordered jobs first. Therefore, by
default, the bottom of the Job list is displayed upon entry to the Active Environment
screen. This default can be altered by setting Profile variable SACTMOD to T, in
which case jobs are displayed from the top of the Job list. Profile variable SACTMOD
is described in the INCONTROL for z/OS Administrator Guide.

AutoRefresh mode is available in this screen.

To exit the Active Environment screen, press the END key (PF03/PF15).

For color terminals, jobs with different statuses are displayed in different colors. Each
of the colors in the following table has been defined as the default for one of these
statuses. These statuses are described more fully in Table 64 on page 200.

NOTE
To change color definitions, see your INCONTROL administrator.

Table 51 Default Colors for Active Missions Screen (part 1 of 2)

Color Corresponding Status
Blue and White Jobs waiting to be scheduled
Yellow Jobs that are executing or about to execute
Red Jobs that are in error or ended NOTOK or LATE (submitted and/or
executing jobs)

174 Control-M for z/OS User Guide

 Active Environment Screen

Table 51 Default Colors for Active Missions Screen (part 2 of 2)

Color Corresponding Status
Green Jobs that ended OK or were forced OK
Pink Jobs that require special user action (such as Wait Confirmation)

Display Types of the Active Environment Screen

The information in the Active Environment screen can be displayed in different
formats or display types. A number of predefined display types are available.

While in the Active Environment screen, the display type can be changed by the
DISPLAY command. The DISPLAY command is described in “Commands of the
Active Environment Screen” on page 180.

Table 52 Predefined Display Types

Type Description
D Default display type.
A All info display type.
N Network display type.

The INCONTROL administrator can use display type support to tailor the display
layout by adding lines, fields, changing colors, and so on. Additional information
about display type support is provided in the section on customizing IOA display
format members in the INCONTROL for z/OS Administrator Guide.

NOTE
The $$ACTDOC member in the IOA MSG library contains information that is useful for
customizing the Control-M Active Environment screen and creating and modifying display
types for screens 3, 3.N, 3.G and the History Environment screen.

Upon reentering the screen, the last-used display type is displayed.

The Default and All Info predefined display types, and the fields they contain, are
discussed in “Format of the Active Environment Screen” on page 176.

The Network display type, although available in this screen, is generally useful only
in the Job Dependency Network screen, and is described in “Job Dependency
Network Screen” on page 249.

Primary and Alternate Bottom Lines

The last two lines of the Active Environment screen are used to display the list of
available commands and options.

Chapter 2 Online Facilities 175

Active Environment Screen

Because there are too many commands and options to list at once, the list is divided
into two parts, each part consisting of two lines, as follows:

■ Upon entry to the screen, the set of available commands is displayed. Because this
list is displayed upon entry to the screen, it is referred to as the Primary Bottom
line.

Commands: OPt DIsplay Show HIstory RBal REFresh Auto Jobstat SHPF Note Table
OPt command toggles between Commands and Options display 15.15.48

■ Upon request (using command OPT), the set of available options is displayed (in
place of the set of commands). The list of available options is referred to as the
Alternate Bottom line.

Opt: ? Why L Log H Hold Z Zoom R Rerun A Activate O Force OK V View Sysout
N Net D Del F Free S Stat T Table U Undelete J JCL Edit C Confirm 15.46.06

To toggle back and forth between the two sets of bottom lines, type OPT in the
COMMAND field and press Enter.

Available commands are described in “Commands of the Active Environment

Screen” on page 180. Available options are described in “Options of the Active
Environment Screen” on page 186.

Format of the Active Environment Screen

Display Type D (Default)

Below is an example of the Default display type. It contains the most relevant
information about the job.

176 Control-M for z/OS User Guide

 Active Environment Screen

Figure 40 Display Type D (Default)

Filter: DEFAULT ------- CONTROL-M Active Environment ------ UP <D> (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ----------- Status ------------
CICSPROD M22 060601 CICSPROD/04368 CST Executing (Run 1)
CICSTEST M22 060601 CICSTEST/04372 CST Executing (Run 2)
BRIVPCC IVP 060601 TBL Active
BRCC0001 IVP 060601 BRCC0001/04382 JOB Held Wait Schedule
BRCC0002 IVP 060601 BRCC0002/04383 JOB Held Ended "OK" (Run3)
Prior Run: Ended "OK"
BRCCIND IVP 060601 BRCCIND /04385 JOB Ended "OK"
BRUPDT02 IVP 060601 BRUPDT02/04387 JOB Ended "OK"
BRREP002 IVP 060601 BRREP002/04389 JOB Ended "OK"
BRIVPCCE IVP 060601 / JOB Wait Schedule
CRCCEND IVP 060601 / JOB Wait Schedule
INTR0001 M22 060601 / JOB Ended- Not "OK" Due to CC -
Rerun Needed (Run 3)
Prior Run: Ended- Not "OK" Due
to CC - Rerun was Needed
INTR0003 M22 060601 / JOB Wait Schedule
BRREP003 IVP 060601 BRREP003/04391 JOB Ended "OK"
BRREP004 IVP 060601 BRREP004/04393 JOB Ended "OK"
INTR0004 M22 060601 INTR0004/04397 JOB Ended- Not "OK" - Abended
Commands: OPt DIsplay Show HIstory RBal REFresh Auto Jobstat SHPF Note Table
OPt command toggles between Commands and Options display 15.15.48

Fields of Display Type D (Default)

Table 53 Fields in the Default Display Type

Field Description
Filter Name of the currently active screen filter. For more information, see
“Filtering the Active Environment Screen Display” on page 196.
Control-M Status Indicator of whether Control-M monitor is UP, DOWN or SUSP
(suspended).
Display Type Indicator of the currently used display type, such as D for the
Default display type.

The following is displayed for each job:

Table 54 Fields for Each Job Default (part 1 of 2)

Field Description
O(ption) Field for requesting options to be activated on jobs.
Name Name of the member containing the JCL of the job, or name of the
started task.
Owner ID of the owner of the job.
Odate Original scheduling date of the job. For more information, see “Date
Definition Concepts” on page 65.
Jobname Job name – generally available only after job submission.
JobID Job number – generally available only after job submission.

Chapter 2 Online Facilities 177

Active Environment Screen

Table 54 Fields for Each Job Default (part 2 of 2)

Field Description
Typ Task type or TBL.
Status Job (task) status, For more information, see “Job Statuses” on
page 191.

The information in the following table can be displayed by request, along with the
STATUS information. For more information, see “Commands of the Active
Environment Screen” on page 180.

Table 55 Other Information in the STATUS Field

Type Descriptions
TABLE Table name of the job, discussed in Chapter 3, “Job Production
Parameters.”
CPU ID of the CPU on which the job is executing or has executed. The
CPU ID is displayed only for those jobs subjected to dynamic
resource acquisition (that is, jobs for which Control-M dynamically
decided to which CPU they would be submitted). Dynamically
acquired resources are identified by a $ character in the Quantitative
resource name. For more information, see “CPUID” on page 184.
OrderID Order ID of the job. For more information, see “ORDERID” on
page 186.
Desc Job description. For more information, see “DESC” on page 134.
Table Scheduling library and table of the job. For more information, see
“TABLE” on page 183.
Note First line of the note (if one exists). For more information, see
“NOTE” on page 193.

O Name Owner Odate Jobname JobID Typ ----------- Status ------------

TO5SP115 TO5 060601 / JOB Wait Schedule Table=NRD-TBL
CPU=A OrderID=0003E ===>BACKUP
SCHED-LIB=CTM.PROD.BKP(SPBKP)
*** Note ***

Display Type A (All Info)

The following is an example of the All Info display type. In addition to the Default
information, it contains statistical information about the job run.

178 Control-M for z/OS User Guide

 Active Environment Screen

Figure 41 Display Type A (All Fields)

Filter: ------- CONTROL-M Active Environment ------ DOWN <A> - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ----------- Status ------------
DAILYPRD PRODMNGR 060601 JOB Wait Schedule
OrderID 001Q6 TBL CTM-CONTROL
MaxRC Res. Use: Y
Time Fr: Time Un: Priority: 00
Due-In: 0859 Due-Out: 0859 Late:
Avg Elaps: 0000 RBA: 000002
DAILYSYS SYSTEM 060601 JOB Wait Schedule
OrderID 001Q7 TBL CTM-CONTROL
MaxRC Res. Use: Y
Time Fr: Time Un: Priority: 00
Due-In: 0859 Due-Out: 0859 Late:
Avg Elaps: 0000 RBA: 000003
CTMLDNRS PRODMNGR 060601 JOB Wait Schedule
OrderID 001Q8 TBL CTM-CONTROL
MaxRC Res. Use: Y
Time Fr: Time Un: Priority: 00
Due-In: 0859 Due-Out: 0859 Late:
Avg Elaps: 0000 RBA: 000004
CTMCLRES PRODMNGR 060601 JOB Wait Schedule
Opt: ? Why L Log H Hold Z Zoom R Rerun A Activate O Force OK V View Sysout
N Net D Del F Free S Stat T Table U Undelete J JCL Edit C Confirm 14.50.56

Fields of the Display Type A (All Info)

Below is a description of fields in the All Info display type that do not appear in the
Default display type. The fields that appear in the Default display type are described
in the preceding section.

Table 56 Fields in the All Fields Display Type (part 1 of 2)

Field Description
TBL Name of the table.
MaxRC Highest return code returned for the job.
Res. Use Indicates (yes or no) whether the job uses (Control and/or
Quantitative) resources.
Time Fr Time the job began execution.
Time Un Time the job ended execution.
Priority Priority at which the job executed.
Due-In Time by which the job was to be submitted.
Due-Out Time by which the job execution must complete.

Chapter 2 Online Facilities 179

Active Environment Screen

Table 56 Fields in the All Fields Display Type (part 2 of 2)

Field Description
Late Indicates if the job is late. Valid (Late) values:

■ I – Late In - the job was submitted late

■ X – Late Execution - the job execution time was outside

predefined limits

■ O – Late Out - the job ended outside the predefined time limit
Avg Elaps Average elapsed run time of the job.
RBA Relative Byte address of the job in the Active Jobs file.

Commands of the Active Environment Screen

The commands in the following table can be requested by typing the command in the
COMMAND field of the Active Environment screen and pressing Enter.

Table 57 Commands of the Active Environment Screen (part 1 of 7)

Command Description
OPT Toggles between the Primary Bottom line (composed of most of the
available Primary commands) and the Alternate Bottom line
(composed of all available options).
DISPLAY Used to change display types. The format of the command is

DISPLAY x (abbreviated DI x)

where x is the desired display type. For example, DI A displays the

All Info display type.
Note: For a list of display types, enter DISPLAY ? to show the
Display Options window. To select a display type in the window,
type S in the Option field next to the ID. To exit the window without
selecting a display type, press the END key (PF03/PF15).

Example

DI N

displays the Net fields display.

Valid predefined displays are:

■ D – Default Display Type. For more information, see “Display

Type D (Default)” on page 176.
■ N – Net Fields Display Type. For more information, see “Display
Type N (Network)” on page 250.
■ A – All Fields Display Type. For more information, see “Display
Type A (All Info)” on page 178.

180 Control-M for z/OS User Guide

 Active Environment Screen

Table 57 Commands of the Active Environment Screen (part 2 of 7)

Command Description
SHOW Activates the specified screen filter, or opens the Show Screen Filter
window or the Display Filters window, depending on the format of
the command. For more information, see “Filtering the Active
Environment Screen Display” on page 196.

Valid formats are:

■ SHOW name – Activates the selected filter.

■ SHOW ? – Opens the Display Filters window that lists all
available filters.
■ SHOW (PF02/PF14) – Opens the Show Screen Filter window,
displaying the settings of the currently active filter. This enables
editing of the selected filter.
■ SHOW name EDIT – Opens the Show Screen Filter window of
the selected filter, displaying its settings. This enables editing of
the selected filter.
Note: Reserved filter name DEFAULT can be used to activate or edit
the default filter for the Active Environment screen.

Only jobs conforming to selection criteria specified in the filter are

displayed in the Active Environment screen
HISTORY Displays the jobs in the History Jobs file in the History Environment
screen, which is described in “History Environment Screen” on
page 252.
RBAL Scrolls the Active Environment screen so that the job with the
specified relative byte address (RBA) is displayed at the top of the
screen.

The format of the command is

RBAL rba (abbreviated RB rba)

where rba is the relative byte address of the job.

This command is especially useful for determining which job is

using a particular resource. The RBA of the job using a resource is
indicated in the IOA Conditions/Resources screen (Screen 4).

Chapter 2 Online Facilities 181

Active Environment Screen

Table 57 Commands of the Active Environment Screen (part 3 of 7)

Command Description
REFRESH Initiates recalculation of job dependency information.

The recalculation

■ updates the list of dependent jobs in the Job Dependency

Network screen, recalculates logical dependencies for all job
orders currently present in the Active Jobs file and updates the
Job Dependency Network screen
■ adjusts DUE OUT times for all job orders in the Active Jobs file
that are not Held
■ adjusts the priority of predecessor jobs
■ simultaneously activates processes NET, DEADLINE, and
PROPAGATE in the Control-M monitor
Note: Although available in the Active Environment screen, this
command is generally used in the Job Dependency Network screen.
AUTO Activates AutoRefresh mode.

The format of the command is

AUTO n

where n is any number of seconds within the range 1 through 99. For
more information, see “AutoRefresh Mode” on page 104
JOBSTAT Displays the Statistics screen, which provides statistics for the
specified job. For more information, see “Statistics Screen” on
page 245.

Unlike Option S (STAT), which can be entered only for jobs

appearing in the Active Environment screen, the JOBSTAT
command can be entered for any job. Format of the command is

JOBSTAT jobname tablename

Specification of a Table name is optional, but if no Table name is

specified, statistics are displayed only for jobs not belonging to any
Table.
SHPF Displays the PFKey assignment of the screen. For more information,
see “Commands and PFKeys” on page 97

182 Control-M for z/OS User Guide

 Active Environment Screen

Table 57 Commands of the Active Environment Screen (part 4 of 7)

Command Description
NOTE Displays or hides the first line of a note (if one exists).

The format of the command is

NOTE {ON|OFF}

where

■ ON – Displays the first line of the note

■ OFF – Hides the note

If no ON of OFF qualifier is entered, the NOTE command toggles

between displaying and hiding the first line of the note.

The current setting is kept in the user profile for the next time the
screen is displayed.
TABLE Displays or hides the name of the job scheduling library and table
from which the job was ordered.

The format of the command is

TABLE {ON|OFF}

where

■ ON – displays the name of the job scheduling library and table

■ OFF – hides the name of the job scheduling library and table

If no ON of OFF qualifier is entered, the TABLE command toggles

between displaying and hiding the name of the job scheduling
library and table.

The current setting is kept in the user profile for the next time the
screen is displayed.

Chapter 2 Online Facilities 183

Active Environment Screen

Table 57 Commands of the Active Environment Screen (part 5 of 7)

Command Description
CPUID Displays or hides the CPU ID of jobs subjected to dynamic resource
acquisition. When displayed, the CPU ID on which the job is running
(or executed on) appears after the job status.

The format of the command is:

CPUID {ON|OFF}

where:

■ ON – displays the CPU ID

■ OFF – hides the CPU ID

If no ON or OFF qualifier is entered, the CPUID command toggles

between displaying and hiding the CPU ID.

The current setting is kept in the user profile for the next time the
screen is displayed.
DESC Displays or hides the description of each job.

The format of the command is:

DESC {ON|OFF}

where

■ ON – Displays the description

■ OFF – Hides the description

If no ON or OFF qualifier is entered, the DESC command toggles

between displaying and hiding the description.

The current setting is kept in the user profile for the next time the
screen is displayed.

184 Control-M for z/OS User Guide

 Active Environment Screen

Table 57 Commands of the Active Environment Screen (part 6 of 7)

Command Description
DUMP Used in special circumstances when requested by BMC Software
Customer Support. The command is used to capture abends
resulting from either internal or external events.

The format of the command is:

DUMP {ON|OFF}

where

■ ON – provides a DUMP
■ OFF – does not provide a DUMP

If no ON of OFF qualifier is entered, the DUMP command toggles

between providing and not providing a DUMP.

The current setting is kept in the user profile for the next time the
screen is displayed.

When DUMP ON is requested, the DUMP ON indicator is displayed

in the first line of the screen.
TABLE Displays or hides the table name. When displayed, the name of the
table appears after the job status.
(PF11/PF23)
The format of the command is:

TABLE {ON|OFF}

where:

■ ON – displays the Table name

■ OFF – hides the Table name

If no ON or OFF qualifier is entered, the TABLE command toggles

between displaying and hiding the table name.

The current setting is kept in the user profile for the next time the
screen is displayed.
OIDL Scrolls the Active Environment screen so that the job with the
specified order-ID is displayed at the top of the screen.

The format of the command is:

OIDL ord_ID

where ord_ID is the order-ID of the job.

Chapter 2 Online Facilities 185

Active Environment Screen

Table 57 Commands of the Active Environment Screen (part 7 of 7)

Command Description
ORDERID Displays or hides the order ID of each job.

The format of the command is:

ORDERID {ON|OFF}

where:

■ ON – Displays the order ID

■ OFF – Hides the order ID

If no ON of OFF qualifier is entered, the ORDERID command

toggles between displaying and hiding the order ID.

The current setting is kept in the user profile for the next time the
screen is displayed.
VIEW Displays the Global View screen, which provides a statistical
overview of the status of jobs running under Control-M. For more
(PF04/PF16) information, see “Global View Screen” on page 206.
VIEW GRAPH Displays the View Graph screen, which provides a graphic statistical
overview of the status of jobs running under Control-M. For more
(VG) information, see “View Graph Screen” on page 208.

Options of the Active Environment Screen

Select an option by typing it in the O (Option) field to the left of the job order and
pressing Enter. The following table describes the available options:

Table 58 Options of the Active Environment Screen (part 1 of 6)

Option Description
? (Why) Display the Why screen, which shows the reasons the job is in Wait
Schedule status. For more information, see “Why screen” on
page 212.
L (Log) Display the Log screen, which shows all IOA Log messages for the
specified job. For more information, see “IOA Log Screen” on
page 303.
H (Hold) Hold Control-M operations on the job order. Only Control-M
operations concerning the job order are halted. The flow of the job
through the operating system is not held. The HOLD request is
recorded in the IOA Log file. The status of the job is changed to
REQUESTED HELD. If the Control-M monitor is active, the status
changes to HELD. In some cases, a HOLD request may be rejected by
the monitor.
Z (Zoom) Display the Zoom screen, which “zooms in” on job details. For more
information, see “Zoom Screen” on page 220.

186 Control-M for z/OS User Guide

 Active Environment Screen

Table 58 Options of the Active Environment Screen (part 2 of 6)

Option Description
R (Rerun) Rerun the job. A Rerun window is displayed. For more information,
see “Confirm Rerun Window” on page 229.
A (Activate) Reactivate a job or started task that has a status of either
DISAPPEARED or FAILED REASON UNKNOWN. Control-M
searches the MVS/JES queues for the disappeared or failed job or
started task.

A job or started task is assigned a DISAPPEARED status if it has

been accidentally deleted. Also, if JES is very busy, it sometimes sets
the status of a job or started task to DISAPPEARED even though the
job or started task actually exists.

A job or started task is assigned a status of FAILED REASON

UNKNOWN whenever Control-M encounters a problem reading the
SYSDATA files of the job and therefore cannot check the completion
status of the job.
O (Force OK) Force the job to complete with ENDED OK status. For more
information, see “Force OK Confirmation Window” on page 254.
§Restart§ V (View View the execution history of the job in the Job Order Execution
Sysout) History screen. From this screen, the Sysout Viewing screen, which
displays the archived SYSDATA of the job, can be requested. For
more information on these screens, see “§Restart§Job Order
Execution History Screen” on page 241, and “§Restart§ Sysout
Viewing Screen” on page 243.
N (Net) Display the Job Dependency Network screen, which shows all the
predecessor and successor jobs for the selected job. For more
information, see “Job Dependency Network Screen” on page 249.
D (Del) Delete the job. For more information, see “Delete Confirmation
Window” on page 219.
Note: If you delete a SMART Table Entity, all jobs which are part of
that SMART Table are also deleted.
F (Free) Free a held job order. All Control-M operations for the job order are
resumed. If the job is currently in the job queue of the operating
system in HOLD state, the job is not released. The FREE request is
recorded in the IOA Log file. The status of the job is changed to
REQUESTED FREE. If the monitor is active, the FREE request is
accepted after a few seconds.
S (Stat) Display the Statistics screen, which shows job run statistics. Statistics
for a job that is not in the Active environment can be displayed using
command JOBSTAT. For more information, see “Statistics Screen”
on page 245.

Chapter 2 Online Facilities 187

Active Environment Screen

Table 58 Options of the Active Environment Screen (part 3 of 6)

Option Description
T(TBL) Display the SMART Table Entity (TBL entry) and all jobs that are
part of that SMART Table. This option can be entered next to a TBL
entry, or next to any job that is part of a SMART Table. Jobs that are
part of a SMART Table are marked with the letter T (TBL) to the right
of the SMART Table name under display type A (Activate).
Option T must be entered as the last option in the screen.
When the Table option is requested, the name of the selected table
appears in the title line of the screen.
U (Undelete) Cancel a previously requested Delete. Valid only for jobs deleted by
request. The job is returned to its status prior to the delete request.
Note: If you undelete a job that is part of a deleted SMART Table, the
SMART Table Entity is undeleted, together with the individual job.
However, if you undelete a deleted SMART Table, only the SMART
Table is undeleted, and not the jobs in the SMART Table. If you want
also to undelete a job or jobs that are part of that SMART Table, you
must undelete each job individually.
J (JCL Edit) Edit the member that contains the JCL of the job.

By default, if the specified JCL member exists in the OVERLIB

library, that member is edited. If the JCL member does not exist in
the OVERLIB library, the member is edited in the MEMLIB library.
C (Confirm) Confirm that this job is to be scheduled. A window is displayed to
permit user confirmation. Entering Y sets the status of the job to
WAIT SCHEDULE. For more information, see “Confirm Scheduling
Window” on page 229.

188 Control-M for z/OS User Guide

 Active Environment Screen

Table 58 Options of the Active Environment Screen (part 4 of 6)

Option Description
% (Simulation) Simulates the action of the Control-M Submission mechanism for a
job that was previously placed in the Active Jobs file. This option is
similar to the CTMAESIM utility, which is described in the section
concerning testing AutoEdit syntax in Chapter 5, “JCL and AutoEdit
Facility.” The option produces the JCL stream for the job and a report
of the process.

The IOA Editor directs the output of the AutoEdit simulation to the
user’s screen, with the following header line displayed:

CONTROL-M_AUTOEDIT_SIMULATION(memname)

where memname is the name of the JCL member of the job.

The report consists of two parts:

■ the messages produced by Control-M during the simulated job

processing
■ the JCL stream as it would be submitted by the Control-M
Monitor to the MVS internal reader if the job is rerun

The user can use the IOA editor to edit the output, and save it as a
member in a library.
Notes:

■ For DUMMY jobs, no JCL stream is generated.

■ To activate this function, the user must have read-access security
authorization to the JCL library (MEMLIB).

Chapter 2 Online Facilities 189

Active Environment Screen

Table 58 Options of the Active Environment Screen (part 5 of 6)

Option Description
B (Bypass) Display the BYPASS option window. This option enables you to
specify criteria and resources to be ignored for those jobs that have a
status of WAIT SCHEDULE.

By default, all fields in the BYPASS option window are set to N.

You may set any or all these fields to Y, with the following effects:

IN Criteria:

■ Time Limit – All the time limit selection criteria of the job, such
as TIME FROM, TIME UNTIL, DUE OUT, and NEXT, are
ignored. The job is submitted when all other criteria are satisfied.
■ IN Conditions – All IN conditions of the job are ignored. The job
is submitted when all other criteria are satisfied.
■ Quantitative Resources – All quantitative resources of the job are
ignored. The job is submitted when all other criteria are satisfied.
■ CONTROL Resources – All CONTROL resources of the job are
ignored. The job is submitted when all other criteria are satisfied.
■ Pipes – (only when using Mainview Batch Optimizer job pipes) All
PIPE statements of the job are ignored. The job is removed from
the pipe sharing job collection of which it is part, and is
submitted when all other criteria are satisfied.
■ Workload Limits – All workload restrictions, for example, the
maximum number of jobs and maximum number of resources,
are ignored.
■ Scheduling Environment – The SCHENV specification for the job
is ignored. The job will run even if the scheduling environment is
not active.
■ Quiesce Time – The job will run, even if Control-M is in Quiesce
mode, either as a result of the QUIESTIME or QUIESQRES
commands.
■ All IN Criteria – Enters Y in all the fields under IN Criteria in the
BYPASS option window. However, the fields under Additional
Options are not affected.

Additional Options:

■ JCL – The member and library specified in the MEMNAME,

MEMLIB, and OVERLIB statements of the job are ignored. When
all run-time criteria are satisfied, a dummy job is submitted.

Note: When BYPASS JCL is specified, Control-M handles post-

processing of the job as if it were a dummy job and will ignore all
ON PGMSTEP pgmstep DO blocks in the job.

■ Post Processing – All post processing specifications are ignored.

190 Control-M for z/OS User Guide

 Active Environment Screen

Table 58 Options of the Active Environment Screen (part 6 of 6)

Option Description
B (Bypass) Notes:

(continued) ■ Using BYPASS does not require that the job be HELD. It is
therefore possible that by the time Control-M comes to handle
the BYPASS request, the status of the job may no longer be WAIT
SCHEDULE. If this occurs, the monitor ignores the BYPASS
setting, and issues an appropriate message to the IOA log.

■ When any BYPASS option has been set to Y, the status field of
the job in the Active Environment Screen will show that the
BYPASS feature is in use, with the relevant activated field
identified. For example, the status may show BYPASS(Time + IN
+ QUANT), to indicate that the Time Limit, IN Conditions, and
Quantitative Resources fields were set to Y, and that those
criteria are being ignored.

■ If you set any field in the BYPASS window to Y, that setting only
remains valid for the current run of the job. When the job is rerun
or restarted, all BYPASS fields are reset to N.
W Display the MVBO/Job Optimizer screen for the selected job. Valid
(MVBO/ only for jobs under the control of MAINVIEW Batch Optimizer
Job Optimizer) (MVBO). The MVBO/Job Optimizer screen is described in the
MAINVIEW Batch Optimizer/Job Optimizer Reference Manual.
K (Kill) (Only jobs that have Executing status) “Kills” the job, meaning that
the job is cancelled (causing the job to fail with a system abend code
of S222), and the status of the job is changed to ENDED NOTOK. Kill
may not be specified for Started tasks or NJE jobs.
X (Exit) Invoke user exit CTMX008. Placing an X next to a job in screen 3
keeps the details of the current job as input parameters for the exit.

For information about the function of user exit CTMX008, please

consult with your site’s IOA administrator.

Job Statuses
The following job statuses can appear in the Active Environment screen:

Chapter 2 Online Facilities 191

Active Environment Screen

Table 59 Job Statuses for the Active Environment screen (part 1 of 4)

Status Description
ACTIVE The job is a dummy job that has not yet reached the
post-processing phase.
BUT NOT FOUND n TIMES If a job is not found at least once, this status displays
the number of times (n) Control-M has looked for the
job. If the job is still not found after 10 times, the
status is changed to DISAPPEARED.

Example

JOB SUBMITTED BUT NOT FOUND 5 TIMES

The job was submitted, but may have been purged.

After checking 10 times, Control-M changes the
status to DISAPPEARED.
Note: This default number can be changed by your
INCONTROL administrator.
§Restart§ CLEANUP Job is being run for Cleanup.
DELETED The job order was deleted by an authorized user.
DISAPPEARED Job disappeared completely. This status only occurs
after a NOT FOUND status.
ENDED NOT “OK” Job ended NOT OK.
ENDED NOT “OK” – ABENDED Job abended.
ENDED NOT “OK” – DUE TO CC Condition code that is not defined as OK has
occurred.
ENDED NOT “OK” – FAILED – This usually occurs following a system crash.
REASON UNKNOWN
ENDED NOT “OK” – JCL ERROR Job failed due to JCL error.
ENDED NOT “OK” – RERUN Rerun is needed for the job.
NEEDED
ENDED NOT “OK” – RERUN WAS Rerun was required for the previous execution of the
NEEDED job.
ENDED NOT “OK” – TERM ON The job was terminated by Control-M due to a NOT
NCT2 CATLGD 2 error.
ENDED “OK” Job finished executing OK.
ENDED “OK” FORCED OK Job ended OK due to a Force OK request.
EXECUTING Job is executing.
EXECUTING (SYSOUT IN HOLD Job was placed in HOLD status by an operator
STATUS) issued JES HOLD command before Control-M could
read the job’s output.
GOING TO START Started task is eligible to be run and is about to be
activated.

192 Control-M for z/OS User Guide

 Active Environment Screen

Table 59 Job Statuses for the Active Environment screen (part 2 of 4)

Status Description
(TBL HELD) The SMART Table Entity of which the job is part is in
Held status, and as a result, the job itself is being
logically held. (While the job’s SMART Table Entity
is being held, actions that require a Held status, such
as Delete, Zoom, and Save, can be performed against
the job. In addition, the Control-M monitor does not
handle the job. For example, if the job is in WAIT
SCHEDULE status it is not selected for submission.)
HELD Job is in hold status.
LATE Job did not finish executing by the time specified in a
SHOUT WHEN LATE statement.
LATE EXECUTION The elapsed runtime of the job is outside the
acceptable limits defined in a SHOUT WITHIN
EXECTIME statement.
LATE SUBMISSION Job was not submitted by the time specified in a
SHOUT WHEN LATESUB statement.
NJE JOB The job is not currently found in either Remote or
Host node, but is in the process of transmission
between nodes. (Either the job is being transmitted to
the Remote node for execution, or the sysdata output
of the job is being transmitted to the Host node.)
Control-M continues to search for the job until it is
located on one of the nodes.

BMC Software recommends that you do not purge

jobs on the Remote node. However, if you do purge a
job on the Remote node, you must notify Control-M
of the event by changing the value in the NJE field in
the Active Environment Zoom screen (Screen 3.Z) to
' ' (Blank). After a short time, the job status changes
to Disappeared.
NJE JOB (ID CHANGED) The job ID of the NJE job has changed. When the
job’s sysdata output was transmitted back to the
Host NJE node, the Control-M monitor detected that
the original job ID of the NJE job is occupied by
another job. The Control-M monitor continues to
search for a job to match the new job ID.
NOT FOUND Job not found in the queue. Check that the job or its
sysout has not been accidentally deleted. This status
may also appear when JES is very busy. In such a
case, Control-M waits for JES until it confirms that
the job is lost.
NOT STARTED Starting of the started task failed.
NOT SUBMITTED Submission of the job failed.
NOTE A Note has been added to the job, through the Zoom
screen.

Chapter 2 Online Facilities 193

Active Environment Screen

Table 59 Job Statuses for the Active Environment screen (part 3 of 4)

Status Description
ON HST FILE Job is currently in the History file. If the job is
included in the flow of jobs being rerun, it will be
restored to the Active Jobs file before being rerun.
Note: This option appears only in the Rerun Flow
Job List window.
ON OUTPUT QUEUE Job is on the output queue of the remote NJE node or
on the output queue of the host node with a changed
job ID.
PRIOR RUN Termination status of the previous job (or cyclic task)
execution (for jobs that have been rerun).
PROBLEMS READING SYSOUT Usually means that problems prevent the Control-M
monitor from reading the job’s output.
PSEUDO At the time when the job was ordered, Control-M
automatically converted it to a DUMMY job.
RELEASED On Spool job has been released and is waiting to be
executed.
REQUESTED CHANGE Job parameters were changed using the Zoom
option, but the request has not yet been performed
by the Control-M monitor.
REQUESTED FORCE OK A Force OK request was issued for a held job, but the
request has not yet been performed by the Control-M
monitor.
REQUESTED FREE A free request was issued for a held job, but the
request has not yet been performed by the Control-M
monitor.
REQUESTED HELD A hold request was issued for the job, but the request
has not yet been performed by the Control-M
monitor.
REQUESTED REACT An activate request was issued for a job, but the
request has not yet been performed by the Control-M
monitor.
REQUESTED RERUN A rerun request was issued for the job, but the
request has not yet been performed by the Control-M
monitor.
§Restart§ RESTARTED) Job has run (executed) with the restart step under
Control-M/Restart (that is, a restart has been
performed).
RESTORED This job was restored from the History file.
If this status is displayed in the History Environment
screen, the job has been restored, rerun, and then
copied to the History file as part of the New Day or a
User Daily procedure.
RUN n Run number. Incremented each time a cyclic task is
executed or a job is rerun.

194 Control-M for z/OS User Guide

 Active Environment Screen

Table 59 Job Statuses for the Active Environment screen (part 4 of 4)

Status Description
STARTED Started task started, but is not yet in the operating
system’s job queue.
SUBMITTED Job submitted, but is not yet in the operating
system’s job queue.
WAIT CONFIRMATION (FOR Job is waiting for manual confirmation before it can
SCHEDULE) be scheduled.
§Restart§ WAIT CONFIRMATION Job is waiting for manual restart confirmation.
(WITH RESTART)
WAIT EXECUTION Job is in the operating system’s job queue waiting to
be executed.
WAIT RELEASE On Spool job is eligible to be run and is about to be
released.
WAIT SCHEDULE Job is waiting to be scheduled.
WAIT SCHEDULE ON SPOOL Job is waiting to be scheduled but is already in input
queue on spool.
WAIT SCHEDULE (PIPE) For MAINVIEW Batch Optimizer (MVBO) users. Job
is waiting to be scheduled and is a participant in a
Pipe (Collection).
WAIT SUBMISSION Job is eligible to be run and is about to be submitted.
§Restart§ (WITH RESTART) The restart step under Control-M/Restart will be
added to the JCL of the job when the job is submitted
(that is, a restart will be performed).

SMART Table Entity Statuses

The following statuses can appear for the SMART Table Entity in the Active
Environment screen:

Table 60 SMART Table Entity Statuses for the Active Environment Screen
(part 1 of 2)
Status Description
ACTIVE All runtime criteria for the SMART Table Entity have been satisfied,
but at least one job in the SMART Table has not ended and no job in
the SMART Table has ended NOTOK.
ACTIVE - IN ERROR All runtime criteria for the SMART Table Entity have been satisfied,
but at least one job in the SMART Table has not ended and one or
more jobs in the SMART Table ended NOTOK.
ENDED NOTOK All jobs in the SMART Table have ended. At least one job ended
NOTOK.
ENDED OK All jobs in the SMART Table ended OK.

Chapter 2 Online Facilities 195

Active Environment Screen

Table 60 SMART Table Entity Statuses for the Active Environment Screen
(part 2 of 2)
Status Description
(ORDERING) A SMART Table Entity has been ordered to the Active Jobs file, but
not all of its jobs have been placed in the Active Jobs file, or
connected to the SMART Table Entity. The ORDERING status
disappears when all jobs in the SMART Table appear in the Active
Jobs file and are connected to the SMART Table Entity. Status
ORDERING is an add-on to the SMART Table Entity’s regular
status.
REQUESTED DELETE A delete request was issued for the SMART Table Entity, but the
request has not yet been performed.

Filtering the Active Environment Screen Display

Screen filters may be used to filter the Active Environment screen display.

A filter consists of a set of record selection criteria (selection fields and their values).
Only records that conform to selection criteria specified in the filter are displayed on
the screen.

The INCONTROL administrator may predefine filters and place them in the General
profile.

Each user can activate an existing filter in the Active Environment screen by typing
the command SHOW in the COMMAND line of the Active Environment screen.

The filtering feature utilizes two different windows, the Show Screen Filter window
and the Display Filters window:

■ Each user can define and name multiple filters for the screen by using the Show
Screen Filter window, which is described in “Editing Filter Criteria” on page 198.
User-defined filters are stored in the user profile. Filters that are kept in the user
profile can be activated only by the user who defined the filter.

■ Users can display the list of all available filters by opening the Display Filters
window.

A predefined default filter (DEFAULT) is supplied for the Active Environment

screen. Site-defined defaults determine whether the last filter used or the DEFAULT
filter is activated upon reentry to the Active Environment screen.

196 Control-M for z/OS User Guide

 Active Environment Screen

Activating a Known Filter in the Active Environment screen

The SHOW command may be used to activate an existing filter when you know the
filter name. To activate an existing filter in the Active Environment screen, type the
command SHOW in the COMMAND field, as follows:

SHOW name

where name is the name of the filter to be activated.

Displaying the List of Available Filters

If you do not know the name of a filter, you can display the list of available filters in
the Display Filters window. The display includes Global filters that are available to all
users, and user-defined filters that are only available to the individual user.

You can then select a filter from the Display Filters window for activation or editing.

To open the Display Filters window, type the command SHOW ? in the COMMAND
field. The Display Filters window is opened.

NOTE
Filters that are included with Control-M are those appearing in the Display Filters window.
These system-provided filters do not display descriptions.

Figure 42 Display Filters Window

Filter: DEFAULT ------- CONTROL-M Active Environment ------ DOWN <D> - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ----------- Status ------------
CICSPR M96 270601 JOB Held Wait Schedule (Pipe)
CICSPR M96 270601 JOB Held Wait Schedule (Pipe)
BRIVPC M96 270601 JOB Held Wait Schedule (Pipe)
KA +-----------------------------------+ JOB Held Wait Schedule (Pipe)
KA | DISPLAY FILTERS | JOB Held Wait Schedule (Pipe)
DE | CMD ==> SCROLL==> CRSR | TBL Held Active
NO | O NAME DESCRIPTION | JOB Held Ended "OK" Forced OK
DA | CONFIRM WAIT CONFIRM. JOBS | JOB Held Ended-"OK"
DE | DEL ONLY DELETED JOBS | TBL Active
IO | END ALL ENDED JOBS | JOB Held Ended "OK"
IE | ENDNOTOK ENDED NOT-OK JOBS | JOB Held Wait Schedule
DA | ENDOK ENDED OK JOBS | JOB Wait Schedule
DA | EXEC EXECUTING JOBS | JOB Wait Schedule
CT | LATE LATE JOBS | JOB Wait Schedule
CT | WAIT JOBS ON WAIT QUEUE | JOB Wait Schedule
IE | ECSALL ALL JOBS IN AJF | JOB Ended "OK"
NO | =========>>> BOTTOM <<<========== | JOB Wait Schedule
NO | | JOB Wait Schedule
NO | OPTIONS S SELECT E EDIT | JOB Wait Schedule
Comm +-----------------------------------+ resh Auto Jobstat SHPF Note Table
OPt command toggles between Commands and Options display 15.21.28

Chapter 2 Online Facilities 197

Active Environment Screen

The Display Filters window displays the following information:

Table 61 Field of the Display Filters Window

Field Description
NAME Name of the filter as it appears in the General or user profile.
DESCRIPTION Description of the filter.

NOTE
When you create a user-defined filter and provide a description for that filter, the filter, and its
description, are both displayed in the Display Filters window.

To select a filter in the list for activation or editing, type the appropriate option in the
O (Option) field to the left of the filter name, and press Enter.

Table 62 Options of the Display Filters window

Option Description
S (SELECT) Activate the filter. The display of jobs in the Active Environment
screen is filtered according to the filter criteria.
E (EDIT) Display the filter's filtering criteria in the Show Screen Filter
window to enable editing of the filter.

Editing Filter Criteria

The Show Screen Filter window enables you to create or modify a filter.

■ To open an existing filter for editing, either:

— Type SHOW name EDIT in the Active Environment screen, where name is the
name of the filter.
— Type E (Edit) next to the filter name in the Display Filters window and press
Enter.

■ To edit the currently active filter, it is unnecessary to type the name or Edit. Just
type SHOW in the COMMAND field and press Enter, or press PF02/PF14.

■ To create a new filter, open any existing filter and enter a new name and
description in the FILTER and DESC fields, which are described in Table 63 on
page 199.

The Show Screen Filter window is displayed:

198 Control-M for z/OS User Guide

 Active Environment Screen

Figure 43 Show Screen Filter Window

--------------------------- Show Screen Filter -----------------------(3.SHOW)-
Filter Save (Y/N) Desc:
Memname
Table
Sch Lib Tbl
======== In Process Y ======= | Ended Y | ======= State Y ========
---------------------------------------------------------------------------
Wait Sched Y Wait time Y | Ended "OK" Y | Free Y Forced OK Y
Wait Conf Y Wait Cond Y | Not "OK" Y | Held Y Tbl Held Y
Wait SUB Y Wait quant Y | Rerun Y | On Req Y CMEM Forc Y
Submitted Y Wait contrl Y | Disappeared Y | Deleted N Note Y
Wait Exec Y Tbl Active Y | Abended Y | Late N Restarted Y
Executing Y | Unexpected CC Y | Pseudo N
On Out Queue Y | JCL Error Y |
Task Type: Job Cyc Emr Stc Cst Est Ecj Ecs Wrn Tbl
Y Y Y Y Y Y Y Y Y Y
Res Name
Resource Type: In Y Out Y Conds Y Resource Y Control Y
Owner
Odate: From To Priority
Job Appl
CPU Id LPAR RBC
-----------------------------------------------------------------------------
OPt command toggles between Commands and Options display 11.07.49

Fields of the Show Screen Filter Window

The Show Screen Filter window contains the following fields:

Table 63 Fields of the Show Screen Filter Window

Field Description
Filter User-assigned name of the filter.

The name entered in the Filter field may be modified.

If there are unsaved changes to a filter in memory (discussed in

“Closing the Show Screen Filter window” on page 205), an asterisk
appears to the right of the filter name.
Save (Y/N) Specifies whether to save modifications to the filter upon closing the
window.
Desc: User-defined description of the filter. The description entered here
appears next to the name in the Display Filters window.

The fields listed in Table 64 define the selection criteria to be applied to the screen. Fill
in these selection criteria as desired.

Chapter 2 Online Facilities 199

Active Environment Screen

NOTE
The selection criteria shown in Table 64 marked with the symbol P support masking. For more
information, see “Character Masking” on page 87.

For compatibility with versions prior to version 6.2.xx, the SACTMSK profile variable can be
used to specify how to treat character search criteria that do not use masking characters. The
default setting (Y) results in Control-M treating all character search criteria as if a masking
character was entered. For example, if AB was entered as a member name to be searched, by
default this entry is treated as AB*.

Table 64 Show Screen Filter Window Selection Criteria (part 1 of 5)

Criterion Description
MemnameP Show only jobs of the specified member name. A maximum of five
member names may be specified.
TableP Show only jobs of the specified table. A maximum of two tables may be
specified.
Sch LibP Show only jobs of the specified scheduling library
TblP Show only specified tables in the scheduling library. The scheduling
library table name refers to the SCHDTAB field in the 3.Z screen. A
maximum of two tables may be specified.

Note: For each table created in version 7.0 and later, the scheduling
library table name is the same as the SMART Table name. However, in
earlier versions, the scheduling library table name can be different than
the SMART Table name, see “For a SMART Table Entity” on page 538.

200 Control-M for z/OS User Guide

 Active Environment Screen

Table 64 Show Screen Filter Window Selection Criteria (part 2 of 5)

Criterion Description
status Select only jobs that conform to the status selection criteria. Statuses are
divided into three groups under the following headings: In Process,
Ended, and State.

The following logic applies to these headings:

■ Typing Y in the column heading enables further filtering of jobs on a

status-by-status basis. Typing Y in a field in this column enables all
jobs with this status to be shown, while typing N in a field in this
column prevents jobs with this status from being shown.
■ Typing N in the column heading filters out any job with a status
listed under that heading, even if the status is marked Y or S.

The following logic applies to the fields under these headings:

■ N/Y – If all status selection criteria are set to Y, all jobs and tables are
displayed. Specifying a value of N for a specified status selection
causes the tables and jobs for the specified status selection criteria not
to be displayed. For example, if JCL Error is set to N, jobs that ended,
or did not run, because of a JCL error are not displayed.

Note that status selection criteria Y can be used to select jobs and
tables on a very limited basis because of the interaction between
different status selection criteria being set to Y. For example, in
order to select all executing Late jobs, you must specify Executing=Y,
FREE=Y, and Late=Y. However, this will cause all executing jobs to
be displayed–even those that are not late.

■ S – Select jobs to be displayed. Specifying a value of S for a specified

status selection causes the tables and jobs for the specified status
selection criteria to be displayed. Note that specifying a value of N
for a specified status selection causes the tables and jobs for the
specified status selection criteria not to be displayed. For example, to
see only jobs and tables that are LATE and are executing, set LATE to
S, set ENDED OK to N, set NOT OK to N, and set all other status
selection criteria to Y.

Chapter 2 Online Facilities 201

Active Environment Screen

Table 64 Show Screen Filter Window Selection Criteria (part 3 of 5)

Criterion Description
status (continued) In Process – This heading is for the status of jobs that are not yet
finished.
Wait Sched Jobs waiting to be scheduled
Wait Conf Jobs waiting for confirmation
Wait Sub Jobs waiting to be submitted
Submitted Jobs submitted but not yet in queue
Wait Exec Jobs waiting to be executed
Executing Jobs that are currently executing
On Out Queue Jobs on the output queue that have not yet been
processed by Control-M, for example, because of a
system crash
Wait time Jobs that were not submitted because the current
time is outside the time limits specified in the job
scheduling definition
Wait Cond Jobs that are waiting for prerequisite conditions
Wait quant Jobs that are waiting for Quantitative resources
Wait contrl Jobs that are waiting for Control resources
Tbl Active Tables that are active, meaning
■ all run time criteria of the table have been
satisfied
■ at least one job in the table has not yet ended
■ no job in the table has ended NOTOK

Ended – This heading is for the status of finished jobs.

Ended “OK” Jobs that ended OK
Not “OK” Jobs that ended NOTOK
Rerun Jobs that require rerun
Disappeared Jobs that disappeared from the job queue
Abended Jobs that abended
Unexpected CC Jobs that ended with a condition code that is not
defined as OK
JCL Error Jobs that ended (or did not run) because of a JCL
error

202 Control-M for z/OS User Guide

 Active Environment Screen

Table 64 Show Screen Filter Window Selection Criteria (part 4 of 5)

Criterion Description
status (continued) State – This heading is for the state of jobs and tables.
Free Free jobs
Held Held jobs
Deleted Deleted jobs
On Request Jobs for which a change in job status has been
requested by a Control-M user, but the request has
not yet been processed by the monitor
Late Jobs that were submitted, or finished executing, late;
or jobs with an elapsed execution time outside
specified limits
Pseudo Jobs with prerequisite conditions that were adjusted
as part of the “Adjust conditions in a table” feature
Forced OK Jobs that ended OK due to a FORCE OK request
Tbl Held Tables that were held
CMEM Force Jobs that were forced by the CMEM facility
Note Jobs that contain a note that was added using the
Zoom panel
Restarted Jobs that were restarted under Control-M/Restart
Task Type Limit the task types of jobs to be displayed. Valid task types are:
Job Regular job
Cyc Cyclic job
Emr Emergency job
Stc Started task
Cst Cyclic started task
Est Emergency started task
Ecj Emergency cyclic job
Ecs Emergency cyclic started task
Wrn Warnings. Supported for historical reasons
Tbl SMART Table Entity

Chapter 2 Online Facilities 203

Active Environment Screen

Table 64 Show Screen Filter Window Selection Criteria (part 5 of 5)

Criterion Description
Res NameP An additional cross reference for all jobs that are using a Control
resource, Quantitative resource, or prerequisite condition. A maximum
of two names may be specified. The resources and conditions are
searched according to those specified as Y (Yes) in Resource Type
(described immediately below).
Resource Type Type of Resource or prerequisite condition to be used to filter the display
of the Active Environment screen.
In All prerequisite conditions appearing in IN
statements
Out All prerequisite conditions appearing in OUT
statements
Conds All prerequisite conditions appearing in DO COND
statements
Resource All Quantitative resources
Control All Control resources
OwnerP Show only jobs of the identified owner. A maximum of five owners may
be identified.
Odate Show only jobs whose original scheduling date falls within the range
specified in the From and To fields.
Date format is mmddyy, ddmmyy, or yymmdd, depending on the site
standard.
If a From date is specified without a To date, the current date is used as
the To date.
Priority Show only jobs with the specified priority.
PipeP Show only job participants in the specified pipe.
JobP Show only jobs with the specified job name
P
Appl Show only jobs with job scheduling definitions that contain the specified
value of APPL
CPU IdP Show only jobs that ran under the specified CPU
LPARP Show only jobs that are running or ran in the specified logical partition
RBC Shows rule-based calendars.

Characteristics of the Show Screen filter

The following rules govern the operation of the Show Screen Filter window:

■ The Control-M monitor updates the status of jobs and tables displayed in the
Active Jobs file (AJF). Therefore, if the Control-M monitor is down, the status
displayed in the AJF may not be up-to-date.

204 Control-M for z/OS User Guide

 Active Environment Screen

For example, if a job was waiting for a prerequisite input condition when the
Control-M monitor went down, the job will continue to be shown as waiting for
the condition, even if the condition is present, until the Control-M monitor updates
the AJF.

■ If you set Wait Sched to Y, the values set for Wait time, Wait Cond, Wait quant, and
Wait contrl are ignored. Control-M only looks at the values set for these fields if
Wait Sched is set to N.

■ Executing is only used for jobs (and not for tables).

■ Tbl Activeis only used for tables (and not for jobs).

■ If a job is part of a table, and the table is waiting for some criteria such as a time
requirement, a prerequisite condition, and so on, the job has the same status as the
table.

For example, if the table is waiting for a prerequisite condition, and the filter
criteria is Wait Cond, the job will be displayed as waiting for the condition even if
the condition is not required by the job scheduling definition of the job itself.

■ If the job scheduling definition of a job requires it to wait for more than one input
criteria, these criteria are not all checked at once. They are checked in the following
sequence:

— Wait time
— Wait Cond
— Wait quant
— Wait contrl

For example, if the job is so defined that it must wait for a specific time and for a
prerequisite condition, the job will be displayed in the list of jobs waiting for time,
but will not be displayed in the list of jobs waiting for prerequisite conditions.
However, when the time requirement is satisfied, if the prerequisite condition is
not available, the job will be displayed in the list of jobs waiting for prerequisite
conditions.

Closing the Show Screen Filter window

The filter you have edited can be activated with or without saving changes,
depending on the value entered in the Save field, as follows:

■ To activate and save the filter, type Y (Yes) in the Save field. Changes to the filter
are permanently saved.

■ To activate the filter without saving it, type N (No) in the Save field. Changes are
kept in memory only, but not saved.

Chapter 2 Online Facilities 205

Global View Screen

After typing a value in the Save field, press one of the following keys:

Table 65 Show Screen Filter Window - Closing Values

PFKey Description
Enter Filtering begins with the first job currently displayed in the screen
and continues downward.
PF07/PF19 (UP) Filtering begins with the first job in the Active Job list and continues
downward.
PF08/PF20 (DOWN) Filtering begins with the last job in the Active Job list and continues
upward.

The window is closed and the filter is activated as defined or modified.

To cancel changes made in the Show Screen Filter window, use the RESET command
(PF04/PF16). The changes are canceled regardless of the value entered in the Save field.
The window is closed, and the filter that was previously in effect is restored.

By default, using the END command (PF03/PF15) in the window works like pressing
Enter. However, the default may be modified so that END works like RESET.

Global View Screen

The Global View screen is displayed by typing the command VIEW (abbreviated V)
in the COMMAND field of the Active Environment screen and pressing Enter, or by
pressing PF10/PF22 in the Active Environment screen.

This screen provides a statistical overview of the status of the jobs running under
Control-M. Information is presented by TABLE name, by date (that is, separate
statistics for the same table name on different dates).

NOTE
All jobs having the same table name are grouped together, including jobs from different tables
of different types.

206 Control-M for z/OS User Guide

 Global View Screen

Figure 44 Global View Screen

-------------------------- GLOBAL VIEW - BY TABLE --------------------(3.VIEW)
COMMAND ===> SCROLL===> CRSR
TOTAL WAIT SCHEDULE 647 EXECUTING 19 END NOTOK 9 END OK 2014
STAT TABLE-------------- ODATE #WSC #EXC #END MEMNAME -----JOB STATUS------
WS CTM-CONTROL 060601 1 4 CTMCLRES WAIT SCHEDULE
ER PROD-ONSPOOL 060601 43 P0* ENDED NOTOK S0C4
* EN DD-DAY-PROD 060601 42
WS BR-IVP-CC 060601 8 28 BRIVPCCE WAIT SCHEDULE
WS SYSTEMS-JOBS 060601 4 22 SMFCLEAN WAIT SCHEDULE
WS PROD-KPL 060601 47 PRDKPL01 WAIT SCHEDULE
ER MT-PRODUCTION 060601 10 24 MTPRQV ENDED NOTOK S0C1
MTRRU04 ENDED NOTOK U0016
ER APPL-PROD-INTERNAL 060601 9 2 2 INTPRD02 ENDED NOTOK C0008
INTPRD01 EXECUTING
INTPRD1A WAIT EXECUTION
RN PR-PRODUCTION 060601 10 6 24 PRDINP6A EXECUTING
PRDRPT99 EXECUTING
PRDDFN EXECUTING
PRDRPT10 EXECUTING
PRDUPD12 EXECUTING
PRDUPD14 WAIT EXECUTION
RN VIJ-JOBS 060601 4 42 VIJJBNX ENDED NOTOK NOMEM
VIJRUN22 ENDED NOTOK JNRUN
COMMANDS: REFRESH (VIEW DATA) END (RETURN TO ACTIVE SCREEN) 15.35.49

AutoRefresh mode is available under this screen.

To update the screen, press the REFRESH key (PF10/PF22).

To return to the Active Environment screen, press the END key (PF03/PF15).

Fields of the Global View Screen

Table 66 Fields of the Global View Screen (part 1 of 2)

Field Description
TOTAL Displays the totals from the data. The following summary
information is displayed for all jobs in the Active Jobs file except
emergency jobs:

■ WAIT SCHEDULE – Total number of jobs waiting to be

scheduled
■ EXECUTING – Total number of jobs executing
■ END NOTOKG – Total number of jobs currently in ended
NOTOK status
■ END OK – Total number of jobs that ended OK
Data lines Display the following information about each table:

Chapter 2 Online Facilities 207

View Graph Screen

Table 66 Fields of the Global View Screen (part 2 of 2)

Field Description
STAT Status of the table:

■ WS – Wait Scheduling. All jobs are waiting to be scheduled (no

jobs have begun running).
■ ER – Error. At least one job has finished running and had an
error.
■ RN – Running. At least one job is running (executing) or has
ended; not all jobs have finished executing; and no jobs have
ended NOTOK.
■ * EN – Ended OK. All jobs have finished running and ended OK.
TABLE Name of the table.
ODATE Original scheduling date of the table, discussed in “ODATE” on
page 158.
# WSC Number of jobs in Wait Schedule state.
# EXC Number of jobs executing (or in the input queue).
# END Number of jobs that have finished executing.
MEMNAME Name of each active member (job) in the table. The members that are
displayed are those

■ executing (or in the input queue)

■ ended NOTOK

If none of the above is found within the table, the first job that is
waiting to be scheduled is displayed.
JOB STATUS Status of each job in the table. In case of error, the type of error is
shown (for example, abend code).

View Graph Screen

The View Graph screen is displayed by typing the VIEW GRAPH command
(abbreviated V G) in the COMMAND field of the Active Environment screen and
pressing Enter.

This screen provides a statistical overview of the status of the jobs running under
Control-M, in graph form. Information is presented by TABLE name.

NOTE
All jobs having the same table name are grouped together, including jobs from different tables
of different types.

AutoRefresh mode is available under this screen.

208 Control-M for z/OS User Guide

 View Graph Screen

To update the screen, type the command REFRESH and press Enter, or press
PF04/PF16.

To return to the Active Environment screen, press the END key (PF03/PF15).

Two formats for the View Graph screen are available, one for color displays and one
for non-color displays. They are discussed on the following pages.

View Graph Screen Format for Color Terminals

Figure 45 View Graph Screen Format for Color Terminals
--------------------------- VIEW GRAPH - BY TABLE --------------------(3.GRAPH)
COMMAND ===> SCROLL===> CRSR
TOTAL WAIT SCHEDULE 674 EXECUTING 28 END NOTOK 11 END OK 1549
TABLE NAME -------------SUM %---+---20----+---40----+---60----+---80----+--100%
EBD-PRODUCTION 27 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
GPL-PRODUCTION 35 G100GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
MT-PRODUCTION 40 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
VEJ-JOBS 39 G100GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
PROD-KPL 16 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
INTER-PRODUCTION 42 RR50RRRRRRRRRRRRRRRRRRRRRGG50GGGGGGGGGGGGGGGGGGGGG
NTN-APPLICATION 35 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
APPL-PROD-INTERNAL 37 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
CLIENTS-STATEMENTS 38 R100RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
PR-PRODUCTION 40 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BR-IVP-CC 10 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
SYSTEMS-JOBS 36 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
CICS-BATCH-JOBS 28 G100GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
DD-NIGHT-PROD 37 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BKP-PROD-L 10 BB20BBBBBBYY20YYYYYYRR40RRRRRRRRRRRRRRRRGG20GGGGGG
BKP-PROD-ACCOUNT 9 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BKP-PROD-DD 14 R100RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
FDS-JOBS 39 R100RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
JJL-NIGHT-PROD 33 B100BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
COMMANDS: REFRESH (VIEW DATA) END (RETURN TO ACTIVE SCREEN) 01.26.56

Fields of the View Graph Screen

Table 67 Fields of the View Graph Screen (part 1 of 2)

Field Description
TOTAL Displays the totals from the data. The following summary
information is displayed for all jobs in the Active Jobs file except
emergency jobs:

■ WAIT SCHEDULE – Total number of jobs waiting to be

scheduled
■ EXECUTING – Total number of jobs executing
■ END NOTOKG – Total number of jobs currently in ended
NOTOK status
■ END OK – Total number of jobs that ended OK
The data lines display the following information for each table:

Chapter 2 Online Facilities 209

View Graph Screen

Table 67 Fields of the View Graph Screen (part 2 of 2)

Field Description
TABLE NAME Name of the table.
SUM Total number of jobs in the table.
JOB GRAPH Job graph indicates the number of jobs in each status, in each table.
Scale Scale line used to simplify reading the percentage of jobs of each
status in the table. The scale used (that is, the number of jobs
represented by each column) automatically adjusts based on the
number of jobs in the table containing the most jobs.

Job Graph
In the job graph (D), job statuses are differentiated by color, as follows:

NOTE
Because this guide is printed in black and white, the different colors in the screen are
represented by different shadings in this guide.

Table 68 Job Status Color

Color Description
Blue WAIT SCHEDULE
Yellow EXECUTING
Red END NOTOK
Green END OK

For each table in the graph, the number of columns of a particular color depends on
the number of jobs having that status.

210 Control-M for z/OS User Guide

 View Graph Screen

View Graph Screen Format for Non-Color Terminals

Figure 46 View Graph Screen Format for Non-Color Terminals
--------------------------- VIEW GRAPH - BY TABLE --------------------(3.GRAPH)
COMMAND ===> SCROLL===> CRSR
TOTAL WAIT SCHEDULE 674 EXECUTING 28 END NOTOK 11 END OK 1549
TABLE NAME -------------SUM ----+---20----+---40----+---60----+---80----+--100%
EBD-PRODUCTION 27 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
GPL-PRODUCTION 35 %100%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
MT-PRODUCTION 40 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
VEJ-JOBS 39 %100%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
PROD-KPL 16 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
INTER-PRODUCTION 42 **50*********************%%50%%%%%%%%%%%%%%%%%%%%%
NTN-APPLICATION 35 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
APPL-PROD-INTERNAL 37 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
CLIENTS-STATEMENTS 38 *100**********************************************
PR-PRODUCTION 40 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
BR-IVP-CC 10 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
SYSTEMS-JOBS 36 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
CICS-BATCH-JOBS 28 %100%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
DD-NIGHT-PROD 37 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
BKP-PROD-L 10 $$20$$$$$$++20++++++**40****************%%20%%%%%%
BKP-PROD-ACCOUNT 9 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
BKP-PROD-DD 14 *100**********************************************
FDS-JOBS 39 *100**********************************************
JJL-NIGHT-PROD 33 $100$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
COMMANDS: REFRESH (VIEW DATA) END (RETURN TO ACTIVE SCREEN) 01.26.56

Fields of the View Graph Screen

Table 69 Fields of the View Graph Screen

Field Description
TOTAL Displays the totals from the data. The following summary
information is displayed for all jobs in the Active Jobs file except
emergency jobs:

■ WAIT SCHEDULE – Total number of jobs waiting to be

scheduled.
■ EXECUTING – Total number of jobs executing.
■ END NOTOKG – Total number of jobs currently in ended
NOTOK status.
■ END OK – Total number of jobs that ended OK.
TABLE NAME Name of the table.
SUM Total number of jobs in the table.
JOB GRAPH Job graph indicates the number of jobs in each status, in each table.
Scale Scale line used to simplify reading the percentage of jobs of each
status in the table. The scale used (that is, the number of jobs
represented by each column) automatically adjusts based on the
number of jobs in the table containing the most jobs.

The data lines display the following information about each table:

Chapter 2 Online Facilities 211

Why screen

Job Graph

In the job graph, job statuses are differentiated by symbols, as follows:

Table 70 Job Graph Status Symbols

Symbol Description
$ WAIT SCHEDULE
+ EXECUTING
* END NOTOK
% END OK

For each table in the graph, the number of columns containing a particular symbol
depends on the number of jobs having that status.

Why screen
The Why screen (Screen 3.?) is displayed when the ? (Why) option is entered on the
Active Environment screen. The Why screen shows the reasons why a job is in WAIT
SCHEDULE status.

Figure 47 Active Environment Why Screen

------------------------ PRUPDT02 SCHEDULING ANALYSIS --------------------(3.?)
COMMAND ===> SCROLL===> CRSR
OPT DESCRIPTION

TIME LIMIT FROM 1730 UNTIL 0200

RESOURCE DB2-POWER QUANTITY 0030
HELD BY PRDKPL01 (U) QUANTITY 0022
HELD BY GPLIR17A (U) QUANTITY 0020
HELD BY INTR0002 (U) QUANTITY 0015
HELD BY PRUPDOLV (U) QUANTITY 0010
HELD BY MTPRQV (U) QUANTITY 0025
RESOURCE CARTRIDGE QUANTITY 0002
HELD BY PRDKPL01 (U) QUANTITY 0001
HELD BY GPLIR17A (U) QUANTITY 0002
IN HOLD STATE
CONDITION PRUPDT01-ENDED-OK ODATE 0606
NOT-COND PRPLD03-ENDED-NOTOK ODATE 0606
SCHEDULING ANALYSIS FOR SMART TABLE ACCOUNT (ACCOUNT-GROUP)
SMART TABLE’S RUNTIME CRITERIA SATISFIED
====== >>>>>>>>>>>>>>>>>>>>> END OF "WHY" LIST <<<<<<<<<<<<<<<<<<<<< =====

OPTION: A ADD CONDITION D DELETE NOT-COND 10.32.27

To return to the Active Environment screen, press the END key (PF03/PF15).

212 Control-M for z/OS User Guide

 Why screen

Possible WHY reasons are:

■ ALL RUNTIME CRITERIA SATISFIED. JOB WILL BE SUBMITTED SOON

■ CONTROL-M MONITOR IS NOT ACTIVE
■ IN HOLD STATE
■ WAIT CONFIRMATION
■ TIME LIMIT FROM hhmm UNTIL hhmm
■ NEXT RUN FROM mmddyy hhmm
■ CONDITION condition-name ODATE mmdd

Prerequisite condition required by the job, along with its original scheduling date.

■ RESOURCE resource-name [R] QUANTITY quantity BY priority memname

Name and quantity of a Quantitative resource not currently available for the job.
For critical path jobs, a job with a higher path priority than the current job is also
identified.

■ CONTROL OVER resource TYPE type BY priority memname [ownership type]

Name and type of a Control resource currently being used by another job order,
which is identified by name. For critical path jobs, path priority of the owner is also
identified.

■ CONTROL OVER resource TYPE type HELD BY priority ******** [ownership type]
IOAID ioaid

Name and type of a Control resource currently being used by another job order in
a different instance of the Control-M monitor. The IOAID of the monitor holding
this resource is also shown.

■ JOB WAIT FOR PIPES COLLECTION

PIPE pipename

The job was not run for one of the following reasons:

— Control-M is waiting for the minimum number of participants in the indicated

pipe.

— At least one prerequisite (prerequisite condition, resource, confirmation, and so

on) for a participant in the indicated pipe is not satisfied.

If the job belongs to a SMART Table, the Why screen displays messages related to
both the selected job and the table to which the job belongs. In this case, the reasons
indicated above may be applicable to the selected job and/or to the table.

Chapter 2 Online Facilities 213

Why screen

To enable you to distinguish between “job” reasons and “table” reasons, the job
reasons appear in the screen before the table reasons, and the two sets of reasons are
separated by the following line:

TABLE SCHEDULING ANALYSIS FOR TABLE table-memname (tablename)

In addition to the above line, the following reasons can appear only for a job in a
SMART Table:

■ JOB’S RUNTIME CRITERIA SATISFIED

This reason applies to the job.

■ TABLE’S RUNTIME CRITERIA SATISFIED

This reason applies to the table.

■ WAIT WORKLOAD

The job was not run for one of the following reasons:

— WORKLOAD <workload_name> - REACHED MAX JOBS POLICY LIMIT OF

xxxx

— nnnn RESOURCES <resource_name> NOT AVAILABLE FOR WORKLOAD

<workload_name> DUE TO MAX OF mmmm

Where:

xxxx - maximum number of parallel executing jobs for WORKLOAD

nnnn - required number of resources for this job

mmmm - maximum number of resources defined for WORKLOAD

Condition display modes in the Why screen

If a job is waiting for prerequisite conditions, the conditions can be displayed in the
Why screen in two different modes:

■ In the Missing Conditions display mode, only the conditions which the job is
actually waiting for are displayed. Logical operators and parentheses are not
displayed.

■ In the All Conditions display mode, all the prerequisite conditions defined for the
job are displayed, along with all the relevant logical operators and parentheses.

214 Control-M for z/OS User Guide

 Why screen

Conditions for which the job is not waiting because they already exist are displayed
with the string 'SATISFIED' following their original scheduling date. Conditions for
which the job is not waiting, even though they do not exist, are displayed with the
string 'REDUNDANT' following their original scheduling date. To switch between
the display modes, use the CNDSHOW command. Typing CNDSHOW MISSING
switches to the Missing Conditions display mode, and typing CNDSHOW ALL
switches to the All Conditions display mode.

The condition display mode upon entry to the screen is determined by the value of
the SWHYCND variable in the user's profile: If the value of SWHYCND is M, then the
Missing Conditions display mode is used (this is also the default, if the SWHYCND
variable is not found the user's profile). If the value of SWHYCND is A, then the All
Conditions display mode is used.

Adding conditions in the Why screen

If the Why screen indicates that a job is waiting for prerequisite conditions, the
indicated conditions can be manually added using the Why screen by typing A (Add
Condition) in the OPT (Option) field next to the condition.

Specify option A for every condition to be added, and press Enter.

When adding conditions, a confirmation window may be displayed depending on

user profile customization. The confirmation window is described in “The Why
Screen Add Condition or Delete NOT-COND Confirmation Window” on page 216.

Deleting negative conditions in the Why screen

A negative or inverted condition is a condition that prevents a job from running.

Negative conditions can be seen in the Why screen. They can be identified by the
description NOT-COND.

If the Why screen indicates that a job is waiting for a NOT-COND (negative
condition) that is preventing the job from running, the NOT-COND can be deleted
manually. This enables the job to run despite the fact that the NOT-COND is true.

To delete a NOT-COND manually, type D (Delete NOT-COND) in the OPT (Option)

field next to the condition.

Type D for every NOT-COND to be deleted, and press Enter.

When deleting NOT-COND conditions, a confirmation window may be displayed

depending on user profile customization. The confirmation window is described in
the following paragraphs.

Chapter 2 Online Facilities 215

Why screen

The Why Screen Add Condition or Delete NOT-COND

Confirmation Window
When adding conditions or deleting NOT-COND conditions, a confirmation window
may be displayed depending on user profile customization:

■ By default, when A or D is entered in the Why screen, a confirmation window is

displayed only when the date reference of the condition is **** or $$$$. Addition or
deletion of conditions without generic date references is performed without
confirmation from the user.

■ If, however, the user profile has been customized accordingly, the following
confirmation window is always displayed when either A or D is entered.

Figure 48 Why Screen Add Condition or Delete NOT-COND Confirmation Window

------------------------ WRUPDT02 SCHEDULING ANALYSIS --------------------(3.?)
COMMAND ===> SCROLL===> CRSR
OPT DESCRIPTION +-------------------------+
| CONFIRM MMDD 0606 |
A CONDITION PROD-WRUPDT03-GO <--------| ASK FOR EACH ONE Y |
A CONDITION PROD-WRUPDT03-CHECK +-------------------------+
D NOT-COND PRPLDT03-ENDED-NOTOK ODATE 0606
====== >>>>>>>>>>>>>>>>>>> END OF "WHY" LIST <<<<<<<<<<<<<<<< ======

OPTION: A ADD CONDITION D DELETE NOT-COND 18.15.36

Fill in or modify the fields of the confirmation window as follows and press Enter.

216 Control-M for z/OS User Guide

 Deleting a Job

Table 71 Fields of the Add Condition or Delete NOT-COND Confirmation Window

Field Description
CONFIRM Confirms whether to process the Add Condition or Delete
NOT-COND request. Valid values are:

■ Y (Yes) – Process the Add Condition or Delete NOT-COND

request.

■ N (No) – Cancel the request.

date Date of the listed condition.

■ If the date reference of the listed condition contains **** or $$$$,

the date field of the window is unprotected and you must
explicitly enter the date in the date field.

■ If the date reference of the listed condition is a specific date (in

either mmdd or ddmm format, depending on the standard in use
at the site), the date field of the window is protected and its value
cannot be changed.
ASK FOR EACH This line is displayed only if more than one Add Condition or Delete
ONE NOT-COND is requested. It determines whether individual
confirmation is required for each Add Condition or Delete
NOT-COND request. Valid values are:

■ Y (Yes) – Individual confirmation is required for each Add

Condition or Delete NOT-COND request. The specified
CONFIRM value (Y or N) applies only to the current Add
Condition or Delete NOT-COND request.

■ N (No) – Individual confirmation is not required for each Add

Condition or Delete NOT-COND request. The specified
CONFIRM operation is applied to all Add Condition and Delete
NOT-COND requests. (If CONFIRM is Y, all Add Condition and
Delete NOT-COND requests are processed; if CONFIRM is N, no
Add Condition or Delete NOT-COND requests are processed.)

Deleting a Job
Control-M only allows deletion of WAIT SCHEDULE jobs, or jobs that have finished
executing. To be deleted, a job must be in HELD status. The deletion request is
recorded in the IOA Log file. The job is logically deleted, that is, flagged as deleted,
from the Active Jobs file immediately. It is physically deleted from the disk the next
time cleanup (for example, New Day processing) is performed.

Chapter 2 Online Facilities 217

Deleting a Job

NOTE
Logically deleted jobs can be undeleted by option U (Undelete). When jobs are undeleted they
are added back to the Active Jobs file with the same status they had prior to deletion.

To delete a job, type D (Delete) in the Option field to the left of the job and press
Enter.

Deleting Critical Path Jobs

Critical path jobs (even in HELD status) that hold a Control or Quantitative resource
can only be deleted through the following steps:

1 Remove the critical path priority of the job using the Zoom screen (Screen 3.Z).

2 Free the job.

3 When the job reverts to WAIT SCHEDULE status, hold the job.

4 Delete the job.

Deleting SMART Table Entities

When a SMART Table Entity is deleted, all the jobs belonging to the SMART Table are
deleted. When a SMART Table is deleted, and a job within the SMART Table is
undeleted, the SMART Table Entity itself is undeleted together with the job. To delete
a SMART Table, its SMART Table Entity must first be in WAIT or END status. Place
the SMART Table Entity in HELD status. After a SMART Table Entity is in HELD
status, you can delete the SMART Table.

If all the jobs within a SMART Table are deleted, you can delete the SMART Table
Entity itself through the following steps:

1 Put the SMART Table on hold. If it is already held, free it, then put it on hold again.

2 Delete the SMART Table Entity.

The reason for freeing a held table and then putting it on hold again before
attempting to delete it is that, for efficiency, when a table is held, Control-M does not
check the status of the jobs in it.

218 Control-M for z/OS User Guide

 Log Screen

Delete Confirmation Window

When requesting job deletions, a Delete Confirmation window may be displayed,
depending on user profile customization:

■ By default, when option D is entered in the Active Environment screen, deletion

requests are performed without confirmation from the user.

■ If, however, the user profile has been customized accordingly, the following Delete
Confirmation window is displayed, in sequence, for each deletion request.

Figure 49 Active Environment Screen Delete Confirmation Window

Filter: ------- CONTROL-M Active Environment ------ UP <D> - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ----------- Status ------------
PRD1 PROD 060601 JOB Wait Schedule (Pipe)
IEFBR14T TEST 060601 M70TEST0/24897 JOB Ended "OK"
PRD1 PROD 060601 JOB Wait Schedule (Pipe)
IEFBR14T +------------------------+ Ended "OK"
D SELITBL <--------| Delete (Y/N) | Ended- Not "OK"
TBLJOB1 +------------------------+ Ended "OK"
TBLJOB2 TEST 060601 M70TEST2/24929 JOB Ended "OK"
TBLJOB3 TEST 060601 M70TEST3/24930 JOB Ended- Not "OK" - Abended
========= >>>>>>>>>>>>> Bottom of Jobs List <<<<<<<<<<<<< ========

Opt: ? Why L Log H Hold Z Zoom R Rerun A Activate O Force OK V View Sysout
N Net D Del F Free S Stat T Table U Undelete J JCL Edit C Confirm 16.28.18

Fill in the window as follows and press Enter.

To confirm the delete request, type Y (Yes) in the window.

To cancel the delete request, type N (No) in the window.

Log Screen
To display the Log screen, type option L (Log) in the Active Environment screen. The
Log screen displays all Log messages of the specified job.

Chapter 2 Online Facilities 219

Zoom Screen

Figure 50 Active Messages Log Screen

FILTER: -- LOG MESSAGES FOR JOB(S) INTR0004 -----------------(3.LOG)
COMMAND ===> SCROLL===> CRSR
SHOW LIMIT ON ==> DATE 060601 - 060601
DATE TIME ODATE USERID CODE ------ M E S S A G E --------------------
060601 131143 060601 M22 JOB511I JOB INTR0004 ODATE 060601 ID=00019 PLACED
ON ACTIVE JOBS FILE -
060601 131148 060601 M22 SEL203I JOB INTR0004 ELIGIBLE FOR RUN
060601 131150 060601 M22 SUB133I JOB INTR0004 SUBMITTED
060601 131651 060601 M22 SPY281I JOB INTR0004 INTR0004/04371 START
98253.1316 STOP 98253.1316 CPU 0MIN
00.04SEC SRB 0MIN 00.00SEC 0.19 9QFDSF
060601 131651 060601 M22 SPY254I JOB INTR0004 INTR0004/04371 SCANNED
060601 131652 060601 M22 SEL206W JOB INTR0004 INTR0004/04371 ABENDED CC
SB37 STEP STEP01
060601 131652 060601 M22 SEL219I JOB INTR0004 INTR0004/04371 ENDED "NOT
OK"
060601 132814 060601 M22 CTM659I RERUN OF TASK INTR0004 ODATE 060601
PERFORMED
060601 132817 060601 M22 SEL220I JOB INTR0004 WILL BE RERUN
060601 132818 060601 M22 SEL203I JOB INTR0004 ELIGIBLE FOR RUN
060601 132818 060601 M22 SUB133I JOB INTR0004 SUBMITTED
======== >>>>>>>>>>>>>>>> NO MORE LOG MESSAGES <<<<<<<<<<<<<<<<< ========

CMDS: SHOW, TABLE, CATEGORY, SHPF 13.24.01

Usage of the Log screen is explained in detail in “IOA Log Screen” on page 303.
However, if you entered the Log screen by option L on the Active Environment
screen instead of by option 5 on the IOA Primary Option menu, note the following
differences in usage:

■ The SHOW command cannot be used with any parameters or qualifiers.

■ Only filter options related to Control-M (and CMEM) are displayed in the Show
Screen Filter window.

■ Only the default job filter can be displayed.

If you enter L (Log) in the O (Option) column for multiple jobs in the Active
Environment screen, the log displays are stacked. Each time the END key (PF03/PF15)
is pressed, the next log in the stack is displayed, until all logs have been displayed.

To return to the Active Environment screen, press END (PF03/PF15).

Zoom Screen
The Zoom screen “zooms in” on the details of a specific job order. To display the
Zoom screen, type Z (Zoom) on the Active Environment screen.

220 Control-M for z/OS User Guide

 Zoom Screen

NOTE
To save changes made in the Zoom screen, the job must be placed in HELD state before
entering the Zoom screen.

Figure 51 Control-M Zoom Screen

------------------------- CONTROL-M ZOOM SCREEN --------------------------(3.Z)
COMMAND ===> SCROLL===> CRSR
+------------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 DFLT N
SCHDTAB MIKLE SCHDLIB CTMP.V524.SCHEDULE
APPL PROD TBL KPL RBC
OVERLIB STAT CAL PERIOD
SCHENV SYSTEM ID NJE NODE
JOBNAME JOBID ODATE 060601 ORDERID 0005C MAXWAIT 04
RESTART DECISION-FROM . TO . CONFIRM N
DESC DAILY PRODUCTION - START OF PRODUCTION TABLE KPL
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
=============================================================================
NOTE
=============================================================================
DOC
=============================================================================
IN DAILY-PROD-KPL-GO 0606
CONTROL DB2-MAIN-FILE E
RESOURCE INIT 0001 CART 0001
PIPE CTM.PROD.PIPE
FROM TIME + DAYS UNTIL TIME + DAYS PRTY CONFIRM
DUE IN + DAYS ELAPSE DUE OUT + DAYS
TIME ZONE: WAIT FOR ODATE:
CPU-ID NODE NAME NJE SEARCH COUNTER LPAR OS35
=============================================================================
OUT PROD-PRDKPL01-OK 0606 +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP
SYSOUT OP C (C,D,F,N,R) 2 FROM
MAXRERUN MEMBER INTRVL FROM END NXT RUN
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST PROCST CODES A/O *
DO
SHOUT WHEN NOTOK TIME + DAYS TO OPER2 URGN R
MS DAILY PRODUCTION JOB PRDKPL01 ENDED NOT OK. NOTIFY PRODUCTION MANAGER
SHOUT WHEN TIME + DAYS TO URGN
MS
=============================================================================
APPL TYPE APPL VER
APPL FORM CM VER
INLINE JCL: N

====== >>>>>>>>>>>>>>>>>>> END OF JOB PARAMETERS <<<<<<<<<<<<<<<<<<<<<<< ======

COMMANDS: CANCEL DOC NOTE 18.33.28

Chapter 2 Online Facilities 221

Zoom Screen

NOTE
The Zoom screen is displayed in Browse mode if the requested job order is already being
zoomed by another user. In this case, updates are not permitted.

The Zoom screen is similar to the Job Scheduling Definition screen used for defining
job production parameters, but it is different in several respects:

■ The Zoom screen contains fields that do not appear in the Job Scheduling
Definition screen (and vice versa).

■ Some fields on the Zoom screen cannot be modified at all. Other fields can or
cannot be modified depending on the status of the job.

■ Changes to a field in the Zoom screen affect only the current job order, not the job
scheduling definition.

For information about most fields in the Zoom screen, see “Job Scheduling Definition
Screen – Defining Schedules” on page 131.

Fields of the Zoom screen that are not in the Job Scheduling Definition screen are
described below:

Table 72 Fields of the Job Scheduling Definition Zoom Screen (part 1 of 4)

Field Description
SCHDTAB Name of the table from which the job was ordered (table that
handles jobs individually).
SCHDLIB Name of the scheduling library from which the job was ordered.
ORIGLIB The original value of the MEMLIB parameter before Control-M
changed it to DUMMY.

This line appears only in PSEUDO jobs, meaning jobs in a table that
were automatically changed by Control-M into DUMMY jobs when
they were ordered.

For more information on PSEUDO jobs, see “ADJUST

CONDITIONS: General Job Parameter” on page 395.
STAT CAL PERIOD 1-character field that identifies the actual days within the Control-M
periodic calendar that were used in calculating statistics relating to
the job.
JOBNAME Name of the job (available only after job submission).
JOBID Job number (available only after job submission).
ODATE Original scheduling date assigned to the job.
ORDERID Unique job order ID in Control-M.

222 Control-M for z/OS User Guide

 Zoom Screen

Table 72 Fields of the Job Scheduling Definition Zoom Screen (part 2 of 4)

Field Description
§Restart§ RESTART This has the following subparameters:
DECISION
■ FROM – Program step (and, optionally, procedure step) names
at which to begin processing the job restart.

■ TO – Program step (and, optionally, procedure step) names at

which the restarted job terminates processing. This parameter is
optional. If the FROM parameter is specified and the TO
parameter is not specified, the job is rerun until the last step.

■ CONFIRM – Valid values are:

— Y (Yes) – If the job is to be resubmitted as a result of a DO

RERUN statement, manual confirmation is required (using
the Active Environment screen).
— N (No) – If the job is resubmitted as a result of a DO RERUN
statement, manual confirmation is not required.
NOTE Text of a note has been added to the job order. For more information,
see “Adding or Editing a Job Order Note” on page 227.
IN For users who have MVBO (Mainview Batch Optimizer) installed.

If an IN condition name is preceded by the non-modifiable string

IGN, that IN condition will be ignored when evaluating the job's run
time criteria. The condition is ignored to enable an entire collection
of PIPE-sharing jobs to run simultaneously.
DUE IN + DAYS For complete details, see “DUE OUT: Runtime Scheduling
Parameter” on page 499.
ELAPSE Anticipated elapse time (that is, anticipated job execution time). The
value used is the average of the run times of the job in the Control-M
Statistics file.
WAIT FOR ODATE Whether a job can be executed even though ODATE is a future date.
Valid values are:

■ Y – The job cannot be executed until ODATE arrives.

■ N – The job can be executed even if ODATE has not yet arrived.

When the Job Scheduling Definition Zoom screen is displayed, the

value that appears in this field varies as follows:

■ When the CTMJOB utility was used to order the job, if the
ODATEOPT parameter was set to RUN, the value is Y.
■ If the job was pre-ordered using the Time Zone feature in the
New Day procedure, and the ODATEOPT parameter was
automatically set to RUN, the value is Y.
■ If the job was ordered or forced from the Job List Screen, and the
WAIT FOR ODATE field in the Job List Exit Option window
was set to Y, the value that appears in the Zoom screen is also Y.

You can change the value that appears in this field.

Chapter 2 Online Facilities 223

Zoom Screen

Table 72 Fields of the Job Scheduling Definition Zoom Screen (part 3 of 4)

Field Description
CPU-ID CPUID on which the job executes (if $ Quantitative resources were
specified). This field contains the selected $ value, that is, the CPUID.
For more details, see “RESOURCE: Runtime Scheduling Parameter”
on page 605.
NODE NAME Node on which the job executes (as specified in the JCL).
NJE When this field contains a Y, the job has been sent for execution to a
computer that is connected to a Control-M computer by NJE, that is,
it does not have a shared spool with Control-M. Normally, do not
modify the value in this field.

BMC Software recommends that you do not purge jobs from the
spool on the Remote node. However, if a job was purged from the
spool on the Remote node, you must notify Control-M of the event
by changing the value in the NJE field back to ' ' (Blank). After a
short time, the job status changes to Disappeared.
SEARCH COUNTER Number of times Control-M has looked for a job that is not found.
(This value is displayed (as n) in job status BUT NOT FOUND n
TIMES.) When this value equals the maximum number of searches
allowed, the job status changes to DISAPPEARED.
Note: The default value is 10. This value can be changed by your
INCONTROL administrator, using the # JNFRT parameter in the
CTMPARM member in the IOA PARM library.
You may change the value of this counter. Two instances in which
this might be helpful are:

■ As the counter approaches the maximum number of searches

allowed, set the SEARCH COUNTER back to zero if you do not
want the status changed to DISAPPEARED.

■ If the search is pointless (for example, you know the job has been
deleted from spool), change the SEARCH COUNTER to 99999
thereby causing a DISAPPEARED status.
LPAR Identity of the MVS system (the logical partition) on which the job is
being, or has been, executed.
NXT RUN For rerun situations or for cyclic jobs that use the INTERVAL option,
this field indicates the next time the job is submitted (if other
submission criteria are satisfied). Format: yymmdd hhmm.

224 Control-M for z/OS User Guide

 Zoom Screen

Table 72 Fields of the Job Scheduling Definition Zoom Screen (part 4 of 4)

Field Description
ON PGMST trigger This field appears at the end of the ON PGMST line, to the right of
the A/O field. In Figure 51 an asterisk can be seen in this field. The
field is used to indicate if the ON PGMST statement was triggered.
Possible values are:

■ ‘*’ (Asterisk) – ON PGMST statement was triggered.

■ ‘ ‘ (Blank) – ON PGMST statement was not triggered.
Note: If more than one ON PGMST statement has been specified:

■ If the statements are joined by an OR relationship, related DO

actions were performed if an asterisk appears in this field for any
ON PGMST statements.

■ If the statements are joined by an AND relationship, related DO

actions were performed only if an asterisk appears in this field
for all joined ON PGMST statements.

Only specific dates (or ****, $$$$ or STAT) can be used as valid condition date
references. Therefore, if symbolic date references (such as ODAT or PREV) are
entered as condition date references (in the parameters IN, OUT, CODES, COND,
and so on) in the job scheduling definition, the real date values are derived and
displayed in the Zoom screen.

§Restart§ The restart decision parameters (FROM, TO, CONFIRM) contain a value
other than blank only if

■ the DO IFRERUN parameters have been specified in the Job Scheduling Definition
screen (Screen 2)

and

■ the job was executed.§Restart§

When and if the job is restarted, these parameters are used. You can modify the value
of these parameters.

The DOC command can be used to alternately display and hide the documentation
(DOC lines). Documentation cannot be updated in the Zoom screen.

Zoom Screen for Table Entities

An example of the Zoom screen for Table Entities is shown below.

Chapter 2 Online Facilities 225

Zoom Screen

As noted earlier, a job must be placed in the Held state before entering the Zoom
screen if changes are to be saved. When a SMART Table Entity is held, changes to jobs
within the SMART Table can be saved without having to separately place a hold on
each job.

All information applicable to the regular Zoom screen applies to the SMART Table
Entity Zoom screen as well. All fields in the SMART Table Entity Zoom screen also
appear in the Zoom screen for regular job scheduling definitions. For a description of
the fields in the SMART Table Entity Zoom screen, refer to the descriptions of the
regular Zoom screen, the Job Scheduling Definition screen, and the SMART Table
Entity screen.

Figure 52 Zoom Screen for SMART Table Entities

----------------------------- CONTROL-M ZOOM SCREEN ----------------------(3.Z)
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OWNER N04A TASKTYPE TBL
SCHDTAB SPDCRP SCHDLIB CTM.PROD.SCHED
APPL TBL ACCCOUNTING RBC
OVERLIB STAT CAL PERIOD
SCHENV SYSTEM ID NJE NODE
JOBNAME JOBID ODATE 060601 ORDERID 000IH TBL MAXWAIT 00
DESC
SET VAR
DOCMEM ACCOUNT DOCLIB CTM.CMEM.DOC
===========================================================================
IN
CONTROL
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME 1314 + DAYS PRIORITY SAC CONFIRM N
TIME ZONE:
===========================================================================
OUT
ON TABLE-END OK
DO COND ACCOUNTING-OK 0909 +
SHOUT WHEN TIME + DAYS TO URGN
MS
====== >>>>>>>>>>>>>>>>>>> END OF JOB PARAMETERS <<<<<<<<<<<<<<<<<<<<<<< =====

COMMANDS: CANCEL DOC NOTE 11.41.46

Zoom Screen Commands

The following commands are displayed in the Zoom screen.

Table 73 Commands of the Zoom Screen

Command Description
SAVE Command SAVE in the Zoom screen saves changes to the screen.
DOC Command DOC alternately displays or hides the job documentation.
For more information, see “Job Documentation” on page 149.
NOTE Command NOTE opens a note and adds it to the job order.

226 Control-M for z/OS User Guide

 Zoom Screen

NOTE
When a SAVE command is processed by Control-M, all SHOUT requests, even those which
were already actioned, are re-queued, which may possibly cause redundant SHOUTs. To
prevent specific SHOUTs from being re-queued, delete these SHOUT requests in the Zoom
screen before the SAVE. These changes affect only the current job order, not the original job
scheduling definition.

Adding or Editing a Job Order Note

You can add, delete or change a note for the job order in the Zoom screen. For
example, you might use a note to document a manual intervention in a job run. First,
however, the job must be placed in Held status.

To add a note, type NOTE in the command line of the Zoom screen and press Enter.
A new NOTE line is opened for entering additional notational text.

Figure 53 Adding or Editing a Job Order Note

----------------------------- CONTROL-M ZOOM SCREEN ----------------------(3.Z)
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 DFLT N
SCHDTAB MIKLE SCHDLIB CTMP.SCHEDULE
APPL PROD TBL KPL RBC
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
JOBNAME JOBID ODATE 060601 ORDERID 0005C MAXWAIT 04
RESTART DECISION-FROM . TO . CONFIRM N
DESC DAILY PRODUCTION - START OF PRODUCTION TABLE KPL
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
NOTE
===========================================================================
DOC
===========================================================================
IN DAILY-PROD-KPL-GO 0606
CONTROL DB2-MAIN-FILE E
RESOURCE INIT 0001 CART 0001
COMMANDS: CANCEL DOC NOTE 09.13.15

Add or edit the text in the note lines as desired. When text is added to an empty note
line, a new blank note line is opened. To delete a note, delete all note lines.

When the note is as you want it, type SAVE in the Command line and press Enter.

After all changes to the Zoom screen are made, free the Held job in the Active
Environment screen. When a job order contains a note, an indicator is placed in the
Status field of the Active Environment screen.

Chapter 2 Online Facilities 227

Zoom Screen

Exiting the Zoom Screen

The method of exiting the Zoom screen and saving changes can be customized using
the user profile.

■ By default, END (PF03/PF15) performs a cancel, and the changes are not saved (that
is, no changes are made to the job entry on the Active Jobs file). To save changes,
the SAVE command must be entered.

■ If customized, END (PF03/PF15) performs a save. In this case, the following

confirmation window is displayed if changes have been made.

Figure 54 Exiting the Zoom Screen Confirmation Window

----------------------------- CONTROL-M ZOOM SCREEN ----------------------(3.Z)
COMMAND ===> +---------------------------------------+ SCROLL===> CRSR
+------------------ | | ---------------+
MEMNAME BACKP02 | CONFIRM CHANGES ==> (Y/N) |
OWNER M44 | |
APPL APPL-L +---------------------------------------+ L
OVERLIB CTM.OVER. STAT CAL
SCHENV SYSTEM ID NJE NODE
JOBNAME JOBID ODATE 060601 ORDERID 0007N MAXWAIT 04
RESTART DECISION-FROM . TO . CONFIRM N
DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
SET VAR
CTB STEP AT NAME TYPE
DOCMEM BACKP02 DOCLIB CTM.PROD.DOC
===========================================================================
IN START-DAILY-BACKUP 0606
CONTROL
RESOURCE INIT 0001 CART 0001
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME 1314 + DAYS PRIORITY 00 SAC CONFIRM N
TIME ZONE:
CPU-ID NODE NAME NJE SEARCH COUNTER 00000
ENTER CANCEL TO IGNORE CHANGES. 18.54.43

Fill in the fields of the window as follows and press Enter:

■ Type Y (Yes) in the window to save the changes.

■ Type N (No) in the window to cancel the changes.

To bypass the window if it is normally displayed, exit the Zoom screen as follows:

■ Type SAVE in the Zoom screen to save changes (not available in Browse mode).

■ Type CANCEL in the Zoom screen to cancel changes.

228 Control-M for z/OS User Guide

 Confirm Scheduling Window

Upon saving changes, the status of the job becomes REQUESTED CHANGE HELD.
Wait until the REQUESTED CHANGE status disappears (indicating that the
Control-M monitor has accepted the change), and then free the job in the Active
Environment screen.

Confirm Scheduling Window

If a job scheduling definition contains a value of Y in the runtime scheduling
parameter CONFIRM, the job requires manual confirmation before it can be
considered for submission. When such a job is placed in the Active Jobs file, it
appears in the Active Environment screen with status of WAIT CONFIRMATION.

To confirm the scheduling of the job for submission, type C (Confirm) for the job, in
the Active Environment screen. A confirmation window is then opened. The same
confirmation window is opened when requesting the rerun of a job in the Active
Environment screen. For the description and an example of the confirmation
window, see “Confirm Rerun Window.”

Confirm Rerun Window

If a job scheduling definition does not contain an appropriate DO RERUN statement,
or if the specified MAXRERUN limit was reached, a job is not automatically rerun if
the job execution fails.

In such cases, however, rerun of the job can be manually requested by entering R
(Rerun) in the Active Environment screen.

The following confirmation window is opened when either option R (Rerun) or

option C (Confirm) is entered in the Active Environment screen.

NOTE
§Restart§ If Control-M/Restart is available, a different window is opened for job rerun. For
more information, see “§Restart§Rerun and/or Restart Window (Under Control-M/Restart)”
on page 231.

Chapter 2 Online Facilities 229

Confirm Rerun Window

Figure 55 Active Environment Screen Confirm Rerun Window

Filter: ------- CONTROL-M Active Environment ------ DOWN <D> - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ------------ Status -----------
PRD71 PROD 060601 JOB Held Wait Schedule
PRD453 PROD 060601 JOB Held Wait Schedule
PRD44 PROD 060601 JOB Held Wait Schedule
PRD85 PROD 060601 JOB Held Wait Schedule
PRD72 PROD 060601 JOB Held Wait Schedule
DAILYPRD PRODMNGR 060601 JOB Wait Schedule
DAILYSYS SYSTEM 060601 JOB Wait Schedule
CTMLDNRS PRODMNGR 060601 JOB Wait Schedule
CTMCLRES +------------------------+ Wait Schedule
C SELITBL <--------| Confirm (Y/N) | Ended- Not "OK"
TBLJOB3 +------------------------+ Ended- Not "OK" - Abended
DAILYPRD PRODMNGR 060601 JOB Wait Schedule
DAILYSYS SYSTEM 060601 JOB Wait Schedule
CTMLDNRS PRODMNGR 060601 JOB Wait Schedule
CTMCLRES PRODMNGR 060601 JOB Wait Schedule
TST3 TEST 060601 JOB Ended "OK"
TST3 TEST 060601 JOB Ended "OK"
TST1 TEST 060601 JOB Requested Rerun Ended "OK" (Run 2)
Opt: ? Why L Log H Hold Z Zoom R Rerun A Activate O Force OK V View Sysout
N Net D Del F Free S Stat T Table U Undelete J JCL Edit C Confirm 12.17.59

When R (Rerun) is entered and when Control-M/Restart is not installed, the

following confirmation window is opened:

+----------------------+
R mem-name <-----| Rerun (Y/N) |
+----------------------+

Fill in the fields of the window as follows, and press Enter:

Table 74 Fields of the Confirm Rerun Window

Field Description
Confirm or Rerun Valid values are:

■ Y (Yes) – Submission or rerun of the job is requested.

The status of the job is changed to WAIT SCHEDULE, and the
job is eligible for submission by Control-M once all other runtime
criteria are satisfied.
■ N (No) – No action is taken.
The status of the job remains unchanged and the job is not
submitted.

230 Control-M for z/OS User Guide

 §Restart§ Confirm Restart Window (Under Control-M/Restart)

§Restart§ Confirm Restart Window (Under Control-M/Restart)

When Control-M/Restart is available, and the job scheduling definition of a job
whose execution fails contains a DO IFRERUN statement, the job can be restarted.
Manual intervention is required for the job restart if the job appears in the Active
Environment screen with a status of WAIT CONFIRMATION (WITH RESTART). For
a job requiring restart, this status appears when all the following conditions exist:

■ A DO RERUN statement is defined following the DO IFRERUN statement,

indicating that the job must be scheduled for restart or rerun.

■ The CONFIRM field in the DO IFRERUN statement contains a value of Y (Yes),

indicating that confirmation is required before the job is restarted.

■ A MAXRERUN value greater than zero is defined in the job scheduling definition,
but the number of reruns specified in this field has not yet been performed. In this
case, restart can be confirmed by entering option C (Confirm) for the job.

To confirm restart or rerun for such a job, enter option C (Confirm) for the job. A
restart confirmation window is then opened. The same confirmation window is
opened when requesting the rerun (option R) of a restart job in the Active
Environment screen. For the description and an example of the confirmation
window, see the following section. “§Restart§Rerun and/or Restart Window (Under
Control-M/Restart)”.

§Restart§Rerun and/or Restart Window (Under

Control-M/Restart)
When Control-M/Restart is available, and the job scheduling definition of a job
whose execution fails contains a DO IFRERUN statement, the job can be restarted.

Manual intervention is required for the job restart in the following cases:

■ No DO RERUN statement is defined following the DO IFRERUN statement in the

job scheduling definition. In this case, the job appears in the Active Environment
screen with a failed job status.

■ The CONFIRM field of the DO IFRERUN statement contains a value of Y (Yes). In

this case, job appears in the Active Environment screen with a failed job status.

■ No maximum number of reruns is defined in field MAXRERUN, or the maximum

number reruns defined in field MAXRERUN has been performed. In this case, the
job appears in the Active Environment screen with a status of ENDED NOT “OK”
– RERUN NEEDED.

Chapter 2 Online Facilities 231

§Restart§Rerun and/or Restart Window (Under Control-M/Restart)

To manually request rerun and/or restart for such a job, enter option R (Rerun) for
the job.

The following confirmation window is opened when either option R (Rerun) or

option C (Confirm) is entered in the Active Environment screen for a job requiring
rerun and/or restart under Control-M/Restart.

Figure 56 §Restart§ Active Environment Rerun and/or Restart Confirmation Window

Filter: ------- CONTROL-M Active Environment ------ DOWN <D> - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ----------- Status ------------
DAILYPRD PRODMNGR 110405 JOB Wait Schedule
DAILYSYS SYSTEM 110405 +---------------------------------(3.R)+
IOALDNRS PRODMNGR 110405 | Job IEFBR14 Is to be Rerun |
IOACLCND PRODMNGR 110405 | Please Confirm (Y/N) |
R IEFBR14 K39 110405 | With Restart N (?/Y/N) | o CC
| ---------------------------------- |
| From Step/Proc . |
IEFBR14 N98A 110405 | To Step/Proc . |
IEFBR14 K39 110405 | Recapture Abend Codes (Y/N) |
IEFBR14 K39A 110405 | Recapture Cond Codes (Y/N) |
IEFBR14 K39A 110405 | Step Adjustment (Y/N) |
========= >>>>>>>>>>>>> | ---------------------------------- | < ========
| Flow Rerun |
| (Type 'R' to change options) |
| Forward Flow |
| Backward Flow |
| View Jobs in Flow |
| ---------------------------------- |
| Restart Parm Member Name IEFBR14 |
Opt: ? Why L Log H Hold Z Z+--------------------------------------+ Sysout
N Net D Del F Free S Stat T Table U Undelete J JCL Edit C Confirm 08.36.28

Fill in the fields of the window as follows, and press Enter:

Table 75 §Restart§ Fields of the Active Environment Rerun and/or Restart

Confirmation Window (part 1 of 4)
Field Description
Confirm Valid values are:

■ Y (Yes) – Job rerun is requested. The job is returned for possible

resubmission by Control-M (provided that all runtime
conditions are met). The status of the job is changed according to
the value of the With Restart field.
■ N (No) – No action is taken. The job is not rerun. The status of
the job remains unchanged.

232 Control-M for z/OS User Guide

 §Restart§Rerun and/or Restart Window (Under Control-M/Restart)

Table 75 §Restart§ Fields of the Active Environment Rerun and/or Restart

Confirmation Window (part 2 of 4)
Field Description
With Restart This field is applicable only if Y is entered for Confirm. If N is
entered for Confirm, this field is ignored. Valid values are:

■ Y (Yes) – When the job is rerun, it is restarted using the Restart

facilities of Control-M/Restart. The status of the job is changed
to WAIT SCHEDULE (WITH RESTART).
■ N (No) – The Restart facilities of Control-M/Restart are not used.
The status of the job is changed to WAIT SCHEDULE.
■ ? – Opens the Restart Step List window, which contains a list of
the job’s steps. This list can then be used for specifying From
Step and To Step values. For more information, see “Step List
Window” on page 240.
From Step/Proc The pgmstep (and optionally procstep) names at which the restart of
the job is to be attempted.
To Step/Proc The pgmstep (and optionally procstep) names at which the restarted
job terminates processing. Optional.

The From Step/Proc and To Step/Proc fields display from and to

step values specified in the DO IFRERUN statement. These values
may be modified.

If a From Step/Proc value is specified, and the To Step/Proc field is

blank, the job is rerun up to and including the last step.
Recapture Abend Whether to enable abend code recapture. This field is applicable only
Codes if Y is entered for WITH RESTART. (If N is entered for WITH
RESTART, this field is ignored.) Valid values are:

■ Y (Yes) – Automatic abend code recapture is performed.

■ N (No) – Abend code recapture is prevented.
■ ' ' (Blank) – The job member or the $DEFAULT member in the
CTR.PARM library is used. If the $DEFAULT member is not
found, the Control-M/Restart default is used to perform the
recapture.
Note: If ordering a restart of a job from a step after an abended step,
type N in this field. If not, only steps that specify the JCL parameters
COND=ONLY or COND=EVEN run during restart.
Recapture Cond This field is applicable only if Y is entered for With Restart. (If N is
Codes entered for With Restart, this field is ignored.) Valid values are:

■ Y (Yes) – Automatic condition code recapture is performed

■ N (No) – Condition code recapture is prevented
■ ' ' (Blank) – The job member or the $DEFAULT member in the
CTR.PARM library is used. If the $DEFAULT member is not
found, the Control-M/Restart default is used to perform the
recapture.

Chapter 2 Online Facilities 233

§Restart§Rerun and/or Restart Window (Under Control-M/Restart)

Table 75 §Restart§ Fields of the Active Environment Rerun and/or Restart

Confirmation Window (part 3 of 4)
Field Description
Step Adjustment This field is applicable only if Y is entered for With Restart. (If N is
entered for With Restart, this field is ignored.) Valid values are:

■ Y (Yes) – Automatic step adjustment is performed.

■ N (No) – Step adjustment is prevented.
■ ' ' (Blank) – The job member or the $DEFAULT member in the
CTR.PARM library is used. If the $DEFAULT member is not
found, the Control-M/Restart default is used to perform the step
adjustment.
Note: Values specified for Recapture Abend Codes, Recapture Cond Codes and Step
Adjustment override all other parameter specifications and the default. They apply to the
current restart only.
Flow Rerun Whether to open the Flow Rerun Options window. Type R in this
field to open the window.
Forward Flow This is a display only field that indicates whether to enable the
restart of a successive series of jobs, beginning with the selected job:

■ Y (Yes) – The job is restarted along with all its successor jobs.
■ N (No) – Only the selected job is restarted.
Backward Flow This is a display only field that indicates whether to enable the
restart of a preceding series of jobs, ending with the selected job:

■ Y (Yes) – The job is restarted along with all its predecessor jobs.
■ N (No) – Only the selected job is restarted.

234 Control-M for z/OS User Guide

 §Restart§Rerun and/or Restart Window (Under Control-M/Restart)

Table 75 §Restart§ Fields of the Active Environment Rerun and/or Restart

Confirmation Window (part 4 of 4)
Field Description
View Jobs in Flow This is a display only field that indicates whether to generate a Rerun
Flow Job List. This list enables the user to select specific jobs (or
SMART Table Entity) in the selected flow or flows to be restarted.
For more information, see “Rerun Flow Job List Window” on
page 237.

■ Y (Yes) – The Flow Rerun Job List screen is displayed. The list
contains:
— The job's successors (if Y was specified in Forward Flow)
— The job’s predecessors (if Y was specified in Backward Flow)
— The jobs’s successors and predecessors (if Y was specified in
both fields).
■ N (No) – The Rerun Flow Job List is not displayed.

If the job is a SMART Table Entity, and Y was not specified in either
the Forward Flow or Backward Flow fields, the generated list
contains the jobs in the SMART Table. (If Y was not specified in
either of the fields, and the job is not a SMART Table Entity, then this
value is ignored and no list is displayed.)
Restart Parm Member Name of the member that contains control parameters for the job
Name restart. The specified value must be a valid member name of 1
through 8 characters. The default value, displayed in the window, is
the member that contains the JCL of the job. This member is either
the value in the MEMNAME field of the Zoom screen, or the NAME
field of the Active Environment screen.

Note the following points about From Step/Proc and To Step/Proc values:

■ Pgmstep name can be any specific program step name or $FIRST. $FIRST resolves
to the first step of the job if procstep name is blank. Otherwise, $FIRST resolves to
the first step in the procedure identified by procstep.

■ $ABEND and $EXERR are not recognized by Control-M/Restart and must not be
specified as restart steps in this window. ($ABEND and $EXERR are valid only in
job scheduling definitions.)

■ If specifying a procstep name when there are nested procedures, specify the
procstep name of the innermost procedure in which the program is included.

■ Entering $FIRST in the first From Step/Proc field followed by $CLEANUP in the
adjacent (second) From Step/Proc field reruns the job for Cleanup (that is, run the
Control-M/Restart cleanup step and flushes the job). All other parameters entered
in the Restart window are ignored.

Chapter 2 Online Facilities 235

§Restart§Rerun and/or Restart Window (Under Control-M/Restart)

NOTE
AutoEdit resolution is performed at time of cleanup job submission. For example, if a job with
AutoEdit date variable %%DATE is submitted for cleanup the day after the original run, the
resolution of the variable during cleanup varies from that of the original run.

The RERUN request and, in Control-M/Restart, the RESTART decision are recorded
in the IOA Log file. If the Control-M monitor is active, the RERUN request is accepted
after a few seconds.

Flow Rerun Options Window

This section explains the Flow Rerun Options window. Figure 57 shows an example
of the Flow Rerun Options window. Table 76 describes the fields on the Flow Rerun
Options window.

Figure 57 §Restart§ Flow Rerun Options Window

Filter: ------- Control-M Active Environment ------ DOWN <D> - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ----------- Status ------------
DAILYPRD PRODMNGR 110405 JOB Wait Schedule
DAILYSYS SYSTEM 110405 +---------------------------------(3.R)+
IOALDNRS PRODMNGR 110405 | Job IEFBR14 Is to be Rerun |
IOACLCND PRODMNGR 110405 | Please Confirm (Y/N) |
R IEFBR14 K39 110405 | With Restart N (?/Y/N) | o CC
| ---------------------------------- |
| From Step/Proc . |
IEFBR14 N98A 110405 | To Step/Proc . |
IEFBR14 K39 110405 |+-----------------------------------+ |
IEFBR14 K39A 110405 || Forward Flow _ (Y/N) | |
IEFBR14 K39A 110405 || Backward Flow _ (Y/N) | |
========= >>>>>>>>>>>>> || View Jobs in Flow _ (Y/N) | | < ========
|+-----------------------------------+ |
| (Type 'R' to change options) |
| Forward Flow |
| Backward Flow |
| View Jobs in Flow |
| ---------------------------------- |
| Restart Parm Member Name IEFBR14 |
Opt: ? Why L Log H Hold Z Z+--------------------------------------+ Sysout
N Net D Del F Free S Stat T Table U Undelete J JCL Edit C Confirm 08.36.28

236 Control-M for z/OS User Guide

 Rerun Flow Job List Window

Table 76 §Restart§ Fields of the Flow Rerun Options Window

Field Description
Forward Flow Whether to enable the restart of a successive series of jobs, beginning
with the selected job:

■ Y (Yes) – The job is restarted along with all its successor jobs.
■ N (No) – Only the selected job is restarted.
Backward Flow Whether to enable the restart of a preceding series of jobs, ending
with the selected job:

■ Y (Yes) – The job is restarted along with all its predecessor jobs.
■ N (No) – Only the selected job is restarted.
View Jobs in Flow Whether to generate a Rerun Flow Job List. This list enables the user
to select specific jobs in the selected flow or flows to be restarted. For
more information, see “Rerun Flow Job List Window” on page 237.

■ Y (Yes) – The Flow Rerun Job List screen is displayed. The list
contains:
— The job's successors (if Y was specified in Forward Flow)
— The job’s predecessors (if Y was specified in Backward Flow)
— The jobs’s successors and predecessors (if Y was specified in
both fields).
■ N (No) – The Rerun Flow Job List is not displayed.

If the job is a SMART Table Entity, and Y was not specified in either
the Forward Flow or Backward Flow fields, the generated list
contains the jobs in the Table. (If Y was not specified in either of the
fields, and the job is not a SMART Table Entity, then this value is
ignored and no list is displayed.)

Rerun Flow Job List Window

A list of the jobs that may be restarted from a job flow rerun request can be displayed
from the Active Environment screen, by selecting the View Jobs in Flow option in the
Rerun and/or Restart Confirmation window. The user can then select specific jobs
from this list to be restarted or not, by using the I (Include) and E (Exclude) options.

Chapter 2 Online Facilities 237

Rerun Flow Job List Window

Figure 58 Rerun Flow Job List Window

Filter: ------- RERUN FLOW --- JOB LIST ------ UP <F> - (3)
COMMAND ===> SCROLL ==> CRSR
O Level ----- N a m e ----- Rerun? ------ Status -----
-1 ADDRESOR YES Ended "OK"
-1 SOURCERN YES Ended "OK"
-2 CEDOLXRX YES Ended "OK"
-1 CTDORDER YES Ended "OK"
-1 QD61P38 YES Ended "OK"
--> QD61P38 YES Ended "OK"
========= >>>>>>>>>>>>> Bottom of Jobs List <<<<<<<<<<<<< ========

Commands: OPt EXclude INclude CANcel

OPt command toggles between Commands and Options display 15.01.32

The following fields are displayed for each job in the list:

Table 77 Fields of the Rerun Flow Job List Window

Field Description
O(ption) Field for requesting options to be activated.
Level Successor or predecessor level relative to the selected job. The
current job is indicated by -->. Predecessor jobs are indicated by a
minus sign and successor jobs are indicated by a plus sign. Jobs that
have several paths to or from the selected job appear with the
shortest possible route as their level number.
Name Name of the member containing the JCL of the job, or name of the
started task.
Rerun? Whether the job is to be rerun. Valid values are YES and NO.

When the list is first generated, this field is set to YES for all jobs.
Status Job (task) status. A complete list of job statuses is found in “Job
Statuses” on page 191. One of the listed statuses appears only in this
window:

ON HST FILE – Job is currently in the History file. If the job is

included in the flow of jobs being rerun, it will be restored to the
Active Jobs file before being rerun.

To specify rerun/restart options for individual jobs:

238 Control-M for z/OS User Guide

 Rerun Flow Job List Window

■ Type I (Include) next to specific jobs to rerun/restart them. The status for the
selected job(s) is changed to YES.

■ Type E (Exclude) to prevent specific jobs from being rerun/restarted. The status
for the selected job(s) is changed to NO.

To specify rerun/restart options for the entire Rerun Flow Job List at once:

■ Type IN (Include) on the command line to rerun/restart all jobs in the list. The
status for all jobs are changed to YES.

■ Type EX (Exclude) on the command line to prevent all jobs in the list from being
rerun/restarted. The status for all jobs are changed to NO.

To rerun all the included jobs and exit the window, type RUN on the command line.
To exit the window without rerunning any of the included jobs, type CANCEL on the
command line. Pressing the END key (PF03/PF15) causes all the included jobs to be
rerun if profile variable RESWPF3 is set to N; otherwise, it exits the window without
rerunning any of the included jobs.

If you choose to rerun all the included jobs, either by typing RUN or by pressing the
END key (if profile variable RESWPF3 is set to N) a confirmation window will be
displayed.

Figure 59 Rerun Flow Job List Confirmation Window

Filter: ------- RERUN FLOW --- JOB LIST ------ UP <F> - (3)
COMMAND ===> SCROLL ==> CRSR
O Level ----- N a m e ----- Rerun? ------ Status -----
-1 ADDRESOR YES Ended "OK"
-1 SOURCERN YES Ended "OK"
-2 CEDOLXRX YES Ended "OK"
-1 CTDORDER YES Ended "OK"
-1 QD61P38 YES Ended "OK"
--> QD61P38 YES Ended "OK"
========= >>>>>>>>>>>>> Bottom of Jobs List <<<<<<<<<<<<< ========

+------------------------------------------+
| Type 'R' to rerun flow, 'C' to cancel: |
+------------------------------------------+

Commands: OPt EXclude INclude CANcel

OPt command toggles between Commands and Options display 15.01.32

Type one of the following values in the confirmation window:

Chapter 2 Online Facilities 239

Step List Window

■ R - to rerun all the included jobs

■ C - to exit the window without rerunning jobs

The order in which the Rerun Flow jobs are displayed can be controlled by the
RSORT command. Typing RSORT FLOW on the command line causes the jobs to be
displayed in the order of the flow, that is, with predecessor jobs before their
successors. Typing RSORT NAME on the command line causes the jobs to be
displayed in alphabetical order.

Step List Window

A list of the job steps from the previous job run, with the completion codes of each
step, can be displayed from the Restart window in the Active Environment screen.
Steps from this list can then be selected as From Step/Proc and/or To Step/Proc
values in the Restart window.

To display the list of job steps, type a ? symbol in the With Restart field of the Restart
window, and press Enter. The Step List window, below, is opened. This “window
within a window” contains the list of job steps.

Figure 60 Rerun and/or Restart Step List Window

Filter: ------- Control-M Active Environment ------ UP <D> - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ------------ Status -----------
PRD71 PROD 060601 JOB Held Wait Schedule
PRD453 PROD 060601 +---------------------------------(3.R)+
PRD44 PROD 060601 | Job TBLJOB3 Is to be Rerun |
PRD85 PROD 060601 | Please Confirm (Y/N) |
PRD72 PROD 060601 | +----------- CONTROL-R Step List ------------+
SELITBL M70 060601 | | Command ==> |
R TBLJOB3 M70 060601 | | O Num Pgm-stp Proc-stp Pgm= Comp |
TST1 TEST 060601 | | 001 STEP1 IEBGENER C0000 |
TST2 TEST 060601 | | 002 STEP2 XYZA7891 S806 |
TST3 TEST 060601 | | |
DAILYPRD PRODMNGR 060601 | | |
DAILYSYS SYSTEM 060601 | | |
CTMLDNRS PRODMNGR 060601 +- | |
CTMCLRES PRODMNGR 060601 | |
IEFBR14 PROD 060601 N9 | |
IEFBR14 PROD 060601 N9 | |
IEFBR14 PROD 060601 N2 | |
IEFBR14 PROD 060601 | Opt: F From T To O Only |
========= >>>>>>>>>>>>> +--------------------------------------------+ =
Opt: ? Why L Log H Hold Z Zoom R Rerun A Activate O Force OK V View Sysout
N Net D Del F Free S Stat T Table U Undelete J JCL Edit C Confirm 12.43.09

To locate a specific step, type the LOCATE command in the Command field of the
Control-M/Restart Stop List window and press Enter. The format of the command is:

240 Control-M for z/OS User Guide

 §Restart§Job Order Execution History Screen

LOCATE stepname

Steps selected in the Step List window are displayed in the appropriate field of the
Restart window. To select steps, type the appropriate selection values in the Option
(O) field by the step names. Valid selection values are shown in Table 78.

Table 78 Options of the Rerun and/or Restart Step List Window

Option Description
F (From) Restart begins at the indicated step. The indicated step becomes the
From Step/Proc parameter.
T (To) Restart ends at the indicated step. The indicated step becomes the To
Step/Proc parameter.
O (Only) Restart begins and ends at the indicated step. The indicated step
becomes the From Step/Proc and To Step/Proc parameter. This
value cannot be specified with an F or a T value.

NOTE
If a step cannot be used as a From Step/Proc and/or To Step/Proc for restart, the Option field
is protected, and an option cannot be entered, for that step.

Pressing the END key (PF03/PF15) closes the Step List window and automatically
updates the From Step/Proc and To Step/Proc fields of the Restart window with the
appropriate steps.

Typing the command RESET, or pressing the RESET key (PF04), closes the Step List
window without updating the Restart window.

§Restart§Job Order Execution History Screen

The Job Order Execution History screen is displayed when option V (View Sysout) is
entered on the Active Environment screen. The Job Order Execution History screen
lists all runs of the job and displays relevant execution information for each run.

This option is used for jobs that have executed at least once and whose SYSDATA has
been automatically archived by the Control-M monitor as part of Control-M/Restart
processing (Auto-Archive=Y). The V option does not support the viewing of output
on the spool or output that has been archived by a Control-M SYSOUT F function.)

Chapter 2 Online Facilities 241

§Restart§Job Order Execution History Screen

Figure 61 §Restart§ Job Order Execution History Screen

------------------------ JOB ORDER EXECUTION HISTORY ---------------------(3.V)
COMMAND ===> SCROLL===> CRSR
MEMNAME MSGCMPR OWNER M05A ORDERID 00051 ODATE 060601
O JOBNAME JOBID DATE START ELAPSED PAGES MAX RC --------- STATUS ---------
PRDYLLM 01318 060601 21:40 1.46 00007 S222 ENDED- NOT "OK" - ABENDED
PRDYLLM 01425 060601 21:56 1.21 00014 C0008 ENDED- NOT "OK" DUE TO CC
PRDYLLM 01447 060601 22:01 1.50 00014 ENDED- OK
======= >>>>>>>>>>> BOTTOM OF ACTIVE JOB ORDER HISTORY LIST <<<<<<<<<<< =======

OPTION: S SELECT 11.41.04

By default, older data are displayed before more recent data (that is, in FIFO order –
first in, first out), so that the first run of the job is shown first. If, however, the user
profile has been customized accordingly, data is displayed in LIFO order (last in, first
out).

The Job Order Execution History screen is pre-configured to the D (Default) display
type. Additional display types may be defined by the INCONTROL administrator. To
display a different display type on the screen, type command DISPLAY x
(abbreviated DI x) where x is the identifying letter of the display type (such as DI D).

To return to the Active Environment screen, press the END key (PF03/PF15).

§Restart§ Format of the Job Order Execution History Screen

The following information about the job is displayed in the Default display type of
the Job Order Execution History screen.

Table 79 §Restart§ Default Display Type Fields of Job Order Execution History
Screen
Field Description
MEMNAME Name of the member containing the job’s JCL.
OWNER User ID of the owner of the job.
ORDERID Job order ID.
ODATE Original scheduling date of the job.

242 Control-M for z/OS User Guide

 §Restart§ Sysout Viewing Screen

For each execution of the job, the following information is displayed:

Table 80 §Restart§ Fields in the Job Order Execution History Screen

Field Description
O Option field.
JOBNAME Job name.
JOBID JES job number.
DATE Execution date of the job.
START Start time of the job execution (format hh:mm).
ELAPSED Total elapsed time of the job execution (format mmmm.nn – where
mmmm is minutes, and nn is hundredths of minutes).
PAGES Number of pages in the sysout.
MAX RC Highest return code of the job execution.
STATUS Status assigned to the job by Control-M, based on execution results.

§Restart§ Displaying Job Sysout

Job execution sysout, which is displayed in the Sysout Viewing screen, can be
requested from the Job Order Execution History screen in the following ways:

■ To display job sysout for specific executions of the job, type the option S (Select) in
the OPTION field of the selected executions and press Enter.

■ To display job sysout for all executions of the job, type the command VIEWALL
(abbreviated V) in the COMMAND field and press Enter.

§Restart§ Sysout Viewing Screen

The Sysout Viewing screen is displayed when the option S (Select) is entered for
specific job executions, or when the command VIEWALL is entered, in the Job Order
Execution History screen.

This screen displays the job execution sysout, as follows:

■ If the option S (Select) was typed in the Job Order Execution History screen for
specific executions of the job, the sysout for those executions are displayed.

■ If the command VIEWALL was entered in the Job Order Execution History screen,
the sysout for all executions is displayed.

Chapter 2 Online Facilities 243

§Restart§ Sysout Viewing Screen

Figure 62 §Restart§ Sysout Viewing Screen

------------ CONTROL-M/CONTROL-R SYSOUT VIEWING -------- PAGE 1 OF 12
COMMAND ===> SCROLL===> CRSR
MEMNAME PRDKPL01 OWNER M22 JOBNAME PRDKPL01 ODATE 060601
---+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
J E S 2 J O B L O G -- S Y S T E M F D S F -- N O
18.31.20 JOB 8666 $HASP373 PRDKPL01 STARTED - INIT 1 - CLASS A - SYS FDSF
18.31.20 JOB 8666 IEF403I PRDKPL01 - STARTED - TIME=18.31.20
18.35.21 JOB 8666 PRDKPL01.STEP01 .#01; - COMPLETION CODE=0000
18.39.22 JOB 8666 PRDKPL01.STEP01A .#02; - COMPLETION CODE=0000
18.42.22 JOB 8666 PRDKPL01.STEP02 .#03; - COMPLETION CODE=0000
18.50.23 JOB 8666 PRDKPL01.STEP03 .#04; - COMPLETION CODE=0000
18.51.25 JOB 8666 IEF450I PRDKPL01 STEP04 - ABEND S0C4 U0000 - TIME=18.51.25
18.51.25 JOB 8666 PRDKPL01.STEP04 .#05; - COMPLETION CODE=S00C4 - ABENDED####
18.51.25 JOB 8666 PRDKPL01.STEP05 .#06; - COMPLETION CODE=NOT RUN
18.51.25 JOB 8666 PRDKPL01.STEP06 .#07; - COMPLETION CODE=NOT RUN
18.51.25 JOB 8666 PRDKPL01.STEP07 .#08; - COMPLETION CODE=NOT RUN
18.51.26 JOB 8666 PRDKPL01.STEP08 .#09; - COMPLETION CODE=NOT RUN
18.51.26 JOB 8666 PRDKPL01.STEP09 .#10; - COMPLETION CODE=NOT RUN
18.51.26 JOB 8666 PRDKPL01.STEP10 .#11; - COMPLETION CODE=NOT RUN
18.51.26 JOB 8666 IEF404I PRDKPL01 - ENDED - TIME=18.51.26
18.51.26 JOB 8666 $HASP395 PRDKPL01 ENDED
------ JES2 JOB STATISTICS ------
COMMANDS: LEFT, RIGHT, FIND str, FIND str PREV, N n, P n, END 18.56.48

Job orders are displayed in the same order (LIFO/FIFO) in this screen as in the Job
Order Execution History screen.

To return to the Job Order Execution History screen, press END (PF03/PF15).

The following commands are supported:

Table 81 §Restart§ Commands of the Sysout Viewing Screen

Command Description
LEFT Shift display to the left.
RIGHT Shift display to the right.
Note: Terminals with 132-character lines display the entire data line. Therefore, LEFT and
RIGHT do not affect the display on those terminals.
FIND str Find next occurrence of the string.
FIND str PREV Find previous occurrence of the string.
NEXT n Scroll forward n number of print pages (can be abbreviated N n).
PREV n Scroll backward n number of print pages (can be abbreviated P n).
END Exit the screen.

For color terminals, display colors for the sysout are defined in the user profile. If you
want to change the default colors, see your INCONTROL administrator.

244 Control-M for z/OS User Guide

 Statistics Screen

Statistics Screen
The Statistics screen displays the most current run statistics for a particular job. The
screen is displayed when any of the following actions is performed:

■ Option S (STAT) is typed next to the jobname in the Active Environment screen.
■ Option T (JOBSTAT) is typed next to the job name in the Job List screen.
■ Command JOBSTAT is typed in Command field of the Job Scheduling Definition
screen or the Active Environment screen.

A separate set of statistics is collected for each table name on each computer in which
the job is run. Statistics for a job are retained for a maximum of 200 executions in each
table name on each computer.

Figure 63 Active Environment Statistics Screen

----------------------------- BR14 STATISTICS ------------------------(3.S)
COMMAND ===> SCROLL===> CRSR
JOBNAME JOBID STATUS STRT DATE/TIME END DATE/TIME ELAPSED CPU
ELAPSED AVERAGE: 0.01 MAX: 0.01 MEDIAN: 0.01 STD: 0.01
SYSID: 1 SMFID: ESA1 PERIOD: A AVERAGE: 0.00 0:00.00
NEWJOB 0016156 04/07/06 14:13 04/07/06 14:13 0.00 0:00.01
BR14A 0016157 04/07/06 14:13 04/07/06 14:13 0.00 0:00.01
BR14B 0016144 04/07/06 13:55 04/07/06 13:55 0.00 0:00.00
0016146 04/07/06 13:55 04/07/06 13:55 0.00 0:00.01
ABNDJOB 0016133 NOTOK 04/07/06 13:41 04/07/06 13:41 0.00 0:00.01
IEFBR14 0016134 DUMMY 04/07/06 13:41 04/07/06 13:41 0.00 0:00.01
0016135 04/07/06 13:41 04/07/06 13:41 0.00 0:00.01
JCLERR 0016131 NOTOK 04/07/06 13:39 04/07/06 13:39 0.00 0:00.00

ELAPSED AVERAGE: 0.00 MAX: 0.00 MEDIAN: 0.00 STD: 0.01

SYSID: 3 SMFID: OS33 PERIOD: AVERAGE: 0.00 0:00.00
0016167 04/07/06 14:41 04/07/06 14:41 0.00 0:00.01
MYJOB 0016168 04/07/06 14:41 04/07/06 14:41 0.00 0:00.01
YOURJOB 0016155 04/07/06 14:13 04/07/06 14:13 0.00 0:00.00
0016146 04/07/06 13:55 04/07/06 13:55 0.00 0:00.01
====== >>>>>>>>>>>>>>>>>>> END OF STATISTICS LIST <<<<<<<<<<<<<<<< ======

PRESS END PFK TO RETURN PRESS PF11 TO SCROLL RIGHT 14.28.25

To return to the Active Environment screen, press the END key (PF03/PF15).

NOTE
Update of the Statistics file is performed by the CTMJSA utility, which must be scheduled
periodically. The CTMJSA utility is described in the INCONTROL for z/OS Utilities Guide.

WARNING
If statistics that exist for a job are not displayed, refresh the display by entering the REFRESH
command (PF04/PF16).

Chapter 2 Online Facilities 245

Statistics Screen

Fields of the Statistics Screen

For each computer with statistics on the job, an Average Statistics line is displayed
followed by individual job or SMART Table Entity statistics for each execution.
Individual job and SMART Table Entity statistics are listed in descending
chronological order, with the most recently ended job at the top.

Average Statistics Lines

The second line following the report heading contains:

■ SYSID of the computer for which statistics are calculated

■ SMF ID corresponding to the SYSID
■ statistical PERiod indicator specified in the job definition's STAT CAL
■ average CPU time
■ average SRB time

The first line following the header contains the following statistics for the jobs which
are grouped by the SYSID and PERiod specified above:

■ AVERAGE ELAPSED time

■ MAXimum elapsed time
■ MEDIAN elapsed time
■ STandard Deviation elapsed time (see utility CTMJSA in the INCONTROL for z/OS
Utilities Guide for details on calculating standard deviation)

NOTE
The SYSID consists of one or two digits, left-justified.

Individual Execution Statistics

Table 82 Statistics Screen Individual Execution Statistics (part 1 of 2)

Field Description
JOBID Job number under JES. Blank for DUMMY jobs (and some NOTOK
jobs).
JOBNAME Job name from the JCL JOB statement. Blank for DUMMY jobs.
STATUS Job’s status. Valid values are:

■ ' ' (Blank) – job ended OK (or Forced OK)

■ NOTOK – job ended NOTOK (or required a RERUN)
■ DUMMY – dummy job

246 Control-M for z/OS User Guide

 Statistics Screen

Table 82 Statistics Screen Individual Execution Statistics (part 2 of 2)

Field Description
STRT DATE/TIME Date and time the job began executing.
Date format: mmddyy, yymmdd or ddmmyy depending on site
standard.
Time format: hh:mm, where hh=hours and mm=minutes.
END DATE/TIME Date and time the job finished executing. Same format as STRT
DATE/TIME.
ELAPSED Elapsed runtime. Format: mmmm.ss, where mmmm is minutes and
ss is seconds.
CPU CPU time used. Format mmmm:ss.nn, where mmmm is minutes, ss
is seconds and nn is hundredths of seconds.
SRB SRB (System Request Block) time used. Format: mmmm:ss.nn, where
mmmm is minutes, ss is seconds and nn is hundredths of seconds.
USER DATA Optionally supplied data from the user data area in the Control-M
Statistics file (edited by user Exit CTMX013).

SMART Table Entity Execution Statistics

Fields of the SMART Table Entity Execution statistics have different meanings than
corresponding fields of the Individual Execution statistics.

Table 83 Statistics Screen SMART Table Entity Execution Statistics

Field Description
JOBID Order ID of the SMART Table Entity.
JOBNAME Blank
STATUS Status of the jobs in the SMART Table. Valid values are:

■ ' ' (Blank) – all jobs in the table ended OK (or Forced OK)
■ NOTOK – at least one job in the SMART Table did not end OK
(or required a RERUN)
STRT DATE/TIME Date and time the SMART Table began executing.
Date format: mmdd or ddmm depending on site standard.
Time format: hh:mm (where hh=hours and mm=minutes).
END DATE/TIME Date and time the SMART Table finished executing. Same format as
STRT DATE/TIME.
ELAPSED Elapsed time from the time the first job in the SMART Table began
executing until the time the last job in the SMART Table finished
executing.
CPU 0
SRB 0
USER DATA Blank

To view the entire screen displayed in Figure 63, scroll to the right (using PF11/PF23).

Chapter 2 Online Facilities 247

Statistics Screen

Tape Device Usage Statistics

If the AUTOTAPE parameter in the CTMPARM member in the IOA PARM library is
set to Yes, tape device usage information is accumulated for every Control-M job
execution that ended OK. This information is used by the Automatic Tape
Adjustment facility to automatically allocate the appropriate number of tape drives
for a job at job order time. This allocated value overrides any specified tape device
usage value in the RESOURCE parameter. For more information, see the discussion
of using the automatic tape adjustment facility in the INCONTROL for z/OS
Administrator Guide.

This information (shown below) can be displayed by scrolling to the right of the
Statistics screen (using PF11/PF23):

Figure 64 Tape Device Usage Statistics

JOBID STRT DATE DEVICES USED
AVERAGE: SYSID:
0239 05/02/01 TAPE=1;CARTRIDGE=1;
0643 06/02/01 TAPE=1;CARTRIDGE=1;
0399 07/02/01 TAPE=1;CARTRIDGE=1;
2141 12/02/01 TAPE=1;CARTRIDGE=1;
0493 13/02/01 TAPE=1;CARTRIDGE=1;

The tape usage information consists of fields JOBID and START date (from the
Statistics screen) so that tape usage of a specific job execution can be easily identified,
and an additional field, DEVICES USED, which is described below.

The DEVICES USED field contains tape device types and number of devices of each
type that were used by the job. This field has the following format:

devtype1=quant1;devtype2=quant2;...devtypex=quantx;

where:

■ devtype – A tape device type used by the job.

■ quant – The number of tape devices of the specified type used by the job.

The maximum quantity of units per device type for any job that can be
accommodated by the Statistics file is 15. Any actual quantity exceeding 15 will be
stored and displayed as 15.

Tape device types are displayed in the order specified by the INCONTROL
administrator in the UNITDEF member of the Control-M PARM library.

If the tape device usage information occupies more than the visible screen, scroll
again to the right (using PF11 or PF23) to view additional device usage information.
The maximum length of tape device usage data is 255 characters.

248 Control-M for z/OS User Guide

 Job Dependency Network Screen

Job Dependency Network Screen

The Job Dependency Network screen is displayed when option N (Network) is
entered on the Active Environment screen. The Job Dependency Network screen
displays all the predecessor and successor jobs (including eventual successors and
predecessors) for the selected job.

Job dependencies are determined according the prerequisite IN and OUT conditions
of the job. DO COND statements are not used for this purpose because the
dependencies they create are conditional rather than constant.

The Job Dependency Network screen is a special case of the Active Environment
screen, and therefore contains most of the same features. A filter that is active in the
Active Environment screen also remains active in the Job Dependency Network
screen (and vice versa).

Jobs are listed in job flow order (that is, level) relative to the selected job. The selected
job is indicated by level 0. Predecessor jobs are indicated by a minus sign and
successor jobs are indicated by a plus sign.

The network of jobs is maintained by the Control-M monitor, and is refreshed only by
request. The REFRESH Command is described in “Commands of the Job Dependency
Network Screen” on page 251. The time of the last network refresh is displayed on the
top line of the Job Dependency Network screen.

To return to the Active Environment screen, press the END key (PF03/PF15).

Features of the Job Dependency Network screen that have already been described
earlier for the Active Environment screen are not described below. Refer to the Active
Environment screen for information about those features. However, note the
following points:

■ The RBAL command of the Active Environment screen is not supported in the Job
Dependency Network screen. This difference is also reflected in the Primary
Bottom lines of the two screens.

■ The N (Network) display type is specifically oriented to the Job Dependency

Network screen, and is therefore described in the following section. It is also
available in the Active Environment screen.

For a description of the fields in the D (Default) display type and the A (All Info)
display type, see “Format of the Active Environment Screen” on page 176.

Chapter 2 Online Facilities 249

Job Dependency Network Screen

Format of Job Dependency Network Information

Display Type N (Network)

The Network display type is intended for use by the INCONTROL administrator and
operations personnel. Basic information is displayed for each job.

Figure 65 Job Dependency Network Display Type N (Network)

Filter: DEFAULT ------- CONTROL-M NETWORK OF BGPCBHK6 ------ UP <N> - (3)
COMMAND ===> SCROLL ==> CRSR
O Level ----- N a m e ----- DueIN/Out Elaps Late Prio Res ------ Status -----
-6 JOBPREP1 1206 1209 0003 9 WAIT SCHEDULE
-5 CHECKFL1 1209 1212 0003 9 WAIT SCHEDULE
-5 JOBPREP2 1212 1215 0003 9 WAIT SCHEDULE
-5 CHECKFL2 1215 1218 0003 9 WAIT SCHEDULE
-4 CHECKFL3 1218 1221 0003 9 WAIT SCHEDULE
-4 LOGLIST 1221 1224 0003 9 WAIT SCHEDULE
-4 FLOWCHK 1224 1227 0003 9 WAIT SCHEDULE
-3 MAINTST 1227 1230 0003 9 WAIT SCHEDULE
-2 SAMP 1230 1233 0003 9 WAIT SCHEDULE
-1 FLOWPRT 1233 1236 0003 9 WAIT SCHEDULE
--> RGL1 1236 1239 0003 9 WAIT SCHEDULE
+1 RGL2 1239 1242 0003 9 WAIT SCHEDULE
+2 RGLCHK 1242 1245 0003 9 WAIT SCHEDULE
+3 RGL3 1245 1248 0003 9 WAIT SCHEDULE
+4 DELCHK 1248 1251 0003 9 WAIT SCHEDULE
+5 DELLOG 1251 1254 0003 2 WAIT SCHEDULE
+6 DELRUN 1254 1257 0003 2 WAIT SCHEDULE
+7 CLEANUP 1257 1300 0003 2 WAIT SCHEDULE
========= >>>>>>>>>>>>> Bottom of Jobs List <<<<<<<<<<<<< =========
Commands: OPt DIsplay Show HIstory REFresh Auto Jobstat SHPF Note Table
OPt command toggles between Commands and Options display 15.15.48

Table 84 Fields of the Job Dependency Network Display Type N (Network)

(part 1 of 2)
Field Description
Filter Name of the currently active screen filter. For more information, see
“Filtering the Active Environment Screen Display” on page 196.

IOA profile variable SACT3NFL, described in the INCONTROL for

z/OS Administrator Guide, determines whether the filter in effect in
the Active Environment screen also filters this display.
Control-M status Indicator of whether the Control-M monitor is UP, DOWN or SUSP
(suspended).
Display Type Indicator of the currently used display type, for example, N for the
Indicator Network display type.
The following are displayed for each job:
O(ption) Field for requesting options to be activated.

250 Control-M for z/OS User Guide

 Job Dependency Network Screen

Table 84 Fields of the Job Dependency Network Display Type N (Network)

(part 2 of 2)
Field Description
Level Successor or predecessor level relative to the selected job. The
current job is indicated by -->. Predecessor jobs are indicated by a
minus sign and successor jobs are indicated by a plus sign. Jobs that
have several paths to or from the selected job appear with the
shortest possible route as their level number.
Name Name of the member containing the job’s JCL, or name of the started
task.
DueIn Due in date and time. Date and time by which the job must be
submitted.
DueOut Due out date and time. Date and time by which the job must finish
executing.
Elaps Elapse time. Expected time (in minutes) for the job to execute.
Late Indication that a job is late. Possible values:

■ X – Actual execution has not completed within the expected

execution time. Also indicates that SHOUT WHEN EXECTIME
was issued.
■ I – Job was not submitted in time. Also indicates that SHOUT
WHEN LATESUB was issued.
■ O – Job is late. Also indicates that SHOUT WHEN LATE was
issued.
Prio Control-M priority of the job.
Res Indicator that the job accesses Quantitative resources. Valid values
are:

■ ' ' (Blank) – Quantitative resources are not accessed

■ Y (Yes) – Quantitative resources are accessed
Status Job (task) status.

Commands of the Job Dependency Network Screen

Except for command REFRESH, detailed descriptions of the Job Dependency
Network screen commands can be found in “Commands of the Active Environment
Screen” on page 180.

Command REFRESH is described here in detail because this command is most

relevant to the Job Dependency Network screen.

Command REFRESH causes the Control-M monitor to recalculate job dependencies.

During the refresh, that is, from the time the refresh is initiated until the refresh is
completed, a special status message is displayed at the top of the screen. The format
of the command is:

REFRESH parm

Chapter 2 Online Facilities 251

History Environment Screen

where parm is the type of refresh to be performed.

The following parameters may be entered with the REFRESH command:

Table 85 Parameter of the REFRESH Command

Parameter Description
NET Update the list of dependent jobs in the Job Dependency Network
screen. As soon as possible, the monitor recalculates logical
dependencies for all job orders currently present in the Active Jobs
file and updates the Job Dependency Network screen. Default.
DEADLINE Adjust DUE OUT times, if necessary, for all job orders in the Active
Jobs file that are not Held. For an explanation of the method used to
recalculate DUE OUT time, see “Automatic Job Flow Adjustment”
on page 77.
PROPAGATE Check and adjust the priority of predecessor jobs. For more
information, see “Automatic Job Flow Adjustment” on page 77.
ALL Activates the processes described above (NET, DEADLINE and
PROPAGATE) simultaneously in the Control-M monitor.

History Environment Screen

Jobs can be automatically moved from the Active Jobs file to the History Jobs file
during the subsequent New Day processing.

Jobs in the History Jobs file can be displayed in the History Environment screen.

The History Environment screen is a special case of the Active Environment screen. It
is displayed when command HISTORY is typed in the Command field in the Active
Environment screen.

252 Control-M for z/OS User Guide

 History Environment Screen

Figure 66 History Environment Screen

Filter: DEFAULT ------- CONTROL-M History Environment ------ DOWN - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ----------- Status ------------
DAILYSYS SYSTEM 060601 JOB Wait Schedule
CTMLDNRS PRODMNGR 060601 JOB Wait Schedule
CTMCLRES PRODMNGR 060601 JOB Wait Schedule
GEN1 PRODMNGR 060601 PRDGEN1 /17048 JOB Ended "OK"
GEN2 PRODMNGR 060601 PRDGEN2 /17049 JOB Ended "OK"
GEN3 PRODMNGR 060601 PRDGEN3 /17050 JOB Ended "OK"
GEN4 PRODMNGR 060601 PRDGEN4 /17051 JOB Ended "OK"
GEN5 PRODMNGR 060601 PRDGEN5 /17053 JOB Ended "OK"
TPCICS47 TP05 060601 TPCICS47/18081 JOB Ended "OK"
TPCICS12 TP01 060601 TPCICS12/18082 JOB Ended "OK"
GEN1 PRODMNGR 060601 PRDGEN1 /18084 JOB Ended "OK"
GEN2 PRODMNGR 060601 PRDGEN2 /18085 JOB Ended "OK"
TPCICS05 TP05 060601 TPCICS05/18090 JOB Ended "OK"
Y01ACCB ACCT 060601 Y01ACCB /19053 JOB Ended "OK"
Y01ACCC ACCT 060601 Y01ACCB /19150 JOB Ended "OK"
Y01ACCD ACCT 060601 Y01ACCB /19230 JOB Ended "OK"
Y01ACCE ACCT 060601 Y01ACCB /19232 JOB Ended "OK"
Y01ACCF ACCT 060601 Y01ACCB /19233 JOB Ended "OK"
Y01ACCG ACCT 060601 Y01ACCB /19501 JOB Ended "OK"
Commands: OPt DIsplay Show HIstory RBal REFresh Auto Jobstat SHPF Note Table
OPt command toggles between Commands and Options display 14.55.34

Because the History Environment screen is a special case of the Active Environment
screen, the features of the two screens are almost identical, and are described in
“Active Environment Screen” on page 173. Differences between the screens are as
follows:

The selection of line options available in the History Environment screen is different
than the selection of line options available in the Active Environment screen. Below is
the Alternate Bottom line of the History Environment screen.

Opt: L Log Z Zoom S Stat R Restore J JCL Edit V View Sysout T Table

The OPT command toggles between Commands and Options display.

Upon exiting the History Environment screen (by pressing PF03/PF15), the Active
Environment screen is displayed.

Options of the History Environment Screen

The History Environment screen has the same options as the Active Environment
screen, with the addition of R Restore.

The R Restore option restores the specified job to the Active Jobs file and marks it as
deleted in the History Jobs file. The restored job appears in the Active Jobs file in
Held status.

Chapter 2 Online Facilities 253

Force OK Confirmation Window

For a description of the remaining options, see “Options of the Active Environment
Screen” on page 186.

Working with different History files

By default, when the HISTORY command is entered without any parameters, the
entries in the default History file are displayed. It's possible to enter the HISTORY
command followed by the name of a different history file. As a result, the entries from
the "different" history file are displayed.

This feature is available only when using the IOA Online environment under TSO,
not under the IOA Online monitor.

Force OK Confirmation Window

To change the status of a job to ENDED OK, type O (Force OK) in the option field to
the left of the job order and press Enter.

Status changes are performed as follows:

■ If the job status is WAIT SCHEDULE, the status is changed to ENDED OK without
submitting the job. As a result, all resources required by the job are freed, and OUT
and SHOUT WHEN OK job post-processing are performed as if the job terminated
with status ENDED OK.

■ If the job has an ON PGMST code of FORCE, and it terminates with status ENDED
NOTOK, the status is changed to ENDED OK. In addition, ON PGMST post
processing is performed for the following DO actions: DO COND, DO FORCEJOB,
DO SETVAR, and DO SHOUT. For more information about the code FORCE, see
the table of parameter values for use with the “ON” Post Processing Parameter in
“ON Statements: Post–Processing Parameter” on page 546.

The same effect is achieved if a job has the ON PGMST parameter with value
ANYSTEP specified with the code OK, if the FRCOKOPT parameter in the
CTMPARM member in the IOA PARM library is set to Y, and if the command
FORCE OK is requested.

In the case of a cyclic job, Force OK works only after the job has reached an ENDED
status, such as the result of a DO STOPCYCLE command.

A Force OK request is not performed if the job is currently being executed or rerun.

In the case of a SMART Table Entity, Force OK works only if the SMART Table Entity
has an ENDED status.

254 Control-M for z/OS User Guide

 Force OK Confirmation Window

When requesting Force OK, the Force OK confirmation window is displayed, unless
the user profile has been modified to suppress the window. The Force OK
confirmation window is illustrated in Figure 67.

Figure 67 Control-M Active Environment FORCE OK confirmation window

Filter: ------- CONTROL-M Active Environment ------ UP <D> - (3)
COMMAND ===> SCROLL ==> CRSR
O Name Owner Odate Jobname JobID Typ ----------- Status ------------
========= >>>>>>>>>>>>> Top of Jobs List <<<<<<<<<<<<< ========
DAILYSYS SYSTEM 271207 JOB Held Wait Schedule
DAILYPRD PRODMNGR 301207 JOB Wait Schedule
DAILYSYS SYSTEM 301207 JOB Wait Schedule
IOALDNRS PRODMNGR 301207 JOB Wait Schedule
IOACLCND PRODMNGR 301207 JOB Wait Schedule
TEST1 K30 301207 JOB Ended "OK"
TEST3 K30 301207 JOB Ended "OK"
NOT-SUB +-----------------------------------+ule
O FAILUNK | Force OK (Y/N) |eason Unknown Ended-
| Post-processing Options: |
WM3714#1 <ssssssss| OUT Statements Y (Y/N) | Forced OK
WM3714#1 | ON PGMSTEP Statements Y (Y/N) | Forced OK (Run 2)
| SHOUT Statements Y (Y/N) | Ended "OK"
========= > | CTB STEP Statements Y (Y/N) |<<<<<<<<<<<< ========
+-----------------------------------+

Commands: OPt DIsplay Show HIstory RBal REFresh Auto Jobstat SHPF Note Table
OPt command toggles between Commands and Options display 09.18.27

You can specify in the Force OK confirmation window whether the following DO
actions are performed:

■ DO COND
■ DO FORCEJOB
■ DO SET
■ DO SHOUT

If you specify that these actions must be performed, this overrides the value specified
in the FRCOKOPT parameter in the CTMPARM member in the IOA PARM library.
For more information about the FRCOKOPT parameter, see the INCONTROL for z/OS
Installation Guide.

These actions are only performed if the following additional conditions are satisfied:

■ ON PGMST is set to ANYSTEP.

■ CODES is set to OK.
■ The ON PGMST ANYSTEP statement is not part of a Boolean block.

NOTE
If CODES is set to FORCE, the DO actions are performed regardless of the value set in the
With Post-Processing field.

Chapter 2 Online Facilities 255

CMEM Rule Definition Facility

Fill in the Force OK confirmation window as follows, and press Enter.

1. To confirm the Force OK request, type Y in the Force OK field. To cancel the
Force OK request, type N in this field.

2. If you do not want the job's OUT condition statements to be performed, type N in
the OUT Statements field. If you want the job's OUT statements performed, type Y
in this field.

3. If you do not want the DO actions listed above performed, type N in the ON
PGMSTEP Statements field. If you want these DO actions performed, type Y in this
field.

4. If you do not want the job's SHOUT statements to be performed, type N in the
SHOUT Statements field. If you want the job's SHOUT statements performed, type
Y in this field.

5. If you do not want the job's CTB STEP statements to be performed, type N in the
CTB STEP Statements field. If you want the job's CTB STEP statements performed,
type Y in this field.

NOTE
The default values for fields OUT Statements, ON PGMSTEP Statements, SHOUT Statements,
and CTB STEP Statements will be taken from the following variables in the user's profile:
SACTFOU, SACTFPS, SACTFSH, and SACTFCB (respectively). If the SACTFPS variable is not
found in the user's profile, the value set in the FRCOKOPT parameter will be the default for
the ON PGMSTEP Statements field. For the other fields, if their respective variables are not
found in the user's profile, the default will be Y. The default values will be used if the user
profile has been modified to suppress the Force OK Confirmation window.

CMEM Rule Definition Facility

The Control-M Event Manager (CMEM) Rule Definition facility enables you to create,
view, or modify CMEM rules for the handling of events in your environment. A
CMEM rule consists of parameters that correspond to the decisions and actions to be
taken when handling the occurrence of specified external events.

A CMEM rule for a specific situation needs to be defined only once. Once defined, the
rule is saved and used as necessary for managing events. CMEM rules may be
modified or deleted as required.

CMEM rules are stored in members called rule tables. In many environments, several
rules can work together as a group to handle a specific situation. In these cases, it is
common to define all such related rules in a single rule table.

256 Control-M for z/OS User Guide

 CMEM Rule Definition Facility

Any number of rule tables may be defined, and each rule table may contain any
number of CMEM rules.

CMEM rule tables (members) are stored in rule libraries (partitioned data sets). You
may define any number of rule libraries.

The number of rule tables in a library, the number of rules in a rule table, and the size
of each rule definition, are all calculated dynamically and are not dependent on
parameter specifications.

NOTE
The CMEM Rule Definition facility does not support members that have been compressed
using the ISPF PACK option.

Accessing the CMEM Rule Facility

The CMEM Rule Definition facility contains the following screens:

Table 86 Rule Definition Facility Screens

Screen Definition
CMEM Rule entry Allows specification of parameters that determine which screen is
panel displayed.
Table List screen Displays the list of tables (members) in the specified CMEM rule
library.
Rule List screen Displays the list of rules in the selected table.
Rule Definition screen Displays the parameters of the selected CMEM rule. This is the main
screen of the facility.

To enter the CMEM Rule facility, type C in the OPTION field in the IOA Primary
Option menu and press Enter. The CMEM Rule entry panel is displayed.

Creating CMEM Rule Tables

CMEM rule tables can be created in one of the following ways:

■ By typing the new table name in the entry panel and pressing Enter. The name of a
new rule for the new table may also be entered.

Upon using this method to request that a table be created, a skeletal CMEM rule
(that is, one with most fields not filled in) is displayed in the CMEM Rule
Definition screen.

Chapter 2 Online Facilities 257

CMEM Rule Definition Facility

Fill in and save this rule definition. The table is created and the rule is the first and
only rule in the Rule list of the table. As additional rules are created in the table
(described below), they are added to the Rule list.

■ Upon exiting the Rule List screen, if changes have been made to at least one rule,
an Exit Option window is displayed. One option of the window allows creation of
a new table in which the rules are saved.

Creating CMEM Rules

CMEM rules can be created using the following basic methods:

■ A skeletal rule definition can be created by typing the name of a new rule in the
entry panel. The table specified in the entry panel may be either a new or an
existing table. In this case, the fields in the rule definition are empty.

■ A basic copy of an existing rule can be created using the INSERT option in the Rule
List screen. In this case, most fields of the new rule definition contain the same
values as the fields in the copied rule. The INSERT option is described in “Options
of the Rule List Screen” on page 264.

Performing Operations on CMEM Tables and Rules

Many operations can be performed on CMEM rule tables and on the rules contained
within them. These operations are performed through commands and options in the
various screens of the CMEM Rule Definition facility.

Below is a brief summary of some of the major operations possible in the facility.
Options and commands that have not yet been explained are explained in detail
following the summary.

Accessing (Editing or Browsing) a Table and its Rules

A table (actually, the rules in the table) can be browsed or edited.

When browsed, the table cannot be modified or updated. When the table is edited,
new rules may be added and existing rules may be modified or deleted.

Browsing, however, has advantages:

■ Access and exit are quicker than in editing.

■ A rule list and/or rules that are in use by another user can be viewed.
■ Access for browsing might be granted, even though access for editing might be
denied due to site security requirements.

258 Control-M for z/OS User Guide

 Entry Panel

To browse a table, and its rule list and the rules it contains, use the BROWSE option in
the Table List screen.

Typing the table name in the entry panel or using the SELECT option in the Table List
screen provides edit access.

Depending on user profile definitions, if the table requested for editing is in use,
either access is granted in Browse mode or access is not granted.

Deleting a Table or a Rule

Unneeded rules can be deleted by the DELETE option in the Rule List screen,
described in “Options of the Rule List Screen” on page 264. Unneeded tables can be
deleted by the DELETE option in the Table List screen, described in “Deleting Tables”
on page 164.

Ordering Rule Tables

Rule tables are ordered by option ORDER or FORCE in the Table List screen,
discussed in “Ordering CMEM Rule Tables” on page 274.

Saving Modifications

All changes made to a table and its rules are kept in memory until the table is exited.
Upon exiting the table, you may choose to save or cancel the changes, as described in
“Exiting the CMEM Rule Definition Facility” on page 271.

Entry Panel
The entry panel is displayed upon entering the CMEM Rule Definition facility
(option C on the IOA Primary Option menu).

Chapter 2 Online Facilities 259

Entry Panel

Figure 68 CMEM Rule Definition Facility – Entry Panel

----------------- CMEM RULE DEFINITION FACILITY - ENTRY PANEL --------------(C)
COMMAND ===>

SPECIFY LIBRARY, TABLE NAME, RULE NAME

LIBRARY ===> CTM.PROD.RULES

TABLE ===> (Blank for table selection list)
RULE ===> (Blank for rule selection list)

USE THE COMMAND SHPF TO SEE PFK ASSIGNMENT 22.35.51

Fields of the Entry Panel

Fill in the following fields and press Enter.

Table 87 Fields of the Entry Panel

Field Description
LIBRARY Name of the desired CMEM rule library. Mandatory.

If this field is specified without filling in the TABLE field, the list of
tables in the specified library is displayed in the Table List screen.
TABLE Name of the desired rule table. Optional.

If this field is specified without filling in the RULE field, the list of
rules in the specified member is displayed in the Rule List screen. If a
new table name is specified, a new rule definition is displayed in the
Rule Definition screen.
RULE Name of the desired rule. Optional.

This field can be specified only if a TABLE value is entered. If

specified, the requested rule is displayed in the Rule Definition
screen.

260 Control-M for z/OS User Guide

 Table List Screen

NOTE
If you use the selection list fields, their values are not erased until you exit the entry panel by
pressing END (PF03/PF15).

Table List Screen

The Table List screen displays a list of rule tables (members) in the specified library.
This screen can be entered directly from the entry panel or upon exiting the Rule List
screen.

By default, only table names are listed in the screen. However, if the default has been
modified at time of installation, statistical information is displayed for each table
name (as shown below).

Figure 69 CMEM Definition Facility Table List Screen

TABLES OF LIBRARY CTM.PROD.RULES -------------(C)
COMMAND ===> SCROLL===> CRSR
OPT NAME ----------- VV.MM CREATED CHANGED SIZE INIT MOD ID
PRDJACCT 01.06 01/02/07 01/06/06 14:29 56 56 0 M06
PRDJPYRL 01.03 01/02/07 01/06/06 10:11 56 56 0 M86B
PRDJFNC 01.01 01/02/07 01/06/06 13:06 6 6 0 N04A
PRDJMRKT 01.01 01/02/07 01/06/06 15:08 5 5 0 N04B
BACKUP 01.01 01/02/07 01/06/06 14:35 61 56 0 M06
TESTJ 01.06 01/02/07 01/06/06 11:16 6 56 0 M06
======= >>>>>>>>>>>>>>>> NO MORE TABLES IN THIS LIBRARY <<<<<<<<<<<<<< =======

OPTIONS: S SELECT O ORDER F FORCE B BROWSE D DELETE 12.11.50

To return to the entry panel, press the END key (PF03/PF15).

Options of the Table List Screen

To request one of the following options, type the option in the OPT field to the left of
the table names and press Enter.

Chapter 2 Online Facilities 261

Rule List Screen

Table 88 Options of the Table List Screen

Option Description
S (SELECT) Display the list of rules in the table for any purpose, including
editing or modification. Only one table can be selected at a time.
O (ORDER) Order all rules in the table, as described in “Ordering CMEM Rule
Tables” on page 274. Multiple tables can be ordered.
B (BROWSE) Display a list of rules in the table for browsing. Only one table at a
time can be browsed.
F (FORCE) Order all rules in the table. Because CMEM rules have no basic
scheduling parameters, this option works like the Order option.
Multiple tables can be forced.
D (DELETE) Delete the table (member) from the library. This is discussed in
“Deleting Tables” on page 164. Multiple tables can be deleted.

NOTE
Users whose access to options has been limited by the INCONTROL administrator can only
access the Browse option.

Rule List Screen

The Rule List screen displays the list of CMEM rules in the specified CMEM table.
The following fields are listed for each rule:

Table 89 Fields of the Rule List Screen

Field Description
OPT Select, Delete and Insert options can be entered in this field, as
described in “Options of the Rule List Screen” on page 264.
TYPE The event type of the rule. The following event type codes exist:

■ R – Job arrival
■ X – Job end
■ D – Data set
■ Z – Step
DESCRIPTION The description of the rule. This appears in the DESCRIPTION field
of the rule definition.

This screen can be entered directly from the entry panel or the Table List screen, or
upon exiting from the Rule Definition screen.

262 Control-M for z/OS User Guide

 Rule List Screen

NOTE
If the S (Select) option was typed in the Table List screen for a table that is currently in use
(“selected”) by another user, either the Rule List screen is not displayed and the Table List
screen remains displayed (the default), or the Rule List screen is displayed in Browse mode (if
a user profile definition overrides the default). In either case, an appropriate message is
displayed.

Figure 70 CMEM Rule Definition Rule List Screen

RULES OF LIBRARY: CTM.PROD.RULES TABLE: TESTJ
COMMAND ===> SCROLL===> CRSR
OPT RULE TYP -------------- DESCRIPTION --------------------------------
JOBNAM1 R ON JOB JOBNAM1 ARRIVAL FORCEJOB
JOBN*2 R ON JOB JOBN*2 ARRIVAL ADDCOND
JOBNAM3 X ON JOB JOBNAM3 JOBEND FORCEJOB
JOBN*4 X ON JOB JOBN*4 JOBEND DELCOND
JOBDST* D ON JOB JOBDST* DATASET * DELETE FORCEJOB
MERGE D ON JOB MERGE DATASET * NCT 2
CICSP D ON JOB CICSP DATASET * CATLG ADDCOND
PROD* D ON JOB PROD* DATASET * NCT 2
======= >>>>>>>>>>>>>>>>> NO MORE RULES IN THIS TABLE <<<<<<<<<<<<<<<<< =======

OPTIONS: S SELECT D DELETE I INSERT C COPY 12.22.27

Commands of the Rule List Screen

The following commands may be typed in the COMMAND field of the Rule List
screen.

Table 90 Commands of the Rule List Screen (part 1 of 2)

Command Description
DESC The DESC command displays the rule description next to the rule
name. The description is taken from the DESCRIPTION field in the
rule.

Chapter 2 Online Facilities 263

Rule List Screen

Table 90 Commands of the Rule List Screen (part 2 of 2)

Command Description
STAT The STAT command displays the following ISPF-like statistical
information about the rule next to the rule name: version and
modification numbers, creation date, last modification date, and user
ID.
SORT Sorts the list of rules in the Rule List screen according to specified
criteria. Valid values are:

■ R (rule) - Sorted according to rule name

■ T (type) - Sorted according to rule type

Options of the Rule List Screen

To request one of the following options, type the option in the OPT field to the left of
the rule names and press Enter.

NOTE
If the Rule List screen is displayed in Browse mode, options D (Delete) and I (Insert) are not
available.

Table 91 Options of the Rule List Screen

Option Description
S (SELECT) Display the Rule Definition screen with details of the specific rule.
Only one rule can be selected at a time.

If the Rule List screen is not displayed in Browse mode, the rule
definition may be edited and updated. If the Rule Definition screen
is displayed in Browse mode, the rule definition may only be
browsed; it cannot be modified.
D (DELETE) Delete a rule from the Rule list (member). Multiple rules can be
selected for deletion.
I (INSERT) Insert a new rule in the list. The Rule Definition screen appears, with
the same details of the rule marked “I”. Only one rule may be
inserted at a time.
C (COPY) Copy the rule to another table. Multiple rules can be selected. For
more information, see “Copying Rules to Another Table” on
page 276.

264 Control-M for z/OS User Guide

 Rule Definition Screen – Defining Rules

Rule Definition Screen – Defining Rules

The Rule Definition screen is used to define, display and modify parameters of a
specific CMEM rule.

This screen can be entered directly from the entry panel or from the Rule List screen.
Update of parameters is not permitted in Browse mode.

The rule definition may take up more than one screen.

To delete a parameter on the screen, simply erase it by the EOF key or blank it out. If
additional action is required, Control-M issues appropriate instructions.

Figure 71 Rule Definition Screen - Defining Rules

RL: BKP* LIB CMEM.PROD.RULES TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
ON JOBARRIV = BKP* JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN TABLE BACKUP MODE PROD RUNTSEC
THRESHOLD
DESCRIPTION MONITOR STARTUP OF BACKUP JOBS
DESCRIPTION
===========================================================================
/* TELL CONTROL-M TO MONITOR THIS JOB
/*
DO FORCEJOB = TABLE BACKUP JOB DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
/*
DO
=============================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

Rule parameters are divided into the following basic groups:

■ Event Selection parameters

■ General parameters
■ Action parameters

A brief explanation of available parameters follows. For a detailed explanation of

each rule parameter, see Chapter 4, “CONTROL-M Event Manager (CMEM).”

Chapter 2 Online Facilities 265

Rule Definition Screen – Defining Rules

NOTE
Parameters marked with the M symbol may have many occurrences. Whenever you fill in the
last occurrence of the parameter on the screen, Control-M adds a new empty occurrence of the
parameter that can be filled in. The only limit to the number of occurrences is the region size
available for the application.

Event Selection Parameters

Event Selection parameters specify selection criteria under which actions are
performed by CMEM.

Figure 72 CMEM Rule Definition Event Selection Parameters - Example

ON JOBARRIV = A* JTYPE J SMFID SYSTEM And/Or/Not O
ON JOBARRIV = C* JTYPE J And/Or/Not
OWNER ADMIN TABLE CICS MODE RUNTSEC

ON JOBEND = CICSPROD JTYPE SMFID SYSTEM And/Or/Not

OWNER ADMIN TABLE CICS MODE PROD RUNTSEC

ON DSNEVENT = PRD0001 JTYPE SMFID SYSTEM

DSN PROD.* DISP NCT2
PROCSTEP PGMSTEP STEPRC And/Or/Not
OWNER ADMIN TABLE PRODJOBS MODE RUNTSEC

ON STEP = PRD0001 JTYPE SMFID SYSTEM

PROCSTEP STEP2 PGMSTEP STEPRC OK And/Or/Not
OWNER CTMCTLM TABLE MODE PROD RUNTSEC NONE

Table 92 CMEM Rule Definition Event Selection Parameter

Parameter Description
ON statementM Conditions under which the rule is to be performed. Subparameters
may be displayed.

Valid ON statement values are:

■ ON JOBARRIV – Job name (or mask) of a job or started task that

arrived on the JES spool from any source.

■ ON JOBEND – Job name (or mask) of a job or started task that

terminated.

■ ON DSNEVENT – Name (or mask) of a job or started task or TSO

user to be monitored for data set events (including NOT
CATLGD 2 events).

■ ON STEP – Name (or mask) of a job procedure step (and

optionally, program step) that terminated, and its desired return
code.
AND/OR/NOTM Conjunctional subparameter that enables linking of ON statements.

266 Control-M for z/OS User Guide

 Rule Definition Screen – Defining Rules

General Parameters
The following are General parameters that apply to the rule.

Figure 73 General Parameters

ON JOBARRIV = BKP* JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN TABLE BACKUP MODE PROD RUNTSEC
THRESHOLD
DESCRIPTION MONITOR STARTUP OF BACKUP JOBS
DESCRIPTION

Table 93 CMEM Rule Definition General Parameters

Parameter Description
OWNER ID of user requesting CMEM services.
GROUP Logical name of a group of rules.
MODE CMEM rule operation mode.
RUNTSEC Type of runtime security checks to be performed by the rule.
DESCRIPTION Free text description of the rule definition that appears in the Rule
List screen.

Action Parameters
Action parameters specify actions to be performed by CMEM.

Table 94 CMEM Rule Definition Action Parameters

DO statementM Actions to be performed when the rule is triggered. They are
performed sequentially. Valid DO statements are illustrated below:

DO COND = FILE-RECEIVED ODAT +

DO COND Add or delete a prerequisite condition.

DO FORCEJOB = TABLE BACKUP JOB DATE ODAT

LIBRARY CTM.PROD.SCHEDULE
DO

DO FORCEJOB Force one or more jobs under Control-M.

DO STOPJOB
DO

Chapter 2 Online Facilities 267

Rule Definition Screen – Defining Rules

DO STOPJOB Stop execution of the remaining steps of the job that triggered the
rule.

The following DO statements are available in CMEM only if Control-O is active. For
more information on the subparameters of the DO parameter which appear in these
illustrations, see the Control-O User Guide.

DO SHOUT = TO TSO-DBA URGENCY U SYSTEM

MESSAGE DB2 MASTER ENDED - PLEASE CHECK!
DO

DO SHOUT Issue a message to a console, TSO user, ROSCOE user, IOA Log or
the system administrator using the Control-O Shout facility.

DO RULE = PROCFILE %%$DSN OWNER PROD

TABLE PRODRULE LIBRARY CTO.PROD.RULES
SYSTEM SHARELOC NO TIMEOUT NO
DO

DO RULE Invoke a Control-O rule from within the current rule.

Commands of the Rule Definition Screen

The following commands may be typed in the COMMAND field of the Rule
Definition screen.

268 Control-M for z/OS User Guide

 Entering Comments

Table 95 Commands of the Rule Definition Screen

Command Description
CAPS By default, all entries of lowercase characters are converted and
saved as uppercase. In CMEM rules, certain fields, such as the string
entered in the ON SHOUT MS field, can be enabled to accept and
save lowercase characters, by using the CAPS OFF command, as
described below. Valid formats are:

■ CAPS OFF – Enables certain user entries to be saved and

displayed in lowercase characters.

■ CAPS ON – Forces all user entries to be displayed in uppercase

characters, regardless of the case in which they were entered.
Default.

■ CAPS – Indicates whether CAPS ON or CAPS OFF mode is

active.

Note: JCL jobs used by Control-M do not support lowercase

characters. Using lowercase characters to define IOA variables is not
recommended if those variables are shared by Control-M through
IOAVAR.
EDIT Alternately enters and exits the Edit environment of the Rule
Definition screen. The Edit environment provides ISPF-like line
editing commands to the Rule Definition screen. For more
information, see Appendix D, “Editing CMEM Rule Definitions in
the Edit Environment.”
SHPF Shows the current PFKey assignments.

Commands used to exit the Rule Definition screen are described in “Exiting the Rule
Definition Screen” on page 271.

Entering Comments
Comments are free text descriptions of rule definition parameters that are stored in a
rule definition. It is recommended that comments be inserted within rule definitions
for clarification and documentation purposes. Comment lines begin with the symbols
/* , and are not processed during rule execution.

Use one of the following methods to insert comment lines:

■ Decide where you want the comment to be inserted. Position the cursor on the
preceding line, and press CMNT (PF04/PF16) to open the comment line. If you need
more than one line, press Enter at the end of each line.

Chapter 2 Online Facilities 269

Editing CMEM Rule Definitions in the Edit Environment

■ Type CMNT in the COMMAND field and move the cursor to the line before which
the comment is to be inserted. Press Enter.

■ To insert comments between DO statements an additional method is available.

Type /* in an empty DO statement and press Enter.

Comment usage is illustrated in the following Rule Definition screen:

Figure 74 Rule Definition Screen Comment Usage

RL: BKP* LIB CMEM.PROD.RULES TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
ON JOBARRIV = BKP* JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN TABLE BACKUP MODE PROD RUNTSEC
THRESHOLD
DESCRIPTION MONITOR STARTUP OF BACKUP JOBS
DESCRIPTION
==========================================================================
/* TELL CONTROL-M TO MONITOR THIS JOB
/*
DO FORCEJOB = TABLE BACKUP JOB DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
/*m
DO
===========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF, 21.00.36

An unlimited number of comment lines may be entered within a rule definition.

Editing CMEM Rule Definitions in the Edit Environment

Rule Definition parameters can be edited (moved, copied, deleted, repeated) using
CMEM Line Editing commands, similar to standard ISPF line commands, from
within the CMEM Edit environment.

The Edit environment in a Rule Definition screen is accessed by typing EDIT in the
COMMAND field and pressing Enter.

Details and examples of the editing CMEM rule definitions in the Edit environment
are provided in Appendix D, “Editing CMEM Rule Definitions in the Edit
Environment.”

270 Control-M for z/OS User Guide

 Exiting the CMEM Rule Definition Facility

Exiting the CMEM Rule Definition Facility

When exiting the CMEM Rule Definition facility, screens are exited in the following
sequence:

■ Rule Definition screen

■ Rule List screen
■ Table List screen

NOTE
If the Table List screen was bypassed when you entered the CMEM Rule Definition facility
(that is, if you entered a TABLE value in the entry panel), the Table List screen is not
displayed upon exiting the Rule List screen; instead, the entry panel is displayed.

■ Entry panel

The commands and options available when exiting screens depend on the screen
being exited and on whether changes have been made. If changes have been made,
the selected exit options and commands determine whether the changes are saved.
Exit options and commands are discussed below on a screen-by-screen basis.

Exiting the Rule Definition Screen

Use any of the following commands, or press the corresponding PFKey, to exit the
Rule Definition screen:

Table 96 Commands for Exiting the Rule Definition Screen

Command Description
CANCEL Cancel the changes made to the rule and return to the Rule List
screen.
END (PF03/PF15) Keep changes to the rule in memory and exit to the Rule List screen.

NOTE
The END command retains changes to the rule in memory. To permanently save the changes
to disk, you must request that the changes be saved when you exit the Rule List screen.

Exiting the Rule List Screen

Use the END command (PF03/PF15) to exit the Rule List screen. If changes made to at
least one rule have been kept in memory (as described in the preceding section)
and/or if any changes have been made to the Rule List screen, the Exit Option
window is displayed.

Chapter 2 Online Facilities 271

Exiting the CMEM Rule Definition Facility

Figure 75 Rule List Screen Exit Option Window

RULES OF LIBRARY: CTM.PROD.RULES TABLE: TESTJ
COMMAN +———————————————————————————————————————————————————————————+ ===> CRSR
OPT R | PLEASE SELECT EXIT OPTION | --------
J | |
J | SAVE CREATE |
J | |
J | LIBRARY CTM.PROD.RULES |
J | TABLE BACKUP | FORCEJOB
M | |
C +———————————————————————————————————————————————————————————+ ADDCOND
======= >>>>>>>>>>>>>>>>> NO MORE RULES IN THIS TABLE <<<<<<<<<<<<<<<<< =======

OPTIONS: S SELECT D DELETE I INSERT C COPY 13.00.12

Fill in the Exit Option window as follows:

The LIBRARY and TABLE fields indicate the library and table in which the rule
definitions are saved. The specified values can be modified (for example, to save the
rule definitions in a new or different table).

■ To save all changes currently in memory and exit the Rule List screen, type Y (Yes)
after the word SAVE or CREATE:

— Type Y after SAVE if a table with the same name already exists in the specified
library.
— Type Y after CREATE if a table with the same name does not exist in the
specified library.

NOTE
If you create a new table, the table name does not appear in the Table List screen upon
exiting the Rule List screen; it first appears when you reenter the Table List screen from the
entry panel.

■ To cancel changes currently in memory and exit the Rule List screen, type N (No)
after the word SAVE or CREATE.

■ To close the Exit Option window and remain in the Rule List screen (with the
changes remaining in memory), press the RESET key (PF04/PF16).

272 Control-M for z/OS User Guide

 Deleting Tables

Exiting the Table List Screen

Press the END key (PF03/PF15) to exit the Table List screen.

Exiting the Entry Panel

Press the END key (PF03/PF15) to exit the entry panel.

Deleting Tables
Tables can be deleted from the Table List screen.

To delete tables, type option D (Delete) by the table names in the Table List screen
and press Enter.

The confirmation window illustrated below is displayed, in sequence, for each table
selected for deletion.

Figure 76 Rule Definition Facility Delete Table Confirmation Window

TABLES OF LIBRARY CTMP.V600TST.RULES -------------(C)
COMMAND ===> SCROLL===> CRSR
OPT NAME -------------- VV.MM CREATED CHANGED SIZE INIT MOD ID
PRDJACCT 01.06 01/02/14 01/06/06 14:29 56 56 0 M06
PRDJPYRL 01.03 01/02/14 01/06/06 10:11 56 56 0 M86B
PRDJFNC +--------------------------+ 6 6 0 N04A
PRDJMRKT | CONFIRM DELETE OPTION | 5 5 0 N04B
D BACKUP <-----------| (Y/N) | 61 56 0 M06
TESTJ +--------------------------+ 6 56 0 M06
======= >>>>>>>>>>>>>>>> NO MORE TABLES IN THIS LIBRARY <<<<<<<<<<<<<<< =======

OPTIONS: S SELECT O ORDER F FORCE B BROWSE D DELETE 13.05.52

Type Y (Yes) in the window to confirm the delete request.

Type N (No) in the window to cancel the delete request.

A message is written to the IOA Log file for each table deleted.

Chapter 2 Online Facilities 273

Ordering CMEM Rule Tables

NOTE
If PDSMAN is operational at your site, $$$SPACE members are not deleted.

Ordering CMEM Rule Tables

A rule definition that resides in a library is not active until it has been ordered. Rule
tables can be ordered automatically when CMEM is started, as described in the
INCONTROL for z/OS Administrator Guide, or they can be ordered manually.
Regardless of the method used to order them, CMEM rule tables only need to be
ordered once. Once a rule table is ordered, it remains active unless replaced or
deleted by an operator command, or until CMEM is stopped.

When rule definitions are updated or modified, the rule table must be ordered again.
The newly ordered version of the rule table automatically replaces the previous
version of the rule table. Rule tables can be deleted from the Active environment by
an operator command. For details, see Chapter 6, “Selected Implementation Issues.”

To order a rule table, type O (Order) or F (Force) in the OPT field to the left of the
table name in the Table List screen. Because there are no basic scheduling criteria in
CMEM rules, the Order and Force options work the same way. More than one rule
table can be ordered at the same time.

When you order rule tables, the following default confirmation window is opened. If
the default has been modified in the user profile, a double confirmation window is
opened. For more information on the double confirmation window, see “The Double
Confirmation Window” on page 161.

274 Control-M for z/OS User Guide

 Ordering CMEM Rule Tables

Figure 77 Order and Force Confirmation Window

TABLES OF LIBRARY CTM.PROD.RULES -------------(C)
COMMAND ===> SCROLL===> CRSR
OPT NAME -------------- VV.MM CREATED CHANGED SIZE INIT MOD ID
PRDJACCT 01.06 01/02/14 01/06/06 14:29 56 56 0 M06
PRDJPYRL +-------------------------------+ 56 0 M86B
PRDJFNC | CONFIRM ODATE 060601 | 6 0 N04A
O PRDJMRKT <-----------| ASK FOR EACH ONE Y | 5 0 N04B
O BACKUP +-------------------------------+ 56 0 M06
TESTJ 01.06 01/06/06 01/06/06 11:16 6 56 0 M06
======= >>>>>>>>>>>>>>>> NO MORE TABLES IN THIS LIBRARY <<<<<<<<<<<<<<< =======

OPTIONS: S SELECT O ORDER F FORCE B BROWSE D DELETE 12.11.50

Table 97 Options for Ordering Rule Tables

Option Description
CONFIRM Whether to process the order request. Valid values are:

■ Y (Yes) – Process the request

■ N (No) – Cancel the request
ODATE Current date (in mmddyy, ddmmyy or yymmdd format,
depending on the site standard).
ASK FOR EACH ONE This line is displayed only if more than one table order is
requested. It determines whether individual confirmation is
required for each order request. Valid values are:

■ Y (Yes) – Individual confirmation is required for each order

request. The selected CONFIRM value (Y or N) applies only to
the current order or request.

■ N (No) – Individual confirmation is not required for each order

request. The selected CONFIRM operation is applied to all
order requests. If CONFIRM is Y, all order requests are
processed; if CONFIRM is N, no order requests are processed.

When you press Enter, the results of the order request are displayed in a message at
the top of the screen. If more than one message is required, the original list screen
disappears and the messages appear in a new screen. If the messages span more than
one screen, you may scroll up and down on the messages list. Press the END key
(PF03/PF15) to return to the Table List screen.

Chapter 2 Online Facilities 275

Copying Rules to Another Table

Wish WO0945
As a result of the Order or Force request an MVS MODIFY command is sent to the
CMEM monitor. Some installations may protect the MVS command. If the user is not
authorized to issue an MVS MODIFY command the Order or Force fails.

After applying this wish, by specifying WO0943 APPLY=YES in the IOADFLTL

member, the MODIFY command will be executed under the CMEM monitor.
Therefore, authority to issue a MVS MODIFY command is required only for the
CMEM or CMEM monitor USERID.

Wish WO0945 also introduces

■ the following AutoEdit System variables that return Wish WO0943 with a status of
Y or N

— %%$WO0943
— %%$MODIFY_O_F

■ the following CMEM MODIFY command

F controlo,WISH=WO0943=xxxxx

where xxxxxx - ENABLE or DISABLE

This command allows the user to enable or disable optional Wish WO0943 without
stopping Control-O.

NOTE
This is a temporary change to the Wish only. In order to make the change permanent, Wish
WO0943 must set to the required value, YES or NO, in member IOADFLTL.

Copying Rules to Another Table

To copy one or more rules from the current table to another table, type C (Copy) in
the OPT column of the Rule List screen, next to the rule names, and press Enter. The
following window is displayed:

276 Control-M for z/OS User Guide

 Copying Rules to Another Table

Figure 78 Window for Copying Rules to Another Table

RULES OF LIBRARY: CTM.PROD.RULES TABLE: TESTJ
COMMAND ===> SCROLL===> CRSR
OPT RULE TYP -------------- DESCRIPTION --------------------------------
JOBNAM1 R ON JOB JOBNAM1 ARRIVAL FORCEJOB
JOBN*2 R ON JOB JOBN*2 ARRIVAL ADDCOND
JOBNAM3 X ON JOB JOBNAM3 JOBEND FORCEJOB
C JOBN*4 X ON JOB JOBN*4 JOBEND DELCOND
JOBDST* +-----------------------------------------------------------+
MERGE | |
CICSP | SPECIFY DESTINATION LIBRARY AND TABLE |
PROD* | |
======= >>>>>>> | LIBRARY : CTM.PROD.RULES |
| TABLE : |
| RULE : JOBN*4 |
| |
| PRESS END/RESET TO CANCEL ENTER TO PERFORM THE COPY |
+-----------------------------------------------------------+

OPTIONS: S SELECT D DELETE I INSERT C COPY 12.22.27

The window contains the fields shown in the following table. Some fields contain
default values that can be modified.

Table 98 Fields in the Window for Copying Rules to Another Table

Field Description
LIBRARY Library containing the table into which the rules must be copied.
Must be an existing library. Default is the current library.
TABLE Name of the table into which the rule must be copied.
Notes: A rule can only be copied to another table. It cannot be copied
to its own table (even if the rule is renamed).

If the selected table does not exist, the table is created when the
request is performed.
RULE Name of the rule to be copied. If multiple rules are selected, the
window initially display with the first selected rule. As each request
is performed or canceled, the next requested rule name is displayed.

To perform a request, press Enter.

To cancel a request, press END (PF03/PF15) or RESET (PF04/PF16).

Chapter 2 Online Facilities 277

IOA Variables Database Facility

IOA Variables Database Facility

The IOA Variable Database facility is composed of a series of screens that enable you
to view, create, and modify Global AutoEdit variables in IOAVAR, the IOA Global
Variable database.

As of version 6.0.00, this facility is available to Control-M and/or Control-O users

only, and is available only if CMEM and/or Control-O are installed. Control-O users
can also create and modify other variable databases.

NOTE
If Control-O is installed, the CMEM facility is controlled by the Control-O monitor instead of
the CMEM monitor. In this case, references to the CMEM monitor apply instead to the
Control-O monitor, and operator commands must contain CONTROLO in place of
CTMCMEM.

Certain screens and features of the IOA Variable Database Facility are relevant to Control-O
but not to Control-M. If Control-O is installed, and you are using the IOA Variable Database
Facility with Control-O, refer to the description of the IOA Variable Database facility in the
Control-O User Guide.

Global variables may be defined in variable database IOAVAR. They can be accessed
and updated by all Control-M jobs and/or Control-O rules on that computer. In
addition, if Sysplex support is installed, these variables can be accessed and updated
by all Control-M jobs and Control-O rules across the Sysplex. IOA Global variable
database administration and Sysplex support are described in detail in the
INCONTROL for z/OS Administrator Guide.

NOTE
In addition to using the online IOA Variable Definition facility to define Global variables,
Global variables can be defined or updated through SET VAR and DO SET statements in
Control-M job scheduling definitions, through SET statements in the job’s JCL, and through
SETOGLB statements in a KSL or KOA script. For more information on KeyStroke Language
(KSL) User Guide, refer to the KeyStroke Language (KSL) User Guide.

The IOA Variable Database facility consists of several screens, some of which are
relevant only to the INCONTROL administrator, and some of which are relevant to
all users. The following screens are relevant to all users. Screens relevant only to
administrators are described in the INCONTROL for z/OS Administrator Guide.

Table 99 IOA Variable Database Facility Screens (part 1 of 2)

Screen Description
Variable Database Enables specification of a database name. If no database name is
entry panel entered, the Database List screen is displayed.
Database List screen Displays the list of variable databases.

278 Control-M for z/OS User Guide

 Entry Panel

Table 99 IOA Variable Database Facility Screens (part 2 of 2)

Screen Description
Values of Database Displays the list of variables, and their values, in the selected
screen database.
Variable Zoom screen Displays the complete variable name and the complete variable
value of the selected variable, and enables update of the variable
value.

To enter the Variable Database facility, select option IV in the IOA Primary Option
menu. The IOA Variables Entry Panel is displayed.

Entry Panel
The following entry panel is displayed upon specification of option IV in the IOA
Primary Option menu:

Figure 79 IOA Variable Database Entry Panel

----------------------- IOA Variables - ENTRY PANEL ----------------------(IV)
COMMAND ===>

SPECIFY DATABASE NAME

DATABASE ===> (Blank for Database selection list)

MODE ===> (Blank or ADMIN for Administration mode)

USE THE COMMAND "SHPF" TO SEE PFK ASSIGNMENT 16.21.43

■ To display the list of all variable databases: Press Enter. The Database List screen is
displayed.

■ To display the list of variables in a specific variable database: Type the database
name in the DATABASE field and press Enter. The Values of Database screen for
the specified database is displayed. An asterisk (*) can be used as a mask character
in the DATABASE field of this screen.

Chapter 2 Online Facilities 279

Database List Screen

NOTE
Control-O can have multiple variable databases; Control-M can only use the IOAVAR
database.

■ To enter the IOA Variables Database facility as a regular user: Leave the MODE
field blank. In this case, you will be able to view the variables in the databases, but
you will not be able to perform administration functions.

■ To enter the IOA Variables Database facility with full administrator

functionality: Type ADMIN in the MODE field.

NOTE
The additional functions available in administration mode are described in the INCONTROL
for z/OS Administrator Guide.

Database List Screen

The Database List screen (also called the IOA Variables In Use screen) displays a list
of the variable databases currently defined. This screen can be entered directly from
the entry panel or when returning from the Variable List screen.

NOTE
For a Control-O variable database to be loaded into memory, the database must be listed in
the DAGLBLST DD statement of the CMEM monitor. For more information, see the
description of the IOA Variable Database facility in the INCONTROL for z/OS Administrator
Guide.

280 Control-M for z/OS User Guide

 Values of Database Screen

Figure 80 IOA Variable Database Facility Database List Screen

LIST OF DATABASES ----- IOA VARIABLES IN USE ---------------------------(IV)
COMMAND ===> SCROLL===> CRSR
OPT NAME DESCRIPTION
COSALLMT COSMOS - DEMO - METHODS DATABASE
COSALLPR COSMOS - DEMO - PREREQUISITES DATABASE
COSIMGOB COSMOS - DEMO - SYSIMAGE WORKING DATABASE
IOAVAR IOA GLOBAL VARIABLE DATABASE
PRDALLMT COSMOS - PROD - METHODS DATABASE
PRDALLPR COSMOS - PROD - PREREQUISITES DATABASE
PRDSTCOB COSMOS - PROD - STC WORKING DATABASE
PRDSTCSD COSMOS - PROD - STC SOURCE DATABASE
PRDVTMOB COSMOS - PROD - VTAM WORKING DATABASE
PRDVTMSD COSMOS - PROD - VTAM SOURCE DATABASE
TUTORIAL AUTOEDIT DATABASES - TUTORIAL
XAES1D01 XESXAE - DEMO - S1 - TEMP
XAES1D02 XESXAE - DEMO - S1 - INPUT
XAES1D03 XESXAE - DEMO - S1 - PROT (S1PROT SAME AS INPUT)
XAES1D04 XESXAE - DEMO - S1 - INOUT (S1INOUT SAME AS INPUT)
XAES2D01 XESXAE - DEMO - S2 - TEMP
XAES2D02 XESXAE - DEMO - S2 - INPUT
XAES2D03 XESXAE - DEMO - S2 - PROT (S2PROT SAME AS INPUT)
XAES2D04 XESXAE - DEMO - S2 - INOUT
===== >>>>>>>>>>>>>>>>>>>>>>> NO MORE DATABASES <<<<<<<<<<<<<<<<<<<<<< =====
OPTIONS: V VIEW VARS 08.15.55u

A short description is displayed for each database. You should create a description
when creating a new database.

Options of the Database List Screen

To request an option, type the option in the OPT field to the left of the database name,
and press Enter. The V (VIEW VARS) option is available for all users. This option
displays the variables of the database in the Values of Database screen.

NOTE
Only option V is intended for all users. The remaining options
(I - Insert, U - Update, and S - Select) are intended for INCONTROL administrators only, and
are described in the INCONTROL for z/OS Administrator Guide.

Values of Database Screen

The Values of Database screen can be entered directly from the entry panel or from
the Database List screen.

Each line in the screen represents a variable in the database. Variables and their
values are loaded into memory automatically at Control-M startup.

Chapter 2 Online Facilities 281

Values of Database Screen

Figure 81 IOA Values of Database Screen

VALUES OF DATABASE: IOAVAR (IV.V)
COMMAND ===> SCROLL===> CRSR
ROW VARNAME VALUE

00022889 %%\M\ACCTS\BCKP\PDTAPE_0001_1 045673

00023866 %%\M\ACCTS\BCKP\PDTAPE_0001_2 1045683
00024902 %%\M\ACCTS\BCKP\PDTAPE_0001_3 045677
00025863 %%\M\ACCTS\BCKP\PDTAPE_0001_4 043433
00026943 %%\M\ACCTS\BCKP\PDTAPE_0001_5 045543
00027792 %%\M\ACCTS\BCKP\PDTAPE_0001_6 045556
00028972 %%\M\ACCTS\BCKP\PDTAPE_0001_7 045666
00029831 %%\M\ACCTS\EMPLY\EMP_00123_SCHOOL STATE UNIVERSITY OF NEW YORK A
00030765 %%\M\OPER\KPL\SPACE_TYPE_5 TRK
00031985 %%\M\SYS\DBLG\NAME_OF_COMPUTER_1 A
00032972 %%\M\SYS\DBLG\NAME_OF_COMPUTER_2 D
00033769 %%\M\SYS\DBLG\NAME_OF_COMPUTER_3 K
00034919 %%\M\SYS\DBLG\NAME_OF_COMPUTER_4 W
00035955 %%\M\OPER\TBLBKP\GENERATION_NUMBER_A 001
00036932 %%\M\OPER\TBLBKP\GENERATION_NUMBER_B 001
00037778 %%\M\OPER\TBLBKP\GENERATION_NUMBER_C 003
00038808 %%\M\OPER\TBLBKP\GENERATION_NUMBER_D 002
======== >>>>>>>>>>>>>>> NO MORE ROWS FOR THIS DATABASE <<<<<<<<<<<<<< ========

OPTIONS: Z ZOOM I INSERT D DELETE R REPEAT 09.19.41

The Values of Database screen displays the following information about the variables
in the IOAVAR database:

Table 100 Fields of the IOA Values of Database Screen (part 1 of 2)

Field Description
ROW Each variable is assigned its own row in the database. This column
displays the row number of the variable.

282 Control-M for z/OS User Guide

 Values of Database Screen

Table 100 Fields of the IOA Values of Database Screen (part 2 of 2)

Field Description
VARNAME The variable path and name, with the following format:

%%\M\app_name\table_name\job_name\var_name

where:

■ %% – Indicates that the string is a variable. Constant.

■ M – Indicates that the string is a Control-M variable. Constant.
Mandatory.
■ app_name – The Control-M application where var_name resides.
Optional.
■ table_name – The Control-M table within app_name where
var_name resides. Optional.
■ job_name – The Control-M job within table_name where var_name
resides. Optional.
■ var_name – The variable name. Mandatory.

Up to 30 characters of the VARNAME string are displayed. If the

VARNAME string is longer, the full variable path and name can be
viewed in the Variable Zoom screen, which is described in “Variable
Zoom Screen” on page 285.
Note: All levels in the path within the VARNAME string are
separated by a \ (backslash).
VALUE Value of the variable. Up to thirty characters of the value are
displayed. If the value is longer, the full value can be viewed in the
Variable Zoom screen, which is described in “Variable Zoom Screen”
on page 285.

Use the scrolling PFKeys to scroll the variable database LEFT (PF10/PF22) and RIGHT
(PF11/PF23).

Options of the Values of Database Screen

To request one of the following options, type the option in the first column of the row
number to the left of the variable name and press Enter.

Table 101 Options of the Values of Database Screen (part 1 of 2)

Option Description
Z (ZOOM) Display the full variable and value of the selected row (variable) in
the Variable Zoom screen. The displayed variables may be edited in
this screen, as well. For more information, see “Variable Zoom
Screen” on page 285.
I (INSERT) Insert a new row in the variable database. For more information, see
“Adding a Row (Variable)” on page 284.

Chapter 2 Online Facilities 283

Values of Database Screen

Table 101 Options of the Values of Database Screen (part 2 of 2)

Option Description
D (DELETE) Delete the selected row (variable).
R (REPEAT) Insert a new row that is identical to the one for which this option is
selected. For more information, see “Adding a Row (Variable)” on
page 284

Adding a Row (Variable)

A row (variable) can be added to the database using either option I or option R:

■ Option I (Insert)

This option is useful for defining a variable that is not similar to the one it follows.
When option I is typed next to a variable, a row is immediately inserted below the
selected row, and a row value is assigned, as explained in “Row Numbering” on
page 284. However, the VARNAME and VALUE fields are blank.

■ Option R (Repeat)

This option is useful for defining a variable that is similar to the one it follows.
When option R is typed next to a variable, a row is immediately inserted below the
selected row, and a row value is assigned, as explained in “Row Numbering” on
page 284. The new row contains the same VARNAME and VALUE as the selected
row.

Using either method, the new row must be edited:

■ If Option I was entered, a VARNAME and VALUE must be added to the new row.

■ If Option R was entered, the repeated VARNAME must be changed because each
variable in the database must be unique. The VALUE may also be changed if
desired.

The VARNAME and VALUE in the new row can only be edited in the Variable Zoom
screen, described below.

Row Numbering
Row numbers in a variable database are initially incremented by 1000.

■ When a new row is inserted (by option I or R), it is assigned an intermediate

number incremented by 100.

■ Rows inserted between row numbers with a hundreds value are assigned numbers
incremented by ten.

284 Control-M for z/OS User Guide

 Variable Zoom Screen

■ Rows inserted between row numbers with a tens value are assigned numbers
incremented by one.

For example, a row inserted immediately after row 2000 is assigned a number of 2100.

A maximum of 999 rows may be inserted between two original rows in a variable
database.

Row numbers can be refreshed (that is, assigned new numbers incremented by 1000)
in the following way:

1. Unload the IOA Variable Database Variables file using job IOAVARUL in the IOA
JCL library. This job invokes the IOADUL utility.

2. Reload the file using job IOAVARLD in the IOA JCL library. This job runs the
IOADLD utility with the RENUM parameter specified.

For more information about the IOADUL and IOADLD utilities, see the INCONTROL
for z/OS Utilities Guide.

Variable Zoom Screen

The Variable Zoom screen is used to display the full variable name and path, and the
full variable value. The screen is also used to update the variable name and path, and
its assigned value.

The full name and path of each variable, and the value of each variable, can be up to
140 characters in length. However, only thirty characters each of the variable and its
value can be displayed in the Values of Database screen.

The Variable Zoom screen enables display of the full variable name and path, and its
value. To display the Variable Zoom screen for a row (variable), type option Z
(Zoom) in the first column of the desired row in the Values of Database screen.

The Variable Zoom screen is displayed.

Chapter 2 Online Facilities 285

Variable Zoom Screen

Figure 82 Variable Zoom Screen

VALUES OF DATABASE: IOAVAR ROW: 00029831 < D > (IV.V.Z)
COMMAND ===> SCROLL===> CRSR
O NAME VALUE
VARNAME %%\M\ACCTS\EMPLY\EMP_00123_SCHOOL
VALUE STATE UNIVERSITY OF NEW YORK AT STONY BROOK
======== >>>>>>>>>>>>>>>> NO MORE COLUMNS IN THIS ROW <<<<<<<<<<<<<<<< ========

OPTIONS: A ADDITIONAL INFORMATION 14.31.38

Display Types of the Variable Zoom Screen

The following predefined display types are available for the Variable Zoom screen.

Table 102 Display Types of the Variable Zoom Screen

Type Description
D (Default display Includes the first 64 characters of both the variable name and path,
type) and the variable value for the selected database row.

An additional line containing the remainder of the variable name

and path (up to 76 characters), and an additional line containing the
remainder of the variable value (up to 76 characters) can be
displayed by option A (Additional Information), which is described
in Table 103.
B (Blank Line display This display type displays the second line for all variables and
type) values, regardless of whether the line contains additional
information.

Changing Display Types

While in the Variable Zoom screen, the display type can be changed using the
DISPLAY command. Format of the command is:

DISPLAY x

286 Control-M for z/OS User Guide

 Variable Zoom Screen

where x is the identifying letter for the desired type.

DISPLAY can be abbreviated to DI.

Example

DI B

displays the Blank Line display type

Uppercasing and lowercasing of variables’ values

While in the Variable Zoom Screen, uppercase or lowercase mode can be set using the
CAPS command. Format of the command is:

CAPS [{ON | OFF}]

In this command:

■ CAPS ON – Forces all user entries to be saved and displayed in uppercase

characters, regardless of the case in which they were entered. Default.

■ CAPS OFF – Enables certain user entries to be saved and displayed in lowercase
characters.

■ CAPS – Indicates whether CAPS ON or CAPS OFF mode is active.

NOTE
Name of variables do not support lowercase characters.

Options of the Variable Zoom Screen

The following option is available in the Default display type of the Variable Zoom
screen:

Table 103 Options of the Variable Zoom Screen

Option Description
A (Additional Display a second line for the selected variable. This option can be
Information) entered for the VARNAME and/or the VALUE lines. If used, it
displays the second line containing the remainder (up to 76
characters) of the value.

Chapter 2 Online Facilities 287

Condition and Resource Handling Facility

Exiting the Variable Zoom Screen

■ To exit the Variable Zoom screen and save the changes, press END (PF03/PF15).

■ To exit the Variable Zoom screen without implementing the changes, press RESET
(PF04/PF16), or type CANCEL in the COMMAND line and press Enter.

Changes made to the Variable database through the online Variable Database facility
are not available to Control-M or Control-O until the modified database is reloaded
into memory by the appropriate operator command
(F CTMCMEM,LOADGLOBAL=IOAVAR), as described in the INCONTROL for z/OS
Administrator Guide.

However, changes made to the Variable database through DO SET and SET VAR
statements in Control-M, and SET statements in the JCL, are kept in memory. The
Variable database file is automatically updated during the next internal Control-M
interval cycle (or when the Control-O or CMEM monitor is stopped.)

Condition and Resource Handling Facility

Options 4 and 7 in the IOA Primary Option menu are directly related to the handling
of IOA conditions and Control-M resources. The screens displayed by these options
are discussed on the following pages.

IOA Conditions/Resources Screen

The IOA Conditions/Resources screen is accessed through Option 4 of the IOA
Primary Option menu. It displays information from the IOA Conditions file, which
contains the list of all existing prerequisite conditions, and the Control-M Resources
file, which contains the list of Quantitative resources and Control resources. The IOA
Conditions/Resources screen enables you to

■ view IOA prerequisite conditions

■ view Control-M Quantitative resources
■ add or delete prerequisite conditions or resources or both
■ change the available quantity of Control-M Quantitative resources

For a description of prerequisite conditions, see “Prerequisite Conditions” on page 72

288 Control-M for z/OS User Guide

 IOA Conditions/Resources Screen

NOTE
Prior to version 6.0.00 a single file, the IOA Conditions/Resources File, contained all IOA
conditions and all Control and Quantitative resources. As of version 6.0.00, the IOA
Conditions/Resources File has been replaced by two files:

■ IOA Conditions file - contains all IOA conditions

■ Control-M Resources file - contains all Control and Quantitative resources

To enter the IOA Conditions/Resources screen, select Option 4 on the IOA Primary
Option menu.

Figure 83 IOA Conditions/Resources Screen

-------------------------- IOA CONDITIONS/RESOURCES ------------------------(4)
COMMAND ===> SCROLL ===> CRSR
PREFIX ===> COND Y CONTROL Y RES Y STAT Y DATE 0606 - 0606
OPT TYPE CONDITION/RESOURCE IOAID USE QUANTITY MAX *P RBA DATE
CONTROL CONTROLM 01 E (00000)
RESOURCE TAPEP B 0003 0003
RESOURCE CPU1 B 0098 0100
RESOURCE CPU2 B 0197 0200
RESOURCE TAPEP 01 U 0002 (00091)
RESOURCE CPU1 01 U 0002 (00091)
RESOURCE CPU2 01 U 0003 (00092)
RESOURCE TAPEP 01 R 0002 1 (00093)
COND BR-BRIVPCC-ENDED-OK 0909
COND BR-BRCC0001-ENDED-OK 0909
COND BR-BRCC0002-ENDED-OK 0909
COND BR-BRCC0003-ENDED-OK 0909
COND BR-BRCCIND-ENDED-OK 0909
COND BR-BRUPDT02-ENDED-OK 0909
COND BR-BRREP001-ENDED-OK 0909
COND BR-BRREP002-ENDED-OK 0909
COND GL-GLINP001-ENDED-OK 0909
COND EBD-APPL-STARTED 0909
COND CICS-PROD-IS-UP STAT
OPTIONS: D DELETE C CHANGE ? WHY COMMANDS: ADD 14.07.08

To return to the IOA Primary Option menu, press the END key (PF03/PF15).

Fields of the IOA Conditions/Resources Screen

The information displayed in each screen line is shown in Table 104:

Chapter 2 Online Facilities 289

IOA Conditions/Resources Screen

Table 104 Fields of the IOA Conditions/Resources Screen (part 1 of 2)

Field Description
OPT Option to be activated on the condition or resource.
TYPE Type of condition or resource:

■ COND – Prerequisite condition

■ CONTROL – Control resource
■ RESOURCE – Quantitative resource
CONDITION/ Name of the condition or resource.
RESOURCE
IOAID ID of the IOA installation that is using the particular Control or
Quantitative resource. This value is significant when multiple IOA
installations share the same resources.
USE Resource usage indicator for Control or Quantitative resources.
Valid values depend on the type of resource.

For Control resources, valid values are:

■ E – Resource is being used in Exclusive mode

■ S – Resource is being used in Shared mode

For Quantitative resources, valid values are:

■ B – Line indicates the initial definition for the resource

■ U – Line indicates an instance of resource usage
■ R – Line indicates an unfulfilled critical path request (that is, a
request with an *-type priority) for the resource
QUANTITY Quantity of a Quantitative resource. What the quantity represents
depends on the value in the USE field, as follows:
Use Quantity
B Quantity available. If the maximum quantity is
more than 1 but only 1 is available, 0001 is
displayed in pink for color terminals. If the
maximum quantity is more than 1 but none is
available, 0000 is displayed in red for color
terminals.
U Quantity in use by the particular process.
R Quantity requested by the particular
process, but unfulfilled.
MAX Maximum available quantity of a Quantitative resource.
*P Priority of the job requesting a Control-M resource using *-type
priority. For more information, see “PRIORITY: Runtime Scheduling
Parameter” on page 597.`

290 Control-M for z/OS User Guide

 IOA Conditions/Resources Screen

Table 104 Fields of the IOA Conditions/Resources Screen (part 2 of 2)

Field Description
RBA Internal Control-M ID (relative byte address) of the job currently
holding a Control-M resource. An RBA value of 000000 indicates that
the resource was added manually.
Notes:

■ Line indicates an unfulfilled critical path request (that is, a

request with an *-type priority) for the resource.

■ It is permissible to add a duplicate CONTROL resource, either

online in screen 4 or by using batch utility IOACND, to enable
manual intervention in the job flow processing.
DATE Original date reference of a prerequisite condition (format mmdd or
ddmm depending on the site standard, or the value STAT).

The conditions are displayed in day (dd) order (regardless of the

site's date format), followed by STAT conditions.

Specifying Retrieval Criteria

You can control the type and amount of information displayed in the screen by
specifying retrieval criteria.

Table 105 IOA Conditions/Resources Retrieval Criteria (part 1 of 2)

Field Description
PREFIX prefix If specified, limits the display to conditions with the specified prefix.

To display only conditions containing a specific string, enter the

string preceded by an *.

Example:

If *OK is entered, the following conditions are included in the

display:

UPDATE-ENDED-OK
OK-RUN
OK
COND Determines whether prerequisite conditions are displayed. Valid
values are:
■ Y (Yes) – Display prerequisite conditions. Default.
■ N (No) – Do not display prerequisite conditions.

CONTROL Determines whether Control resources are displayed. Valid values

are:
■ Y (Yes) –Display Control resources. Default.
■ N (No) – Do not display Control resources.

Chapter 2 Online Facilities 291

IOA Conditions/Resources Screen

Table 105 IOA Conditions/Resources Retrieval Criteria (part 2 of 2)

Field Description
RES Determines whether Quantitative resources are displayed. Valid
values are:
■ Y (Yes) – Display Quantitative resources. Default.
■ N (No) – Do not display Quantitative resources.

STAT Determines whether prerequisite conditions with a date value of

STAT are displayed. (Applies only if Y is specified for COND.) Valid
values are:
■ Y (Yes) – Include prerequisite conditions with a date value of
STAT.
■ N (No) – Do not include prerequisite conditions with a date
value of STAT.
DATE from – to Limits the display of prerequisite conditions to the selected date
range. Valid values are:
■ from – Earliest date in the date range, in mmdd or ddmm format
(depending on the site standard). The default value is three days
prior to the current date. This default can be modified in the
Profile member by the INCONTROL administrator.
■ to – Latest date in the date range, in mmdd or ddmm format
(depending on the site standard). The default value is the current
date.

Adding Conditions and Resources – The ADD Command

From the Command field, use the ADD command to add conditions to the IOA
Conditions file or resources to the Control-M Resources file.

The format of the command is:

ADD type

where type is one of the following:

■ COND – Add a prerequisite condition. Special care must be taken when adding
prerequisite conditions, because added conditions can trigger job submission.

■ LCOND – Add a long prerequisite condition (a condition name that exceeds 20

characters).

■ RESOURCE/RES – Add a Quantitative resource. Only authorized personnel

should add Quantitative resources.

■ CONTROL/CON – Add a Control resource. A Control resource entry may be

added manually even if a job is holding the resource. Only authorized personnel
should add Control resources.

292 Control-M for z/OS User Guide

 IOA Conditions/Resources Screen

When the ADD command is entered, an appropriate window is opened. The window
shown in Figure 84 opens when ADD COND is entered.

Figure 84 IOA Conditions/Resources COND Window

-------------------------- IOA CONDITIONS/RESOURCES ------------------------(4)
COMMAN +---------------------------------------------------------+ L ===> CRSR
PREFIX | PLEASE FILL IN COND NAME, DATE AND PRESS ENTER | 0606 - 0606
OPT TY | | BA DATE
CO | NAME ===> DDMM ===> | 00)
RE | |
RE +---------------------------------------------------------+
RE
RESOURCE TAPEP 01 U 0002 (00091)
RESOURCE CPU1 01 U 0002 (00091)
RESOURCE CPU2 01 U 0003 (00092)
RESOURCE TAPEP 01 R 0002 1 (00093)
COND BR-BRIVPCC-ENDED-OK 0606
COND BR-BRCC0001-ENDED-OK 0606
COND BR-BRCC0002-ENDED-OK 0606
COND BR-BRCC0003-ENDED-OK 0606
COND BR-BRCCIND-ENDED-OK 0606
COND BR-BRUPDT02-ENDED-OK 0606
COND BR-BRREP001-ENDED-OK 0606
COND BR-BRREP002-ENDED-OK 0606
COND GL-GLINP001-ENDED-OK 0606
COND EBD-APPL-STARTED 0606
COND CICS-PROD-IS-UP STAT
OPTIONS: D DELETE C CHANGE ? WHY COMMANDS: ADD 14.07.08

Fill in the window fields as described in Table 106 according to the specified ADD
command:

Table 106 IOA Conditions/Resources ADD Command Formats

Format Description
ADD COND Enter the name of the prerequisite condition. The current working
date is displayed as the default date. This date can be modified.
ADD LCOND Same as ADD COND, but for use only when the length of the
condition name is from 21 through 39 characters.
ADD RESOURCE or Enter the name of the Quantitative resource and the quantity to be
ADD RES added.
ADD CONTROL or Enter the name of the Control resource and the control type
ADD CON (E – Exclusive; S – Shared).
Note: If a Control resource is manually added with a type of E
(Exclusive), no jobs in WAIT SCHEDULE status that require this
resource are submitted.

If a Control resource is manually added with a type of S (Shared), no

jobs in WAIT SCHEDULE status that require exclusive access to this
resource are submitted.

After filling in the window, press Enter to add the condition or resource.

Chapter 2 Online Facilities 293

IOA Conditions/Resources Screen

To close the window without adding the condition or resource, press the RESET key
(PF04/PF16).

Options of the IOA Conditions/Resources Screen

The following options can be selected for conditions and resources by typing the
option in the OPT field to the left of the resource or condition name and pressing
Enter. Available options are shown in Table 107:

Table 107 Options of the IOA Conditions/Resources Screen

Option Description
D (DELETE) Delete a condition or resource from the list. The event is recorded in
the IOA Log file.
C (CHANGE) Change the maximum available quantity of a Quantitative resource.
The event is recorded in the IOA Log file.
? (WHY) View a list of the jobs that are either waiting for this resource or
holding it.

These options are discussed in detail on the following pages.

Deleting Conditions and Resources – The DELETE Option

To delete conditions and/or resources, type D (Delete) in the OPT field to the left of
the conditions and resources being deleted and press Enter.

A confirmation window may be displayed, depending on user profile customization:

■ By default, conditions and resources are deleted without confirmation from the
user.

■ The User profile can be customized to display a confirmation window with an

arrow pointing to a delete request (beginning with the first request).

294 Control-M for z/OS User Guide

 IOA Conditions/Resources Screen

Figure 85 IOA Conditions/Resources DELETE Confirmation Window

-------------------------- IOA CONDITIONS/RESOURCES ------------------------(4)
COMMAND ===> SCROLL ===> CRSR
PREFIX ===> COND Y CONTROL Y RES Y STAT Y DATE 0606 - 0606
OPT TYPE CONDITION/RESOURCE IOAID USE QUANTITY MAX *P RBA DATE
COND SALARY-PRSL01A-OK 0909
COND SALARY-PRSL002-OK +----------------------+
COND SALARY-PRSL003-OK | CONFIRM |
D COND CBT-TAPE-ARRIVED <---------| ASK FOR EACH ONE Y |
D COND KPL-PRKPL03-OK +----------------------+
COND KPL-PRKPL04-OK 0606
======== >>>>>>>>>>>>>>>> B O T T O M O F L I S T <<<<<<<<<<<<<<<< ========

OPTIONS: D DELETE C CHANGE ? WHY COMMANDS: ADD 14.07.08

If a confirmation window is displayed, fill in the window as shown in Table 108 and
press Enter:

Table 108 IOA Conditions/Resources DELETE Confirmation Window Options

Option Description
CONFIRM Whether to process the delete request. Valid values are:

■ Y (Yes) – Process the request.

■ N (No) – Cancel the request.
ASK FOR EACH This line is displayed only if more than one delete is requested. It
ONE determines whether individual confirmation is required for each
delete request. Valid values are:

■ Y (Yes) – Individual confirmation is required for each delete

request. The specified CONFIRM value applies only to the
current order or request.

■ N (No) – Individual confirmation is not required for each delete

request. The specified CONFIRM value is applied to all delete
requests. (If CONFIRM is Y, all delete requests are processed; if
CONFIRM is N, no delete request is processed.)

Changing the Quantity of a Resource – The CHANGE Option

To request a change to the maximum available quantity of a resource, type

C (Change) in the OPT field to the left of the resource and press Enter. The window
shown in Figure 86 is opened.

Chapter 2 Online Facilities 295

IOA Conditions/Resources Screen

Figure 86 IOA Conditions/Resources CHANGE Option Window

-------------------------- IOA CONDITIONS/RESOURCES ------------------------(4)
COMMAN +---------------------------------------------------------+ L ===> CRSR
PREFIX | PLEASE FILL IN QUANT RES NAME, COUNT AND PRESS ENTER | 0606 - 0606
OPT TY | | BA DATE
CO | NAME ===> TAPEP COUNT ===> | 000)
C RE | |
RE +---------------------------------------------------------+
RE
RESOURCE TAPEP 01 U 0002 (00091)
RESOURCE CPU1 01 U 0002 (00091)
RESOURCE CPU2 01 U 0003 (00092)
RESOURCE TAPEP 01 R 0002 1 (00093)
COND BR-BRIVPCC-ENDED-OK 0606
COND BR-BRCC0001-ENDED-OK 0606
COND BR-BRCC0002-ENDED-OK 0606
COND BR-BRCC0003-ENDED-OK 0606
COND BR-BRCCIND-ENDED-OK 0606
COND BR-BRUPDT02-ENDED-OK 0606
COND BR-BRREP001-ENDED-OK 0606
COND BR-BRREP002-ENDED-OK 0606
COND GL-GLINP001-ENDED-OK 0606
COND EBD-APPL-STARTED 0606
COND CICS-PROD-IS-UP STAT
OPTIONS: D DELETE C CHANGE ? WHY COMMANDS: ADD 14.07.08

The NAME value in the window is protected and cannot be changed.

The COUNT parameter consists of two values: sign and quantity. Fill in the COUNT
parameter as shown in Table 109 and press Enter:

Table 109 COUNT Parameter Values

Value Description
sign Valid values (one character):

■ + (Plus) – Add the selected quantity to the current maximum

available quantity to give a new maximum available quantity.

■ - (Minus) – Subtract the selected quantity from the current

maximum available quantity to give a new maximum available
quantity.

■ ' ' (Blank) – Set the maximum available quantity to the selected
quantity.
quantity Quantity to be used to adjust the maximum quantity of the resource
(four digits) according to the specified sign. Leading zeros are
required.

296 Control-M for z/OS User Guide

 IOA Conditions/Resources Screen

Viewing a List of the Jobs Waiting for a Resource – The WHY Option

To view a list of the jobs that are either waiting for this (quantitative or control)
resource or holding it, type ? in the OPT field to the left of the resource and press
Enter. The window shown in Figure 87 is displayed:

Figure 87 Resource Analysis WHY Option Window

-------------------------------- RESOURCE ANALYSIS --------------------(4.?)
COMMAND ===> SCROLL===> CRSR
MEMBER RBA ORDERID PRIORITY QUANTITY USE DISP STATUS
IOATEST 000011 001L0 0001 R,R HOLDING
IOATEST 00000E 001KX 0003 R,R WAITING
====== >>>>>>>>>>>>>>>>>>>>> END OF "WHY" LIST <<<<<<<<<<<<<<<<<<<<< =====

The information displayed for each job in the list is shown in Table 110:

Table 110 Fields of the WHY Option Window

Field Description
MEMBER The job’s member name
RBA The job’s relative byte address
ORDERID The job’s Order ID
PRIORITY The job’s priority field
QUANTITY The number of Quantitative resources held by this job. If the
resource being viewed is not quantitative, then this field will contain
blanks
USE The mode in which the control resource is used by this job. Valid
values are:

■ E – the control resource is used in Exclusive mode

■ S – the control resource is used in Shared mode
■ ' ' (Blank) – the resource is not a control resource
DISP Whether the resource is to be kept, released, or discarded when the
job finishes running. The field contains two 1-character values,
separated by a comma. The first value represents the behavior if the
job ends normally, and the second value represents the behavior if
the job fails. Valid values are:

■ R – the resource will be released

■ K – the resource will be kept
■ D – the resource will be discarded`
STATUS Whether this job is currently waiting for the resource, or holding it.
Possible values are HOLDING and WAITING.

Chapter 2 Online Facilities 297

IOA Manual Conditions Screen

IOA Manual Conditions Screen

The IOA Manual Conditions screen displays a list of prerequisite conditions that
must be confirmed manually by operations personnel.

The list of manual conditions is created by utility IOALDNRS. The utility is described
in the INCONTROL for z/OS Utilities Guide. This utility is intended for use at sites
where Control-M and/or Control-D are installed.

The utility scans the jobs in the Control-M Active Jobs file, and/or missions in the
Control-D Active Missions file, for all conditions requested in IN statements that

■ are not resolved by an OUT statement

■ are not resolved by ON PGMST or DO COND statements
■ do not exist in the IOA Conditions file

The utility automatically places the conditions conforming to the above criteria into
the IOA Manual Conditions file. This file is used as a checklist for manual operations
that operations personnel are expected to perform.

To enter the IOA Manual Conditions screen, select Option 7 on the IOA Primary
Option menu.

Figure 88 IOA Manual Conditions Screen

--------------------------- IOA MANUAL CONDITIONS --------------------------(7)
COMMAND ===> SCROLL ===> CRSR
PREFIX ===> PENDING Y ADDED Y STAT Y DATE 0606 - 0606
OPT TYPE CONDITION DATE ADDED
COND USR-GOT-TAX-TAPE 0606
COND DBA-RUN-UPDATE 0606 Y
COND OP-EXTERNAL-TAPE-OK 0606 Y
COND USR-GOT-BANK-TAPE 0606
COND OP-SHUT-THE-SYSTEM 0606
COND DBA-START-MPMXXX 0606
COND USR-GOT-SALARY-TAPE 0606 Y
COND OP-COMMUNICATION-DOWN 0606
======== >>>>>>>>>>>>>>>> B O T T O M O F L I S T <<<<<<<<<<<<<<<< ========

OPTIONS: A ADD TO COND/RES LIST (SCREEN 4) E ERASE COMMANDS: NEW 18.33.47

To exit the IOA Manual Conditions screen, press END (PF03/PF15).

298 Control-M for z/OS User Guide

 IOA Manual Conditions Screen

Fields of the IOA Manual Conditions Screen

The information displayed on each screen line is shown in Table 111:

Table 111 Fields of the IOA Manual Conditions Screen

Field Description
OPT Option to be activated on the condition.
TYPE Type of condition, meaning, COND for prerequisite condition.
CONDITION Condition name.
DATE Date reference of prerequisite condition. Format is either mmdd or
ddmm depending on the site standard, or the date value STAT.
ADDED Indicates whether the condition has been manually added to the IOA
Conditions file.

■ N (No) – Condition has not been added.

■ Y (Yes) – Condition has been added.

Specifying Retrieval Criteria

You can control the type and amount of information displayed in the screen by
specifying retrieval criteria.

Table 112 Retrieval Criterion for IOA Manual Conditions Screen (part 1 of 2)
Criterion Description
PREFIX prefix Limits the display to conditions with the selected prefix. Default:
Blank (no limit).

To display only those conditions containing a specific string, enter

the string preceded by an *.

Example:

If *OK is entered, the following conditions are included in the

display:

UPDATE-ENDED-OK
OK-RUN
OK
PENDING Determines whether conditions not yet added are displayed. Valid
values are:
■ Y (Yes) – Display pending conditions.
■ N (No) – Do not display pending conditions.

ADDED Determines whether added conditions are displayed. Valid values

are:
■ Y (Yes) – Display added conditions.
■ N (No) – Do not display added conditions.

Chapter 2 Online Facilities 299

IOA Manual Conditions Screen

Table 112 Retrieval Criterion for IOA Manual Conditions Screen (part 2 of 2)
Criterion Description
STAT Determines whether prerequisite conditions with a date value of
STAT are displayed. Valid values are:
■ Y (Yes) – Display prerequisite conditions with a date value of
STAT.
■ N (No) – Do not display prerequisite conditions with a date
value of STAT.
DATE from – to Limits the display of prerequisite conditions to the selected date
range. Valid values are:
■ from – Earliest date in the date range, in mmdd or ddmm format
(depending on the site standard). The default value is three days
before the current date.
■ to – Latest date in the date range, in mmdd or ddmm format
(depending on the site standard). The default value is the current
date.

Adding a New Prerequisite Condition – NEW Command

To add a prerequisite condition to the IOA Manual Conditions file, type NEW COND
in the COMMAND field and press Enter. The window shown in Figure 89 is opened.

To add a condition with a name from 20 through 39 characters in length, type NEW
LCOND in the COMMAND field and press Enter. The window shown in Figure 89 is
opened.

Figure 89 IOA Manual Conditions Screen NEW Window

--------------------------- IOA MANUAL CONDITIONS --------------------------(7)
COMMAN +---------------------------------------------------------+ L ===> CRSR
PREFIX | PLEASE FILL COND NAME AND DATE AND PRESS ENTER | 0606 - 0606
OPT TY | |
CO | NAME ===> MMDD ===> |
CO | |
CO +---------------------------------------------------------+
CO
COND OP-SHUT-THE-SYSTEM 0606
COND DBA-START-MPMXXX 0606
COND USR-GOT-SALARY-TAPE 0606 Y
COND OP-COMMUNICATION-DOWN 0606
======== >>>>>>>>>>>>>>>> B O T T O M O F L I S T <<<<<<<<<<<<<<<< ========

OPTIONS: A ADD TO COND/RES LIST (SCREEN 4) E ERASE COMMANDS: NEW 18.33.47

300 Control-M for z/OS User Guide

 IOA Manual Conditions Screen

In the NAME field of the window, type the name of the condition to be added. If the
condition has a date other than the current working date, enter the date in the MMDD
field of the window, in the format DDMM or MMDD, depending on the site
standard.

■ To add the condition, press Enter.

■ To close the window without adding the condition, press RESET (PF04/PF16).

NOTE
Adding a new condition to the IOA Manual Conditions file does not affect the IOA
Conditions file.

Options of the IOA Manual Conditions Screen

To add a condition to the IOA Conditions file, or to erase a condition from the IOA
Manual Conditions file, type the appropriate option in the OPT field to the left of the
condition name and press Enter. Valid options are shown in Table 113:

Table 113 Options of the IOA Manual Conditions Screen

Option Description
A (ADD) Add the condition to the IOA Conditions file (screen 4), and mark it
“Added” (Y) in the IOA Manual Conditions file. The event is
recorded in the IOA Log file.
E (ERASE) Erase (Delete) a condition from the IOA Manual Conditions file. This
does not affect the IOA Conditions file. This option is discussed in
more detail below.

Erasing (Deleting) Conditions

To erase prerequisite conditions, type E in the OPT field to the left of the condition
names being erased and press Enter.

A confirmation window may be displayed, depending on user profile customization:

■ By default, conditions are deleted without confirmation from the user.

■ If, however, the user profile member has been customized accordingly, a
confirmation window is displayed with an arrow pointing to an erase request
(beginning with the first request).

Chapter 2 Online Facilities 301

IOA Manual Conditions Screen

Figure 90 IOA Manual Conditions Screen ERASE Confirmation Window

--------------------------- IOA MANUAL CONDITIONS --------------------------(7)
COMMAND ===> SCROLL ===> CRSR
PREFIX ===> PENDING Y ADDED Y STAT Y DATE 0401 - 0701
OPT TYPE CONDITION +——————————————————————+
E COND USR-GOT-TAX-TAPE <—————————| CONFIRM (Y/N) |
COND DBA-RUN-UPDATE +——————————————————————+
COND OP-EXTERNAL-TAPE-OK 0606 Y
COND USR-GOT-BANK-TAPE 0606
COND OP-SHUT-THE-SYSTEM 0606
COND DBA-START-MPMXXX 0606
COND USR-GOT-SALARY-TAPE 0606 Y
COND OP-COMMUNICATION-DOWN 0606
======== >>>>>>>>>>>>>>>> B O T T O M O F L I S T <<<<<<<<<<<<<<<< ========

OPTIONS: A ADD TO COND/RES LIST (SCREEN 4) E ERASE COMMANDS: NEW 11.30.02

If a confirmation window is displayed, fill in the window as follows and press Enter:

Table 114 Fields of the IOA Manual Conditions Screen ERASE Confirmation Window
Field Description
CONFIRM Indicates whether to process the erase (delete) request. Valid values
are:
■ Y (Yes) – Process the request.
■ N (No) – Cancel the request.

ASK FOR EACH This line is displayed only if more than one erase is requested. It
ONE determines whether individual confirmation is required for each
erase request. Valid values are:

■ Y (Yes) – Individual confirmation is required for each erase

request. The selected CONFIRM value applies only to the
current order or request.

■ N (No) – Individual confirmation is not required for each erase

request. The selected CONFIRM value is applied to all erase
requests. If CONFIRM is Y, all erase requests are processed; if
CONFIRM is N, no erase request are processed.

302 Control-M for z/OS User Guide

 IOA Log Facility

IOA Log Facility

The IOA Log facility places automatically generated messages, which record every
significant event in the life of a job, rule or mission, in the IOA Log file. Significant
events recorded in the IOA Log file include normal processing occurrences, such as
job submitted, as well as error conditions encountered during processing, such as job
abends. Shout facility notifications and user remarks may also be recorded in the IOA
Log file.

IOA Log Screen

The IOA Log screen enables you to view the information contained in the Log file. To
enter the IOA Log screen, select option 5 on the IOA Primary Option menu. Upon
entry, the screen displays the most recent messages currently in the IOA Log file.

Figure 91 IOA Log Screen

FILTER: ---------------- IOA LOG -------------------------------(5)
COMMAND ===> SCROLL===> CRSR
SHOW LIMIT ON ==> DATE 060601 - 060601
DATE TIME ODATE USERID CODE -------- M E S S A G E ------------------
060601 092144 060601 M22 SPY254I JOB CT085955 CT085955/01835 SCANNED
060601 092144 060601 M22 SEL208I JOB CT085955 CT085955/01835 ENDED "OK"
060601 092150 060601 M22 SPY254I JOB CT085956 CT085956/01836 SCANNED
060601 092150 060601 M22 SEL208I JOB CT085956 CT085956/01836 ENDED "OK"
060601 092156 060601 IVP SPY254I JOB BRIVPCC BRIVPCC /01843 SCANNED
060601 092157 060601 IVP SEL208I JOB BRIVPCC BRIVPCC /01843 ENDED "OK"
060601 092157 060601 DBA CTM659I FREE OF TASK BRCC0001 ODATE 060601
PERFORMED
060601 092201 060601 M22 SPY281I JOB INTR0004 INTR0004/04371 START
98253.1316 STOP 98253.1316 CPU 0MIN
00.04SEC SRB 0MIN 00.00SEC 0.19
060601 092201 060601 M22 SPY254I JOB INTR0004 INTR0004/04371 SCANNED
060601 092201 060601 M22 SEL206W JOB INTR0004 INTR0004/04371 ABENDED CC
SB37 STEP STEP01
060601 092201 060601 M22 SEL219I JOB INTR0004 INTR0004/04371 ENDED "NOT
OK"
060601 092208 060601 IVP SEL203I JOB BRCC0001 ELIGIBLE FOR RUN
060601 092208 060601 IVP SUB133I JOB BRCC0001 BRCC0002/01958 SUBMITTED
060601 092208 060601 IVP SEL203I JOB BRCC0002 ELIGIBLE FOR RUN
CMDS: SHOW, TABLE, CATEGORY, SHPF 09.43.00

To return to the IOA Primary Option menu, press END (PF03/PF15).

Chapter 2 Online Facilities 303

IOA Log Screen

Fields of the IOA Log Screen

Table 115 Fields of the IOA Log Screen

Field Description
SHOW LIMIT ON Identifies which selection criteria other than yes or no were entered
in the IOA Log Show Screen window (USERID, MEM/MIS,
JOBNAME, CATEGORY, TABLE). For more information, see
“Filtering the IOA Log Screen Display” on page 306.
DATE Date on which the message was issued.
TIME Time at which the message was issued.
ODATE Original scheduling date of the job associated with the message.
Format is mmddyy, ddmmyy or yymmdd, depending on the site
standard.
Note: When the display type is set to RBA display using the
DISPLAY command, the Relative Byte Address (RBA) of the
message within the IOA Log file is displayed instead of the ODATE.
For more information on changing the screen display, see “Changing
IOA Log Screen Display Types” on page 305.
USERID User ID of the job issuing the message, or user ID of the user writing
to the log.
CODE IOA message code.
MESSAGE Text of the message. If the message is longer than the space available
on the screen, the message is split and continues on the following
line. Messages relating to a job have the following format:

tasktype memname jobname/jobid message

fromdate – todate Log information displayed in the screen can be limited to the
specified date range in mmddyy, ddmmyy or yymmdd format,
depending on the site standard. If the DATE or the ODATE value for
a message is in the range selected, the message is included in the
IOA Log display. Valid values are:
■ fromdate – Earliest date in the date range.
■ todate – Latest date in the date range.

Commands of the IOA Log Screen

The following commands can be entered in the COMMAND field.

304 Control-M for z/OS User Guide

 IOA Log Screen

Table 116 Commands of the IOA Log Screen

Command Description
SHOW The SHOW command activates the specified screen filter, opens the
IOA Log Show Screen window, or opens the Display Filters window,
depending on the format of the command. For more information on
filtering the IOA Log Screen, see “Filtering the IOA Log Screen
Display” on page 306. Valid formats are:

■ SHOW name – Activates the specified filter.

■ SHOW ? – Opens the Display Filters window, which lists all

available filters.

■ SHOW (PF02/PF14) – Opens the IOA Log Show Screen window

for the currently active filter, and allows editing of that filter.

■ SHOW name EDIT – Opens the IOA Log Show Screen window
for the specified filter, and allows editing of that filter.
Note: Reserved filter name DEFAULT can be used to activate or edit
the default filter for the status screen. For example, SHOW
DEFAULT EDIT opens the IOA Log Show Screen window for the
default filter.

Only jobs conforming to selection criteria specified in the filter are

displayed in the IOA Log screen. For more information, see
“Filtering the IOA Log Screen Display” on page 306.
TABLE The TABLE Command alternately displays or hides the TABLE name
(if any) that is associated with the relevant job, mission or rule
definition. When displayed, the name of the table appears after the
job, mission or rule status.
CATEGORY The CATEGORY command alternately displays and hides the
CATEGORY of the relevant Control-D mission. This command
applies to Control-D generated messages only. When displayed, the
name of the category appears after the mission status.
Note: At sites where Control-D is active.

Changing IOA Log Screen Display Types

While in the IOA Log screen, the display type can be changed through the DISPLAY
command. The format of the command is:

DISPLAY x

where x is a 1-character code that identifies the desired display type. DISPLAY can be
abbreviated DI.

Chapter 2 Online Facilities 305

IOA Log Screen

NOTE
For a list of display types, enter DISPLAY ? to show the Display Options window. To select a
display type in the window, type S in the Option field next to the ID. To exit the window
without selecting a display type, press the END key (PF03/PF15).

Example

DI B

displays the No Reverse display.

Valid predefined displays are shown in Table 117.

Table 117 IOA Log Screen Predefined Display Types

Display Description
A Show RBA (Relative Byte Address) display (displays the RBA of the
message within the IOA Log file in place of the ODATE)
D Default display
B No Reverse display (display is in No Reverse mode)

Filtering the IOA Log Screen Display

Screen filters can be used to filter the IOA Log screen display.

A filter consists of a set of record selection criteria (selection fields and their values).
Only records that conform to the selection criteria specified in the filter are displayed
on the screen.

The INCONTROL administrator can predefine filters and place them in the General
profile.

Each user can activate an existing filter in the IOA Log screen by entering the SHOW
command in the COMMAND line of the IOA Log screen.

Each user can define multiple filters for the screen, through the IOA Log Show Screen
window, which is described in “Fields of the IOA Log Show Screen Window” on
page 309. User-defined filters belong to, are assigned names by, and can only be
activated by, the user who defined them. They are stored in the user profile.

You can see the list of all available filters by opening the Display Filters window.

A predefined default filter (DEFAULT) is defined for the IOA Log screen.
Site-defined defaults determine whether the last filter used or the DEFAULT filter is
activated upon reentry to the IOA Log screen.

306 Control-M for z/OS User Guide

 IOA Log Screen

Activating an existing filter in the IOA Log screen

The SHOW command can be used to activate an existing filter when you know the
name of the filter.

■ To activate an existing filter in the IOA Log screen, enter the SHOW command in
the COMMAND field, as follows:

SHOW name

where name is the name of the filter to be activated.

■ To activate the DEFAULT filter, use DEFAULT as the name of the filter.

Display Filters Window

When you do not know the name of a filter, you can still activate a filter from the list
of available filters by opening the Display Filters window. This window displays the
list of all available filters. These include Global filters that are available to all users, as
well as user-defined filters that are only available to the individual user. You can
activate a filter from the Display Filters window, or switch to the IOA Log Show
Screen window, where you can edit or define a filter.

To enter the Display Filters window, type SHOW ? in the COMMAND field of the IOA
Log screen and press Enter.

Figure 92 IOA Log Screen Display Filters Window

FILTER: DEFAULT ---------------- IOA LOG ------------------------------(5)
COMMAND ===> SCROLL===> CRSR
SHOW LIMIT ON ==> DATE 060601 - 060601
DATE TIME ODATE USERID CODE ------ M E S S A G E --------------------
060601 092144 060601 M22 SPY254I JOB CT085955 CT085955/01835 SCANNED
060601 092144 060601 M22 SEL208I JOB CT085955 CT085955/01835 ENDED "OK"
0 +-----------------------------------+ B CT085956 CT085956/01836 SCANNED
0 | DISPLAY FILTERS | B CT085956 CT085956/01836 ENDED "OK"
0 | CMD ==> SCROLL==> CRSR | B BRIVPCC BRIVPCC /01843 SCANNED
0 | O NAME DESCRIPTION | B BRIVPCC BRIVPCC /01843 ENDED "OK"
0 | CONFIRM | EE OF TASK BRCC0001 ODATE 080800
| DEL | RFORMED
0 | END | B INTR0004 INTR0004/04371 START
| ENDNOTOK | 253.1316 STOP 98253.1316 CPU 0MIN
| ENDOK | .04SEC SRB 0MIN 00.00SEC 0.19
0 | EXEC | B INTR0004 INTR0004/04371 SCANNED
0 | LATE | B INTR0004 INTR0004/04371 ABENDED CC
| WAIT | 37 STEP STEP01
0 | ECSALL | B INTR0004 INTR0004/04371 ENDED "NOT
| =========>>> BOTTOM <<<========== | "
0 | | B BRCC0001 ELIGIBLE FOR RUN
0 | OPTIONS S SELECT E EDIT | B BRCC0001 BRCC0002/01958 SUBMITTED
0 +-----------------------------------+ B BRCC0002 ELIGIBLE FOR RUN
CMDS: SHOW, TABLE, CATEGORY, SHPF 09.43.00

Chapter 2 Online Facilities 307

IOA Log Screen

Fields of Display Filters Window

The Display Filters window contains the fields shown in Table 118:

Table 118 Fields of the Display Filters Window

Field Description
NAME Name of the filter as it appears in the General or user profile.
DESCRIPTION Description of the filter.

Options of the Display Filters Window

To request one of the following options, type the option in the OPT field to the left of
the filter name and press Enter.

Table 119 Options of the Display Filters Window

Option Description
S (SELECT) Filters the entries that are displayed in the Automation Log Screen
according to the criteria specified in the selected filter.
E (EDIT) Opens the IOA Log Show Screen window, where the filter criteria
are displayed. You can modify the filter criteria.

IOA Log Show Screen Window

The IOA Log Show Screen window in the IOA Log screen enables you to create or
modify a filter.

■ To open an existing filter for editing, enter the following command:

SHOW filtername EDIT

where filtername is the name of the filter to be displayed in the IOA Log Show
Screen window.

■ To edit the currently active filter, it is not necessary to enter the name of the filter or
the EDIT keyword. Enter the SHOW command in the COMMAND field, or press
PF02/PF14. The following IOA Log Show Screen window is displayed:

Figure 93 IOA Log Show Screen Window

FILTER: DEFA +-------------------- IOA LOG SHOW SCREEN -------------------(5)
COMMAND ===> | FILTER DEFAULT SAVE (Y/N) DESC: |
SHOW LIMIT O | CM : D JOB M JOB SHOUT USER GENERAL D INT M INT STAT |
DATE TIME | Y Y Y N N N N Y |
060601 14131 | CMEM : GENERAL |
| |
| |
060601 14131 | |

308 Control-M for z/OS User Guide

 IOA Log Screen

060601 14131 | |
060601 14153 | |
| |
060601 14155 | |
| CODE |
| URGENCY: REGULAR Y URGENT Y VERY-URGENT Y |
060601 14155 | TASK TYPE CM: JOB CYC EMR STC CST EST ECJ ECS WRN TBL |
060601 14155 | Y Y Y Y Y Y Y Y Y Y |
060601 14173 | |
| |
060601 14174 | USERID N54A |
| MEM/MIS MIGDASD |
| JOBNAME |
060601 14174 | CATEGORY |
060601 14174 | TABLE |
060601 14174 | ORDERID |
CMDS: SHOW, +--------------------------------------------------------------+

■ To create a new filter, open any existing filter and enter a new name and
description in the FILTER and DESC fields (described in “Fields of the IOA Log
Show Screen Window,” below).

Fields of the IOA Log Show Screen Window

The IOA Log Show Screen window contains the following fields:

Table 120 Fields of the IOA Log Show Screen Window

Field Description
FILTER User-assigned name of the filter. The name entered in the FILTER
field can be modified.

If changes to a filter have not been saved, an asterisk is displayed to

the right of the filter name. For more information, see “Closing the
IOA Log Show Screen Window” on page 312.
SAVE (Y/N) Specifies whether to save modifications to the filter upon closing the
window.
Desc: User-defined description of the filter. The description entered here
appears next to the name in the Displaying Filters window.

NOTE
The INCONTROL administrator can limit which installed INCONTROL products and
options each user may access. However, because all INCONTROL products and the messages
they issue are integrated, it may be important for users to see the messages of products and
options to which they have no access. Therefore, the types of messages for all INCONTROL
products are listed in the IOA Log Show Screen window, and by default, the messages of all
installed products are listed in the IOA Log screen.

Fields that define the selection criteria to be applied to the screen are described below.
Fill in the selection criteria as necessary.

Chapter 2 Online Facilities 309

IOA Log Screen

NOTE
The selection criteria marked with the P symbol act on a prefix basis. For example, typing D4
in the JOBNAME field causes the retrieval of all jobs whose names start with D4.

Table 121 IOA Log Show Screen Window Selection Criteria (part 1 of 2)
Criteria Description
CM message type To limit the type of log messages displayed, enter Y (Yes) or N (No)
under the desired message type.

Valid Control-M message type codes are:

■ D JOB – Messages related to jobs produced during New Day

processing.
■ M JOB – Job-related messages produced by the Control-M
monitor. The majority of job messages are of this type.
■ SHOUT – Messages written to the Log file by the SHOUT
parameter. For more information, see “SHOUT: Post–Processing
Parameter” on page 636.
■ USER – Messages resulting from manual intervention of
authorized users in the operation of Control-M; for example, the
addition of a prerequisite condition, HOLD or RERUN of the job,
and so on.
■ GENERAL – General messages on Control-M operation.
■ D INT – Internal messages generated during New Day
processing. For use mainly by maintenance personnel.
■ M INT – Certain CMEM messages, and internal messages of the
Control-M monitor.
■ STAT – Statistical information about job execution.
CMEM message type To limit the type of log messages displayed, enter Y (Yes) or N (No)
under the desired message type. Valid CMEM message type code:

■ GENERAL – General messages on CMEM operation.

Note: Selection criteria identified by “CM message type” and “CMEM message type” are
specific to Control-M and CMEM, respectively. Other selection criteria, such as those
described below, are primarily applicable to other INCONTROL products, but may also be
available to Control-M and CMEM.
CODEP Show only IOA Log file messages with the specified message IDs or
prefix(es). A maximum of 6 message IDs (or prefixes) can be
specified.
URGENCY Mark Y (Yes) or N (No) to specify the desired urgency of messages.
Urgent and very urgent messages are highlighted.

310 Control-M for z/OS User Guide

 IOA Log Screen

Table 121 IOA Log Show Screen Window Selection Criteria (part 2 of 2)
Criteria Description
TASK TYPE When job messages are selected, limit the task types to be displayed.
Type Y to include or N to exclude the following task types:

■ JOB – Regular job.

■ CYC – Cyclic job.
■ EMR – Emergency job.
■ STC – Started task.
■ CST – Cyclic started task.
■ EST – Emergency started task.
■ ECJ – Emergency cyclic job.
■ ECS – Emergency cyclic started task.
■ WRN – Warnings. Supported for historical reasons only.
■ TBL – SMART Table Entity.
USERIDP Show only messages of the selected user IDs. A maximum of
five user IDs can be specified.
Note: Selection criteria MEM/MIS, JOBNAME, and TABLE, described below, only affect the
display of messages related to a job. Messages not related to a job are not affected by these
selection criteria and are displayed unless suppressed by other selection criteria.

CATEGORY is not relevant to Control-M.

MEM/MISP Limit displayed job messages to the selected member names. A
maximum of five member names can be specified. Messages not
related to a job are not affected by this show limit.
JOBNAMEP Limit displayed job messages to the selected job names. A maximum
of five job names can be specified. Messages not related to a job are
not affected by this show limit.
CATEGORY Control-D category. This selection field is not relevant to Control-M
and does not filter Control-M jobs.
GROUPP Limit displayed job messages to the selected groups. A maximum of
four groups can be specified. Messages not related to a job are not
affected by this show limit.
ORDERID Limit displayed job messages to the specified order ID

IOA Log Show Screen window (at Sites Where Multiple IOA
Products Are Active)
The IOA Log Show Screen window displays different selection criteria depending on
which INCONTROL products are operational at your site.

The IOA Log Show Screen window at sites where all INCONTROL products are
active is illustrated in Figure 94.

Chapter 2 Online Facilities 311

IOA Log Screen

Figure 94 IOA Log Show Screen Window at Sites where Multiple INCONTROL
Products are Active
FILTER: DEFA +-------------------- IOA LOG SHOW SCREEN -------------------(5)
COMMAND ===> | FILTER SAVE (Y/N) |
SHOW LIMIT O | CM : D JOB M JOB SHOUT USER GENERAL D INT M INT STAT |
DATE TIME | Y Y Y Y Y N N N |
060800 21354 | CO+CMEM: GENERAL SHOUT JOBS GENERAL W PIPE W JOB W |
| Y Y Y |
060601 22040 | CD+CV : SBSYS REP MIS SHOUT USER GENERAL DAILY MONIT STAT |
060601 22040 | Y Y Y Y Y Y N N N |
060601 22040 | CB : RUNTIME SHOUT DAILY GENERAL STATISTICS |
| Y Y Y Y Y |
060601 22040 | CT : GENERAL SHOUT REAL-TIME UTILITIES |
060601 22040 | Y Y Y Y |
060601 22040 | CODE |
| URGENCY: REGULAR Y URGENT Y VERY-URGENT Y |
060601 23034 | TASK TYPE CM: JOB CYC EMR STC CST EST ECJ ECS WRN TBL |
060601 23040 | Y Y Y Y Y Y Y Y Y Y |
060601 23040 | CD: REP PRT BKP/MIG RST EMR NOEMR CYC NOCYC |
060601 23040 | Y Y Y Y Y Y Y Y |
| USERID N54A |
060601 23040 | MEM/MIS MIGDASD |
060601 23040 | JOBNAME |
060601 23040 | CATEGORY |
| TABLE |
| ORDERID |
CMDS: SHOW, +--------------------------------------------------------------+

The Control-M selection criteria are described in Table 121 on page 310. For
descriptions of the selection options for other INCONTROL products, see the user
guides of the respective products.

NOTE
The INCONTROL administrator can limit which installed INCONTROL products and
options each user can access. However, because all INCONTROL products and the messages
they issue are integrated, it may be important for users to see the messages of products and
options to which they have no access. Therefore, the types of messages for all INCONTROL
products are listed in the IOA Log Show Screen window, and by default, the messages of all
installed products are listed in the IOA Log screen.

Closing the IOA Log Show Screen Window

You can activate an edited filter with or without saving changes, depending on the
value you type in the SAVE field, as follows:

■ To activate and save the filter, type Y (Yes) in the SAVE field. Changes to the filter
are permanently saved.

■ To activate the filter without saving it, type N (No) in the SAVE field. Changes are
kept in memory only, but are not saved.

After entering a value in the SAVE field, press one of the following keys:

312 Control-M for z/OS User Guide

 IOA Calendar Facility

Table 122 IOA Log Show Screen window - Closing Values

Key Description
Enter Filtering begins with the first message currently displayed in the
screen and continues downward.
PF07 (UP) Filtering begins with the first message in the IOA Log file and
continues downward.
PF08 (DOWN) Filtering begins with the last message in the IOA Log file and
continues upward.

The window is closed and the filter is activated as defined or modified.

To cancel changes made in the IOA Log Show Screen window, press RESET
(PF10/PF22). The changes are canceled regardless of the value entered in the SAVE
field, the window is closed, and the filter that was previously in effect is restored.

By default, pressing END (PF03/PF15) in the window works like pressing Enter.
However, the default can be modified so that pressing END works like pressing
RESET.

IOA Calendar Facility

The IOA Calendar facility enables you to create, view, or modify calendar definitions.

Calendars simplify the scheduling of INCONTROL product jobs, missions, rules, and
so on. When a particular schedule is used in many job scheduling, mission, and/or
rule definitions, a calendar can be defined for that schedule, and the name of that
calendar can be specified in all the job, mission, or rule definitions that use that
particular schedule.

For example, calendars may be defined to handle the normal scheduling needs for
workdays, holidays, weekends, beginning of month, end of month, and so on.
Exception calendars may also be created.

A calendar definition consists of parameters that specify when scheduling occurs.

Calendar definitions are stored in members. A member usually contains multiple

calendar definitions, as follows:

■ A member contains the calendars required for a specific type of scheduling need.
For example, the calendar member WORKDAYS may contain the calendar
definitions for normal workday scheduling.

Chapter 2 Online Facilities 313

Accessing the IOA Calendar Facility

■ Each calendar definition in that member defines the schedule for a given year. For
example, the calendar member WORKDAYS may contain calendar definitions
2001, 2002, and 2003. Each of those definitions contains the normal workday
schedule for the corresponding year.

The IOA Calendar facility also enables the definition of varied work periods
throughout the year, in special calendars called periodic calendars.

A calendar definition needs to be created only once. Once defined, the definition is
saved and used as necessary for scheduling. Calendar definitions can be modified or
deleted as required.

Any number of calendar members can be defined. Calendar members are stored in
calendar libraries (partitioned data sets). Generally one calendar library is defined at
time of installation, and referenced by the DACAL DD statement.

NOTE
The IOA Calendar facility does not support members that have been compressed using the
ISPF PACK option.

Ensure that each IOA calendar that you define contains entries for the years
preceding and following the period you want to define. The entries for the preceding
and following years can be dummy entries, provided that these years contain at least
one day set to Y. If an IOA calendar does not contain entries for the preceding and
following years, problems may arise when Control-M resolves scheduling criteria, in
which event the CTM707E message is displayed.

Accessing the IOA Calendar Facility

The IOA Calendar facility contains the screens shown in Table 123:

Table 123 IOA Calendar Facility Screens

Screen Description
IOA Calendar Facility Enables specification of parameters that determine which records are
entry panel displayed in subsequent screens.
Calendar List screen Displays the list of calendar members in the selected calendar
library.
Year List screen Displays the list of years for which there is a calendar definition in
the selected calendar member.
Calendar Definition Displays the parameters of the selected calendar for the selected
screen year. This is the main screen of the facility.

314 Control-M for z/OS User Guide

 Entry Panel

To enter the Calendar facility, select Option 8 in the IOA Primary Option menu. The
Calendar facility entry panel is displayed.

Depending on the values entered in the entry panel, you can bypass the Calendar List
screen and/or the Year List screen.

Entry Panel
The entry panel is displayed upon entering the IOA Calendar facility (Option 8 in the
IOA Primary Option menu).

Figure 95 IOA Calendar Facility – Entry Panel

--------------------- IOA CALENDAR FACILITY - ENTRY PANEL ------------------(8)
COMMAND ===>

SELECT CALENDAR TYPE:

_ REGULAR/PERIODIC
LIBRARY ===> IOA.V700.OLPREFA.CAL
CALENDAR ===> (Blank for calendar selection list)
YEAR ===> (Blank for year selection list)

_ RULE-BASED (RBC)
LIBRARY ===> IOAP.V700.OLPREFA.RBC
CALENDAR ===> (Blank/Mask for calendar selection list)

USE THE COMMAND "SHPF" TO SEE PFK ASSIGNMENT 10.58.42

Enter S either near REGULAR/PERIODIC or RULE-BASED (RBC) to select the

calendar type.

Table 124 Calendar types

Calendar type Description
REGULAR/PERIODIC Regular calendars consist of scheduling dates or days of the
week that can be defined according to monthly patterns.
Periodic calendars are especially useful when scheduling
dates do not easily conform to fixed date or day of the week
or month patterns. For more information on regular/periodic
calendars and defining its parameters, proceed to “Defining
a regular/periodic calendar” on page 316.
RULE-BASED (RBC) Rule-based calendars schedule jobs according to rules and
can be referred to from any job definition. The criteria can be
applied to any given year. For more information on rule-
based calendars and defining its parameters, proceed to
“Defining rule-based calendars” on page 327.

Chapter 2 Online Facilities 315

Defining a regular/periodic calendar

Defining a regular/periodic calendar

You can define a regular/periodic calendar by selecting the REGULAR/PERIODIC
calendar type in the IOA Calendar Facility - Entry Panel or upon exiting the Year List
screen.

In the IOA Calendar Facility - Entry Panel, complete the parameters shown in Table 125
and press Enter.

Table 125 Regular/periodic job parameters

Field Description
LIBRARY Name of the desired calendar library. Mandatory.

If you make an entry in this field without filling in the

CALENDAR field, the list of calendars in the selected library is
displayed in the Calendar List screen.

If you make an entry in this field, you can restrict the list of
calendars that are displayed by entering in the CALENDAR field
part of a Calendar name together with a mask character or
characters (? and *).
CALENDAR Name of the desired calendar member. Optional.

If you make an entry in this field without filling in the YEAR field,
the list of years in the selected calendar member is displayed in the
Year List screen.
YEAR Year of the desired calendar definition. Optional.

This field can be used only if a CALENDAR value is also entered.

If specified, the calendar definition is displayed in the Calendar
Definition screen.

NOTE
If you use the selection list fields, their values are not erased until you exit the entry panel by
pressing END (PF03/PF15).

The Calendar List screen appears displaying a list of calendars (members) in the
selected library.

By default, only calendar names are listed in the screen. However, if the default has
been modified at time of installation, statistical information is displayed for each
calendar name, as shown in Figure 96.

316 Control-M for z/OS User Guide

 Year List Screen

Figure 96 Calendar List Screen

CALENDARS IN LIB IOA.PROD.CAL ------------(8.D)
COMMAND ===> SCROLL===> CRSR
OPT NAME ------------ VV.MM CREATED CHANGED SIZE INIT MOD ID
BANKDAYS 01.00 02/01/28 01/06/29 09:50 104 104 0 IOAPROD
DAYSOFF 01.00 02/01/28 01/06/29 09:50 30 30 0 IOAPROD
HOLIDAYS 01.00 02/01/28 01/06/29 09:50 15 15 0 IOAPROD
PERIOD1O 01.00 02/01/28 01/06/29 09:50 45 45 0 IOAPROD
SACAYCLN 01.01 02/01/28 01/11/29 17:43 26 26 0 L3051
SPMONCLN 01.01 02/01/29 01/11/30 15:00 117 104 0 M16A
SPWEKCLN 01.01 02/01/29 01/11/30 15:10 117 104 0 M16A
STOCKDAY 01.00 02/01/30 01/06/31 09:50 45 45 0 IOAPROD
WORKDAYS 01.01 02/01/30 01/11/31 17:43 26 26 0 L3051
======= >>>>>>>>>>>>>>>> NO MORE CALENDARS IN LIBRARY <<<<<<<<<<<<<<<< ======

OPTIONS: S SELECT B BROWSE D DELETE 13.54.14

To return to the IOA Calendar Facility - Entry Panel, press END (PF03/PF15).

To request one of the following options, type the option in the OPT field to the left of
the calendar names, and press Enter.

Table 126 Options for Calendar List screen

Option Description
S (SELECT) Display the list of years for the calendar for any purpose, including
editing or modification. Only one calendar can be selected at a time.
B (BROWSE) Display the list of years for the calendar for browsing. Only one
calendar can be selected at a time.
D (DELETE) Deletes the calendar (member) from the library. Multiple calendars
can be selected.

Year List Screen

The screen displays the list of years for which a specified calendar is defined. This
screen can be entered directly through the entry panel or the Calendar List screen, or
upon returning from the Year Definition screen.

NOTE
If the S (Select) option was entered in the Calendar List screen for a calendar that is currently
in use (selected) by another user, either the Year List screen is not displayed and the Calendar
List screen remains displayed (the default), or the Year list screen is displayed in Browse
mode (if a user profile definition overrides the default). In either case, an appropriate message
is displayed.

Chapter 2 Online Facilities 317

Year List Screen

If a calendar description was defined in the Calendar Definition screen, the definition
is displayed to the right of the year.

Figure 97 Year List Screen

LIST OF YEARS IN IOA.PROD.CAL CALENDAR WORKDAYS
COMMAND ===> SCROLL===> CRSR
OPT YEAR ------------------ DESCRIPTION --------------------------------------
2001 REGULAR WORKING DAYS IN 2001
2002 REGULAR WORKING DAYS IN 2002
2003 REGULAR WORKING DAYS IN 2003
2004 REGULAR WORKING DAYS IN 2004
2005 REGULAR WORKING DAYS IN 2005
======= >>>>>>>>>>>>>>>> NO MORE YEARS IN CALENDAR <<<<<<<<<<<<<<<< =====

OPTIONS: S SELECT D DELETE I INSERT W INSERT BY WEEK DAYS C COPY 08.52.54

To return to the Calendar List screen press END (PF03/PF15).

Format of the Year List Screen

Next to each year in the Year list, certain information can be displayed. The type and
format of this information depends on whether the screen is displayed in DESC
format or in STAT format:

■ In DESC format, the description of the year, taken from the DESC field of the
calendar definition, is displayed. Default.

■ In STAT format, the ISPF statistical information for the calendar definition is
displayed.

By default, the Year list is displayed in DESC format. To change formats, use the
DESC or STAT commands, described in Table 127.

Commands of the Year List Screen

The following commands can be entered in the COMMAND field of the Year List
screen.

318 Control-M for z/OS User Guide

 Year List Screen

Table 127 Commands of the Year List Screen

Command Description
DESC The DESC command displays the calendar description next to the
year. The description is taken from the DESCRIPTION field in the
calendar definition.
STAT The STAT command displays the following ISPF-like statistical
information about the calendar next to the year: version and
modification numbers, creation date, last modification date, and user
ID.

Options of the Year List Screen

To request one of the options shown in Table 128, type the option in the OPT field to
the left of the year and press Enter.

NOTE
If the Year List screen is displayed in Browse mode, options D (Delete), I (Insert), and W
(Insert By Week Days) are not available.

Table 128 Options of the Year List Screen

Option Description
S (SELECT) Display the calendar definition for the specific year.

Parameters can be edited and updated only if the Calendar

Definition screen is not displayed in Browse mode. If the Calendar
Definition screen is displayed in Browse mode, the screen can only
be browsed and parameters cannot be modified.
D (DELETE) Delete the calendar definition for the specified year.
I (INSERT) Insert a new year in the Year List screen and display the Calendar
Definition screen with a predefined year definition for editing. The
predefined calendar definition is defined with the same dates as the
year next to which the I (Insert) request was specified. For more
information, see “Inserting a new year” on page 320.
W (INSERT BY WEEK Insert a new year in the Year List screen and display the Calendar
DAYS) Definition screen for editing a predefined year definition. The
predefined year definition is defined with the same days of the week
as the year next to which the W (Insert by Week Days) request was
specified. For more information, see “Inserting a new year.”
C (COPY) Copy the year to another calendar, as described in “Copying Years to
Another Calendar” on page 321. Multiple years can be selected.

Chapter 2 Online Facilities 319

Year List Screen

Inserting a new year

All calendar definitions identified in the same Year List usually have the same fixed
scheduling pattern. Often, this scheduling pattern is based either on dates within a
month or on days of the week within the month. For example:

■ Calendar QUARTERLY might always indicate scheduling for the last day of
March, June, September and December (that is, a scheduling pattern based on
dates).

■ Calendar WEEKEND might always indicate scheduling all Saturdays and/or

Sundays in each month (that is, a scheduling pattern based on days of the week).

This scheduling pattern also applies to new calendar definitions resulting from the
insertion of a new year in the Year List screen.

When a year is inserted in the Year List, the IOA Calendar facility automatically
generates a predefined calendar definition for the new year, based on the scheduling
pattern of the calendar by which the insert request was specified. This frees the user
from having to manually define the new calendar. This automatically generated
calendar definition can be displayed and modified.

NOTE
The Year list must be kept in ascending order without missing years (for example, 2001, 2002,
2003, 2004, 2005). Each new year must be added at the end of the list.

In calendar definitions, a defined scheduling date is described by both the date

(month and day) and the day of the week. Because a particular date falls on a
different day of the week in different years, it is necessary to indicate whether the
scheduling pattern is based on the date or on the days of the week. This is indicated
by the specified insert option.

■ To define the calendar with the same scheduling dates (although corresponding
days of the week may vary, for example, calendar QUARTERLY described above),
type option I (INSERT).

■ To define the calendar so that scheduling takes place on the same weekdays as in
the previous calendar (although the corresponding dates may vary, for example,
calendar WEEKEND described above), type option W (INSERT BY WEEK DAYS).

■ If the scheduling pattern is mixed (for example, calendar HOLIDAYS always

indicates scheduling on both January 1 and the first Monday in September),
specify the more appropriate option and correct the new calendar definition
manually.

320 Control-M for z/OS User Guide

 Copying Years to Another Calendar

Copying Years to Another Calendar

Years currently displayed in the Year List screen can be copied to another calendar.
To copy the desired years, type option C (COPY) next to each desired year in the
screen and press Enter. The window shown in Figure 98 is displayed:

Figure 98 Calendar List Screen Copy Window

LIST OF YEARS IN: IOA.PROD.CAL CALENDAR: CALEN1
COMMAND ===> SCROLL===> CRSR
OPT YEAR -------- DESCRIPTION ------------------------------------------------
2001 REGULAR WORKING DAYS IN 2001
C 2002 REGULAR WORKING DAYS IN 2002
2003 REGULAR WORKING DAYS IN 2003
2004 REGULAR WORKING DAYS IN 2004
+-----------------------------------------------------------+
| |
| SPECIFY DESTINATION LIBRARY,CALENDAR AND RULE NAME |
| |
| LIBRARY : IOA.PROD.CAL |
| CALENDAR: |
| YEAR : 2005 |
| |
| PRESS END/RESET TO CANCEL ENTER TO PERFORM THE COPY |
+-----------------------------------------------------------+

OPTIONS: S SELECT D DELETE I INSERT W INSERT BY WEEK DAYS C COPY 15.37.39

The window contains the fields shown in Table 129 (some fields contain default
values that can be modified):

Table 129 Fields of the Calendar List Screen Copy Window

Field Description
LIBRARY Library containing the calendar into which the years must be copied.
Must be an existing library. Default: The current library.
CALENDAR Name of the calendar into which the year must be copied.
Note: A year can only be copied to another calendar. It cannot be copied
to its own calendar (even if the year is renamed).

If the selected calendar does not exist in the Calendar List, the calendar is
created when the request is performed.
YEAR Name of the year to be copied. If multiple years are selected, the window
is initially displayed with the first selected year. As each request is
performed or canceled, the next requested year name appears.

To perform a request, press Enter.

To cancel a request, press END (PF03/PF15) or RESET (PF04/PF16).

Chapter 2 Online Facilities 321

Calendar Definition Screen

Calendar Definition Screen

This screen is used to define, display and modify dates in a calendar for a specific
year. This screen can be entered directly from the entry panel or from the Year List
screen.

Figure 99 Calendar Definition Screen

--------------------------- IOA CALENDAR - WEEKDAYS ----------------------(8.Y)
COMMAND ===> SCROLL===> CRSR
YEAR 2002 REGULAR WORKDAYS IN 2002

-----S-------------S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
01 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
-----S-------------S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8
02 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
-----S-------------S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
03 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
-----S-------------S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 +
04 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
-----S-------------S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
05 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
-----S-------------S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 +
06 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
-----S-------------S-------------S-------------S-------------S-------------S---
TYPE Y IN ALL THE EXECUTION DAYS 14.37.10

Fields of the Calendar Definition Screen

Table 130 Fields of the Calendar Definition Screen (part 1 of 2)

Field Description
YEAR Year of the calendar. This value can be modified. When modified, the values
indicated for each date in each month (described below) are shifted to the
appropriate day of the week.
description User-supplied, free text description of the calendar. Optional.

322 Control-M for z/OS User Guide

 Calendar Definition Screen

Table 130 Fields of the Calendar Definition Screen (part 2 of 2)

Field Description
month/dates Each month of the year (01 through 12) of the calendar consists of the
following:

■ Separator line. Sunday (or Saturday) is marked “S” (according to the

default at your site).
■ Month label (01 through 12).
■ Date label for the day of the month.

Updatable field for defining execution dates. Valid values are:

■ Y (Yes) – Select the job on that date.

■ N (No) or ' ' (Blank) – Do not select the job for execution on that date.
■ + – For a relative calendar, select the closest next “date.”
■ - – For a relative calendar, select the closest previous “date.”

Note: A relative calendar is a calendar used in a formula to create other

calendars. It cannot be specified in a DCAL, WCAL, or CONFCAL field. For
details, see the description of the IOABLCAL utility in the INCONTROL for
z/OS Utilities Guide.

Periodic Calendars
Some jobs must be scheduled periodically, according to schedules that are not easily
expressed in terms of fixed days and dates within months. In these cases, monthly, or
even yearly, scheduling definition is awkward. For example:

■ A payroll job needs to be scheduled every other Wednesday:

— In some months, the job may be scheduled on the first, third, and even fifth
Wednesday in the month. In other months, it may be scheduled on the second
and fourth Wednesday in the month.

— In some years, the job may be scheduled beginning on the first Wednesday of
the year. In other years, it may be scheduled beginning on the second
Wednesday of the year.

■ A job must be scheduled every 25 days, regardless of date. Such a job is scheduled
on different dates each month and each year.

The IOA Calendar facility provides special calendars, called periodic calendars, to
allow specification of these scheduling requirements. These periodic calendars are
very flexible.

To designate a calendar as periodic, you must type reserved string ==PERIODIC== in

the first 12 positions of the description field. Any text can be entered in the rest of the
description field. This is illustrated in Figure 100.

Chapter 2 Online Facilities 323

Calendar Definition Screen

Figure 100 Use of Reserved String “==PERIODIC==”

COMMAND ===> SCROLL===> CRSR
YEAR 2002 - ==PERIODIC== GENERAL WORKDAY CALENDAR

The following are characteristics of periodic calendars:

■ In a periodic calendar, days are not marked using the letters Y (Yes) or N (No).
Instead, a period identifier is used to mark working days in a period. A period
identifier can be any letter from A to Z (except Y and N), any number from 0 to 9,
or any other printable sign. If you need more characters, use characters falling
within the hexadecimal range 4A through F9. All working days within the same
period must be marked using the same period identifier character so that different
identifier characters indicate different periods. Days that are not marked are
nonworking days because they do not belong to any period in this calendar.

■ Identifiers from different periods can be interspersed throughout a periodic

calendar.

■ A periodic calendar can consist of smaller units that do not correspond to regular
months, in that they can be longer or shorter than regular months.

■ A periodic calendar can span a period, called a “logical year”, which can be longer
or shorter than one regular calendar year.

When a periodic calendar spans parts of two regular calendar years, special
considerations are likely to arise. For more information, see “Special Year-End
Handling of Periodic Calendars” on page 325.

■ A period can span any number of days, but no more than a preset number of days
can elapse after the appearance of one identifier in a period until the appearance of
the next matching identifier in the same period. After that period expires, the next
matching identifier starts a new period.

By default, this period is preset to 33 days. Once the length of the gap between
matching identifiers exceeds 33 days, the period automatically closes.

NOTE
The length of the default period can be changed from 33 days by the INCONTROL
administrator, using optional Wish WM2888.

For more information on the use of periodic calendars, see “DAYS: Basic Scheduling
Parameter” on page 426 and “WDAYS: Basic Scheduling Parameter” on page 681.

324 Control-M for z/OS User Guide

 Calendar Definition Screen

Examples

Figure 101 shows examples of periodic calendars:

Figure 101 Periodic Calendar – Example 1

-----S-------------S-------------S-------------S-------------S-------------S--
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
12 A A A B A
-----S-------------S-------------S-------------S-------------S-------------S--
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
01 B B
-----S-------------S-------------S-------------S-------------S-------------S--

This example contains two periods: A and B.

■ Period A starts on December 13 and ends on December 23. During this period, the
defined working days are December 13, December 18, December 20, and December
23.

■ Period B spans more than one calendar year. It starts on December 21 and ends on
January 24. During this period, the defined working days are December 21,
January 4, and January 24.

Figure 102 Periodic Calendar – Example 2

-----S-------------S-------------S-------------S-------------S-------------S----
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
03 B A B A
-----S-------------S-------------S----------0---S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 +
04 B
-----S-------------S-------------S-------------S-------------S-------------S--

This example includes a period B that begins on March 9. The last marked working
day of the period is March 21, which is followed by a 33-day gap. Assuming that
Wish WM2888 has not been used to alter the default period of 33 days, period B
automatically ends on April 23, and April 24 marks the beginning of a new period B.
If no more B identifiers are added, this new B period ends on May 27.

Special Year-End Handling of Periodic Calendars

Jobs or missions may be improperly scheduled if both the following are true:

■ a periodic calendar contains one or more periods that start in one year and
continue into the next year

■ the first occurrence of the matching identifier in one logical year falls within the
default gap that began at the last occurrence of the matching identifier in a prior
logical year, possibly as a result of changes made using optional Wish WM2888.

Chapter 2 Online Facilities 325

Calendar Definition Screen

In such cases, the period in the prior logical year overlaps the period in the later
logical year, causing a scheduled job not to run in the later logical year as expected.
To avoid this problem, remove logical years from periodic calendars as soon as they
are no longer needed.

Example
■ Logical year FISCAL01 extends from April 1, 2001 through March 31, 2002.
■ Logical year FISCAL01 contains a period identified as Period A that has been
defined to begin on December 28, 2001 and to continue through January 15, 2002.
■ Logical year FISCAL02 extends from April 1, 2002 through March 31, 2003.
■ Logical year FISCAL02 also contains a period identified as Period A, defined to
begin on April 20, 2002 and continue through May 3, 2002.
■ Job X is scheduled for the seventh day of Period A in each logical year, through the
job definition DAYS=D7PA.

In a case where the default gap is 33 days, Job X runs in January 2002, and again in
April 2002, as expected.

In a case where the default gap is changed from 33 days to a longer period, such as
120 days, the first day of Period A in logical year FISCAL02 occurs less than 120 days
after the last appearance of Period A in logical year FISCAL01. As a result, what
appears to be the seventh day in Period A in April 2002 is not recognized as such,
because the “old” Period A overlaps the “new” Period A. Consequently, Job X does
not run again when the user may have expected it to run.

Deleting calendars
To delete calendars, type option D next to the calendar names in the Calendar List
screen and press Enter. The confirmation window shown in Figure 103 is displayed,
in sequence, for each calendar selected for deletion.

Figure 103 Calendar List Screen Delete Confirmation Window

CALENDARS IN LIB IOA.PROD.CAL ------------(8.D)
COMMAND ===> +--------------------------+ SCROLL===> CRSR
OPT NAME --- | CONFIRM DELETE OPTION | E INIT MOD ID
D BANKDAYS <-----------| (Y/N) | 4 104 0 IOAPROD
DAYSOFF +--------------------------+ 0 30 0 IOAPROD
HOLIDAYS 01.00 02/01/28 01/06/29 09:50 15 15 0 IOAPROD
PERIOD1O 01.00 02/01/28 01/06/29 09:50 45 45 0 IOAPROD
D SACAYCLN 01.01 02/01/28 01/11/29 17:43 26 26 0 L3051
SPMONCLN 01.01 02/01/29 01/11/30 15:00 117 104 0 M16A
SPWEKCLN 01.01 02/01/29 01/11/30 15:10 117 104 0 M16A
STOCKDAY 01.00 02/01/30 01/06/31 09:50 45 45 0 IOAPROD
WORKDAYS 01.01 02/01/30 01/11/31 17:43 26 26 0 L3051
======= >>>>>>>>>>>>>>>> NO MORE CALENDARS IN LIBRARY <<<<<<<<<<<<<<<< ======

OPTIONS: S SELECT D DELETE I INSERT W INSERT BY WEEK DAYS C COPY 13.54.14

326 Control-M for z/OS User Guide

 Defining rule-based calendars

Type Y (Yes) in the window to delete the calendar. Type N (No) in the window to
cancel the delete request.

NOTE
If PDSMAN is operational at your site, $$$SPACE members are not deleted.

For each calendar deleted, a message is written to the IOA Log file.

Defining rule-based calendars

You can define a rule-based calendar (RBC) job by selecting the RULE-BASED (RBC)
calendar type in the IOA Calendar Facility - Entry Panel screen. For more information,
see “IOA Calendar Facility” on page 313.

In the IOA Calendar Facility - Entry Panel, complete the parameters shown in Table 131
and press Enter.

Table 131 Rule-based (RBC) parameters

Field Description
LIBRARY Name of the desired calendar library. Mandatory.

If you make an entry in this field without filling in the

CALENDAR field, the list of calendars in the selected library
is displayed in the Calendar List screen.

If you make an entry in this field, you can restrict the list of
calendars that are displayed by entering in the CALENDAR
field part of a Calendar name together with a mask character
or characters (? and *).
CALENDAR Name of the desired calendar. Optional.

The List of RBC Calendars screen appears displaying a list of rule-based calendars
(members) in the selected library.

By default, only calendar names are listed in the screen. However, if the default has
been modified at time of installation, statistical information is displayed for each
calendar name, as shown in Figure 104.

Chapter 2 Online Facilities 327

Selecting rule-based calendars

Figure 104 List of RBC Calendars Screen

LIST OF RBC CALENDARS IOAP.V700.OLPREFA.RBC ------------(8.RL)
COMMAND ===> SCROLL===> CRSR
OPT NAME ------------ VV.MM CREATED CHANGED ID
BANKDAYS 01.00 2010/01/28 2010/06/29 09:50 IOAPROD
DAYSOFF 01.00 2010/01/28 2010/06/29 09:50 IOAPROD
HOLIDAYS 01.00 2010/01/28 2010/06/29 09:50 IOAPROD
PERIOD1O 01.00 2010/01/28 2010/06/29 09:50 IOAPROD
SACAYCLN 01.01 2010/01/28 2010/11/29 17:43 L3051
SPMONCLN 01.01 2010/01/29 2010/11/30 15:00 M16A
SPWEKCLN 01.01 2010/01/29 2010/11/30 15:10 M16A
STOCKDAY 01.00 2010/01/30 2010/06/31 09:50 IOAPROD
WORKDAYS 01.01 2010/01/30 2010/11/31 17:43 L3051
======= >>>>>>>>>>>>>>>> NO MORE CALENDARS IN LIBRARY <<<<<<<<<<<<<<<< ======

OPTIONS: S SELECT D DELETE R RENAME C COPY 14.49.21

Table 132 Options for List of RBC Calendars screen

Option Description
S (SELECT) Display the list of years for the calendar for any purpose, including editing
or modification. Only one calendar can be selected at a time. See “Selecting
rule-based calendars” on page 328.
D (DELETE) Delete the calendar (member) from the library. Multiple calendars can be
selected. See “Deleting rule-based calendars” on page 329.
R (RENAME) Change the name of an existing rule-based calendar. See “Renaming rule-
based calendars” on page 330.
C (COPY) Copy an existing rule-based calendar from a specified destination library.
See “Copying rule-based calendars” on page 330.

Selecting rule-based calendars

To select a calendar, type the option S next to the calendar name in the List of RBC
Calendars screen and press Enter.

The RULE-BASED CALENDAR screen appears.

Figure 105 Rule-based calendar screen

===============================================================================
RULE-BASED CALENDAR FINANCE OWNER M46A
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT MAXWAIT 00
RULE-BASED CALENDAR ACTIVE FROM UNTIL

328 Control-M for z/OS User Guide

 Deleting rule-based calendars

Table 133 Rule-based calendar screen parameters

Parameter Description
RULE-BASED CALENDAR Identifies the set of scheduling criteria defined in the SMART
Table Entity or IOA Calendar Facility that can be used to
schedule the job.
OWNER User ID of the owner of the job.
DAYS Days of the month to schedule the job. A maximum of two
lines can be entered.
WDAYS Days of the week to schedule the job. A maximum of two
lines can be entered.
WCAL Identifies a calendar containing working days on which a job
can be scheduled.
MONTHS Months to run the job.
DATES Specific dates in the year to run the job.
CONFCAL Name of a calendar used to confirm job scheduling dates.
SHIFT Indicates when and if a job must be scheduled. Optional.
MAXWAIT Number of extra days within which to try to execute a job in
the Active Jobs file if the date of the job has passed.
RULE-BASED CALENDAR When a date is entered in this field within a job scheduling
ACTIVE FROM definition, the job will only be ordered if the current date is
later than that date. Valid values are:

■ Date in the format ddmmyy, or mmddyy, or yymmdd,

depending on your site format, as set by the DATETYP
parameter in the IOAPARM member in the IOA PARM
library.

■ ‘ ‘ (Blank)
RULE-BASED CALENDAR When a date is entered in this field within a job scheduling
ACTIVE UNTIL definition, the job will only be ordered if the current date is
earlier than that date. Valid values are:

■ Date in the format ddmmyy, or mmddyy, or yymmdd,

depending on your site format, as set by the DATETYP
parameter in the IOAPARM member in the IOA PARM
library.

■ ‘ ‘ (Blank)

Deleting rule-based calendars

To delete a calendar, type option D next to the calendar name in the List of RBC
Calendars screen and press Enter.

The CONFRIM DELETE OPTION dialog box appears in the center of the screen.

Chapter 2 Online Facilities 329

Renaming rule-based calendars

Enter Y to delete the rule-based calendar. Enter N to cancel the delete request.

Renaming rule-based calendars

To rename calendars, type option R next to the calendar name in the List of RBC
Calendars screen and press Enter.

The RENAME AN RBC dialog box appears in the center of the screen.

Figure 106 RENAME AN RBC dialog box

RENAME AN RBC

ORIGINAL: SHIPPING
NEW : DISTRIBUTION

PRESS END/RESET TO CANCEL ENTER TO PERFORM THE RENAME

Enter the original name of the rule-based calendar you want to rename. Enter the new
name of the rule-based calendar.

Press ENTER to rename the calendar or press END/RESET to cancel the rename
request.

Copying rule-based calendars

To copy calendars, type option C next to the calendar name in the List of RBC
Calendars screen and press Enter.

The SPECIFY DESTINATION LIBRARY AND CALENDAR NAME window appears in

the center of the screen.

Figure 107 SPECIFY DESTINATION LIBRARY AND CALENDAR NAME Window

SPECIFY DESTINATION LIBRARY AND CALENDAR NAME

LIBRARY : IOAP. V700.OLPREFA.RBC

RBC : REPLACE: Y (Y/N)

PRESS END/RESET TO CANCEL ENTER TO PERFORM THE COPY

In the Library field, enter the destination library. In the RBC field, enter the calendar
name of the rule-based calendar you want to copy.

Press ENTER to copy the calendar or press END/RESET to cancel the copy request.

330 Control-M for z/OS User Guide

 Exiting the IOA Calendar Facility

Exiting the IOA Calendar Facility

When exiting the IOA Calendar facility, screens are exited in the following sequence:

1. Calendar Definition screen

2. Year List screen
3. Calendar List screen

NOTE
If the Calendar List screen was bypassed as you entered the IOA Calendar facility (that is, if
you entered a CALENDAR value in the entry panel), the Calendar List screen is not displayed
upon exiting the Year List screen; instead, the entry panel is displayed.

Calendar Facility Entry Panel

The commands and options available when exiting screens depend on the screen
being exited and on whether changes have been made. If changes have been made,
the selected exit options and commands determine whether the changes are saved.
Exit options and commands are discussed below on a screen by screen basis.

Exiting the Calendar Definition Screen

Use any of the following commands, or press the corresponding PFKey, to exit the
Calendar Definition screen:

Table 134 Commands for Exiting the Calendar Definition Screen

Command Description
CANCEL Cancel the changes made to the calendar definition and return to the
Year List screen.
Note: The following exit commands retain changes to the calendar definition in memory.
To permanently save the changes to disk, you must also request that the changes be saved
when you exit the Year List screen.
END (PF03/PF15) Keep changes to the calendar definition in memory and exit to the Year
Enter List screen.
NEXTYEAR Keep changes to the calendar definition in memory and display the next
(PF11/PF23) calendar definition in the Year List screen.
PREVYEAR Keep changes to the calendar definition in memory and display the
(PF10/PF22) previous calendar definition in the Year List screen.

Chapter 2 Online Facilities 331

Exiting the Year List Screen

Exiting the Year List Screen

Press END (PF03/PF15) to exit the Year List screen. If changes made to at least one
calendar definition have been kept in memory or if any changes have been made to
the Year List screen, the Exit Option window is displayed. For more information, see
“Exiting the Calendar Definition Screen” on page 331.

Figure 108 Year List Screen Exit Option Window

LIST OF YEARS IN IOA.PROD.CAL CALENDAR WORKDAYS
COMMAN +-----------------------------------------------------------+ ===> CRSR
OPT N | PLEASE SELECT EXIT OPTION |
1 | |
1 | SAVE CREATE |
1 | |
====== | LIBRARY IOA.PROD.CAL | << =====
| TABLE WORKDAYS |
| |
+-----------------------------------------------------------+

OPTIONS: S SELECT D DELETE I INSERT W INSERT BY WEEK DAYS C COPY 08.53.50

The LIBRARY and TABLE (member) fields indicate the library and member in which
the calendar definitions must be saved. The specified values can be modified (for
example, to save the calendar definitions in a different member).

■ To save all changes currently in memory and exit the Year List screen, type Y (Yes)
after the word SAVE or CREATE:

— Type Y after the word SAVE if a member with the same calendar name already
exists in the specified library.
— Type Y after the word CREATE if a member with the same calendar name does
not exist in the specified library.

NOTE
If you create a new calendar member, the member name does not appear in the Calendar List
screen upon exiting the Year List screen; it first appears when you reenter the Calendar List
screen from the entry panel.

■ To cancel changes currently in memory and exit the Year List screen, type N (No)
after the word SAVE or CREATE.

■ To close the Exit Option window and remain in the Year List screen (with the
changes remaining in memory), press RESET (PF04/PF16).

332 Control-M for z/OS User Guide

 Exiting the Calendar List Screen

Exiting the Calendar List Screen

Press END (PF03/PF15) to exit the Calendar List screen.

Exiting the Entry Panel

Press END (PF03/PF15) to exit the entry panel.

Utilities Under ISPF

Several IOA facilities can only be activated under ISPF. To activate these facilities,
select option 6 on the IOA Primary Option menu (under ISPF) or invoke the IOAUTIL
CLIST from the TSO Command Processor. The IOA Online Utilities menu is
displayed.

NOTE
The INCONTROL administrator can remove user authority to access option 6 on the IOA
Primary Option menu. In this case, the IOA Online Utilities menu is not displayed.

IOA Online Utilities Menu

Depending on the INCONTROL products that are available at your site, different
online utility options are displayed in the On-line Utilities menu. Figure 109 shows
the IOA On-line Utilities menu that is displayed when all applicable INCONTROL
products are active.

Chapter 2 Online Facilities 333

I1: Add, Check, or Delete a Prerequisite Condition

Figure 109 IOA Online Utilities Menu when all INCONTROL Products are Installed
------------------------------ ON-LINE UTILITIES ------------------------------
USERID - N06
TIME - 13:40
TERMINAL - 3278

D1 DECOLLATING - Schedule a Report Decollating Mission

D2 PRINT - Schedule a Printing Mission
D3 BACKUP/MIGRATION - Schedule a Backup/Migration Mission
D4 RESTORE - Schedule a Restore Mission
I1 PREREQ CONDITION - Add/Check/Delete a Prerequisite Condition
M1 JOB ORDER ISSUE - Issue a Job Order
M2 AUTOEDIT SIMUL - Perform an AutoEdit Simulation
M3 SIMUL/TAPE PULL - Prepare Simulation/Tape Pull List Job
M4 PARAM PROMPTING - Parameter Prompting Facilities
M5 QUICK SCHEDULE - Quick Schedule Definition
M6 USER INTERFACE - End-User Job Order Interface
R1 CTM/RESTART SIM - Control-M/Restart Simulation
R2 DATASET CLEANUP - Control-M/Restart Dataset Cleanup
R3 JOB DATASET LIST - Prepare a Job Dataset List
R4 STANDALONE - Control-M/Restart Standalone
T1 CONTROL-M/Tape SIMUL - Simulate Control-M/Tape Rules
X EXIT - Exit This Menu

OPTION ===>

NOTE
If DOCU/TEXT has also been installed at your site, an additional utility, option U1, is
displayed in the Online Utilities menu.

To access an available utility, type the desired option number in the OPTION field
and press Enter.

Options I1, M1, M2, M3, M4, M5, and M6, which are also available when Control-M is
installed as a standalone product are described on the following pages. For the
descriptions of other utilities on the menu, see the user guides of the relevant
products.

Online utility screens utilize standard ISPF profile capabilities.

Quick transfer to a utility can be performed by entering =opt from another utility
screen, or =6.opt from a non-utility screen (for example, the IOA Log screen), where
opt is the 2-character option identified on the IOA Online Utilities menu.

I1: Add, Check, or Delete a Prerequisite Condition

This utility adds prerequisite conditions to, checks the existence of prerequisite
conditions in, and deletes prerequisite conditions from, the IOA Conditions file.

334 Control-M for z/OS User Guide

 I1: Add, Check, or Delete a Prerequisite Condition

The Prerequisite Condition Utility screen, shown in Figure 110, can be displayed in
the following ways:

■ Select Option I1 in the Online Utilities menu.

■ Invoke the IOACCND CLIST from the TSO Command Processor screen.

Figure 110 Prerequisite Condition Utility Screen

----------------------- PREREQUISITE CONDITION UTILITY ---------------------
COMMAND ===>

FUNCTION ===> ADD (ADD/CHECK/DELETE)

CONDITION NAME ===> SALARY_RPT_OK

Enter either date or STAT:

CONDITION DATE ===> STAT (DDMM OR STAT)

ENTER YES TO CONTINUE ===> YES

To activate the utility, fill in the fields shown in Table 135 and press Enter:

Table 135 Prerequisite Condition Utility Screen Fields (part 1 of 2)

Field Description
FUNCTION Function to be performed. Valid values are:

■ ADD – Add the specified condition to the IOA Conditions file.

■ CHECK – Check if the specified condition exists in the IOA

Conditions file.

■ DELETE – Delete the specified condition from the IOA Conditions

file.
CONDITION Name of the prerequisite condition (1 through 39 characters) to be
NAME added, checked, or deleted. If CONDITION NAME values contain the
special characters ampersand (&) or apostrophe (‘), they must be
repeated in order to appear on the screen.

Chapter 2 Online Facilities 335

M1: Issue a Job Order

Table 135 Prerequisite Condition Utility Screen Fields (part 2 of 2)

Field Description
CONDITION 4-character date associated with the specified condition. Valid values
DATE are:

■ date – Valid date in date in mmdd or ddmm format, depending on

the site standard.

■ STAT – Static. Value assigned to conditions that are not

date-dependent, such as DATABASE-OK.
ENTER YES TO Confirmation field to prevent the unintentional addition or deletion of
CONTINUE a condition. When blank, the operation is not performed. Type YES to
add, check or delete the condition.

To exit the screen without activating the utility, press PF03/PF15.

M1: Issue a Job Order

This utility is used to issue manual job orders.

Although most job orders are requested by User Daily jobs that are automatically
submitted by Control-M, it is sometimes necessary to issue a job order manually, as in
the following situations:

■ to order a special purpose job

■ to issue a job order for a different working date, for example
— to reschedule a job run from the 1st of the next month to the 30th of this month
— to reschedule the run of an entire table (one that was not defined as a SMART
Table) from the 4th of the month to the 5th of the month because all job runs in
the table must be performed again

The utility screen (Figure 111) is displayed in the following ways:

■ Select option M1 on the Online Utilities menu.

■ Activate CLIST CTMJOBRQ from the TSO Command Processor.

336 Control-M for z/OS User Guide

 M1: Issue a Job Order

Figure 111 Job Request Utility Screen

---------------------------- JOB REQUEST UTILITY ---------------------------
COMMAND ===>

SCHEDULING LIBRARY ===> CTM.PROD.SCHEDULE

TABLE NAME ===>

JOB NAME ===> (* for all jobs)

TABLE NAME ===> (* for all tables)

SCHEDULED RUN DATE ===> 06 06 01 (ODATE - format MM DD YY)

WAIT FOR ODATE ? ===> NO (YES,NO)

FORCED SCHEDULING ===> NO (YES,NO)

ENTER YES TO CONTINUE ===>

CALENDAR LIBRARY ===> IOA.PROD.CAL

To activate the utility, fill in the fields shown in Table 136 and press Enter:

Table 136 Parameters of the Job Request Utility Screen (part 1 of 2)

Parameter Description
SCHEDULING Name of the scheduling library containing the table or jobs to be
LIBRARY scheduled.
TABLE NAME Name of the table (member).
JOB NAME Name of the job to be scheduled.

If you type an asterisk (*) in this field, all jobs in the specified table
are ordered.
TABLE NAME Name of the table to be scheduled.

If you type an asterisk (*) in the field, all groups in the specified table
are eligible for ordering. The Table name and Job name are logically
‘ANDED’ to determine whether a job will be selected for scheduling.
SCHEDULED RUN Original scheduling date of the job or jobs. The default is the current
DATE working date.
WAIT FOR ODATE For a description of the WAIT FOR ODATE parameter, refer to
page 158.

Chapter 2 Online Facilities 337

M2: Perform an AutoEdit Simulation

Table 136 Parameters of the Job Request Utility Screen (part 2 of 2)

Parameter Description
FORCED Determines whether the specified job or jobs are forced.
SCHEDULING
Valid values are:

■ Y (YES) – Schedule the job (or jobs) even if the requested date is
not a scheduling date for the job according to its basic scheduling
parameters.

■ N (NO) – Schedule the job (or jobs) only if the requested date
satisfies the basic scheduling criteria of the job.
Note: Jobs in SMART Tables must be forced. Merely ordering them
is not sufficient.
ENTER YES TO Confirmation field to help prevent the job (or jobs) from being
CONTINUE unintentionally run.

Valid values are:

■ Y (Yes) – The job will run.

■ ' ' (Blank) – The job will not run.
CALENDAR Name of the calendar library (if used) for scheduling the job or jobs.
LIBRARY If no calendar library name is specified, the utility uses the calendar
library or libraries that are allocated to the DACAL DD name in the
online environment.

To exit the screen without activating the utility, press PF03/PF15.

M2: Perform an AutoEdit Simulation

This utility checks AutoEdit control statement syntax in jobs. It is essential that the
syntax of AutoEdit control statements be checked while the member is being
prepared. Otherwise, Control-M may detect an AutoEdit syntax error during job
submission in the production environment and cancel the submission.

The utility can be initiated either online (through this screen) or by batch procedure
CTMAESIM. For more information, see “Testing AutoEdit Syntax” on page 806.

To activate the utility online, display the utility screen in either of the following ways:

■ Select option M2 on the Online Utilities menu

■ Activate CLIST CTMCAES from the TSO Command Processor

338 Control-M for z/OS User Guide

 M2: Perform an AutoEdit Simulation

NOTE
By default, the utility allocates several files with the TSO user ID as the file name prefix. To
change this, activate CLIST from the TSO Command Processor as follows:

TSO CTMCAES PREFX(alternate-prefix)

The CTMCAES utility can operate in either JCL library mode or scheduling library
mode:

■ In JCL Library mode, the utility checks the AutoEdit statements in the job’s JCL.

■ In scheduling library mode, the utility not only checks the AutoEdit statements in
the job’s JCL, it also checks the impact that SET VAR statements in the job
scheduling definition have on the job’s JCL.

NOTE
Started tasks (STCs) are not supported in scheduling library mode.

This facility simulates the actions of the Control-M submission mechanism and
produces a printed report of the process.

The output of the simulation process is a standard print file containing

■ input control statements

■ log messages of the submission process
■ actual lines that are submitted under the same conditions

NOTE
During AutoEdit simulation, some variables may not contain valid or expected values. For
example, %%$RBC is always blank and %%ORDERID is ZZZZZ.

Chapter 2 Online Facilities 339

M2: Perform an AutoEdit Simulation

Figure 112 Control-M AutoEdit Simulation Screen

------------------- PERFORM CONTROL-M AUTOEDIT SIMULATION --------------------
COMMAND ===>

SPECIFY JCL LIBRARY OR SCHEDULE LIBRARY INFORMATION

JCL LIBRARY MODE:

JCL LIBRARY ===> CTM.PROD.JCL
MEMBER NAME ===> BRCCIND
OWNER ===> M21
APPLICATION NAME ===>
TABLE NAME ===>
SCHEDULE RBC NAME ===>

SCHEDULING LIBRARY MODE:

SCHEDULING LIBRARY ===>
TABLE NAME ===>
JOB NAME ===>

PARAMETER LIBRARY ===> CTMP.PROD.PARM

WDATE ===> 06 06 01 (DD MM YY)
ODATE ===> 06 06 01 (DD MM YY)
FUNCTION ===> LIST (LIST/SUBSCAN/SUBMIT)

Enter YES to continue ===>

The submission simulation utilizes control statements that are written to

DD statement DASIM. These control statements are based on the parameters
described below.

Depending on the mode in which the utility operates, either JCL library mode or
scheduling library mode parameters (but not both) must be specified. In addition,
General simulation parameters must also be specified.

To activate the utility, fill in the parameters and press Enter.

JCL Library Mode Parameters

Table 137 JCL Library Mode Parameters

Parameter Description
JCL LIBRARY Name of the JCL library from which the required JCL is to be
“submitted” by the AutoEdit simulation.
MEMBER NAME Name of the JCL member to be “submitted” by the AutoEdit
simulation.
OWNER User ID of the job’s owner.
APPLICATION Name of the application as specified in field APPL in the job
NAME scheduling definition.
TABLE NAME Name of the table to which the job belongs.

340 Control-M for z/OS User Guide

 M2: Perform an AutoEdit Simulation

Scheduling Library Mode Parameters

Table 138 Scheduling Library Mode Parameters

Parameter Description
SCHEDULING Name of the library containing the job scheduling definition.
LIBRARY
TABLE NAME Name of the table containing the job scheduling definition.
JOB NAME Name of the job scheduling definition.

NOTE
When specifying scheduling library mode parameters, values for owner, application name,
and the JCL library and member of the job are not specified because the utility takes these
values directly from the specified job scheduling definition.

The name of the JCL member is obtained from the OVERLIB parameter (if specified) instead
of the MEMLIB member.

Table 139 AutoEdit Simulation (part 1 of 2)

Parameter Description
CONTROL-M Name of the library that contains the members referenced by
GLOBAL LIBRARY AutoEdit statement %%GLOBAL.
WDATE Working date of the job.
ODATE Original scheduling date of the job.
FUNCTION Function to be performed by the simulation. Valid values are:

■ LIST – The utility simulates submission of the member from the

designated library using the specified date and user ID
parameters. Control-M checks the JCL. The output is displayed
on the terminal. The JCL is not actually submitted.

■ SUBMIT – Control-M attempts to resolve the AutoEdit

statements. If successful, the JCL member lines are also written
to the file referenced by the DASUBMIT DD statement and the
member is submitted by the utility for execution. In this case,
MVS also checks the JCL. This option can also be used to submit
jobs when the Control-M monitor is not active (for example, if
there is a severe technical problem).

■ SUBSCAN – This function is similar to SUBMIT except that it

adds a TYPRUN=SCAN parameter to the job card before
performing simulation. As a result, the job is submitted and the
JCL is checked by MVS but the job is not executed.

Chapter 2 Online Facilities 341

M3: Prepare Simulation/Tape Pull List Job

Table 139 AutoEdit Simulation (part 2 of 2)

Parameter Description
Note: When executing the AutoEdit simulation SUBSCAN function,
any JES statements that can cause the console subsystem to be
triggered are removed from the job's runstream. Examples of such
JES2 statements are:

/*MESSAGE
/*NETACCT
/*NOTIFY
/*OUTPUT
/*PRIORITY
/*ROUTE
/*SIGNxxx
/*SETUP
/*XMIT

JES3 statements that have similar effects are also removed.

Utilize this function also if a JCL-checking product (other than
JOB/SCAN or PRO/JCL) is in use at the site. The utility creates a
copy of the JCL member with all Control-M AutoEdit variables
resolved. The JCL-checking product can then be invoked against this
copy.

■ JOBSCAN – This option is available at sites where the

JOB/SCAN or PRO/JCL product is installed, but only if the
utility is activated from the Online Utilities menu. (This option is
not displayed and cannot be used if the utility is activated by a
CLIST or batch procedure.) This function is similar to SUBMIT
except that if Control-M finds no JCL errors, JCL is checked by
JOB/SCAN before it is written to the file referenced by the
DASUBMIT DD statement.
Enter YES to continue Confirmation field to help prevent the simulation jobs from being
unintentionally run. When blank, the jobs do not run. Enter YES to
enable the job run.

To exit the screen without activating the utility, press PF03/PF15.

M3: Prepare Simulation/Tape Pull List Job

This screen is used to activate the Simulation procedure or the Tape Pull List
procedure. The screen can be displayed in the following ways:

■ Select option M3 from the Online Utilities menu

■ Activate CLIST CTMCSIM from the TSO Command Processor

342 Control-M for z/OS User Guide

 M3: Prepare Simulation/Tape Pull List Job

Figure 113 Control-M Simulation and Forecasting Facility and Tape Pull List
------- CONTROL-M SIMULATION AND FORECASTING FACILITY AND TAPE PULL LIST -----
COMMAND ===>

RUN SIMULATION ===> Y (Y-to run, N-skip to reports)

From ===> 200106030900 (Format YYYYMMDDhhmm)
Until ===> 200106031600 (Format YYYYMMDDhhmm)
ON Today's-current AJF ===> Y (Y/N If "N", fill in the date)
Another day - DATE ===> (DD MM YY)
Create new AJF ===> N (Y/N)
Order daily jobs ===> N (Y/N)
Keep output AJF,RES ===> Y (Y/N)
Parameters member ===> SIMPARM (Simulation parameters)
REPORTS Jobs left ===> Y (Y/N)
Night schedule ===> Y (Y/N)

TAPE PULL LIST ===> N (Y/N)

Report by VOLSER ===> Y (Y/N)
Report by TIME ===> Y (Y/N)
Report by JOBNAME ===> N (Y/N)
Report by DSN ===> N (Y/N)
Parameters member ===> TAPULPRM (Tape pull parameters)

Enter YES to continue ===> YES or END key to EXIT

The Simulation facility simulates the actions of the Control-M monitor under the
conditions specified in the simulation parameters.

Online simulation is performed in the CPU without updating the simulation input
files, or without performing any other I/O procedure.

NOTE
At sites supporting the JOB/SCAN, PRO/JCL, or DOCU/TEXT Interface, the lower portion of
the Simulation screen is modified to contain the INVOKE JOBSCAN parameters.

The Tape Pull List procedure creates a list of all tapes to be mounted in a specified
period, taking into account the expected order of job execution and the order of
creation of tape data sets. The list can be sorted and edited in various ways.

This utility also provides the following benefits:

■ It checks the syntax of all AutoEdit statements in all jobs that are planned for the
given period.

■ It checks the JCL syntax.

■ It produces a list of data sets that are not available. These are usually input data
sets due to arrive, but they may indicate JCL errors. For more information, see the
discussion of CTMRNSC, the night schedule report, in the INCONTROL for z/OS
Utilities Guide.

Chapter 2 Online Facilities 343

M3: Prepare Simulation/Tape Pull List Job

NOTE
For the Tape Pull List procedure to execute properly, authority must be granted for the
submission of jobs to the internal reader (INTRDR).

For more information about Simulation and Tape Pull List procedures, see Chapter 7,
“Simulation and Forecasting Facility.”

To activate this online utility, fill in the fields and sub-fields shown in Table 140, and
press Enter.

Table 140 Fields of the Control-M Simulation and Forecasting and Tape Pull List
Screen (part 1 of 4)
Field Description
RUN SIMULATION Fields:
RUN SIMULATION Whether to run the simulation. Valid values are:

■ Y (Yes) – Run the simulation. The results of the

simulation run are kept in the Log file and the Active
Jobs file (AJF) and can be used for producing reports
and/or the tape pull list. Default.

■ N (No) – Do not run the simulation. Use the results of a

prior simulation to produce reports and/or the tape
pull list.
From Simulation start date and time, in the format
yyyymmddhhmm.
Until Simulation end date and time, in the format
yyyymmddhhmm.
ON Fields:
ON Today’s-current AJF Whether to use “Today’s” data (that is, the data currently
in the AJF) as input for the simulation. Valid values are:

■ Y (Yes) – Use “Today’s” data. If you choose this option,

BMC Software recommends that you run the
simulation after “Today’s” jobs have been placed on
the AJF using New Day processing. Default.

■ N (No) – Use data from the date specified in the

Another Day - DATE field.
Another day - DATE Date to use for scheduling or ordering simulation jobs. The
format is ddmmyy, mmddyy, or yymmdd, depending on
your site standard. A valid date must be entered when not
using “Today’s” data (that is, if N is entered in the
Today’s-current AJF field.)

344 Control-M for z/OS User Guide

 M3: Prepare Simulation/Tape Pull List Job

Table 140 Fields of the Control-M Simulation and Forecasting and Tape Pull List
Screen (part 2 of 4)
Field Description
Create new AJF Whether to allocate a new AJF to contain jobs for the
simulation. Valid values are:

■ Y (Yes) – Allocate a new AJF. This value must be

specified when not using the data currently in the AJF,
that is, if N is entered in the Today’s-current AJF field.

■ N (No) – Do not allocate a new AJF. This value must be

specified when using the data currently in the AJF, that
is, if Y is entered in the Today’s-current AJF field.
Default.
Order daily jobs Whether to load into the new AJF all the jobs that are
scheduled to execute on the specified date. Valid values
are:

■ Y (Yes) – Load the jobs into the AJF. A User Daily step
is entered into the job. This step schedules all the jobs
based on their basic scheduling criteria. It is the user’s
responsibility to ensure that the Table list for this job is
up-to-date.
This value must be specified when not using
“Today’s” data and when creating a new AJF, that is, if
N is entered in the Today’s-current AJF field and Y is
entered in the Create new AJF field.

■ N (No) – Do not load the jobs into the AJF. This value
is generally specified when using “today’s” data or
when not creating a new AJF (that is, if Y is entered in
the Today’s-current AJF field or N is entered in the
Create new AJF field.) Default.
Keep output AJF,RES Specifies whether to save the output AJF, the IOA
Conditions file, and the Control-M Resources file (that is,
the files as they appear at the end of the simulation.) The
output files must be kept if you plan to produce reports,
such as a Jobs Left report, based on these files. Valid values
are:

■ Y (Yes) – Keep the output files. Default.

■ N (No) – Do not keep the output files.

Parameters member Name of the member in the CTM PARM library that
contains the simulation parameters. This member may
contain parameters such as INTERVAL, ADD COND, and
so on.

Default: SIMPARM
REPORTS Fields:

Chapter 2 Online Facilities 345

M3: Prepare Simulation/Tape Pull List Job

Table 140 Fields of the Control-M Simulation and Forecasting and Tape Pull List
Screen (part 3 of 4)
Field Description
Types of reports to be produced. Valid values for each report type are:

■ Y – the report type is generated

■ N – the report type is not generated
Note: This part of the panel is often site-modified. The following are the default report types:
Jobs left This report lists the jobs that did not end OK by the end of
the simulation (jobs in status WAIT SCHEDULE,
EXECUTING, ENDED NOTOK, and so on). This report is
identical to KeyStroke Sample report REPJOBMO in the
IOA.KSL library. Default: Y
Night schedule This report provides a job execution time summary. For
more information, see the discussion of CTMRNSC, the
night schedule report, in the INCONTROL for z/OS Utilities
Guide. Default: Y
TAPE PULL LIST Fields:
TAPE PULL LIST Specifies whether to run the Tape Pull List procedure. The
accompanying “Report by” fields specify whether to
generate individual Tape Pull reports. Valid values for this
field and the accompanying “Report by” fields are:

■ Y (Yes) – Generate the report.

■ N (No) – Do not generate the report
Report by VOLSER This report is sorted by volume serial number (this
includes all tapes from the tape library). Default: Y
Report by TIME This report is sorted by the expected mount time. Default:
Y
Report by JOBNAME This report is sorted by job name. Default: N
Report by DSN This report is sorted by data set name. Default: N.
Parameters member Name of the member in the CTM PARM library that
contains the Tape Pull parameters. This member may
contain parameters such as REPBYVOL, REPBYTIME, or
REPBYJOB. Default: TAPULPRM
INVOKE JOBSCAN Fields:
INVOKE JOBSCAN These parameters apply only if the JOB/SCAN, PRO/JCL,
or DOCU/TEXT Interface is installed at your site. Valid
values for the accompanying fields are Y (Yes) or N (No).
Only one Y value can be entered.

■ Y (Yes) – JOBSCAN or PRO/JCL is invoked, the

validation is performed, and the appropriate report is
displayed in the utility output.

■ N (No) – The specified validation is ignored.

346 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

Table 140 Fields of the Control-M Simulation and Forecasting and Tape Pull List
Screen (part 4 of 4)
Field Description
JCL Checking If Y is entered

■ checks the JCL specified in the member referenced by

the DAJCLOUT DD statement for errors

and

■ checks for adequate DASD disk space allocation.

Errors Only If Y is entered, checks for JCL errors only.
Space Report If Y is entered, checks for adequate DASD disk space
allocation only.
Enter YES to continue Field:
Enter YES to continue When set to blank, the jobs are not generated. This
prevents the simulation or tape pull list jobs from being
unintentionally generated.

Type YES to enable the job run. The file of the simulation
job as tailored to your specifications is displayed in ISPF
EDIT. You can submit it, save it for future use, and so on.

Default: YES

To exit the screen without activating either facility, press PF03/PF15.

M4: Parameter Prompting Facilities

Control-M Parameter Prompting facilities provide an automatic online interface for
assigning values to AutoEdit parameters in the JCL. These facilities prompt the user
for values requiring manual modification.

These facilities eliminate the need to remember which AutoEdit parameters require
assignment each day, the location of AutoEdit members, and the manual conditions
that need to be added (Screen 7).

To display the Parameter Prompting entry panel (below), select option M4 on the
Online Utilities menu.

Figure 114 Parameters Prompting Entry Panel

------------------- CONTROL-M PARAMETER PROMPTING ----------------------------
OPTION ===>
USERID - M14
TIME - 21:05
TERMINAL - 3278

Chapter 2 Online Facilities 347

M4: Parameter Prompting Facilities

1 CTMCFMNU - Parameter Prompting Facility - TYPE 1

2 CTMCAMNU - Parameter Prompting Facility - TYPE 2

X EXIT - Terminate this menu

Two different prompting facilities are available:

■ Parameter Prompting facility – TYPE 1

■ Parameter Prompting facility – TYPE 2

Using these facilities requires a basic understanding of JCL, the AutoEdit facility, and
the concept of prerequisite conditions.

An brief introduction to each of these two types of facilities is presented before the
description of the screens in that facility.

NOTE
For a much more detailed explanation of how the Parameter Prompting facilities work, how
they differ from each other, and how to choose the facility that best suits your operational
needs, see the discussion of that topic in “Parameter Prompting Facilities” on page 837.

Introduction to Parameter Prompting Facility - Type 1

The Parameter Prompting facility – Type 1 is an ISPF table based facility that provides
automatic prompting for AutoEdit parameter values and setting of prerequisite
conditions.

This facility is the recommended method for updating AutoEdit parameter members
when the parameter value requires manual specification or modification. Frequently,
such parameters are associated with prerequisite conditions that must also be
manually added to the IOA Conditions file (from the Manual Conditions file).

Example

Tape ABC, which is required by a particular job, arrives from an external location.
The volume serial number must specified in the AutoEdit parameter
%%ABC_TAPENO, and the condition TAPE_ABC_ARRIVED must be added to
the IOA Conditions file, before the job can run.

348 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

Without this facility, the user (generally operations personnel) must access the
appropriate AutoEdit member and update the parameter value, and must enter the
Manual Conditions screen to manually add the required condition to the IOA
Conditions file.

With this facility, the user is prompted for the required value. The facility
automatically updates the AutoEdit member and adds the related condition to the
IOA Conditions file.

Parameter Prompting facility – Type 1 works basically as follows:

1. Using the first option of the facility (DEFINE PARAMETERS AND CREATE A
NEW MASTER TABLE), groups of AutoEdit parameters that require value
assignment are defined once. These parameters are grouped into a Master
Prompting table, the Master table. Default parameter values can be assigned. In
addition, prerequisite conditions to be associated with parameters are designated.

The administration of the parameter prompting facility can be decentralized by

user groups or applications by choosing a unique Control-M Prompt library on the
Primary menu for each application. Master tables defined in a specific Prompt
library will be available for update (in option 2) only when that Prompt library is
coded on the primary menu. This permits different applications to be concerned
only with the master tables associated with that application without cross-
interference with other user groups or applications. This design also simplifies
security issues.

2. During daily processing, specification of values is made using option 2 (UPDATE

PARAMETERS AND SET CONDITIONS). The user selects the desired table from
the list of Master tables and is presented with Daily Prompting table - an
automatically created copy of the Master table for the current date.

The Daily Prompting table consists of parameter names, (optional) descriptions,

and default values. The user updates the desired parameters with the appropriate
values.

The facility automatically adds the appropriate conditions to the IOA Conditions
file and updates the daily AutoEdit member with the specified values.

Screens of the Parameter Prompting Facility (Type 1)

After selecting option 1 of the Control-M Parameter Prompting entry panel, the
screen shown in Figure 115 is displayed:

Figure 115 Parameter Prompting Facility (Type 1) Primary Menu

---- CONTROL-M - PARAMETER PROMPTING FACILITY (TYPE 1) PRIMARY MENU --------(P)
OPTION ===>

Chapter 2 Online Facilities 349

M4: Parameter Prompting Facilities

1 DEFINE PARAMETERS AND CREATE A NEW MASTER TABLE

2 UPDATE PARAMETERS, SET CONDITIONS AND DELETE TABLES

OPTIONS:
PARAMETER DESCRIPTION WILL BE DISPLAYED ===> NO (YES/NO)

IOA CORE PREFIX ===> IOA.PROD

CONTROL-M PROMPT LIB ===> CTM.PROD.PROMPT

CONFIRM PARAMETER UPDATE ACTIONS ===> YES (YES/NO)

ENTER END COMMAND OR PF3 TO TERMINATE

NOTE
You can enter this screen directly by activating CLIST CTMCFMNU.

This screen displays the following options:

1. Define Parameters and Create a New Master Table

This option defines groups of parameters. The definition and association with any
prerequisite condition is performed only once per parameter.

2. Update Parameters and Set Conditions

This option is accessed daily (or multiple times in one day) to assign values to
parameters and set prerequisite conditions.

The IOA Core Prefix used at your site appears as a default. Files with this prefix are
accessed by the Parameter Prompting facility to add prerequisite conditions. Usually,
there is no need to change the value of this field.

The library in which the Control-M prompting tables will be placed appears as a
default, and can be changed. The ability to decentralize the administration of the
parameter prompting facility by using different Control-M prompting libraries is
discussed in “Introduction to Parameter Prompting Facility - Type 1” on page 348.

The Confirm Parameters Update Actions field determines whether a confirmation

window is displayed following update requests in the Update Parameters and Set
Conditions screen, which is described in “Option 2: Update Parameters and Set
Conditions” on page 353.

350 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

Option 1: Define Parameters and Create a New Master Table

After selecting option 1 of the Parameter Prompting facility (Type 1) Primary menu,
the screen shown in Figure 116 is displayed:

Figure 116 Define Parameters and Condition - New Master Table Screen
---- CONTROL-M - P.P.F. - DEFINE PARAMETERS AND CONDITIONS ---------------(P.1)
COMMAND ===>

TABLE NAME PREFIX ===>

Please fill in the TABLE NAME PREFIX and press ENTER

ENTER END COMMAND OR PF3 TO TERMINATE

Fill in a Table Name Prefix (a maximum of three characters) and press Enter.

A Master table is usually defined for a group of AutoEdit parameters controlled by

one person or project.

If the table does not exist (because you are attempting to define a new table), the
screen shown in Figure 117 is displayed:

Figure 117 Define Parameters/ and Conditions - Master Table Definition Screen
---- CONTROL-M - P.P.F. - MASTER TABLE DEFINITION ----------------------(P.1.2)
COMMAND ===>
CTMB14E MASTER TABLE TAPTMSTR WAS NOT FOUND. YOU MAY CREATE IT, OR EXIT

TABLE NAME PREFIX ===> TAP

DESCRIPTION ===> EXTERNAL TAPE DATA

Please fill in the Table Description and press ENTER

ENTER END COMMAND OR PF3 TO TERMINATE

You can create a new table or exit the screen. To create a new table, enter a table
description and press Enter.

Chapter 2 Online Facilities 351

M4: Parameter Prompting Facilities

Define Parameters and Conditions Screen

After creation of a new table, or if the table exists, the following screen is displayed. If
the table exists, the previously defined parameters and associated conditions are
displayed for modification.

Figure 118 Define Parameters and Conditions Screen

---- CONTROL-M - P.P.F - DEFINE PARAMETERS AND CONDITIONS ------- ROW 1 OF
COMMAND ===> SCROLL ===> PAGE
PARM PREFIX ===> TABLE NAME : TAPTMSTR
-----------------------------------------------------------------------------
_ PARM ===> IRS_TAPE
VALUE ===>
DESC. ===> WEEKLY TAPE FROM IRS
CONDITION => IRS-TAPE-ARRIVED
-----------------------------------------------------------------------------
_ PARM ===> A_BANK_TAPE
VALUE ===> XXXX
DESC. ===> TAPE FROM BANK GROUP A
CONDITION => MN-A-BANK-TAPE-READY
****************************** Bottom of Data *******************************

This screen is used to define, display and modify parameters and optional
prerequisite conditions that are used for prompting on a daily basis.

Specifying Retrieval Criteria

The display of parameters can be limited to parameters beginning with a specific

prefix by filling in the PARM PREFIX field.

To display the first occurrence of a parameter at the top of a screen, use the line
command L xxxx, where xxxx is a specific parameter or parameter prefix.

Define Parameters and Conditions Screen – Format

The following information can be defined, displayed, or modified for each parameter:

Table 141 Define Parameters and Conditions Screen – Format

Format Description
PARM Name of the AutoEdit parameter.
CONDITION Name of a prerequisite condition to be added to the IOA Conditions
file when this parameter is updated. Optional.
VALUE A default parameter value. Optional.
DESC A meaningful description of the parameter.

352 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

Define Parameters and Conditions Screen – Options

To request one of the following options, type the option in the field to the left of the
word PARM and press Enter.

Table 142 Define Parameters and Conditions Screen – Options

Option Description
DELETE Delete a parameter from the table.
REPEAT Duplicate a parameter.
ADD Add a parameter (same as option R).
INSERT Insert a new parameter in the table. INSERT typed on the Command
line inserts a new parameter at the top of the table.

Changes made to a parameter are updated in the plan when you press Enter, even if
no option is specified.

Define Parameters and Conditions Screen – How to Exit

To exit the Define Parameters and Conditions screen, press END (PF03/PF15).

If additions or modifications have been made, the Save window shown in Figure 119
is displayed:

Figure 119 Define Parameters and Conditions Save Screen Window

---- CONTROL-M - P.P.F. - DEFINE PARAMETERS AND CONDITIONS --------------------
COMMAN +-----------------------------------------------------------+
| PLEASE SELECT EXIT OPTION |
| |
| SAVE (Y/N) |
| |
| LIBRARY CTM.PROD.PROMPT |
| TABLE TAP |
| |
+-----------------------------------------------------------+

Type Y (Yes) to save the changes. Type N (No) to cancel the changes.

Option 2: Update Parameters and Set Conditions

After selecting option 2 of the Parameter Prompting facility (Type 1) Primary menu,
the Table Selection screen is displayed.

Chapter 2 Online Facilities 353

M4: Parameter Prompting Facilities

Figure 120 Update Parameters and Set conditions - Table Selection Screen
---- CONTROL-M - P.P.F. - TABLE SELECTION ------------------------- Row 1 of 3
COMMAND ===> SCROLL ===> PAGE
TABLE PREFIX ===>
-------------------------------------------------------------------------------
_ TABLE NAME ===> BAK DATE ===> 06 / 06
LIBRARY : CTM.PROD.PROMPT
DESCRIPTION: BACKUP CRITERIA
_ TABLE NAME ===> REP DATE ===> 06 / 06
LIBRARY : CTM.PROD.PROMPT
DESCRIPTION: REPORTING CRITERIA
_ TABLE NAME ===> TAP DATE ===> 06 / 06
LIBRARY : CTM.PROD.PROMPT
DESCRIPTION: EXTERNAL TAPE DATA
******************************** Bottom of Data *******************************

This screen displays a list of Daily Prompting tables available for update. A Daily
table is a copy of a Master Table specific to a particular business day. It is accessed in
order to assign values to (previously defined) parameters and to set conditions. The
Daily table can be accessed multiple times on the same day.

When you enter this screen, the current date is displayed for each Daily Table. You
can overwrite the date to select a different date.

Table deletion can be performed from this screen by typing option D (Delete) in the
selection field to the left of TABLE NAME and pressing Enter. A Delete Confirmation
window is displayed.

Figure 121 Table Selection Screen Delete Confirmation Window

---- CONTROL-M - P.P.F. - TABLE SELECTION ------------------------- Row 1 of 3
COMMAND ===> SCROLL ===> PAGE
TABLE PREFIX ===> +-----------------------------------------------+
----------------------- | CONFIRM DELETE OPTION | ----
D TABLE NAME ===> BAK | <<=== < N > (Y/N) |
LIBRARY | |
DESCRIPTIO | DELETE DAILY PROMPT TABLE ONLY ===> N (Y/N) |
_ TABLE NAME ===> REP +-----------------------------------------------+
LIBRARY : CTM.PROD.PROMPT
DESCRIPTION: REPORTING CRITERIA
_ TABLE NAME ===> TAP DATE ===> 06 / 06
LIBRARY : CTM.PROD.PROMPT
DESCRIPTION: EXTERNAL TAPE DATA
******************************** Bottom of Data ******************************

The Delete Confirmation window also enables you to choose the type of deletion
desired.

Type Y (Yes) to confirm the deletion. When deletion is requested, then by default the
table is deleted from the Table list, and both the Master Prompting table and the
current Daily table are deleted from the Prompting library.

354 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

To delete the current daily table without deleting the table from the Table list and
without deleting the Master Prompting table from the Prompting library, type Y in
the DELETE DAILY TABLE ONLY field. In this case, only the current daily table and
the corresponding daily AutoEdit member are deleted. The setting of the DELETE
DAILY TABLE ONLY field is preserved in a profile variable for ease of subsequent use.
This is useful if the Master Prompting table has been updated. To reflect those
changes in the Daily table and the AutoEdit member, the current Daily table must be
deleted, and then be reselected again.

To select a table for any action other than deletion, enter any character except D in the
selection field to the left of TABLE NAME and press Enter.

The display of tables can be limited to those tables beginning with a prefix of 1
through 3 characters by filling in the TABLE PREFIX field. The TABLE PREFIX is
retained as an ISPF profile variable from one invocation of the Table Selection screen
to the next.

To display the first occurrence of a table at the top of the screen, use the line
command L xxxx, where xxxx is a specific parameter or parameter prefix (under the
command line).

Update Parameters and Set Conditions Screen

After table selection, the screen shown in Figure 122 is displayed:

Figure 122 Update Parameters and Set Conditions Screen

---- CONTROL-M - P.P.F. - UPDATE PARAMETERS AND SET CONDITIONS --- Row 1 of 2
COMMAND ===> SCROLL ===> PAGE
PARM PREFIX ===> TAPT1112 UPDATED ON
------------------------------------------------------------------------------
_ VALUE ===>
OF ===> IRS-TAPE
WEEKLY TAPE FROM IRS
_ VALUE ===> XXXX
OF ===> A-BANK-TAPE 06 06
TAPE FROM BANK GROUP A
****************************** Bottom of Data *******************************

This screen displays a list of all AutoEdit parameters for which values can be
updated. The following information is presented for each parameter:

Table 143 Fields of the Update Parameters and Set Conditions Screen (part 1 of 2)
Field Description
VALUE Default value of the parameter. This value can be modified.
OF Parameter name.

Chapter 2 Online Facilities 355

M4: Parameter Prompting Facilities

Table 143 Fields of the Update Parameters and Set Conditions Screen (part 2 of 2)
Field Description
Description This description appears only if the value YES was entered in the
PARAMETER DESCRIPTION WILL BE DISPLAYED field on the
Parameter Prompting facility (Type 1) Primary menu.
Date Updated The date of update is displayed in either mm dd or dd mm format
depending on the site standard.

The display of parameters can be limited to parameters beginning with a specific

prefix by filling in the PARM PREFIX field (under the command line).

To display the first occurrence of a parameter at the top of a screen, use the line
command L parm, where parm is a specific parameter or parameter prefix.

From this screen, conditions can be added to the IOA Conditions file, with or without
changing the value of the parameter.

■ To add the condition without changing the parameter value, enter any character in
the selection field to the left of the VALUE field.

■ To update a parameter value and add the condition, update the value as desired
and press Enter.

If Y (Yes) was entered for the “Confirm Parameter Update Actions” option in the
Type 1 Primary menu, the following confirmation window is displayed. Type Y to
confirm the updates (or N to cancel them).

Figure 123 Update Parameters and Set Conditions - Confirm Parameter Update
Actions
---- CONTROL-M - P.P.F. - UPDATE PARAMETERS AND SET CONDITIONS --- Row 1 from 2
COMMAND ===> SCROLL ===> PAGE
PARM PREFIX ===> TAPT1112 UPDATED ON
-------------------------------------------------------------------------------
_ VALUE ===>
OF ===> IRS-TAPE +------------------------+
WEEKLY TAPE FRO | CONFIRM UPDATE ACTION |
_ VALUE ===> XXXX | <<=== < N > (Y/N) |
OF ===> A-BANK-TAPE +------------------------+
TAPE FROM BANK GROUP A
****************************** Bottom of Data ********************************

After an update request is completed in the screen, all changes are immediately saved
in the Daily table. Any manual condition associated with this parameter prompt is
added to the IOA Conditions file.

Press END (PF03/PF15) to exit the screen.

356 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

Introduction to Parameter Prompting Facility - Type 2

The Parameter Prompting facility – Type 2 provides automatic prompting for
AutoEdit parameter values for manually scheduled jobs. This may be very useful in a
distributed environment where user departments are responsible for manually
ordering jobs and specifying required parameters.

On any given day, the user selects tables for execution. The user is then prompted for
parameter values required for the execution of those jobs.

The Parameter Prompting facility – Type 2 works as follows:

■ First, relevant tables are defined or placed in the Master Scheduling Tables library.

Then, using the CREATE AND UPDATE A MASTER PLAN option of the facility,
the user defines a Master Prompting Plan (MPP) for each table in the library. The
MMP is placed in the Master Prompting Plan library. It contains all AutoEdit
variables used by all jobs in the table. Default values and value validity checks can
also be defined.

After all definitions are complete, the facility is ready for use on any given day, as
needed.

■ The user uses the second option of the facility, FETCH A PLAN, to select a plan for
execution by Control-M on any specific day.

— When a FETCH option is executed for a specific plan (or set of plans), a Daily
scheduling table is automatically created and placed in the Daily Scheduling
Tables library. The Daily Scheduling table is a subset of the Master Scheduling
table, and contains the job scheduling definition of each job in the Master
Scheduling table scheduled that day.

— The FETCH also creates a User Prompting Plan (UPP), which is placed in the
Daily Prompting Plan library. The UPP is a subset of the Master Prompting
Plan, and contains only parameters that are required by the jobs scheduled to
run on that day.

— A Daily JCL library is also created containing JCL for the day’s jobs.

■ Using the third option of the facility, EXEC A PLAN, the user may then accept or
update the default values of all the parameters appearing in the daily UPP.

A daily AutoEdit parameters member, which is accessed at the time of job

submission, is automatically created and placed in the Daily AutoEdit Parameter
library.

Chapter 2 Online Facilities 357

M4: Parameter Prompting Facilities

Screens of Parameter Prompting Facility (Type 2)

After selecting option 2 of the Control-M Parameter Prompting entry panel, the
following menu is displayed:

Figure 124 Parameter Prompting Facility (Type 2) Primary Menu

---- CONTROL-M - PARAMETER PROMPTING FACILITY (TYPE 2) PRIMARY MENU --------(P)
OPTION ===>

1 CREATE AND UPDATE A MASTER PLAN

2 FETCH A PLAN (CTMFETCH)

3 EXEC A PLAN (CTMEXEC)

ENTER END COMMAND OR PF3 TO TERMINATE

NOTE
You can enter this screen directly by activating CLIST CTMCAMNU.

This screen displays three options:

1. CREATE AND UPDATE A MASTER PLAN

This option defines groups of parameters in a Master Prompting Plan.

2. FETCH A PLAN (CTMFETCH)

This option places a User Prompting Plan (a copy of the Master Prompting Plan)
and related job scheduling definitions in Daily libraries. A “fetch” is required
before assigning parameter values and ordering plan execution with Option 3.

3. EXEC A PLAN (CTMEXEC)

This option assigns values to parameters and orders a Plan for execution.

358 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

Option 1: Create and Update a Master Plan

After selecting Option 1 of the Parameter Prompting facility (Type 2) Primary menu,
the following screen is displayed:

Figure 125 Primary Prompting Facility – Define or Update a Master Plan

---- CONTROL-M - P.P.F. - DEFINE OR UPDATE A MASTER PLAN -----------------(P.1)
COMMAND ===>

PLAN NAME IS:

PLAN NAME PREFIX ===> REPTS

LIBRARY ===> CTM.PROD.PLANMSTR

Please fill in the Plan Name Prefix and press ENTER

ENTER END COMMAND OR PF3 TO TERMINATE

A Master Plan is usually defined for a group of jobs and their AutoEdit parameters
that are controlled by one person or project.

Type a maximum of six characters in PLAN NAME PREFIX and press Enter.

The name of the default library in which the Master Plan is placed is displayed. It
may be changed.

If the plan does not exist (because you are defining a new plan), the following screen
is displayed:

Figure 126 Parameter Prompting Facility – Master Plan Definition

---- CONTROL-M - P.P.F. - MASTER PLAN DEFINITION -----------------------(P.1.2)
COMMAND ===>
CTMB14E MASTER PLAN REPTS NOT FOUND. YOU MAY CREATE IT, OR EXIT

PLAN PREFIX NAME ===> REPTS

DESCRIPTION ===> DAILY REPORTS

LIBRARY ===> CTM.PROD.PLANMSTR

Please fill in the Plan Description and press ENTER

ENTER END COMMAND OR PF3 TO TERMINATE

Chapter 2 Online Facilities 359

M4: Parameter Prompting Facilities

You can create a new plan or exit the screen. To create a new plan, enter a plan
description and press Enter.

Define Parameters in the Master Plan

After creation of a new plan, or if the requested plan exists, the following screen is
displayed. If the plan exists, the previously defined parameters are displayed for
modification.

Figure 127 Define Parameters in the Master Plan Screen

---- CONTROL-M - P.P.F. - DEFINE PARAMETERS IN THE MASTER PLAN --- ROW 1 OF 3
COMMAND ===> SCROLL ===> CSR
PARM PREFIX ===> PLAN NAME: REPTS
------------------------------------------------------------------------------
_ PARM NAME ===> REPT_NAME OCCUR NO. ===> 01
JOB NAME ===> SLSREPTS PROMPT IND ===> Y (Y/N)
DEFAULT ===>
TYPE ===> NONBLANK,MAXL 8
MESSAGE ===> Enter name of sales report required
------------------------------------------------------------------------------
_ PARM NAME ===> DEPT_NUMBER OCCUR NO. ===>
JOB NAME ===> ******** PROMPT IND ===> Y (Y/N)
DEFAULT ===> 035
TYPE ===> NUM,MAXL 3
MESSAGE ===> Enter department number (used for all reports)
------------------------------------------------------------------------------
_ PARM NAME ===> REPT_NAME OCCUR NO. ===> 02
JOB NAME ===> EXPREPTS PROMPT IND ===> Y (Y/N)
DEFAULT ===>
TYPE ===> NONBLANK,MAXL 8
MESSAGE ===> Enter name of expense report required
****************************** Bottom of Data ********************************

This screen is used to define, display and modify parameters that are used for
prompting on a daily basis.

Define Parameters in the Master Plan Screen – Format

The following information can be defined, displayed, or modified for each parameter:

Table 144 Fields of the Define Parameters in the Master Plan Screen (part 1 of 2)
Field Description
PARM NAME Name of the AutoEdit parameter.
OCCUR NO. Occurrence number (2 digits). Differentiates between use of the same
parameter name for different purposes in different jobs (for example,
assign OCCUR NO. 01 to occurrence of %%PARM1 in Job A; assign
OCCUR NO. 02 to occurrence of %%PARM1 in Job B).

360 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

Table 144 Fields of the Define Parameters in the Master Plan Screen (part 2 of 2)
Field Description
JOB NAME Name of the job using the parameter.

If the parameter and its assigned value are shared by more than one
job in the plan, enter ******** in this field. It is not necessary to
redefine the parameter. (If the value assigned is different for each
job, refer to the OCCUR NO. parameter above.)
PROMPT IND Prompting Indicator:

■ Y (Yes) – Promptable. The user is prompted for a value for this

parameter.
■ N (No) – Non-promptable. The value is fixed in the Master
Prompting Plan and is not modifiable in the EXEC phase.
DEFAULT Default value for the parameter that is displayed during the EXEC
phase.

This field is mandatory if PROMPT IND is set to N

(non-promptable).

BLANK – Type the word BLANK to set a value of “ “.

TYPE Type of parameter value that can be entered. A validation check is
performed during both the plan definition and EXEC phases.

Valid types:

■ NUM – Limits the value to digits only (0 through 9).

■ ALPHA – Limits the value to letters only (a-z, A-Z, and $,# ,@).
■ CHAR – Alphanumeric.
■ BLANK – Field must be blank.
■ NONBLANK – Any non-blank value.
■ MINL n – Limits the value to a specified minimum character
length, where n is any number from 1 through 70.
■ MAXL n – Limits the value to a specified maximum character
length, where n is any number between 1 and 70.

MINL, MAXL, and NONBLANK can be combined with NUM or

ALPHA.

Example: NUM MAXL 8 limits the parameter value to a numeric

value with a maximum length of 8 characters.
MESSAGE Prompting message to be displayed during the EXEC phase.

The display of parameters can be limited to parameters beginning with a specific

prefix by filling in the PARM PREFIX field (under the command line).

To display the first occurrence of a parameter at the top of a screen, use the line
command L xxxx, where xxxx is a specific parameter or parameter prefix.

Chapter 2 Online Facilities 361

M4: Parameter Prompting Facilities

Define Parameters in the Master Plan Screen – Options

To request one of the following options, type the option in the field to the left of the
words PARM NAME and press Enter.

Table 145 Options of the Define Parameters in the Master Plan Screen
Option Description
D (DELETE) Delete a parameter from the plan.
R (REPEAT) Duplicate a parameter.
A (ADD) Add a parameter (same as option R).
I (INSERT) Insert a new parameter in the plan. INSERT typed on the Command line
inserts a new parameter at the top of the plan.

Changes made to a parameter are updated in the plan when you press Enter, even if
no option is specified.)

Define Parameters in the Master Plan Screen – How to Exit

To exit the Define Parameters in the Master Plan screen, type one of the following
commands on the command line:

Table 146 Define Parameters in the Master Plan Screen - Exit Screen Commands
Command Description
END Keep all plan changes, and exit.
CANCEL Exit without saving plan changes.

Option 2: Fetch a Plan (CTMFETCH)

After selecting option 2 of the Parameter Prompting facility (Type 2) Primary menu,
the following screen is displayed:

362 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

Figure 128 Fetch a Plan Screen

---- CONTROL-M - P.P.F. ------ FETCH A PLAN ------------------------------(P.2)
COMMAND ===>

PLAN NAME ===> REPTS

PLAN NAME SUFFIX ===> (For multiple plans in the same day)

OVERRIDE DAILY PLAN ===> NO (YES / NO)

ODATE ===> 080800

Please fill in the Plan Name and press ENTER

MASTER SCHEDULING LIB ===> CTM.PROD.SCHEDULE

DAILY SCHEDULING LIB ===> CTM.PROD.SCHD
MASTER PLANS LIB ===> CTM.PROD.PLANMSTR
DAILY PROMPT PLANS LIB ===> CTM.PROD.PLAN
MASTER JCL LIB ===> CTM.PROD.JCLPROMP
DAILY JCL LIB ===> CTM.PROD.JCLP

ENTER END COMMAND OR PF3 TO TERMINATE

This screen places a daily User Prompting Plan (a copy of the Master Prompting Plan)
and related job scheduling definitions in Daily libraries. Fill in the details in the
screen (libraries and the current date appear as defaults) and press Enter.

The PLAN NAME is the same as the Master Prompting Plan PREFIX.

You can designate two characters to serve as a suffix to the Plan Name. This permits
execution of a specific plan more than once a day.

Valid values for OVERRIDE DAILY PLAN:

Table 147 Fetch Plan Screen OVERRIDE DAILY PLAN Values

Value Description
YES A duplicate fetch of a plan (with a suffix, if one has been designated)
replaces an existing copy of a plan with the same PLAN NAME (and
same suffix) for that day.
NO Multiple fetches of a plan are not permitted on the same day.
Default.

Option 3: Exec / Order a Plan (CTMEXEC)

After selecting option 3 of the Parameter Prompting facility (Type 2) Primary menu,
the following screen is displayed:

Chapter 2 Online Facilities 363

M4: Parameter Prompting Facilities

Figure 129 Exec/Order a Plan (CTMEXEC) Screen

---- CONTROL-M - P.P.F. ---- EXEC / ORDER A PLAN -------------------------(P.3)
COMMAND ===>

PLAN NAME ===> REPTS (Blank for plan selection list)

PLAN NAME SUFFIX ===> (For multiple plans in the same day)

REMAINING PARAMETERS ===> NO (YES / NO)

ODATE ===> 080800

FORCED FROM TIME ===>

Please fill in the Plan Name (or blanks) and press ENTER

DAILY SCHEDULING LIB ===> CTM.PROD.SCHD

USER PROMPT PLANS LIB ===> CTM.PROD.PLAN
DAILY PARAMETERS LIB ===> CTM.PROD.AEDI

ENTER END COMMAND OR PF3 TO TERMINATE

This screen orders a plan for parameter updating and plan execution. Fill in the
details in the screen (libraries and the current date appear as defaults) and press
Enter.

The PLAN NAME is the same as the Master Prompting Plan PREFIX. You can
designate two characters to serve as a suffix to the PLAN NAME. This permits
execution of a specific plan more than once a day.

The REMAINING PARAMETERS field determines whether you are automatically

prompted in the Update Parameter Values screen for parameter values that have yet
to be updated for active plans. Valid values are:

■ YES – Prompt
■ NO – Do not prompt

The ODATE field specifies the original scheduling date for executing the plan.

The FORCED FROM TIME field specifies a time (format hhmm) before which the jobs
cannot run.

If you leave PLAN NAME blank on the Exec / Order a Plan screen, the Plan Selection
screen is displayed:

Figure 130 Plan Selection Screen

---- CONTROL-M - P.P.F. - PLAN SELECTION ------------------------- Row 1 FROM 2
COMMAND ===> SCROLL ===> PAGE
PLAN PREFIX ===> PLAN ORDERED ALREADY:
-------------------------------------------------------------------------------

364 Control-M for z/OS User Guide

 M4: Parameter Prompting Facilities

_ PLAN NAME ===> REPTS ===> NO

ORDER TIME :
_ PLAN NAME ===> BACKUP ===> YES
ORDER TIME :
****************************** Bottom of Data *******************************

This screen displays a list of active Daily Plans.

PLAN ORDERED ALREADY: indicates whether the plan was already ordered. If the
plan has already been ordered, it is possible to select a plan for parameter value
updating only.

To select a plan, enter any character in the field to the left of the PLAN NAME.

Update Parameter Values Screen

After selecting a plan from the Plan Selection screen or specifying a particular plan on
the Exec / Order a Plan screen, the Update Parameter Values screen is displayed:

Figure 131 Update Parameters Values Screen

---- CONTROL-M - P.P.F.- UPDATE PARAMETER VALUES ---------------------- (P.3.1)
COMMAND ===> SCROLL ===> CSR
PARM PREFIX ===> PLAN NAME: REPTS
-------------------------------------------------------------------------------
_ PARM NAME ===> REPT_NAME OCCUR NO. ===> 01 NO DEFAULT
VALUE ===>
Enter name of sales report required
_ PARM NAME ===> DEPT_NUMBER OCCUR NO. ===> DEF EXISTS
VALUE ===> 035
Enter department number (used for all reports)
_ PARM NAME ===> REPT_NAME OCCUR NO. ===> 02 NO DEFAULT
VALUE ===>
Enter name of expense report required
****************************** Bottom of Data ******************************

This screen displays a list of all AutoEdit parameters for which values can be entered.
Press END (PF03/PF15) to exit the screen.

The Master Prompting Plan for the PLAN NAME is copied from the Master
Prompting Library to the Daily Prompting Library to create or replace the
corresponding User Prompting Plan (UPP). Only parameters that belong to jobs that
meet both of the following criteria are copied into the UPP.

■ The job names, which are specified in the DEFINE PARAMETERS IN THE
MASTER PLAN screen (option 1), reference a job that appears in the Daily
Scheduling table.

■ The jobs must be scheduled to run on the specified day (today). The CTMJOB
utility is invoked to determine which jobs run today.

Chapter 2 Online Facilities 365

M4: Parameter Prompting Facilities

The display of parameters can be limited to plans beginning with a specific prefix
using the PARM PREFIX field (under the command line).

To display the first occurrence of a parameter at the top of the screen, type the line
command L xxxx, where xxxx is a specific parameter or parameter prefix.

After all variables in a plan have been updated or have had their defaults approved,
you receive screen messages indicating the jobs from each plan that were ordered
automatically. To cancel any parameter value changes made and return to the
Exec / Order a Plan screen, type the line command CANcel.

Table 148 Format of the Update Parameter Values Screen

Field Description
PARM PREFIX Plan prefix. If a value is entered in this field, the display of
parameters is limited to plans beginning with the specified prefix.
PLAN NAME Name of the User Prompting Plan ordered for execution.
PARM NAME Name of the parameter available for update.
VALUE Default value of the parameter. This value can be modified;
embedded blanks are permitted.
MESSAGE Prompting message.
OCCUR NO. Occurrence number (2 digits). Differentiates between use of the
same parameter name for different purposes in different jobs (for
example, assign OCCUR NO. 01 to occurrence of %%PARM1 in Job
A; assign OCCUR NO. 02 to occurrence of %%PARM1 in Job B).
DEFAULT STATUS Indication of default:

■ NO DEFAULT – No associated default value.

■ DEF EXISTS – Parameter has an associated default value that

has not yet been approved by the user.

■ DEF CONFIRMED – Default value has been approved.

■ DEF CHANGED– Default value is not being used. Parameter

has been assigned a different value.
SELECTION FIELD Type S in this field (A) to accept the default, if a default exists.

Special Options

A special option, activated by typing YES in the REMAINING PARAMETERS field

on the Exec / Order a Plan screen, prompts you automatically for parameter values
that have yet to be updated from all active plans (that is, those plans “fetched” for the
day). The parameters are presented on consecutive Update Parameter Values screens.

■ YES – You are presented with remaining (non-updated) parameters from active
plans.

366 Control-M for z/OS User Guide

 M5: Quick Schedule Definition

■ NO – After updating the current plan, the Exec / Order a Plan screen is displayed
or, if Plan Name was left blank, the Plan Selection screen containing all active plans
is displayed. Default.

M5: Quick Schedule Definition

The Quick Schedule Definition facility is an automatic online interface for creating
tables for regular jobs that have common scheduling parameters. (SMART Tables are
not supported.) This facility speeds up the process of defining a schedule by
eliminating the need to individually define parameters for each job and its job
interdependencies.

Twenty-one jobs and their interdependencies can be defined on one screen with
Control-M automatically providing space for additional jobs.

The utility can be requested in the following ways:

■ Select option M5 on the Online Utilities menu

■ Activate CLIST CTMQUICK from the TSO Command Processor

Quick Schedule Definition Process

Four simple steps are performed one time only in order to create a complete table for
an unlimited number of jobs.

Table 149 Quick Schedule Definition Process

No. Step Where Performed
1. Create a skeleton job. Screen 2, Scheduling Definition facility.
2. Specify general table information and Quick Schedule Definition entry panel.
prerequisite conditions format.
3. List job interdependencies. Quick Definition Job List screen.
4. Exit the Quick Schedule Definition Note: The table is automatically created
facility. upon exit from the Quick Schedule
Definition facility.

These steps are described in detail below.

Step 1: Create a Skeleton Job

In this step you create a job in a table to be used as a skeleton, or model, for all the jobs
in the automatically created table (output table).

Chapter 2 Online Facilities 367

M5: Quick Schedule Definition

Enter the Control-M Scheduling Definition facility and create a Control-M table
containing one skeleton job. For more information, see “Scheduling Definition
Facility” on page 114.

Specify in the skeleton job all parameter values that are to be common to (the same in)
all the jobs in the automatically created table.

IN and OUT prerequisite conditions are automatically created by Control-M in the

output scheduling table; therefore, IN and OUT parameters in the skeleton definition
should not be coded, as they will be ignored.

MEMNAME, MEMLIB, and DOCLIB fields are overridden by Control-M during

automatic table creation.

The data in all other fields is copied into each of the new jobs in the output table.
Therefore, it is important to verify the data carefully.

%%JOBNAM and %%JOBNAME Variables

If variable %%JOBNAM, a non-AutoEdit variable specific to the Quick Schedule

Definition facility, is specified in a SHOUT statement, it is resolved during table
creation to the member name in each job.

If System variable %%JOBNAME is specified in a SHOUT statement, it is resolved at

runtime to the name of the job. If the job name is not known, %%$MEMNAME can be
used in its place.

Step 2: Specify General Table Information and Prerequisite Conditions Format

In this step, you display the Quick Schedule Definition entry panel and specify
general table information and the desired format for automatically defined
prerequisite conditions.

The entry panel can be displayed either by requesting option M5 on the Online
Utilities menu, or by activating CLIST CTMQUICK from the TSO Command
Processor. The following screen is displayed:

368 Control-M for z/OS User Guide

 M5: Quick Schedule Definition

Figure 132 Control-M Quick Schedule Definition Screen

------------------- CONTROL-M QUICK SCHEDULE DEFINITION -----------------------
COMMAND ===>

SPECIFY LIBRARY, OUTPUT SCHEDULING TABLE, SKELETON SCHEDULING TABLE

LIBRARY ===> CTM.PROD.SCHEDULE

TABLE ===> PAYROLL (Table to be created)
SKELETON ===> DAILY (Skeleton scheduling table)

OWNER in the output table S (T: your TSO User ID)

(S: OWNER from the skeleton table)

PREREQUISITE CONDITIONS FORMAT (CHOOSE ONE)

GROUP-FROMJOB-SUFFIX ===> Y (Y/N)

FROMJOB-TOJOB-SUFFIX ===> N (Y/N)
PREFIX-FROMJOB-TOJOB ===> N (Y/N)
TOJOB-FROMJOB-SUFFIX ===> (Y/N)

PREFIX OR SUFFIX ===> OK

TABLE ===> FINANCE SERVICES (For table-fromjob-suffix option)

CONNECTOR CHARACTER ==>

Fill in the following general table information fields:

Table 150 Fields of the Control-M Quick Schedule Definition Screen

Field Description
LIBRARY Name of the library that contains the skeleton member created in
Step 1 and that will contain the output scheduling table.
SCHEDULING Name of the table to be created.
TABLE
SKELETON Member name of the model scheduling table containing common
parameter values (created in Step 1 above). The member must exist
in the library specified above.
OWNER Value to be entered in the OWNER field in the output scheduling
definitions. Valid values are:

■ T – Your TSO user ID is used as the value for OWNER in the

output tables.

■ S – The value of OWNER in the skeleton table is used for

OWNER in the output tables.

To exit this screen, press END (PF03/PF15).

Chapter 2 Online Facilities 369

M5: Quick Schedule Definition

NOTE
If you use the selection list fields, their values are not erased until you exit the entry panel by
pressing END (PF03/PF15).

Prerequisite Condition Format Fields

Job dependencies are established by prerequisite conditions that are defined in the
job scheduling definitions.

The utility defines prerequisite conditions automatically. Therefore, naming

conventions for these conditions must be specified. Prerequisite conditions created by
the utility must consist of a combination of the following elements:

Table 151 Prerequisite Condition Format Fields

Field Description
FROMJOB Name of the predecessor job in the dependency.

For example, if JOB-A must terminate before JOB-B can be

submitted, JOB-A is the FROMJOB.
TOJOB Name of the successor job in the dependency. For example, if JOB-B
must be submitted after JOB-A terminates, JOB-B is the TOJOB.
TABLENAME Name of the table to which the jobs in the dependency belong.
PREFIX Constant to be added as a prefix to the condition.
SUFFIX Constant to be added as a suffix to the condition.

NOTE
Job dependencies are defined in Step 3, described in “Step 3: Specify Job Interdependencies”
on page 372.

Control-M can create prerequisite conditions based on the above elements in several
different formats. These formats are described below. Select one of the formats by
typing Y (Yes) to the right of one desired format, and N (No), to the right of the
remaining formats. IN and OUT prerequisite conditions are automatically created in
the job scheduling definitions in the selected format.

Table 152 Formats for Prerequisite Conditions (part 1 of 2)

Format Description
TABLENAME-FROMJOB If Y is entered, creates conditions in the following format (for
-SUFFIX example): BACKUP-BKP00010-OK.
FROMJOB-TOJOB-SUFFIX If Y is entered, creates conditions in the following format (for
example): BKP00010-BKP00020-OK.

370 Control-M for z/OS User Guide

 M5: Quick Schedule Definition

Table 152 Formats for Prerequisite Conditions (part 2 of 2)

Format Description
PREFIX-FROMJOB-TOJOB If Y is entered, creates conditions in the following format (for
example): VALCHK-BKP00010-BKP00020.
TOJOB-FROMJOB-SUFFIX If Y is entered, creates conditions in the following format (for
example): BKP00020-BKP00010-OK

The following fields affect the above formatted conditions. The TABLE field also
affects the TABLE value in the job scheduling definition.

Table 153 Fields that Affect Prerequisite Conditions Formats

Field Description
PREFIX OR SUFFIX Constant to be used as a prerequisite condition prefix or suffix
(depending on the format selected). Mandatory. Valid values are: 1
through 9 characters.
TABLE 1 through 20 character table name (no embedded spaces) to be used
in the job scheduling definitions. Optional, except for format
TABLE-FROMJOB-SUFFIX (for which it is mandatory).

If specified, the value in this field is used as the TABLE value in the
created job scheduling definitions (that is, in place of the TABLE
value in the skeleton).

If the TABLE-FROMJOB-SUFFIX format is requested, an * (Asterisk)

can be entered in this field. In this case, the table name is omitted
from the prerequisite condition (such as BKP00010-OK), but the
created job scheduling definitions still contain the table name
defined in the skeleton.
CONNECTOR Character used to concatenate the components of the condition
CHARACTER names. Mandatory. Valid values are: one non-blank character other
than '&' (Ampersand), for example, '-'.

Proceeding to the Job List Screen

Once you have filled in the fields in the Quick Definition entry panel, press Enter.

■ If the table that you specified in the TABLE field does not already exist in the
library, the Job List screen is displayed and you can proceed with Step 3.

■ If the table that you specified in the TABLE field already exists in the library, the
Overwrite Confirmation window is displayed:

Chapter 2 Online Facilities 371

M5: Quick Schedule Definition

Figure 133 Control-M Quick Search Schedule Definition

------------------- CONTROL-M QUICK SCHEDULE DEFINITION -----------------------
COMMAND ===>

+-----------------------------------------------------------+
| |
| LIBRARY CTM.PROD.SCHEDULE |
| TABLE PAYROLL |
| |
| ALREADY EXISTS. |
| |
| THIS PROCEDURE WILL OVERWRITE THE DATA IN THE TABLE. |
| |
| DO YOU WISH TO CONTINUE (Y/N) |
| |
+-----------------------------------------------------------+

— Type Y (Yes) to overwrite the existing table. The current contents of the table are
erased, and an empty table (Job List screen) is displayed.

— Type N (No) if you do not want to overwrite the current contents of the table.
The window is closed. You can now type a different table name in the TABLE
field and press Enter again.

Step 3: Specify Job Interdependencies

In this step you fill in a list of jobs, a description of each job, and the jobs upon which
they depend.

After you fill in the Quick Schedule Definition entry panel (and, if necessary, the
Overwrite Confirmation window) and press Enter, the Job List screen is displayed:

372 Control-M for z/OS User Guide

 M5: Quick Schedule Definition

Figure 134 Quick Schedule Definition Job List Screen Entered

JOB LIST LIB: CTM.PROD.SCHEDULE TABLE: PAYROLL
COMMAND ===> SCROLL===> PAGE
O NR MEMNAME DEPENDS ON---------------------------- DESCRIPTION ------------
1 CHECKCAL *TIME-CARDS-DONE CALCULATE CHECKS
2 CHECKPRT - PRINT CHECKS
3 GOVTREPT CHECKCAL REPORTS TO GOVERNMENT
4 BANKTAPE 1 REPORTS FOR MANAGEMENT
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Fill in one line for each job (the fields are detailed below). Control-M provides
additional lines on the screen, as necessary. When you have finished filling in the list,
press Enter. The entries are validated.

Fields in the Job List Screen

Table 154 Fields in the Job List Screen (part 1 of 2)

Field Description
O Field for specifying options, which are described in Table 155 on
page 374.
NR Line number. This number can be referenced in the DEPENDS ON
field of another job.
MEMNAME Name of the member containing the JCL of the job.

Names that have DUMMY as a prefix cause the utility to create the
job scheduling definition as a dummy job.

Chapter 2 Online Facilities 373

M5: Quick Schedule Definition

Table 154 Fields in the Job List Screen (part 2 of 2)

Field Description
DEPENDS ON Jobs and/or external prerequisite conditions on which this job
depends. Valid formats for the dependencies:

■ name – Name of the job (MEMNAME) upon which the current

job depends.

■ position-number – Number of the job on the screen. This number

is automatically adjusted when an option changes the position of
the current job or the job upon which it depends.

■ - (Minus sign) – The Minus sign represents the previous job in

the list.

■ *in-condition – Name of an external prerequisite condition, that is,

a prerequisite condition other than job interdependencies that
are automatically created. It must be preceded by an asterisk (*)
and be the last dependency entered on the job line. The date
reference ODAT is automatically associated with the
in-condition.

More than one dependency can be listed by separating each name by

a comma. Format types may be mixed on a line.

Examples:

■ CHECKCAL – Job CHECKCAL

■ 1 – Job on line 1 of the list
■ - (Minus sign) – Job on the preceding line
■ 3,*SALES-DATA – Job on line 3 of the list plus an external IN
condition.
DESCRIPTION Description of the job in free text.

Options of the Job List Screen

To use one of the following options, type the option in the O field to the left of the line
number. These options are similar to ISPF line commands.

Table 155 Options of the Job List Screen (part 1 of 2)

Option Description
I Insert a blank line immediately after the current line.
P Insert a blank line immediately preceding this line. This enables
addition of data before the first line in the list.
R Repeat this line immediately after the current line.
D Delete this line. If a job depends upon this line, you receive an error
message.
A Indicates that the target of a copy or move is directly after this line.

374 Control-M for z/OS User Guide

 M5: Quick Schedule Definition

Table 155 Options of the Job List Screen (part 2 of 2)

Option Description
B Indicates that the target of a copy or move is directly before this line.
C Copy this line to the target.
M Move this line to the target.

After performing requested options, Control-M automatically handles renumbering

and adjusts the relevant DEPENDS ON parameter values on the screen.

Step 4: Exit the Quick Schedule Definition Facility (and Create a Table)

To exit the Quick Schedule Definition facility after entering the data for a table, press
the END (PF03/PF15) key. An Exit Option window is opened:

Figure 135 Quick Schedule Definition Facility Exit Option Window

JOB LIST LIB: CTM.PROD.SCHEDULE TABLE: PAYROLL
COMMAN +--------------------------------------------------------------+
| PLEASE SELECT EXIT OPTION |
| |
| SAVE CREATE |
| |
| LIBRARY CTM.PROD.SCHEDULE |
| TABLE PAYROLL |
| |
+--------------------------------------------------------------+

The schedule can be saved (to replace a table of the same name that previously
existed in the library), or created (to store a new table in the library), by typing Y in
the appropriate exit option. The job schedule is automatically created as you exit.

If N is entered, the table is not saved, and the schedule is not produced. You return to
the Utilities screen or other screen, depending on how you entered the utility.

If no changes have been made, the Exit Option window is not opened.

To exit to the Quick Schedule Definition entry panel without saving your entries (and
without creating the job schedule), press RESET (PF04).

The screen below illustrates job GOVTREPT selected from the jobs listed in the Job
List screen in Step 3 above. Note particularly the automatically created MEMNAME,
IN, and OUT parameters, and the job name inserted into the SHOUT message in
place of the %%JOBNAM variable in the skeleton job definition.

Chapter 2 Online Facilities 375

M6: End-User Job Order Interface

Figure 136 Scheduling Definition Screen Quick Schedule Definition Example

JOB: GOVTREPT LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME GOVTREPT MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL APPL-L TBL BKP-PROD-L
DESC REPORTS TO GOVERNMENT
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM GOVTREPT DOCLIB
=============================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
=============================================================================
IN FINANCE-CHECKCAL-OK ODAT
CONTROL
RESOURCE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY 00 SAC CONFIRM
TIME ZONE:
=============================================================================
OUT FINANCE-GOVTREPT-OK ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES NOTOK A/O
DO SHOUT TO TSO-M44 URGENCY R
= JOB GOVTREPT ENDED "NOT OK"
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< =======
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 20.28.53

M6: End-User Job Order Interface

By ordering jobs through the End-User Job Order Interface, you can bypass the rest of
the Control-M Online facility.

The Job List screen (Figure 137) can be displayed in one of the following ways:

■ Select option M6 on the Online Utilities menu.

■ Activate CLIST CTMJBINT from the TSO Command Processor.

376 Control-M for z/OS User Guide

 M6: End-User Job Order Interface

Figure 137 Job List Screen Entered Through the End-User Job Order Interface
JOB LIST M6 - END USER JOB ORDER INTERFACE UTILITY CONTROL:@@USRT
COMMAND ===> SCROLL===> CRSR
OPT NAME --- TABLNAME - SCHEDULING LIBRARY NAME ------- DESCRIPTION ----------
PAYCALC PAYROLL CTMP.V610.SCHEDULE
PERF ASSESS CTMP.V610.SCHEDULE WDAYS=2(TUE),G+3
====== >>>>>>>>>>>>>>>>>>>> NO MORE JOBS IN TABLE <<<<<<<<<<<<<<<< =====

This screen displays a list of jobs that the particular user is permitted to order. The
INCONTROL administrator determines which jobs each user is permitted to order.

1. Do one of the following:

■ Press PF03/PF15 to exit the screen.

■ To order jobs, type S in the OPT field to the left of each job to be ordered and press
Enter.

For each job selected, in sequence, a new screen is displayed. The header of the screen
contains the names of the library and table. Under the command line, the Please Enter
Scheduling Date/Force Options window is displayed (see Figure 138).

Figure 138 Job Scheduling Date and FORCE Options Window

JOB LIST LIB: CTMP.V610.SCHEDULE TABLE:PAYROLL
COMMAND ===>
+---------------------------------------------------------+
| PLEASE ENTER SCHEDULING DATE/FORCE OPTIONS |
| |
| JOB PAYCALC DATE 23 05 04 (DD MM YY) |
| OR USE CONTROL-M WORKING DATE? (Y/N) |
| |
| FORCE JOB? NO (YES/NO) |
| WAIT FOR ODATE? NO (YES/NO) |
+---------------------------------------------------------+

2. In this window, you can

■ replace the date displayed with another date

■ change the scheduling date of the job to the Control-M working date, by typing Y
in the OR USE CONTROL-M WORKING DATE field

■ FORCE the job by typing YES in the FORCE JOB? field

■ wait for a specific date by typing YES in the WAIT FOR ODATE? field, or process
the Order/Force request immediately by typing NO.

Chapter 2 Online Facilities 377

U1: Invoke DOCU/TEXT

3. After selecting these options, you have the following further options:

■ Press Enter to complete the order request.

■ Press PF03/PF15 to cancel the order request.
■ Press PF04/PF16 to cancel the changes and exit the Job List screen.

U1: Invoke DOCU/TEXT

This option is available only at sites that have installed DOCU/TEXT, a product of
Diversified Systems Software, Inc. DOCU/TEXT provides automated, online JCL
documentation, and this option provides a direct interface to DOCU/TEXT. It can be
activated by requesting option U1 on the Online Utilities menu or by activating
CLIST CTMCDOCU directly.

For details about product usage refer to your DOCU/TEXT user guide.

378 Control-M for z/OS User Guide

 Chapter

3
3 Job Production Parameters
This chapter includes the following topics:

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
General Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Basic Scheduling Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Runtime Scheduling Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Post-Processing Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Parameter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
ADJUST CONDITIONS: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
APPL: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
APPL FORM: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
APPL TYPE: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
APPL VER: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
§Restart§ AUTO-ARCHIVE: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . 404
CM VER: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
CONFCAL: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
CONFIRM: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
CONTROL: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
CTB STEP: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
D-CAT: Basic Scheduling Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
DATES: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
DAYS: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
DEFINITION ACTIVE: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . 436
DESC: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
DO Statement: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
DO COND: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
DO CTBRULE: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
DO FORCEJOB: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
§Restart§DO IFRERUN: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . 453
DO MAIL: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
DO NOTOK: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
DO OK: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
DO REMEDY: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
DO RERUN: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
DO SET: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
DO SHOUT: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Chapter 3 Job Production Parameters 379

 DO STOPCYCL: Post-Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
DO SYSOUT: Post-Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
DOC: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
DOCLIB: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
DOCMEM: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
DUE OUT: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
GROUP: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
TBL MAXWAIT: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
IN: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
INSTREAM JCL: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
INTERVAL: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
INTERVAL SEQUENCE: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . 523
MAXRERUN: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
MAXWAIT: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
MEMLIB: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
MEMNAME: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
MINIMUM: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
MONTHS: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
NJE NODE: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
ON Statements: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
ON TABLE-END: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
ON PGMST: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
ON SYSOUT: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
OUT: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
OVERLIB: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
OWNER: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
PDS: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
PIPE: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
§Restart§PREVENT-NCT2:General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
PRIORITY: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
RELATIONSHIP: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
RERUNMEM: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
RESOURCE: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
RETENTION: # OF DAYS TO KEEP: Post–Processing Parameter . . . . . . . . . . . . . . . 612
RETENTION: # OF GENERATIONS TO KEEP: Post–Processing Parameter. . . . . . 614
RETRO: Basic Scheduling Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
SAC: Run Time Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
SCHEDULE RBC: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
SCHEDULE RBC ACTIVE: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . 625
SCHENV: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
SET VAR: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
SHOUT: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
SPECIFIC TIMES: Post–Processing Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
STAT CAL: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
STEP RANGE: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
SYSOUT: Post–Processing Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
SYSTEM ID: General Job Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
TASKTYPE: General Job Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
TIME + DAYS: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671

380 Control-M for z/OS User Guide

 Overview

TIME ZONE: Runtime Scheduling Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679

WDAYS: Basic Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681

Overview
Job scheduling definitions consist of parameters that correspond to the decisions
made and actions performed when handling the scheduling, submission and
post-processing of a job. Job scheduling definitions are defined in the Job Scheduling
Definition screen, which is shown in Figure 139. This is the main screen of the
Scheduling Definition facility.

Figure 139 Job Scheduling Definition Screen

JOB: BACKPL02 LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME BACKPL02 MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL APPL-L GROUP BKP-PROD-L
DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
OVERLIB CTM.OVER.JOBLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM BACKPL02 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL WORKDAYS SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN START-DAILY-BACKUP ODAT
CONTROL
RESOURCE INIT 0001 CART 0001
PIPE CTM.PROD.PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT BAKCKPL02-ENDED-OK ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST PROCST CODES A/O
DO
ON SYSOUT FROM 001 TO 132 A/O
DO
SHOUT WHEN TIME + DAYS TO URGN

Chapter 3 Job Production Parameters 381

Overview

MS
===========================================================================
APPL TYPE APPL VER
APPL FORM CM VER
INSTREAM JCL: N

======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< ====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 19.17.13

NOTE
The PIPE parameter is displayed only if MAINVIEW Batch Optimizer (MVBO) is installed.

RETENTION parameters # OF DAYS TO KEEP and # OF GENERATIONS TO KEEP are

displayed only at sites that use the History Jobs file.

In a SMART Table, a SMART Table Entity (shown in Figure 140) must be defined
before the job scheduling definitions.

Figure 140 SMART Table Entity Definition Screen

TBL ACCOUNTS_GROUP CTM.PROD.SCHEDULE(TBL)
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
GROUP ACCOUNTS_GROUP MEMNAME ACCOUNTS
OWNER N04B
APPL
DESC
ADJUST CONDITIONS N TBL MAXWAIT 00 STAT CAL
SET VAR
DOCMEM ACCOUNTS DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC CTM_LEVEL_RBC LEVEL CTM
===========================================================================
SCHEDULE RBC ALL_DAYS LEVEL TBL
DAYS ALL DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00
SCHEDULE RBC ACTIVE FROM UNTIL
===========================================================================
SCHEDULE RBC TBL_LEVEL_RBC LEVEL TBL
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00
SCHEDULE RBC ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT

382 Control-M for z/OS User Guide

 Overview

ON TABLE-END NOTOK
DO COND ACCTS-CHK-REQUIRED ODAT +
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>>>>> END OF GROUP PARAMETERS <<<<<<<<<<<<<<<<<< ======
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 19.17.13

Most parameters in the SMART Table Entity definition are the same as in the job
scheduling definition, but they apply to the SMART Table as a whole. Therefore:

■ At least one set of basic scheduling criteria in the SMART Table Entity must be
satisfied before any job in the SMART Table can be scheduled.

■ Runtime scheduling criteria in the SMART Table Entity must be satisfied before
any job in the SMART Table can be executed.

■ Post-processing statements in the SMART Table Entity are applied only after all
jobs in the SMART Table have finished executing.

The following parameters in the SMART Table Entity are not found in the job
scheduling definition:

■ ADJUST CONDITIONS
■ ON TABLE-END
■ SCHEDULE RBC ACTIVE FROM and UNTIL

Usage and operation of the Scheduling Definition facility, including entry and exit of
the Job Scheduling Definition screen, is described in the INCONTROL for z/OS
Utilities Guide.

In addition to defining jobs through the Scheduling Definition facility, jobs can also
be defined using the batch utility CTMBLT, described in the INCONTROL for z/OS
Utilities Guide, or using the online utility QUICKDEF. The QUICKDEF utility, the
Quick Schedule Definition facility, is available under ISPF only. For more information
about it, see “Utilities Under ISPF” on page 333.

This chapter provides a detailed description of the job scheduling definition

parameters and statements.

The parameters of the Job Scheduling Definition screen are divided into the following
categories:

■ General parameters
■ Basic Scheduling parameters
■ Runtime Scheduling parameters
■ Post-processing parameters

Chapter 3 Job Production Parameters 383

General Parameters – Summary

A brief summary of the parameters in each category is provided on the following

pages. This is followed by a detailed description of each parameter, in alphabetical
order.

General Parameters – Summary

General parameters provide general information about the job and certain
information required by the JCL. Information about the following parameters is
provided in this chapter:

Table 156 General Parameters (part 1 of 2)

Parameter Description
MEMNAME Member containing the JCL.
MEMLIB Library containing the JCL member.
OWNER Owner of the job.
TASKTYPE Type of job or task.
§Restart§ PREVENT Whether to perform data set cleanup before the original job run.
NCT2
DFLT – Protected field indicating the PREVENT-NCT2 default
value of the site.
APPL Application to which the job belongs.
GROUP Group to which the job belongs.
DESC Brief description of the job.
OVERLIB Library containing a special case JCL for the job.
STAT CAL Name of a periodic calendar that will be used to gather average
runtime statistics for the job, based on a period.
SCHENV Name of the workload management scheduling environment to
be associated with the job.
SYSTEM ID In JES2, the identity of the system in which the job must be
initiated and executed.

In JES3, the identity of the processor on which the job must be

executed.
NJE NODE Identifies the node in the JES system at which the job must
execute.
SET VAR Mechanism for setting the value of a JCL user-defined variable.
CTB STEP Control-M/Analyzer step to be added to the execution of the job.
DOCMEM Member containing detailed information about the job.
DOCLIB Library containing the member specified in the DOCMEM
parameter.
DOC Detailed job documentation.

384 Control-M for z/OS User Guide

 Basic Scheduling Parameters – Summary

Table 156 General Parameters (part 2 of 2)

Parameter Description
INSTREAM JCL Whether Control-M for z/OS submits a JCL stream defined
within the job scheduling definition.
The following General parameters are in the SMART Table Entity only:
ADJUST CONDITIONS Allows conditions to be removed from job orders if the
predecessor jobs that set the conditions are not scheduled.
TBL MAXWAIT Number of additional days after the original scheduling date that
the SMART Table Entity can remain in the Active Jobs file if it
does not have a status of ENDED OK (and none of its jobs
currently appear in the Active Jobs file).

Basic Scheduling Parameters – Summary

Basic Scheduling parameters determine if the job is a candidate for execution on a
specific date. If a job is a candidate for execution on a specific date, a job order is
automatically placed in the Active Jobs file during New Day processing.

Each job order placed in the Active Jobs file is associated with an original scheduling
date. This is the date the job is to run according to the Basic Scheduling parameters.
This date is not necessarily the same as the current system date or the current
working date. For further information, see “Date Definition Concepts” on page 65

Basic Scheduling parameters and subparameters allow different methods of

expressing a job schedule.

Each set of basic scheduling criteria in the SMART Table Entity must be uniquely
labeled by a SCHEDULE RBC value. At least one Schedule RBC must be defined.

In job scheduling definitions, SCHEDULE RBC is optional. Each specified

SCHEDULE RBC value in the job scheduling definition for a job of a SMART table
must match a SCHEDULE RBC value in the SMART Table Entity.

The RELATIONSHIP parameter appears only in job scheduling definitions in

SMART Tables.

The RELATIONSHIP parameter defines the relationship (AND/OR) between rule-

based calendar criteria and the basic scheduling criteria of the job, that is, whether
one or both sets of criteria are to be satisfied.

The Basic Scheduling parameters, except SCHEDULE RBC and RELATIONSHIP, are
listed below by category. When defining basic scheduling criteria for jobs in tables, or
when defining basic scheduling criteria for SMART Table Entities, the following rules
apply to these categories of parameters:

Chapter 3 Job Production Parameters 385

Basic Scheduling Parameters – Summary

■ Parameters must be selected from one and only one of the first three categories
(A, B, or C).

■ Parameters in the last two categories (D and E) are optional.

Table 157 Category A, B, C, and D Parameters

Category Parameter
A ■ MONTHS – Schedule the job during the specified months.

■ DAYS – Schedule the job on specified days (in the

above-specified months) and/or select days from a specified
calendar.

■ WDAYS – Schedule the job on specified days of the week (in the
above-specified months) and/or select days from a specified
calendar.

■ CONFCAL – Confirm scheduling days against a specified

calendar.
B ■ DATES – Schedule the job on specified dates.

■ WDAYS – Schedule the job on specified days of the week.

■ CONFCAL – Confirm scheduling days against a specified

calendar.
C ■ PDS – PDS to be checked for minimum number of tracks.

■ MINIMUM – Minimum number of tracks.

D RETRO – Schedule the job even if the original scheduling date has
passed.
E ■ MAXWAIT – Maximum number of days to keep the job in the
Active Jobs file awaiting execution after its original scheduling
date has passed.

■ D-CAT – Control-D category of the job. (Documented as

CATEGORY prior to version 5.1.4.)

Category C Parameters
Schedule the job if the number of free tracks in the specified partitioned data set
(PDS) is less than the minimum number of tracks specified. This set of criteria is
intended for jobs or started tasks that clean, compress or enlarge libraries or that issue
warning messages if the minimum number of free tracks is not available.

386 Control-M for z/OS User Guide

 Basic Scheduling Parameters – Summary

Basic Scheduling Parameters

Each Basic Scheduling parameter is described in this chapter. However, the
interrelationships between some of these parameters are described briefly below.

DAYS, DCAL, WDAYS, WCAL

These parameters are all optional.

The DAYS parameter identifies days of the month on which the job must be
scheduled, such as first day of the month, third working day of the month. Several
formats are available for specifying DAYS values.

The WDAYS parameter identifies days of the week on which the job must be
scheduled, such as the first day of the week, the second day of each week, and so on.
Several formats are available for specifying WDAYS values.

A calendar name can be specified in the DCAL and/or WCAL fields. A calendar
specifies days of the year on which a rule can be scheduled, known as working days.
For more information on calendars and the IOA Calendar facility, see “IOA Calendar
Facility” on page 313.

When both the DAYS and DCAL parameters are specified, they work as a
complementary unit, as described in “DAYS: Basic Scheduling Parameter” on
page 426. Similarly, when both WDAYS and WCAL are specified, they also work as a
complementary unit, as described in “WDAYS: Basic Scheduling Parameter” on
page 681.

When values for both DAYS (/DCAL) and WDAYS (/WCAL) are specified in the
same job scheduling definition, the resulting schedule is determined by the value
specified in field AND/OR.

CONFCAL and SHIFT

A calendar specified in CONFCAL is not used for job scheduling, but is used instead
for validating a scheduled date. Only jobs that have satisfied all other specified basic
scheduling criteria are checked against the CONFCAL calendar. If the day is a
working day in the CONFCAL calendar, the job is scheduled on that day. Otherwise,
the job is either shifted to (scheduled on) another day according to the value entered
in the SHIFT parameter, or the job is not scheduled (if no SHIFT value has been
specified).

CONFCAL calendars are especially useful for handling holidays and other
scheduling exceptions.

Chapter 3 Job Production Parameters 387

Basic Scheduling Parameters – Summary

Defining a Schedule – Internal Scheduling Logic

When defining tables which handle jobs to be scheduled individually, it is useful to

understand the IOA Scheduling facility logic, which determines whether to order a
job on a specific day. This logic is described below.

1. ACTIVE FROM and UNTIL parameters are checked first. If the current date falls
outside the time range specified, no further checking is performed.

2. DAYS and DCAL parameters are checked independently and a first tentative
scheduling decision is created.

3. WDAYS and WCAL parameters are checked independently and a second tentative
scheduling decision is created.

4. A third tentative scheduling decision is created based on the above two decisions
and the AND/OR value linking them.

(If DAYS and/or DCAL are not specified, this third temporary scheduling decision
is identical to the second scheduling decision. If WDAYS and/or WCAL are not
specified, this third scheduling decision is identical to the first scheduling decision.

5. If CONFCAL and/or SHIFT are specified, this third scheduling decision is

adjusted according to the CONFCAL and SHIFT criteria.

6. This third scheduling decision (as adjusted) becomes the final scheduling decision.
The IOA Scheduling facility determines whether to schedule a job based on this
final scheduling decision.

Scheduling Jobs in SMART Tables

The following scheduling algorithm applies to SMART Tables:

1. Before jobs in a SMART Table can be scheduled, the SMART Table itself must be
eligible for scheduling (that is, at least one of the rule-based calendars of basic
scheduling criteria in the SMART Table Entity has been satisfied).

2. If (and only if) the SMART Table is eligible for scheduling, each job scheduling
definition in the table is individually checked for possible scheduling.

3. For each job scheduling definition:

■ Rule-based calendars in the job scheduling definition are checked sequentially

beginning with the first calendar. The SCHEDULE RBC ACTIVE FROM and
UNTIL parameters are checked first. If the current date falls outside the time
range specified, no further checking is performed.

388 Control-M for z/OS User Guide

 Basic Scheduling Parameters – Summary

If the criteria of a rule-based calendar is satisfied, no further checks are

performed on the remaining calendars. The criteria belonging to the satisfied
calendar are used in the scheduling algorithm.

■ The RELATIONSHIP parameter (AND/OR) is checked.

— If a rule-based calendar was satisfied and the defined relationship is OR, the
satisfied rule-based calendar is sufficient and the job is scheduled according
to criteria of this calendar. No further checks are performed.

— If no rule-based calendar was satisfied and the defined relationship is AND

(that is, the job requires that the rule-based calendar be satisfied), the job is
not scheduled. No further checks are performed.

— If a rule-based calendar was satisfied and the defined relationship is AND, or

if no rule-based calendar was satisfied and the defined relationship is OR, the
basic scheduling criteria of the job must be satisfied (that is, the algorithm
continues with the next step).

■ The basic scheduling criteria of the job are checked.

— If the basic scheduling criteria of the job are not satisfied, the job is not
scheduled.

— If the basic scheduling criteria of the job are satisfied, the job is scheduled.

The basic scheduling criteria of the job, not the rule-based calendar criteria, are used
for scheduling. This is a concern only if there are conflicting MAXWAIT values in the
rule-based calendar criteria and the basic scheduling criteria of the job. In this case,
the MAXWAIT value from the basic scheduling criteria of the job is used.

Chapter 3 Job Production Parameters 389

Basic Scheduling Parameters – Summary

Figure 141 SMART Table Scheduling Flowchart

390 Control-M for z/OS User Guide

 Runtime Scheduling Parameters – Summary

Runtime Scheduling Parameters – Summary

Runtime Scheduling parameters define job submission criteria. The job is not
submitted unless all submission criteria are satisfied. The following criteria can be
defined:

Table 158 Runtime Scheduling Parameter Criteria

Parameter Description
IN Required prerequisite conditions.
CONTROL Required exclusive or shared Control resources.
RESOURCE Quantitative resources and the required quantity.
PIPE Name of each data set that is replaced by a pipe during the run of the
job. Available only at sites where MAINVIEW Batch Optimizer
(MVBO) is installed.
TIME + DAYS Time range during which the job must be submitted.
TIME ZONE Enables automatic adjustment of the times specified in the job
definition to the corresponding times in a different time zone.
PRIORITY Job priority and critical path priority.
DUE OUT Time by which the job must finish executing, which can determine
the time by which the job must be submitted.
CONFIRM Manual confirmation required before the job is submitted.

Post-Processing Parameters – Summary

Actions to be performed after job execution generally depend on the results of the job
execution:

■ Certain actions may be required when the job ends successfully.

■ Certain actions may be required when the job fails, depending on the reason for
failure.

■ Certain actions may be required in any and all situations.

The Control-M monitor tracks each job execution. Following the termination of a job,
the Control-M monitor checks the execution results of each step in the job. Based on
the results, the Control-M monitor determines a final status of the job. Either of two
final job statuses can be assigned:

Chapter 3 Job Production Parameters 391

Post-Processing Parameters – Summary

Table 159 Final Job Statuses

Status Description
OK Job ended OK. This status is usually assigned when all steps in the
job end with a condition code less than or equal to C0004.
NOTOK Job ended NOTOK. This status is assigned when any step ends with
a condition code greater than or equal to C0005. It is also assigned if
the job abends or is not run.

The following statuses are subsets of end status NOTOK:

■ JNRUN – Job not run due to JCL syntax error.

■ EXERR – Execution error (that is, one that occurred after the job
has started running).

■ JFAIL – JCL error was encountered during job step initiation.

This status is also a subset of status EXERR.

If a post-processing error occurs after a job ends OK (including FORCE OK), it

indicates that there is a problem with the post-processing statements defined in the
job scheduling definition. For example, a post-processing statement may have
indicated an action that the owner of the job was not authorized to perform.

Post-processing parameters can be divided into the following groups:

Parameters Performed When the Job Ends OK

Table 160 Parameters Performed When the Job Ends OK

Parameter Description
OUT Adds or deletes prerequisite conditions.
§Restart§ Archives sysout.
AUTO-ARCHIVE
RETENTION Specifies retention criteria of a job in the History Jobs file.
SYSOUT Specifies sysout processing.

Conditional Processing or Processing in All Situations

Most conditional processing is specified through a combination of ON and DO

statements. ON and DO statement definition consists of defining ON statement step
and code events (for example, ON PGMST STEP1 CODE C0016), followed by DO
statement actions (for example, DO SHOUT, DO FORCEJOB), which are performed
when the ON step and code criteria are satisfied.

A range of steps for use in the ON statement can be defined in the STEP RANGE
parameter.

392 Control-M for z/OS User Guide

 Post-Processing Parameters – Summary

ON and DO statements also specify actions that are to be performed in any and all
cases. To ensure that the ON statement is activated for all step and code events, enter
reserved word ANYSTEP as the ON step name and ***** as the ON code.

Table 161 Conditional Processing Statements

DO Statement Description
DO statements allow specification of a wide variety of actions to be performed when the ON
criteria are satisfied:
DO COND Add or delete prerequisite conditions.
DO CTBRULE Activate a Control-M/Analyzer rule.
DO FORCEJOB Force a job.
§Restart§ DO Perform Control-M/Restart job restart.
IFRERUN
DO MAIL Send an e-mail to the specified recipients.
DO NOTOK Set the status of the step to NOTOK.
DO OK Set the status of the step to OK.
DO REMEDY Open a Remedy Helpdesk ticket.
DO RERUN Rerun the job.
DO SET Set the value of an AutoEdit variable.
DO SHOUT Send a message.
DO STOPCYCL Stop recycling a cyclic task.
DO SYSOUT Handle sysout processing.
The following parameter specifies the condition that determines if and when processing is
performed.
SHOUT Sends a message to a specified destination in specified situations (for
example, if the job was submitted late).

Return and Cyclic Post-processing Parameters

Table 162 Return and Cyclic Post-Processing Parameters

Parameter Description
MAXRERUN Maximum number of times to rerun the job (used only for automatic
job rerun or cyclic jobs). (Called RERUN – MAXRERUN prior to
version 6.0.00).
RERUNMEM Member containing the JCL to be used for automatic rerun. (Called
RERUN – RERUNMEM prior to version 6.0.00.)
INTERVAL Minimum time interval between runs of a rerun or cyclic job. This
parameter acts as a Runtime Scheduling parameter for the
subsequent rerun or cyclic runs of the job.

Chapter 3 Job Production Parameters 393

Parameter Descriptions

SMART Table Entity Post-processing Parameters

Table 163 SMART Table Entity Post-Processing Parameters

Parameter Description
The following parameter is found only in the SMART Table Entity definition:
ON TABLE-END The table-processing termination status that determines whether the
accompanying DO statements are performed.

The following DO statements are permitted following an ON

TABLE-END statement:

■ DO COND
■ DO OK
■ DO MAIL
■ DO FORCEJOB
■ DO SET
■ DO NOTOK
■ DO SHOUT

NOTE
DO OK and DO NOTOK statements change the final status of the table (not the status of each
job or job step in the table).

Parameter Descriptions
The following pages contain detailed descriptions of all parameters available in the
Control-M Job Definition screen. Parameters are arranged in alphabetical order.
Within each parameter, subparameters are arranged according to the order of the
fields on the screen.

Each parameter begins on a new page, including:

■ A brief explanation of the purpose of the parameter.

■ The format required for defining the parameter within an extract of the Control-M
screen.

■ General information explaining the parameter and its usage.

■ Where applicable, some practical examples illustrating implementation of the

parameter.

For more information on the Job Definition facility, see Chapter 2, “Online Facilities.”

394 Control-M for z/OS User Guide

 ADJUST CONDITIONS: General Job Parameter

ADJUST CONDITIONS: General Job Parameter

Determines how Control-M handles a requirement for a prerequisite condition by
successor jobs in a SMART Table. This parameter appears in the SMART Table Entity
only and applies only to SMART Tables.

Figure 142 ADJUST CONDITIONS Parameter Format

Optional. Valid values are shown in Table 164.

Table 164 ADJUST CONDITIONS Parameter Values

Value Description
Y (Yes) Control-M ignores, for each job in the group, any IN prerequisite
condition that is triggered by a predecessor job that will not be
ordered during the current day.
N (No) Control-M does not erase any IN prerequisite conditions. Default.
D (Dummy) Control-M orders as a DUMMY job any job with scheduling criteria
that are not satisfied on the current ODATE.

General Information
This parameter is applied to all jobs in the SMART Table. It provides the options
shown in Table 164 when job dependency is defined between jobs in a SMART Table
by their respective conditions.

Such a job dependency arises when one job in a group is dependent on a condition
that is triggered by another job in the group. If the triggering job is not ordered,
meaning, placed on the Active Jobs file, because the scheduling criteria of the
triggering job do not match the current Odate, the dependent job cannot run.

The options provided by the ADJUST CONDITIONS parameter enable you to avoid
this difficulty.

Chapter 3 Job Production Parameters 395

ADJUST CONDITIONS: General Job Parameter

■ If you enter the value Y for the ADJUST CONDITIONS parameter, the following
principles apply:

— Control-M erases IN conditions from each job in the group that is placed on the
AJF. The following criteria must be met before an IN condition is erased:

■ The IN condition in the job is triggered by a predecessor job.

■ The scheduling criteria of the predecessor job are such that the predecessor
job will not be ordered during the current day.

The erasing of these IN conditions frees the successor job from its dependency
on the predecessor job.

— Only the image of the job on the AJF is affected. The original job scheduling
definition remains unchanged.

— The erased condition does not appear in the Zoom screen.

■ If you enter the value N for the ADJUST CONDITIONS parameter, Control-M runs
normally. You must release any jobs that are likely to wait indefinitely on the AJF
because they are dependent on predecessor jobs with scheduling criteria such that
they will not be ordered. To release the dependent jobs, use one of the manual
options, such as those available in

— the IOA Conditions/Resources screen (Screen 4)

— the IOA Manual Conditions file (Screen 7)

■ If you enter the value D for the ADJUST CONDITIONS parameter, the following
principles apply:

— Control-M places all the jobs in the group onto the AJF when the group is
ordered.

— Jobs in the group with scheduling criteria that fit the current ODATE remain
unchanged.

— Jobs in the group with scheduling criteria that do not fit the current ODATE,
and would not ordinarily be ordered, are placed on the AJF as DUMMY jobs
(the MEMLIB parameter is changed to DUMMY). This permits the original
logical flow of the group to be maintained by preserving the relationships of the
IN and OUT conditions of these dummy jobs.

— Only the image of the job on the AJF is affected. The original job scheduling
definition remains unchanged.

396 Control-M for z/OS User Guide

 ADJUST CONDITIONS: General Job Parameter

Examples

Example 1

If a predecessor job is not scheduled, the requirement for the prerequisite conditions
that the predecessor job would have normally placed in the IOA Conditions file is
erased in the successor jobs.

Figure 143 ADJUST CONDITIONS Parameter Example

TBL ACCOUNTS_GROUP CTM.PROD.SCHEDULE(TBL)
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
GROUP ACCOUNTS_GROUP MEMNAME ACCOUNTS
OWNER N04B
APPL
DESC
ADJUST CONDITIONS Y TBL MAXWAIT 00
SET VAR
DOCMEM ACCOUNTS DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC ALL_DAYS
DAYS ALL DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00
SCHEDULE RBC ACTIVE FROM UNTIL
===========================================================================
SCHEDULE RBC SUNDAYS
DAYS 01 DCAL
AND/OR
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 16.44.31

Example 2

Assume that a SMART Table Entity defines a chain of jobs, in the order
DAILY-1 —> DAILY-2 —> DAILY-3 —> WEEKLY-1 —> DAILY-4.

■ The user wants the following:

— Each of the DAILY jobs must run every day, in the order
DAILY-1 —> DAILY-2 —> DAILY-3 —> DAILY-4.

— The WEEKLY-1 job must run only on each Tuesday.

— When WEEKLY-1 runs, it must run after DAILY-3 and before DAILY-4.

■ DAILY-1, DAILY-2, DAILY-3, WEEKLY-1, and DAILY-4 contain IN and OUT

conditions to ensure that they run in the required order.

Chapter 3 Job Production Parameters 397

ADJUST CONDITIONS: General Job Parameter

Unless some step is taken, on the days when WEEKLY-1 does not run, DAILY-4
cannot be executed, because its IN condition causes it to wait for WEEKLY-1 to end.

If the ADJUST CONDITIONS parameter is set to D, WEEKLY-1 is ordered daily.

Every day except Tuesday, its scheduling conditions prevent it running, and it is
ordered as a PSEUDO job. Each Tuesday, it is ordered and executed normally. The
logical job flow is maintained throughout.

398 Control-M for z/OS User Guide

 APPL: General Job Parameter

APPL: General Job Parameter

Descriptive name of the application to which the group of the job belongs. Used as a
common descriptive name for a set of related groups (of jobs).

Figure 144 APPL Parameter Format

APPL specifies an application name of 1 through 20 characters. Only trailing blanks

are allowed.

By default, the APPL parameter is optional. It can be modified in the user profile.

General Information
The parameter facilitates the handling of groups of production jobs.

NOTE
Use of the APPL parameter is highly recommended to facilitate implementation of
Control-M/Enterprise Manager functions and future Control-M options. For details, see the
Control-M User Guide.

Example
Job OPERCOMP belongs to group MAINTENANCE, which is part of application
OPER.

Chapter 3 Job Production Parameters 399

APPL: General Job Parameter

Figure 145 APPL Parameter Example

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME OPERCOMP MEMLIB GENERAL
OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL OPER GROUP MAINTENANCE
DESC JOB RUN ON THE 1ST OF THE MONTH
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
===========================================================================
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 16.44.00

400 Control-M for z/OS User Guide

 APPL FORM: General Job Parameter

APPL FORM: General Job Parameter

The type of form used for entering application data.

This is a protected field whose value is obtained from Control-M/EM. Reserved for
future use.

Figure 146 APPL FORM Parameter Format

Chapter 3 Job Production Parameters 401

APPL TYPE: General Job Parameter

APPL TYPE: General Job Parameter

The application that runs the job.

This is a protected field whose value is obtained from Control-M/EM. Reserved for
future use.

Figure 147 APPL TYPE Parameter Format

402 Control-M for z/OS User Guide

 APPL VER: General Job Parameter

APPL VER: General Job Parameter

The version of the application on which the job runs.

This is a protected field whose value is obtained from Control-M/EM. Reserved for
future use.

Figure 148 APPL VER Parameter Format

Chapter 3 Job Production Parameters 403

§Restart§ AUTO-ARCHIVE: Post–Processing Parameter

§Restart§ AUTO-ARCHIVE: Post–Processing

Parameter
Controls SYSDATA archiving.

Figure 149 §Restart§ AUTO-ARCHIVE Parameter Format

Optional. The AUTO-ARCHIVE parameter consists of the subparameters described

in Table 165.

Table 165 §Restart§ AUTO-ARCHIVE Subparameter Format (part 1 of 2)

Subparameter Description
AUTO-ARCHIVE Determines whether SYSDATA is to be archived. Valid values are:

■ Y (Yes) – Archive SYSDATA. Default.

■ N (No) – Do not archive SYSDATA. If this value is specified for a
job, restart of the job under Control-M/Restart and SYSDATA
viewing under Control-M is not possible.
SYSDB Determines whether all SYSDATA outputs are to be archived to one
predesignated data set or whether each SYSDATA output is to be
archived to its own data set. Valid values are:

■ Y (Yes) – SYSDATA of all jobs containing a SYSDB value of Y are

archived to a common data set. When the common data set is
full, another is automatically allocated and used by the system.
This is the recommended method. Default.

■ N (No) – SYSDATA of each job containing a SYSDB value of N is

archived to a unique data set.

404 Control-M for z/OS User Guide

 §Restart§ AUTO-ARCHIVE: Post–Processing Parameter

Table 165 §Restart§ AUTO-ARCHIVE Subparameter Format (part 2 of 2)

Subparameter Description
MAXDAYS Maximum number of days to retain archived SYSDATA value for
jobs ended NOTOK. Must be a 2-digit number in the range 00
through 98 or 99. 99 means retain for an unlimited number of days
(until deleted by request).
MAXRUNS Maximum number of runs for which the archived SYSDATA must
be retained when the job ended NOTOK. Must be a 3-digit number
in the range of 000 through 998 or 999. 999 means retain the
SYSDATA of all runs.

General Information
The AUTO-ARCHIVE subparameter allows you to decide whether to archive
SYSDATA, which is defined in “SYSDATA” on page 70. While archiving SYSDATA
is normally desirable, it might not be desirable for cyclic jobs, started tasks, or
frequently repeated jobs that do not require restart.

If archiving, the SYSDB subparameter allows you to decide whether SYSDATA for
different jobs must be archived to a common data set (Y) or whether to use a separate
data set for each run (N). If Y is entered, a single archived SYSDATA data set is used
for archiving until it is full. Then, another SYSDATA data set is allocated and used.
This is the recommended method.

Creating a separate data set for each run is not recommended because:

■ Creating many data sets consumes a large amount of space in the disk VTOC.
■ Each data set is allocated on a track basis. If the SYSDATA does not completely fill
the track, large amounts of disk space may be wasted.

The MAXDAYS and MAXRUNS subparameters define retention criteria for the
archived SYSDATA of jobs that ended NOTOK. Defaults are defined in the
Control-M/Restart installation parameters. You can specify either or both parameters
to override the defaults. If both parameters are specified, retention is limited by the
condition that is fulfilled first.

When archiving SYSDATA, BMC Software recommends that you do not enter the
value 99 in the MAXWAIT parameter for cyclic jobs or started tasks. Otherwise, these
jobs, which are never automatically deleted from the Active Jobs file, may cause the
disk to fill up with unnecessary archived SYSDATA. The MAXWAIT parameter is
described in “MAXWAIT: Basic Scheduling Parameter” on page 528.

NOTE
Specified parameters take effect only during execution of the New Day procedure
(CONTDAY) or the CTMCAJF utility. Therefore, it is possible to find more generations of the
same job than the current value of MAXRUNS.

Chapter 3 Job Production Parameters 405

§Restart§ AUTO-ARCHIVE: Post–Processing Parameter

AUTO-ARCHIVE and the History File

SYSDATA is archived in the History Jobs file, as defined by the values set for the
MAXDAYS and MAXRUNS parameters, and under the following conditions:

As long as a job exists either in the AJF or in the History Jobs file, the action of the
MAXDAYS and MAXRUNS parameters applies to the job's SYSDATA, except for the
last archived SYSDATA, which will be retained regardless of the setting of the
MAXDAYS and MAXRUNS parameters. On the other hand, if the HIST parameter in
the CTMPARM member in the IOA PARM library is set to N (No) and a job is deleted
from the AJF, the job's SYSDATA is deleted regardless of the values set for the
MAXDAYS and MAXRUNS parameters. For more information, see information
about maintaining previous runs in the History Jobs file in the Control-M/Restart User
Guide.

Example
Archive the SYSDATA to a common data set. Retain the archived SYSDATA for 7
days or 20 runs, whichever occurs first.

Figure 150 §Restart§ AUTO-ARCHIVE Parameter Example

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS 07 MAXRUNS 020
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 16.44.00

406 Control-M for z/OS User Guide

 CM VER: General Job Parameter

CM VER: General Job Parameter

The version number of the Control Module (CM) that is used to run the job.

This is a protected field whose value is obtained from Control-M/EM. Reserved for
future use.

Figure 151 CM VER Parameter Format

Chapter 3 Job Production Parameters 407

CONFCAL: Basic Scheduling Parameter

CONFCAL: Basic Scheduling Parameter

Specifies the name of a calendar that is used to confirm the scheduling of the job.

Related parameters are “DAYS: Basic Scheduling Parameter” on page 426, “WDAYS:
Basic Scheduling Parameter” on page 681, and “DATES: Basic Scheduling Parameter”
on page 424.

Figure 152 CONFCAL Parameter Format

Optional. CONFCAL subparameters are described in Table 166.

Table 166 Optional CONFCAL Subparameters (part 1 of 2)

Subparameter Description
CONFCAL A valid 1 through 8 character calendar (member) name. This
calendar is used for:

■ validating scheduling dates

■ determining the scheduled work day

Jobs to be scheduled on a day, based on other specified Basic

Scheduling criteria, are checked against the CONFCAL calendar, as
follows:

■ If the day is a working day in the CONFCAL calendar, the job is

tentatively scheduled on that day. This day is referred to as the
original scheduling date. Actual scheduling of the job is then
determined by the value entered in the SHIFT subparameter
(described in this table).

■ If the day is not a working day in the CONFCAL calendar, the

SHIFT subparameter is checked. Depending on the SHIFT value,
the job may be scheduled on an earlier or later day, may be
scheduled on that day, or may be cancelled.

408 Control-M for z/OS User Guide

 CONFCAL: Basic Scheduling Parameter

Table 166 Optional CONFCAL Subparameters (part 2 of 2)

Subparameter Description
SHIFT Determines when and if the job must be scheduled. Optional.

The format of the SHIFT subparameter is xyyy, where

■ x indicates how to shift scheduling of the job if the original

scheduling day of the job is not a working day in the CONFCAL
calendar. Valid values are:

— ' ' (Blank) – No shifting occurs. The job is not scheduled.

Default.
— > – Job scheduling is shifted to the next working day in the
CONFCAL calendar. Additional shifting may be performed,
depending on the yyy value, described below.
— '< – Job scheduling is shifted to the previous working day in
the CONFCAL calendar. Additional shifting may or may not
be performed, depending on the yyy value, described below.
— @ – Tentatively schedule the job for the current day, even if
the current day is not a working day. Additional shifting may
or may not be performed, depending on the yyy value,
described below.

■ yyy shifts scheduling of the job forward or backward the

specified number of working days, as defined in the CONFCAL
calendar. Valid values are:

— ' ' (Blank) – Do not shift job scheduling any additional time.
Default.

— +nn – Shift job scheduling forward to next nth working day,

where n can be as many as 62 working days in the future.

— -nn – Shift job scheduling backward to the previous nth

working day, where n can be as many as 62 working days in
the past.

yyy does not cause 'negative' scheduling days (-n, -Dn, -Ln, etc.)
to be shifted.
Note: For more information on the use of the SHIFT subparameter,
see “The SHIFT Subparameter” below.

General Information
CONFCAL calendars are useful for handling holidays and other scheduling
exceptions.

CONFCAL is optional. If no value is set for the CONFCAL parameter, jobs are
scheduled according to other basic scheduling criteria without confirmation.

Chapter 3 Job Production Parameters 409

CONFCAL: Basic Scheduling Parameter

CONFCAL must not contain the name of a periodic calendar. If it does, no day can
pass the confirmation.

CONFCAL cannot be used with the PDS and MINIMUM parameters.

The SHIFT Subparameter

If no CONFCAL calendar is specified, no value can be entered in the SHIFT

subparameter, and this field has no effect on job scheduling.

The format and valid values of the SHIFT subparameter are described in Table 166.

The interaction between the x value and the yyy value of the SHIFT subparameter is
as follows:

■ If the original scheduling day of the job is a working day in the CONFCAL
calendar, the x value is ignored and the yyy value determines when the job is
scheduled.

■ If the original scheduling day of the job is not a working day in the CONFCAL
calendar, job scheduling is shifted according to the x value and then shifted again
according to the yyy value (if specified) to determine when the job is scheduled.

If the original scheduling day is not a working day and the x value is blank, the job is
not scheduled (regardless of whether a yyy value is specified).

If the result of shifting by yyy days is a day that is not allowed, that is, if -n was
entered for that day in the DAYS parameter of the job scheduling definition, the job is
shifted again to the next allowed working day (for a forward shift) or to the previous
allowed working day (for a backward shift).

NOTE
Prior to version 5.1.4, the SHIFT subparameter consisted of only the x value. If the yyy value is
not specified, CONFCAL and SHIFT work as they did prior to version 5.1.4, and version 5.1.4
job scheduling definitions do not need to be changed.

Example 1
This example is based on the following assumptions:

■ The current month is September 2001.

■ Working days are defined in calendar WORKDAYS, which contains the following
working days (indicated by Y) for September 2001:
---S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 +
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

410 Control-M for z/OS User Guide

 CONFCAL: Basic Scheduling Parameter

■ Start of the week is defined as Monday. Weeks start on the following dates in
September: 3rd, 10th, 17th, and 24th.

Schedule the rule on the 1st, 7th and 15th day of the month if they are both Saturdays
and working days in WORKDAYS. If the day of the month (1st, 7th, 15th) is not a
Saturday, do not schedule the rule. If the day of the month is a Saturday but is not a
working day, schedule the rule on the next working day.

DAYS - 1,7,15
AND/OR - AND
WDAYS - 6
CONFCAL - WORKDAYS
SHIFT - >

The rule is scheduled on the days of the month indicated by an asterisk:

Figure 153 Days When Job Scheduled

Example 2
Assume that the IOA installation parameter SWEEK was set to SUN (meaning that
Sunday is the first working day of the week.)

Schedule the job on every Thursday, except when Friday is a holiday. If Friday is a
holiday, schedule the job on the working day prior to Thursday.

Set the following parameter values:

WDAYS 6
CONFCAL WORKDAYS
SHIFT <-01

Chapter 3 Job Production Parameters 411

CONFIRM: Runtime Scheduling Parameter

CONFIRM: Runtime Scheduling Parameter

Ensures manual confirmation before a job is submitted or a group is made active.

Figure 154 CONFIRM Parameter Format

Optional. Valid values are described in Table 167.

Table 167 Optional CONFIRM Parameter Values

Parameter Description
Y (Yes) Confirmation required. The job is not submitted unless manual
confirmation is entered in the Active Environment screen.
N (No) No confirmation required. The job can be automatically submitted
by Control-M without manual confirmation. Default.

General Information
If CONFIRM is set to Y, the job appears in the Active Environment screen with a
WAIT CONFIRMATION (FOR SCHEDULE) status. Option C (Confirm) must then be
entered in the Active Environment screen for the job to be submitted. When the job is
confirmed in the Active Environment screen, the CONFIRM value in the Zoom screen
changes to N. If CONFIRM is set to N or left blank, the job is automatically submitted
by Control-M at the first available opportunity.

NOTE
In the case of cyclic jobs, confirmation applies to the first run only. Once confirmed, the job is
recycled without waiting for subsequent confirmation.

412 Control-M for z/OS User Guide

 CONFIRM: Runtime Scheduling Parameter

Example
Job OPERCOMP requires manual confirmation in order to be eligible for submission.
Manual confirmation can be provided from the Active Environment screen once the
job is displayed with a status of WAIT CONFIRMATION (FOR SCHEDULE).

Figure 155 CONFIRM Parameter Example

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
RESOURCE INIT 0001
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM Y
TIME ZONE:
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 413

CONTROL: Runtime Scheduling Parameter

CONTROL: Runtime Scheduling Parameter

Ensures exclusive or shared control over runtime resources.

Figure 156 CONTROL Parameter Format

Optional. A maximum of two resources can be specified in each CONTROL line.

Upon specifying the second resource in a CONTROL line and pressing Enter, a new
line is opened (for specifying additional resources).

Each CONTROL specification consists of the mandatory subparameters described in

Table 168 and may include the optional subparameter described in Table 169.

Table 168 Mandatory CONTROL Subparameters

Subparameter Description
res-name User-supplied, descriptive name of 1 through 20 characters used to
identify the resource.
state Type of control the job requires of the resource. Valid values are:

■ E – The job requires exclusive control of the resource during

processing.
■ S – The job requires shared control of the resource during
processing.

NOTE
Do not specify the same Control resource in both Exclusive (E) and Shared (S) states in the
same job scheduling definition or SMART Table Entity, or the job or table cannot run.

In addition, if the resource is in Exclusive state in the SMART Table Entity, it must not be
specified in any of the jobs belonging to the SMART Table; if the resource is in Shared state in
the SMART Table, it must not be in Exclusive state in any of the jobs belonging to the SMART
Table.

414 Control-M for z/OS User Guide

 CONTROL: Runtime Scheduling Parameter

Table 169 Optional CONTROL Subparameter

Subparameter Description
onFail Whether to keep the Control resource allocated to the job if the job
does not end OK. Valid values are:

■ ' ' (blank) – The resource is not kept allocated to the job. Default.

■ K – The resource is kept allocated to the job until one of the

following events occurs:
— the job is rerun and ends OK
— the job is deleted
— the job is FORCEd OK

Example

CONTROL DISK-VS0020 E K

If the job ends NOTOK, the job continues to hold this exclusive resource.

General Information
The CONTROL parameter is used to control parallel execution of jobs.

If a job requires a resource in exclusive state, it cannot share usage of that resource
with another job (that is, the jobs cannot run in parallel). For example:

■ If JOBA requires exclusive control of a resource that is already in use by a different

job, JOBA must wait until the other job frees the resource regardless of whether the
other job is using the resource in shared or exclusive state.

■ If JOBA already has exclusive control of a resource, any job requiring that resource
must wait until JOBA frees the resource, regardless of whether the job requires the
resource in shared or exclusive state.

If a job requires a resource in shared state, that job can run in parallel with other jobs
requiring the same resource in shared state. For example:

■ If JOBA requires shared control of a resource that is already in shared use by

different jobs, JOBA can use that resource at the same time.

■ If JOBA already has shared control of a resource, any job requiring that same
resource in shared state can use that resource at the same time.

Chapter 3 Job Production Parameters 415

CONTROL: Runtime Scheduling Parameter

However:

■ If JOBA requires shared control of a resource that is already in exclusive use by a

different job, JOBA must wait until the other job frees the resource.

■ If JOBA already has shared control of a resource, any job requiring that same
resource in exclusive state must wait until JOBA frees the resource.

For more information, see “Quantitative and Control Resources” on page 76.

Example
The following three screens (job scheduling definitions) indicate how the CONTROL
parameter can control resource usage. All three job scheduling definitions require
resource (disk) DISK-VS0020:

■ The first job, BKPVS020, is a backup job that requires exclusive control of disk
DISK-VS0020.

■ The other two jobs, CMPRSJOB and CMPRSSRC, are both compress jobs. They do
not require exclusive control (that is, they can share control) of disk DISK-VS0020.

The result is as follows:

■ The CMPRSJOB and CMPRSSRC jobs can be run in parallel with each other, but
neither can run in parallel with the BKPUS020 job.

■ If the BKPVS020 job is running, the CMPRSJOB and CMPRSSRC jobs must wait.

■ If either the CMPRSJOB job or the CMPRSSRC job is running, the BKPVS020 job
must wait.

This is the first of the three jobs in the example (job BKPVS020).

416 Control-M for z/OS User Guide

 CONTROL: Runtime Scheduling Parameter

Figure 157 CONTROL Parameter Example 1

JOB: BKPVS020 LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM BKPVS020 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL DISK-VS0020 E
RESOURCE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

This is the second of the three jobs in the example (job CMPRSSRC).

Figure 158 CONTROL Parameter Example 2

JOB: CMPRSSCR LIB CTM.PROD.SCHEDULE TABLE: OPMAINT
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM CMPRSSCR DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM 025 PDS GSD.DEPO.SCR
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL DISK-VS0020 S
RESOURCE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 417

CONTROL: Runtime Scheduling Parameter

This is the third of three jobs in the example (job CMPRSJOB).

Figure 159 CONTROL Parameter Example 3

JOB: CMPRSJOB LIB CTM.PROD.SCHEDULE TABLE: OPMAINT
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM CMPRSJOB DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL DISK-VS0020 S
RESOURCE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

418 Control-M for z/OS User Guide

 CTB STEP: General Job Parameter

CTB STEP: General Job Parameter

Adds Control-M/Analyzer steps as the first and/or last step of the execution of the
job.

Figure 160 CTB STEP Parameter Format

Optional. The CTB STEP parameter consists of the subparameters described in

Table 170.

Table 170 Optional CTB STEP Parameters

Parameter Description
AT Indicates where to place the Control-M/Analyzer step in the job.
Mandatory. Valid values are:

■ START – The indicated Control-M/Analyzer step must become

the first step of the job.
■ END – The indicated Control-M/Analyzer step must become the
last step of the job.
NAME Name of the Control-M/Analyzer entity. Must be a valid name of a
Control-M/Analyzer rule or mission. Mandatory.
TYPE Type of Control-M/Analyzer entity. Mandatory. Valid values are:

■ RULE – Entity is a Control-M/Analyzer rule.

■ MISSION – Entity is a Control-M/Analyzer mission.
ARGUMENTS Arguments to be passed to the Control-M/Analyzer step. Optional.

NOTE
The ARGUMENTS line is not displayed until the CTB STEP line is filled in and Enter is
pressed.

Chapter 3 Job Production Parameters 419

CTB STEP: General Job Parameter

General Information
A maximum of two CTB STEP statements (that is, one START statement and one
END statement) can be entered.

Upon filling in the first CTB STEP line on the screen and pressing Enter, the
ARGUMENTS line and the second CTB STEP line are displayed. If the second CTB
STEP line is filled in and Enter is pressed, its ARGUMENTS line is displayed.

Multiple arguments must be separated by a comma without a space because they are
automatically passed to the Control-M/Analyzer step as a PARM=‘arguments’
parameter in the JCL of the step.

Control-M uses the status returned by Control-M/Analyzer as it would use the

return status of any job step.

■ If Control-M/Analyzer returns a status of OK or TOLER (within accepted

tolerances), Control-M considers the step as having ended OK.

■ If Control-M/Analyzer returns a status of NOTOK or ABEND, Control-M

considers the job step as having ended NOTOK.

Example
After successfully performing salary calculations, job SACALC01 invokes rule
CHKCALC to ensure that the results are reasonable, and then sets OUT condition
SALARY-OK.

420 Control-M for z/OS User Guide

 CTB STEP: General Job Parameter

Figure 161 CTB STEP Parameter Example

JOB: SACALC01 LIB CTM.PROD.SCHEDULE TABLE: SALARY
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME SACALC01 MEMLIB GENERAL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL SAL GROUP SALARY
DESC SALARY CALCULATIONS
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT END NAME CHKCALC TYPE RULE
ARGUMENTS %%ODATE
CTB STEP AT NAME TYPE
DOCMEM SACALC01 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS 0.15 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT SALARY-OK ODAT +
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 421

D-CAT: Basic Scheduling Parameter

D-CAT: Basic Scheduling Parameter

Name of a Control-D report decollating mission category that must be scheduled
under Control-D when the job is scheduled under Control-M.

NOTE
Prior to version 5.1.4, the D-CAT parameter was called CATEGORY.

Figure 162 DCAT Parameter Format

Optional. The D-CAT parameter must be 1 through 20 characters, or * for all

categories.

If this parameter is specified when Control-D is not installed, New Day processing
stops immediately after this job. For a description of New Day processing, see
Chapter 6, “Selected Implementation Issues,” and the INCONTROL for z/OS
Administrator Guide.

General Information
If the parameter is specified, whenever the job is scheduled, a search is made in the
Control-D report decollating mission library for a job (member) with the name
entered in the MEMNAME parameter, which is described in “MEMNAME: General
Job Parameter” on page 537, and with the same category. (No search is made in the
case of job restarts.)

Generally, the selected category is forced and placed in the Control-D Active
Missions file (that is, the output of the job must be decollated by Control-D). If D-CAT
is set to *, all categories of the job are forced under Control-D.

422 Control-M for z/OS User Guide

 D-CAT: Basic Scheduling Parameter

NOTE
If the CTGFORC parameter of the CTMPARM member in the IOA PARM library is set to NO,
selected categories are scheduled (that is, not forced).

Example
The job output must be decollated by the Control-D report decollating mission
category DAILY.

Figure 163 DCAT Parameter Example

JOB: GNRLDR12 LIB CTM.PROD.SCHEDULE TABLE: GNRLDR
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME GNRLDR12 MEMLIB GENERAL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL GENERAL GROUP GENERAL-LEDGER
DESC GENERAL LEDGER DAILY REPORTS
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM GNRLDR12 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT DAILY
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
==========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 423

DATES: Basic Scheduling Parameter

DATES: Basic Scheduling Parameter

Specifies dates, by month and day, on which the job must be scheduled for execution.

Figure 164 DATES Parameter Format

Optional. The DATES parameter specifies a valid 4-character date, in either mmdd or
ddmm format, depending on site format.

A maximum of 12 dates can be specified.

General Information
The job is scheduled for execution only on the dates specified in the DATES
parameter.

The DATES parameter cannot be used with the PDS, MINIMUM, DAYS, and DCAL
parameters.

If values are set for both the MONTHS parameter and the DATES parameter, the
MONTHS parameter setting is ignored.

To specify more than 12 dates for one job, define the dates in a calendar (instead of
using this parameter) and specify the calendar in the DCAL (or WCAL)
subparameter.

As an alternative to using calendars for specifying more than twelve dates in jobs
belonging to a group, up to twelve dates can be specified in a Schedule RBC
definition in the SMART Table Entity, and multiple rule-based calendars of this type
can be defined. These can then be specified in the jobs.

The relationship between DATES and WDAYS and WCAL is OR. If the job is to be
scheduled according to the DATES parameter or according to the WDAYS and
WCAL combination, it is scheduled.

424 Control-M for z/OS User Guide

 DATES: Basic Scheduling Parameter

Examples

Example 1

Schedule a job for the 15th of January (mmdd format).

DATES 0115

Example 2

Schedule job PRDKPL01 for the 21st of June and the 21st of December (ddmm
format).

Figure 165 DATES Parameter Example

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL KPL GROUP PROD-KPL
DESC DAILY PRODUCTION - START OF APPL-PROD-KPL
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES 2106 2112
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN START-DAILY-PROD-KPL ODAT
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 425

DAYS: Basic Scheduling Parameter

DAYS: Basic Scheduling Parameter

The days of the month on which the job must be scheduled.

Related parameters are “WDAYS: Basic Scheduling Parameter” on page 681 and
“CONFCAL: Basic Scheduling Parameter” on page 408.

Figure 166 DAYS Parameter Format

Optional. The DAYS parameter specifies days of the month on which the job must be
scheduled, provided other basic scheduling criteria are met. Values for DAYS can be
specified alone, or they can be specified together with a calendar specified in the
DCAL subparameter. DAYS and DCAL can also be specified together with WDAYS
and WCAL (described under “WDAYS: Basic Scheduling Parameter” on page 681).

The DAYS subparameters are described in Table 171.

Table 171 DAYS Subparameters (part 1 of 2)

Subparameter Description
days Days of the month on which to schedule a job. The months in which
to order jobs are specified in the MONTHS parameter, described in
“MONTHS: Basic Scheduling Parameter” on page 542. Various
formats (described later) can be used to specify DAYS (for example, 2
means the second day of the month, L2 means the day before the last
day of the month, D1PA means the first day in period A).

426 Control-M for z/OS User Guide

 DAYS: Basic Scheduling Parameter

Table 171 DAYS Subparameters (part 2 of 2)

Subparameter Description
DCAL Name of a calendar containing a predefined set of dates (referred to
as working days) on which a job must be scheduled. A specified
value must be either a valid member name of 1 through 8 characters,
or an * to indicate that the calendar specified in the CONFCAL
parameter must be used for scheduling. For more information on
how to define, use and modify calendars, see “IOA Calendar
Facility” on page 313.
Note: A calendar specified in DCAL does not have to exist when
defining the DAYS parameter. It must exist when the job is being
ordered.
AND/OR Conjunctional parameter used to link the DAYS and WDAYS
parameters when both are specified.

■ A (AND) – Both DAYS (/DCAL) and WDAYS (/WCAL) criteria

must be met in order for a job to be scheduled.

■ O (OR) – DAYS (/DCAL) and/or WDAYS (/WCAL) criteria

must be met for a job to be scheduled. Default.

If A (AND) is specified when either DAYS or WDAYS is specified

(but not both), the missing DAYS or WDAYS value is automatically
set to ALL.

Assuming all other basic scheduling criteria are met:

■ When DAYS are specified without DCAL, the job is scheduled on the specified
days (in the specified months).

■ When DCAL is specified without DAYS, the job is scheduled on all working days
marked in the DCAL calendar.

■ When DAYS and DCAL are both specified, scheduling depends on how the
working days are defined in the calendar and the values or format of the DAYS
parameter combine, as described in the following paragraphs.

■ When both DAYS and WDAYS criteria are specified, scheduling depends on the
AND/OR subparameter connecting them.

Valid Formats for DAYS

Valid formats for the DAYS parameter, and how they relate to DCAL, are described
in the following paragraphs.

Chapter 3 Job Production Parameters 427

DAYS: Basic Scheduling Parameter

In the following non-periodic scheduling formats:

■ n is an integer from 1 through 31.

■ Multiple values can be specified (separated by commas) in any order.
■ A calendar name specified for DCAL must not designate a periodic calendar.
Table 172 Non-Periodic Scheduling Formats
Parameter Description
ALL All days of the month. If ALL is specified, other DAYS values cannot
be specified with it.

If a DCAL calendar is not defined, schedule the job on all days in the
month. If a DCAL calendar is defined, schedule the job only on the
working days indicated in the calendar.
n,… Specific days of the month.

If a DCAL calendar is not defined, schedule the job on the specified

days.

If a DCAL calendar is defined, schedule the job only when a day is

defined as a working day in both the DAYS parameter and the
DCAL calendar.
+n,... Days of the month in addition to the working days specified in the
DCAL calendar. DCAL is mandatory.
–n,... Order the job on all days except the nth day from the beginning of
the month. DCAL is mandatory.
>n,... Order the job on the indicated day if it is a working day in the DCAL
calendar; otherwise, order the job on the next working day that is not
negated by a –n value in this parameter. This format is frequently
used for holiday handling. DCAL is mandatory.
<n,... Order the job on the indicated day if it is a working day in the DCAL
calendar; otherwise, order the job on the last previous working day
of the month that is not negated by a –n value in this parameter. This
format is frequently used for holiday handling. DCAL is mandatory.
Dn,... Order the job on the nth working day from the beginning of the
month. DCAL is mandatory.
–Dn,... Order the job on all working days except the nth working day from
the beginning of the month. DCAL is mandatory.
Ln,... Order the job on the nth day (or nth working day if DCAL is defined)
counting backward from the end of the month. DCAL is optional.
–Ln,... If DCAL is defined, order the job on all working days except the nth
working day counting backward from the end of the month. If
DCAL is not defined, order the job on all days except the nth day
counting backward from the end of the month. DCAL is optional.

428 Control-M for z/OS User Guide

 DAYS: Basic Scheduling Parameter

In the following periodic scheduling formats:

■ n is any integer from 1 through 63, and i is any valid period identifier.

■ An * can be specified as the i value to represent all periods.

■ An * can be specified as the n value in format DnPi to represent all days. (* is not a
valid n value in formats –DnPi, LnPi and –LnPi.)

■ A period can span any number of days, but by default, no more than 33 days can
elapse after the appearance of one identifier in a period until the appearance of the
next matching identifier in the same period. Once a gap of 33 days has been
reached, the period automatically closes. However, the INCONTROL
administrator can change the 33-day default by changing the value in member
IOADFLT in the IOAENV library.

■ The name of a periodic calendar must be specified in DCAL. For details about
periodic calendars, see “IOA Calendar Facility” on page 313.

Table 173 Periodic Scheduling Formats

Format Description
DnPi,... Order the job on the nth day of period i from the beginning of the
period.
–DnPi,... Order the job on all days of period i except the nth day of period i
from the beginning of the period.
LnPi,... Order the job on the nth day of period i counting backward from the
last day of the period.
–LnPi,... Order the job on all days of period i except the nth day of period i
counting backward from the last day of the period.

General Information
Negative values take precedence over positive values when determining whether a
job must be scheduled on a certain date. If a negative value (that is, format –n, –Dn, –
Ln, –DnPi, or – LnPi) in either the DAYS or WDAYS field prevents a job from being
scheduled on a date, the job is not scheduled on that date even if a positive value
(such as Ln) in a basic scheduling parameter would otherwise result in the job being
scheduled on that date.

A maximum of eight periodic values of type DnPi, –DnPi, LnPi, and/or –LnPi can be
designated in any desired order.

If periodic and non-periodic values are mixed when specifying the DAYS parameter,
processing depends on the calendar type specified in the DCAL parameter:

Chapter 3 Job Production Parameters 429

DAYS: Basic Scheduling Parameter

■ If a non-periodic calendar is specified in the DCAL parameter, only non-periodic

values in the DAYS parameter are processed; periodic values are ignored. In this
case, negative periodic values (that is, –DnPi, –LnPi) are also ignored and do not
supersede other values.

■ If a periodic calendar is specified in the DCAL parameter, all periodic values and
the negative non-periodic value -n in the DAYS parameter are processed; all other
non-periodic values are ignored.

The MONTHS parameter is ignored when periodic values are specified in the DAYS
parameter.

For information about certain exceptional situations in the interaction of the DAYS
and MONTHS parameters, see “MONTHS: Basic Scheduling Parameter” on
page 542.

The DAYS parameter cannot be used with the PDS, MINIMUM, and DATES
parameters.

Examples
The examples in this chapter are based on the following assumptions:

■ The current month is December, 2001.

■ Working days are defined in calendar WORKDAYS, which contains the following
working days (indicated by Y) for December, 2001.

---S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

■ WDAYS are defined as working days beginning on Monday.

■ Periodic calendar PERIDAYS contains the following periodic definition for

December 2001. These examples assume that all other days of this calendar are
blank.

---S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
B C A A B B C A A B B C A A B B C A A B B

■ Start of the week is defined as Monday. Weeks start on the following dates in
December 2001: 3rd, 10th, 17th, 24th, and 31st.

At the end of each example, asterisks in a December 2001 calendar indicate the days
on which the job is scheduled.

430 Control-M for z/OS User Guide

 DAYS: Basic Scheduling Parameter

Example 1

Schedule the job on the 17th day and the last day of the month.

DAYS 17,L1

The job is scheduled on the days of the month indicated by an asterisk:

Figure 167 DAYS Parameter Example 1

Example 2

Schedule the job on all working days of the month except the 6th day of the month,
and also schedule the job on the 1st day of the month.

DAYS +1,-6
DCAL WORKDAYS

The job is scheduled on the days of the month indicated by an asterisk:

Figure 168 DAYS Parameter Example 2

Example 3

Schedule the job on all working days of the month except the first and last working
days, and except the 17th day, of the month.

DAYS -D1,-17,-L1
DCAL WORKDAYS

Chapter 3 Job Production Parameters 431

DAYS: Basic Scheduling Parameter

The job is scheduled on the days of the month indicated by an asterisk:

Figure 169 DAYS Parameter Example 3

Example 4

Schedule the job on the 8th day of the month. If it is not a working day, schedule the
job on the closest preceding working day.

DAYS <8
DCAL WORKDAYS

The job is scheduled on the days of the month indicated by an asterisk:

Figure 170 DAYS Parameter Example 4

Example 5

Schedule the job on the 1st day of period A, and on all days, except the 2nd day, of
period B. Do not schedule the job on the 5th day of the month.

DAYS -5,D1PA,-D2PB
DCAL PERIDAYS

The job is scheduled on the days of the month indicated by an asterisk:

Figure 171 DAYS Parameter Example 5

432 Control-M for z/OS User Guide

 DAYS: Basic Scheduling Parameter

Example 6

Schedule the job on each Monday and on the 1st day of the month.

DAYS 1
AND/OR OR
WDAYS 1

The job is scheduled on the days of the month indicated by an asterisk:

Figure 172 DAYS Parameter Example 6

Example 7

Schedule the job on the 3rd day of the month provided it is a Monday.

DAYS 3
AND/OR AND
WDAYS 1

The job is scheduled on the days of the month indicated by an asterisk:

Figure 173 DAYS Parameter Example 7

Example 8

Schedule the job on the last Monday of the month.

DAYS L1,L2,L3,L4,L5,L6,L7
AND/OR AND
WDAYS 1

The job is scheduled on the days of the month indicated by an asterisk:

Chapter 3 Job Production Parameters 433

DAYS: Basic Scheduling Parameter

Figure 174 DAYS Parameter Example 8

Example 9

Schedule the job on the 1st, 7th and 15th days of the month if they are both Saturdays
and working days. If the day of the month (1st, 7th, 15th) is not a Saturday, do not
schedule the job. If the day of the month is a Saturday, but it is not a working day,
schedule the job on the next working day.

DAYS 1,7,15
AND/OR AND
WDAYS 6
CONFCAL WORKDAYS
SHIFT >

The job is scheduled on the days of the month indicated by an asterisk:

Figure 175 DAYS Parameter Example 9

Example 10

Schedule the job to run on the first Friday after the 15th of the month.

DAYS 16,17,18,19,20,21,22
AND/OR AND
WDAYS 5

434 Control-M for z/OS User Guide

 DAYS: Basic Scheduling Parameter

The job is scheduled on the days of the month indicated by an asterisk:

Figure 176 DAYS Parameter Example 10

Example 11

Schedule the job to run on the 15th day of every period, except for period G. The
periods are defined in periodic calendar PERCAL.

The following steps are required:

1 In the SMART Table Entity of a SMART Table, define a rule-based calendar, RBC1,
which contains the following scheduling criteria:

DAYS -D15PG,D15P* DCAL PERCAL

2 In the actual job definition, specify the following:

SCHEDULE RBC RBC1

RELATIONSHIP (AND/OR) A
DAYS D15P* DCAL PERCAL

Chapter 3 Job Production Parameters 435

DEFINITION ACTIVE: Basic Scheduling Parameter

DEFINITION ACTIVE: Basic Scheduling

Parameter
Specifies the time limits (FROM, UNTIL) for using the job scheduling definition.

Figure 177 DEFINITION ACTIVE Parameter Format

Optional. The parameters include the subparameters described in Table 172.

Table 174 DEFINITION ACTIVE Subparameters

Subparameter Description
FROM 6-digit date. The job scheduling definition will only be used if the
ordering date is later than the date specified. Default: ‘ ‘ (Blank)
UNTIL 6-digit date. The job scheduling definition will only be used if the
ordering date is earlier than the date specified. Default: ‘ ‘ (Blank)

The format of either the FROM or UNTIL subparameters may be ddmmyy, mmddyy,
or yymmdd, depending on your local site standard, as set by the DATETYP
parameter in the IOAPARM member in the IOA PARM library.

General Information
FROM and UNTIL dates together define a time frame for ordering the job. Unless
forced, a job can only be ordered during the specified time frame. However, if the job
is forced, the FROM and UNTIL parameters are ignored.

■ If you specify both the FROM and UNTIL subparameters for a particular job, the
job can only be ordered on or later than the date specified in the FROM
subparameter, and on or earlier than the date specified in the UNTIL
subparameter. There are two possibilities:

436 Control-M for z/OS User Guide

 DEFINITION ACTIVE: Basic Scheduling Parameter

1. The date specified in the FROM subparameter is earlier than that specified in the
UNTIL subparameter.

For example,

DEFINITION ACTIVE FROM 091002 UNTIL 011102

The job can only be ordered on or between October 9, 2002 and November 1,
2002.

2. The date specified in the FROM subparameter is later than that specified in the
UNTIL subparameter.

For example,

DEFINITION ACTIVE FROM 090502 UNTIL 010402

The job can only be ordered on or after May 9, 2002, or before or on April 1,
2002, but not between those dates.

■ If you specify the FROM subparameter, but not the UNTIL subparameter, the job
cannot be ordered before the date specified, but can be ordered on or at any time
later than that date.

For example,

DEFINITION ACTIVE FROM 091002 UNTIL

The job can only be ordered on or after October 9, 2002.

■ If you do not specify the FROM subparameter, but specify the UNTIL
subparameter, the job can be ordered on or at any time earlier than the date
specified, but not later than that date.

For example,

DEFINITION ACTIVE FROM UNTIL 011102

The job can only be ordered on or before November 1, 2002.

■ If you do not specify either the FROM or UNTIL subparameters, there is no

restriction on the date when the job can be ordered.

For example,

DEFINITION ACTIVE FROM UNTIL

The job can be ordered on any date.

Chapter 3 Job Production Parameters 437

DESC: General Job Parameter

DESC: General Job Parameter

Description of the job to be displayed in the Job List screen.

Figure 178 DESC Parameter Format

Optional. This parameter may consist of text of 1 through 4000 characters. DESC lines
hold 70 characters each and are added as needed.

General Information
The DESC parameter is informational. It does not affect job processing. It serves as
internal documentation, to let the user know the purpose of (or some other key
information about) the job.

The description specified in the DESC parameter appears to the right of the job name
in the Job List screen.

Text for the DESC parameter can be specified in any language.

NOTE
For conversion customers prior to version 6.0.00, if the current job was converted from
another job scheduling product, such as CA-7, the string SCHEDULE-PREV-DAY or
SCHEDULE-PREV-ONLY may appear in the DESC field for the job group. This string causes
all scheduled runs of the job to be shifted back one day. The SAC parameter is used instead.

For information on how to specify more detailed job documentation, see “Job
Documentation” on page 149.

438 Control-M for z/OS User Guide

 DESC: General Job Parameter

Example
Job OPERCOMP appears in the Job List screen with the description: JOB RUN ON
THE 1ST OF THE MONTH.

Figure 179 DESC Parameter Example

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME OPERCOMP MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL OPER GROUP MAINTENANCE
DESC JOB RUN ON THE 1ST OF THE MONTH
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 439

DO Statement: Post–Processing Parameter

DO Statement: Post–Processing Parameter

Actions taken when the ON step and codes event criteria are satisfied.

Figure 180 DO Parameter Format

Optional. Specify DO statements as follows:

■ Type the action keyword (such as COND) in the DO field and press Enter.

■ In many cases, subparameter fields are displayed. Fill in the subparameters and
press Enter again.

■ Multiple DO statements can be specified. After entering a DO statement, another

DO line is automatically displayed.

DO actions are described in Table 175. Each is discussed in detail in this chapter.

Table 175 DO Actions (part 1 of 2)

DO Action Description
DO COND Adds and/or deletes a prerequisite condition.
DO CTBRULE Invokes a Control-M/Analyzer rule.
DO FORCEJOB Forces a job order under Control-M.
§Restart§ DO If a rerun is necessary for the job, specifies restart parameters for
IFRERUN Control-M/Restart.
DO MAIL Sends an e-mail to the specified recipients.
DO NOTOK Sets the job step status to NOTOK.
DO OK Sets the job step status to OK.
DO REMEDY Open a Remedy Helpdesk ticket.
DO RERUN Reschedules the job (for rerun).
DO SET Assigns a value to an AutoEdit variable.
DO SHOUT Sends a message to a specified destination.

440 Control-M for z/OS User Guide

 DO Statement: Post–Processing Parameter

Table 175 DO Actions (part 2 of 2)

DO Action Description
DO STOPCYCL Stops recycling a cyclic task.
DO SYSOUT Handles the job output.

General Information
DO statements are generally paired with the preceding ON PGMST, ON PROCST, or
ON CODES statements (all of which are described in this chapter). Their implied
relationship is:

Table 176 Relationship of DO Statements with Other Statements

Statement Description
IF On step and code event criteria (specified in the ON PGMST, ON
PROCST, or ON CODES statements) are satisfied.
THEN Perform all actions specified in the DO statements.

All specified DO statements have an AND relationship.

To add an empty DO statement between two existing DO statements, type the >
character over the first letter in the DO field of the earlier DO statement, and press
Enter.

Example

DO >OND

>OND is restored to its original value, COND, when Enter is pressed (the > character
disappears).

To delete unwanted DO statements, either delete the DO keyword and press Enter or
specify appropriate Line Editing commands in the Edit environment, which is
described in Appendix A, “The Control-M Application Program Interface
(CTMAPI),”

Chapter 3 Job Production Parameters 441

DO COND: Post–Processing Parameter

DO COND: Post–Processing Parameter

Specifies prerequisite conditions to be added or deleted if the accompanying ON step
and code criteria are satisfied.

NOTE
DO COND and OUT statements are similar, but not identical. The differences are outlined in
“Differences between OUT and DO COND” on page 446.

Figure 181 DO COND Parameter Format

Optional. Type COND in the DO field and press Enter.

A maximum of two prerequisite conditions can be specified in each standard DO

COND line. One prerequisite condition can be specified in each long DO COND line.
When you specify the second prerequisite condition in a standard DO COND line, or
one prerequisite condition in a long DO COND line, and press Enter, a new DO
COND line is opened for specifying additional prerequisite conditions. For more
information, see “Specifying Long DO COND Condition Names” on page 445.

Each DO COND statement consists of the mandatory subparameters described in

Table 177.

442 Control-M for z/OS User Guide

 DO COND: Post–Processing Parameter

Table 177 DO COND Mandatory Subparameter Formats (part 1 of 2)

Subparameter Description
cond-name User-supplied descriptive name of 1 through 39 characters, used to
identify the condition.
Note: A condition name must not begin with the symbols “|”, “¬”,
or “\”, and must not contain parentheses ( ), because each of these
characters has a special meaning.
You can use an AutoEdit variable in a condition name, provided that
the AutoEdit variable has a value that is known before the job is
ordered.
dateref 4-character date reference. Valid values are:

■ date – A specific date, in either mmdd or ddmm format, depending

on the site standard

■ ODAT – Resolves to the original scheduling date. Default.

■ +nnn – Resolves at job order time to ODATE+nnn calendar days.

nnn is three digits (000-999).

■ -nnn – Resolves at job order time to ODATE-nnn calendar days.

nnn is three digits (000-999).
Note: +001 and -001 are not necessarily the same as NEXT and
PREV, because NEXT and PREV are based on job scheduling criteria,
while +nnn and -nnn are based on calendar days.
■ PREV – Resolves to the previous date on which the job ought to
have been scheduled, according to its basic scheduling criteria
(or ODATE–1 for a forced job).

■ NEXT – Resolves to the next date on which the job is scheduled,

according to its basic scheduling criteria (or ODATE+1, for a
forced job.)

■ STAT – Static. Indicates that the condition (such as IMS-ACTIVE)

is not date-dependent.
Note: Before STAT was introduced, date 0101 was recommended
to be used in conditions that were not date-dependent. Unlike
0101, STAT is not a date, and it operates differently. Always use
STAT when defining conditions that are not date-dependent.
■ **** – Any scheduling date. Valid only with opt set to - (Minus)

■ $$$$ – Any scheduling date. Valid only with opt set to - (Minus)
Note: If a date reference is not specified, the value ODAT is
automatically inserted upon pressing Enter.

Chapter 3 Job Production Parameters 443

DO COND: Post–Processing Parameter

Table 177 DO COND Mandatory Subparameter Formats (part 2 of 2)

Subparameter Description
opt Indicates whether to add or delete the specified prerequisite
condition. Valid values are:

■ + (Plus) – Add (create) the prerequisite condition

■ - (Minus) – Delete the prerequisite condition

General Information
When a DO COND statement is activated, the specified prerequisite conditions are
added to or deleted from the IOA Conditions file according to the value set for opt.

Prerequisite conditions are usually used to establish job dependencies or ensure

manual intervention when required.

■ To establish a job dependency, define a prerequisite condition in an OUT or DO

COND statement in the job that must run first, and in an IN statement in the job
that must run afterwards.

The job containing a prerequisite condition in its IN statement is not submitted

unless that prerequisite condition has been added manually or by the job
containing an OUT or DO COND statement.

An OUT statement is used to add the prerequisite condition if the job ends OK.

Use a DO COND statement to add the prerequisite condition if the step and code
event criteria specified in the accompanying ON statement are satisfied.

■ If the IN prerequisite condition can only be satisfied by manual intervention (for

example, TAPE1-ARRIVED is set by the operator after an external tape has arrived
insight), performance of the required manual intervention before job submission is
ensured.

OUT and DO COND statements can also be used to delete prerequisite conditions.
The OUT statement of the job can be used to delete the prerequisite condition after
the job ends OK. A DO COND statement can be used to delete prerequisite conditions
if the accompanying ON step and code criteria are satisfied.

These statements are generally used to delete prerequisite conditions either to

prevent a particular job from running or when the condition is no longer needed by
any other jobs in the Active Jobs file.

DO COND functions are performed after the functions of the OUT parameter.

444 Control-M for z/OS User Guide

 DO COND: Post–Processing Parameter

■ If a prerequisite condition is added by the OUT parameter and deleted by the DO

COND parameter, the combined effect is the deletion of the prerequisite condition.

■ If a prerequisite condition is deleted by the OUT parameter and added by the DO

COND parameter, the combined effect is the addition of that prerequisite
condition.

The following are examples of prerequisite conditions:

IMS-ACTIVE
JOB_PAYCALC_ENDED_OK
TAPE1_LOADED

All prerequisite conditions are associated with a date reference that is used to
distinguish between different runs of the same job with different scheduling dates. If,
for example, a condition is being deleted, only the condition matching the specified
date is deleted. The same condition associated with a different date is not deleted.
When adding or deleting prerequisite conditions, the date associated with the
prerequisite condition can be a specific 4-character date or one of the symbolic dates
described in the explanation of parameter “dateref” on page 443.

Prerequisite conditions created by a DO COND statement can trigger the execution of

other jobs or processes.

Prerequisite conditions deleted by a DO COND statement can prevent the execution

of jobs and processes whose IN statements require those prerequisite conditions.

If two or more DO COND statements are contradictory, statements performed earlier

are overridden by statements that are performed later.

For more information regarding prerequisite conditions, see “IN: Runtime

Scheduling Parameter” on page 507, “ON Statements: Post–Processing Parameter” on
page 546, and “OUT: Post–Processing Parameter” on page 571, and see “Prerequisite
Conditions” on page 72.

Specifying Long DO COND Condition Names

Regular prerequisite conditions are not more than 20 characters in length. If you want
to specify a longer condition name, up to 39 characters in length, enter the string
LONG in the date reference field of an empty DO COND condition line. An (L)
appears at the beginning of the line. If the field already contains data, entering the
string LONG will open a new long DO COND parameter, with (L) appearing at the
beginning of the line. You can now insert a long condition name, as illustrated in
Figure 182.

Specify SHRT in the date reference field to revert back to condition names of standard
length.

Chapter 3 Job Production Parameters 445

DO COND: Post–Processing Parameter

NOTE
Long condition names cannot be used in CMEM rule definitions.

Figure 182 Long DO COND Condition

JOB: IEFBR14 LIB CTMP.V610.SCHEDULE TABLE: PHILL1
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
IN CTM-DAILYPRD-ENDEDXX ODAT CTM-DAILYSYS-ENDEDXX ODAT
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY 00 SAC CONFIRM
TIME ZONE:
==========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST +EVERY PROCST STEP1 CODES SOC4 A/O
DO COND (L) THIS-IS-A-LONG-DO-C0ND-CONDITION-NAME ODAT
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN NOTOK TIME + DAYS TO OPER2 URGN R
MS LOADING OF MANUAL CONDITIONS SCREEN FAILED. CALL OP MANAGER.
SHOUT WHEN TIME + DAYS TO URGN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 16.30.17

Differences between OUT and DO COND

OUT and DO COND statements have the following differences:

■ An OUT statement is applied only if the job ends OK. DO COND statements are
associated with accompanying ON statements and are applied only if the
accompanying ON step and code criteria are satisfied.

■ An OUT statement appears in each job scheduling definition. No DO COND

statement appears unless specified. To specify a DO COND statement, type COND
in an empty DO field and press Enter.

■ DO COND statements are processed after OUT statements and can therefore
override OUT statements.

■ MVS restart can only be requested from an OUT statement, not a DO COND
statement.

446 Control-M for z/OS User Guide

 DO COND: Post–Processing Parameter

Example
The following example provides a simplified demonstration of how Control-M can be
used to monitor IMS. Prerequisite conditions, CHANGE-ACCUMULATION and
LOGCLOSE-NEEDED, can be used as IN prerequisite conditions to trigger the
execution of IMS maintenance jobs that depend on those conditions.

Figure 183 DO COND Parameter

JOB: IMSPROD LIB CTM.PROD.SCHEDULE TABLE: IMSPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
===========================================================================
OUT IMS-ACTIVE **** -
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST STEP01 PROCST CODES U0421 A/O
DO COND CHANGE ACCUMULATION ODAT +
DO
ON PGMST STEP01 PROCST CODES U0428 A/O
DO COND LOGCLOSE-NEEDED ODAT +
DO
ON PGMST STEP01 PROCST CODES U0426 A/O
DO SHOUT TO U-DBA URGENCY V
= *** IMSPROD ABENDED WITH U0426 ****
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 447

DO CTBRULE: Post–Processing Parameter

DO CTBRULE: Post–Processing Parameter

Invokes a Control-M/Analyzer rule to be executed during the processing of a specific
program step. Available only at sites utilizing Control-M/Analyzer.

Figure 184 DO CTBRULE Parameter Format

Optional. Type CTBRULE in the DO field and press Enter. The DO CTBRULE
subparameters are described in Table 178.

Table 178 DO CTBRULE Subparameters

Subparameter Description
rule_name Name of the Control-M/Analyzer rule that is to be executed. The
Control-M/Analyzer rule contains all balancing specifications to be
performed. The rule name can be a maximum of eight characters.
Mandatory.
arg Arguments that are passed to the Control-M/Analyzer rule.
Separate multiple arguments by commas. A maximum of 45
characters can be specified. Optional.

General Information
When DO CTBRULE is specified, balancing is performed by the Control-M/Analyzer
Runtime environment according to the specified rule definition and using the
specified arguments. The Control-M/Analyzer Runtime environment is invoked
once for each DO CTBRULE statement in the job scheduling definition.

NOTE
If DO CTBRULE is specified under ON PGMST ANYSTEP, the Control-M/Analyzer Runtime
environment is invoked only once.

448 Control-M for z/OS User Guide

 DO CTBRULE: Post–Processing Parameter

When Control-M calls a Control-M/Analyzer rule, the Control-M/Analyzer System

variable SYSOPT contains the value CTMWORK. This variable can then be tested
within the Control-M/Analyzer rule definition to determine if Control-M invoked
the Control-M/Analyzer Runtime environment.

When the Control-M/Analyzer Runtime environment is invoked by Control-M, that

is, the Control-M/Analyzer System variable SYSOPT is set to CTMWORK,
Control-M/Analyzer can analyze and balance SYSDATA. For more information
about invoking Control-M/Analyzer rules from Control-M job scheduling
definitions, see the discussion of the interface to Control-M in the Control-M/Analyzer
FOR z/OS User Guide.

Example

If the job ends OK, execute Control-M/Analyzer balancing rule GOVTBAL.

Figure 185 DO CTBRULE Parameter Example

JOB: GOVTREPT LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
TIME: FROM UNTIL PRIORITY DUE OUT SAC CONFIRM
TIME ZONE:
===========================================================================
OUT FINANCE-GOVTREPT-OK ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES OK A/O
DO CTBRULE = GOVTBAL ARG DOREPORT,10,%%ODATE
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN NOTOK TIME + DAYS TO TS0-M44 URGN R
MS JOB GOVTREPT ENDED "NOT OK"
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 449

DO FORCEJOB: Post–Processing Parameter

DO FORCEJOB: Post–Processing Parameter

Force one or more jobs under Control-M.

Figure 186 DO FORCEJOB Parameter Format

Optional. Type FORCEJOB in the DO field and press Enter. The DO FORCEJOB
subparameters are described in Table 179.

Table 179 DO FORCEJOB Subparameter Formats

Subparameter Description
TABLE Name of Control-M table.
JOB Job name. If this field is blank, all jobs in the specified table are
forced.
DATE 6-character scheduling date for the jobs. Valid values are:

■ date – Specific date (in either mmddyy, ddmmyy or yymmdd

format, depending on the site standard).

■ ODAT – Inherit the original Control-M scheduling date of the job

that issues the DO FORCEJOB command. Default.

■ DATE – Resolves to the current system date.

LIBRARY Name of the scheduling library containing the specified table. The
library name may contain auto-edit variables.

General Information
The DO FORCEJOB statement schedules jobs under Control-M even if the jobs are not
normally scheduled on the specified date (according to the Basic Scheduling
parameters of the job). It is similar to the FORCE option in the Control-M Rule List
screen or Table List screen.

450 Control-M for z/OS User Guide

 DO FORCEJOB: Post–Processing Parameter

If the DO FORCEJOB statement specifies a job name belonging to multiple jobs in the
table, the first job in the table with that job name is forced.

Without the DO FORCEJOB statement, emergency jobs and jobs that run in special
circumstances would require daily scheduling or manual forcing (from the Online
facility). By defining appropriate ON criteria and DO FORCEJOB statements,
emergency or other special jobs can be automatically forced when required without
being previously scheduled.

The DO FORCEJOB statement causes the Control-M monitor to dynamically allocate

the job scheduling library specified in the LIBRARY parameter using the DD name
ONSPLT.

DO FORCEJOB request during RESTART

The FORCONCE parameter in the CTMPARM member of the IOA PARM library
may be set to control the behavior of DO FORCEJOB requests during a Restart of a
job.

If DO FORCEJOB statements are not to be executed during the RESTART of a job if

they were already executed during the original run of the job or during a previous
RESTART of the job, then the FORCONCE parameter should be set to Y.

If DO FORCEJOB statements are always to be executed during the RESTART of a job

(when the ON PGMST condition is satisfied), then the FORCONCE parameter should
be set to N.

Failure of a DO FORCEJOB request

When a DO FORCEJOB request fails because the table is in use, Control-M may try
again to execute the job, depending on the values set for the FORCE# RT and
FORCE# WI installation parameters. For more information on the FORCE# RT and
FORCE# WI installation parameters, see the INCONTROL for z/OS Installation Guide.

When a DO FORCEJOB request fails because the table has been migrated, the action
of Control-M depends on the value of the SCRECALL parameter in the CTMPARM
member.

■ If the value of SCRECALL is Y, the table is recalled, and Control-M tries to reorder
the job in the same way as if the table is in use.

■ If the value of SCRECALL is N, the table is not recalled, and the job is not
scheduled. This is the default setting of SCRECALL.

For more information on the SCRECALL parameter, see the customization chapter of
the INCONTROL for z/OS Installation Guide.

Chapter 3 Job Production Parameters 451

DO FORCEJOB: Post–Processing Parameter

Example
On any system or user abend on any step in job PRDKPL01, force emergency job
PRDKPLSP.

Figure 187 DO FORCEJOB Parameter Example

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
===========================================================================
OUT PRDKPL01-ENDED-OK ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES S*** U**** A/O
DO FORCEJOB TABLE EMRJOBS JOB PRDKPLSP DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN NOTOK TIME + DAYS TO TS0-T43 URGN R
MS PRDKPL01 ENDED NOT OK, PLEASE CHECK IT
SHOUT WHEN LATESUB TIME 0200 + DAYS TO U-SHIFT-MANAGER URGN R
MS PRDKPL01 WAS NOT SUBMITTED YET, PLEASE CHECK WHY
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Confirmation panel
If the DFJCONF profile variable is set to Y, and the JOB parameter in the DO
FORCEJOB request is blank, a confirmation panel is displayed when exiting the Job
Scheduling Definition screen. The confirmation panel is displayed only once for each
DO FORCEJOB statement.

Figure 188 DO FORCEJOB Confirmation Panel

+----------------------------------------------------------+
| |
| THIS JOB CONTAINS ONE OR MORE DO FORCEJOB STATEMENTS. |
| WHEN THE JOB IS ORDERED: |
| ARE YOU SURE YOU WANT TO FORCE THE WHOLE TABLE IN THE |
| FORCEJOB STATEMENT(S)? (Y/N) |
| |
+----------------------------------------------------------+

Enter Y to save the table and return to the Job List screen, or N to return to the table
without saving it.

452 Control-M for z/OS User Guide

 §Restart§DO IFRERUN: Post–Processing Parameter

§Restart§DO IFRERUN: Post–Processing

Parameter
Job steps to be executed during restart of a job. Available only at sites utilizing
Control-M/Restart.

Figure 189 §Restart§ DO IFRERUN Parameter Format

Optional. Type IFRERUN in the DO field and press Enter. The DO IFRERUN
subparameters are described in Table 180.

Chapter 3 Job Production Parameters 453

§Restart§DO IFRERUN: Post–Processing Parameter

Table 180 §Restart§ DO IFRERUN Subparameter Formats (part 1 of 2)

Subparameter Description
FROM Step at which the job must be restarted. Mandatory. Valid values are:

■ pgmstep – program step within the job stream (see the following
note)

■ pgmstep.procstep – program step within the called procedure (see

the following note)

■ $FIRST – first step of the job

■ $ABEND – step of the job that ended NOTOK due to system

abend, user abend, condition code C2000 (PL/1 abend) or JFAIL
(job failed on JCL error)
$ABEND is a subset of $EXERR (below)

■ $FIRST.$ABEND – first step of the abended procedure

■ $FIRST.$CLEANUP – this reserved keyword instructs

Control-M to run a Control-M/Restart data set cleanup for the
job
Data set cleanup is performed from the first step of the job. The
job itself is not restarted.

■ $EXERR – job step that ended with any error, including an

abend, or that ended with a condition code that is redefined
using the ON and DO statements as ENDED NOTOK
Note: If, during a restart of the job, the Control-M/Restart step itself
ends NOTOK, you must manually correct the problem encountered
by the Control-M/Restart step and then restart the job once again. In
such a case, Control-M/Restart does both of the following:

■ It restores DO IF RERUN decisions to their state before the last

execution of the job.
■ It deactivates the DO RERUN action.

This enables Control-M/Restart to ignore the occurrence where the

error arose during the operation of Control-M/Restart itself. This
prevents rerun processing from looping.

454 Control-M for z/OS User Guide

 §Restart§DO IFRERUN: Post–Processing Parameter

Table 180 §Restart§ DO IFRERUN Subparameter Formats (part 2 of 2)

Subparameter Description
TO Step at which the restarted job must terminate. Optional. Valid
values are:

■ pgmstep – Program step within the job stream (see the following
note).

■ pgmstep.procstep – Program step within the called procedure (see

the following note).

If not specified, the restarted job terminates at the last job step that
would normally be executed.
Note: For both FROM and TO steps, pgmstep is the name of the step
(EXEC statement) that executes the program from which to begin or
end the restart:

//pgmstep EXEC PGM=program

procstep is the name of the step (EXEC statement) that invokes the
procedure from which the above pgmstep program is executed:

//procstep EXEC procedure

pgmstep and procstep values can each be 1 through 8 characters.

When specifying a procstep when the procedures are nested, the

innermost procstep in which the program is included must be
specified.
CONFIRM Specifies whether a manual confirmation is required before the job is
restarted. Valid values are:

■ Y (Yes) – Confirmation required. The job restart is not submitted

unless a manual confirmation is entered in the Active
Environment screen.

■ N (No) – No confirmation required. The job restart can be

automatically submitted (by the DO RERUN statement) without
a manual confirmation. Default.

Chapter 3 Job Production Parameters 455

§Restart§DO IFRERUN: Post–Processing Parameter

General Information
When a DO IFRERUN statement is specified, the rerun is performed by the Restart
facility of Control-M/Restart using the specified restart subparameters.

■ When DO IFRERUN is specified with a CONFIRM value of N (No):

— If a DO RERUN statement follows, the job is automatically submitted for rerun.

— If a DO RERUN statement does not follow, the job is not automatically rerun.
Instead, the job remains displayed with its error status in the Active
Environment screen.

In this case, to submit the job for rerun or restart, specify option R (Rerun) in the
Active Environment screen. The Rerun (with Restart) Confirmation Window is
displayed. Request the restart or rerun from the window.

■ When DO IFRERUN is specified with a CONFIRM value of Y (Yes), the job

appears in the Active Environment screen with a WAIT CONFIRMATION (WITH
RESTART) status and is not restarted unless confirmed. Specify option C
(Confirm) to open the Confirm window to restart the job.

§Restart§ For more information about job restart, see “Active Environment Screen”
on page 173.

§Restart§ When a job is submitted for restart, if $FIRST is specified in the FROM
subparameter, a $FIRST step specification is passed “as is” to the CONTROLR step. If
$ABEND or $EXERR is specified, the specified $ABEND or $EXERR value is first
resolved to the appropriate step by the Control-M monitor and then passed to the
CONTROLR step. If $FIRST.$ABEND is specified, the Control-M monitor determines
which procedure abended and then passes the $FIRST step specification for that
procedure to the CONTROLR step. For information regarding the CONTROLR step,
refer to the Control-M/Restart User Guide.

§Restart§ The Control-M parameter MAXRERUN determines the maximum number

of times the restart or rerun can be performed. For more information, see
“MAXRERUN: Post–Processing Parameter” on page 525.

456 Control-M for z/OS User Guide

 §Restart§DO IFRERUN: Post–Processing Parameter

§Restart§ Example
§Restart§ If the job abends on any step, restart (and automatically rerun) the job from
the first abended step.

Figure 190 §Restart§ DO IFRERUN Parameter Example

JOB: PRDKL02 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
TIME: FROM UNTIL PRIORITY DUE OUT SAC CONFIRM
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST UPDA CODES S**** U**** C2000 A/O
DO IFRERUN FROM $ABEND TO CONFIRM N
DO RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.26.42

Chapter 3 Job Production Parameters 457

DO MAIL: Post–Processing Parameter

DO MAIL: Post–Processing Parameter

Send an e-mail message to the specified recipients.

Figure 191 DO MAIL Parameter Format

Optional. Type MAIL in the DO field and press Enter. The DO MAIL subparameters
are described in Table 181.

Table 181 DO MAIL Subparameter Formats (part 1 of 2)

Subparameters Description
TO Destination of the message. Mandatory. Valid values are:

■ the full e-mail address

■ a recipient name

If you use a recipient name, the full e-mail address is supplied by

the MAIL section of the IOAPARM member in the IOA PARM
library. The IOAPARM member also includes the value of the
DFLTSFFX field, which specifies the e-mail address suffix (such
as MAIL.DOMAIN.COM), the SMTP STC name, and the HOST
name.
Note: The @ character is taken from the ATSIGN parameter in
the IOAPARM member.

■ the nick name or group name defined in MAILDEST member.

For more information regarding MAILDEST member, see the
INCONTROL for z/OS Administrator Guide.

You can use AutoEdit variables in this field, in any combination of

text and valid AutoEdit variables.

458 Control-M for z/OS User Guide

 DO MAIL: Post–Processing Parameter

Table 181 DO MAIL Subparameter Formats (part 2 of 2)

Subparameters Description
CC Destination to which a copy of the message is to be sent. Optional.

Valid values are:

■ the full e-mail address

■ a recipient name

If you use a recipient name, the full e-mail address is supplied by

the MAIL section of the IOAPARM member in the IOA PARM
library. The IOAPARM member also includes the value of the
DFLTSFFX field, which specifies the e-mail address suffix (such
as MAIL.DOMAIN.COM), the SMTP STC name, and the HOST
name.
Note: The @ character is taken from the ATSIGN parameter in
the IOAPARM member.

■ the nick name or group name defined in MAILDEST member.

For more information regarding MAILDEST member, see the
INCONTROL for z/OS Administrator Guide.

You can use AutoEdit variables in this field, in any combination of

text and valid AutoEdit variables.
SUBJ Message subject of up to 70 characters. Optional.
TEXT Message text of up to 255 text lines, each with a maximum of 70
characters. Optional.
ATTACH SYSOUT If the value is:

■ Y - Control-M attaches the SYSOUT to the email

■ N - Control-M does not attach the SYSOUT to the email

■ D - Control-M uses the default specified by the ATTSYSOT

system parameter

General Information
The specified e-mail is sent to the specified destinations when the accompanying ON
statement criteria are satisfied. Although an e-mail can be sent using a DO SHOUT
statement, the DO MAIL statement provides the following advantages:

■ Using DO MAIL, you can specify any number of TO and CC recipients. With DO
SHOUT, you must specify the mail destination prefix, and you must define the
address in the MAILDEST table.

Chapter 3 Job Production Parameters 459

DO MAIL: Post–Processing Parameter

■ Using DO MAIL, the e-mail text can exceed 70 characters. System variables and
user-defined AutoEdit variables (Global IOA variables and variables defined in the
SET VAR job scheduling definition parameter only) are supported in the subject
line and message text. These variables are resolved when the DO MAIL statement
is processed.

NOTE
The resolved value of an AutoEdit variable is truncated after 70 characters.

For information on the use of AutoEdit variables, see Chapter 5, “JCL and AutoEdit Facility.”

If installation parameter ATTSYSOT=Y, the job's SYSOUT will be attached to the

email message. Setting ATTSYSOT=Y ensures that the SYSOUT is attached to any job
where DO Mail is specified.

However, if you only need to attach SYSOUTs to specific jobs, then set
ATTSYSOT=N, and set the ATTACH SYSOUT subparameter to Y only for those
specific jobs.

The SYSOUT attached to the email message is the first three SYSOUT datasets of the
job. The attachment file name has the following format:

<jobname>-D<ldate>-O<orderid>-R<run-number>.txt

The file attachment size limit, if any, is determined by the Control-M ATTSOTSZ
customization parameter. See the INCONTROL for z/OS Installation Guide for details.

Subparameters TO and CC

Each of these parameters can contain more than one mail name address. When a
value is specified in the TO or CC field, a new empty line is displayed so that an
additional value can be specified (up to a maximum of 255 lines).

Multiple addresses, separated by a semicolon (;), can be specified on a line.

If an address exceeds the length of a full line, it can be continued on the following
line.

Example
If the job is not run due to a JCL error, send an e-mail to the relevant users:

Figure 192 DO MAIL Parameter Example

JOB: SACALC01 LIB CTM.PROD.SCHEDULE TABLE: SALES
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
===========================================================================

460 Control-M for z/OS User Guide

 DO MAIL: Post–Processing Parameter

OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES JNRUN A/O
DO MAIL
TO MAIL_ADDRESS_#1
TO MAIL_ADDRESS_#2
CC MAIL_ADDRESS_#3;MAIL_ADDRESS_#4
SUBJ WARNING MESSAGE
TEXT JCL ERROR IN SALES JOB! PLEASE CORRECT ERRORS AND RERUN THE JOB
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 461

DO NOTOK: Post–Processing Parameter

DO NOTOK: Post–Processing Parameter

Set the status of the job step to NOTOK if the accompanying ON step and code
criteria are satisfied. If specified in a SMART Table Entity, the termination status of
the SMART Table is set to NOTOK.

Figure 193 DO NOTOK Parameter Format

Optional. Type NOTOK in the DO field and press Enter. DO NOTOK has no
subparameters.

General Information
A DO NOTOK statement can change the status of a job step from OK to NOTOK. This
results in the job having a final termination status of ENDED NOTOK.

When specified in a SMART Table Entity, a DO NOTOK statement changes the

termination status of the SMART Table (not the status of jobs or job steps).

The following paragraphs describe the relationship of job step status and the final
termination status of the job.

■ Control-M determines the status of each individual step in a job before

determining the final status of the job.

■ After examining the results of a job step, Control-M automatically assigns a status
of OK or NOTOK to the step:

— By default, any job step ending with a condition code of C0000 through C0004 is
assigned a status of OK, but the INCONTROL administrator can change this.

— If any other condition code, system or user abend code, or user event is
generated, the step is automatically assigned a status of NOTOK.

462 Control-M for z/OS User Guide

 DO NOTOK: Post–Processing Parameter

■ In general, if any of the steps in a job ends with a status of NOTOK, the job is
assigned a final status of ENDED NOTOK. For a job to be assigned a final status of
ENDED OK, each step in the job must be assigned a status of OK.

This logic suits most situations. Do not change it. However, there may be a situation
in which Control-M assigned a step a status of OK, but the status ought to be changed
to NOTOK. Such a situation is described in the following example. The job ended
with a condition code of C0004, but in this particular situation, it is better that the step
have a status of NOTOK and the entire job be assigned a status of ENDED NOTOK.

DO NOTOK cannot be specified for the same ON step and code event as DO OK.

When a DO NOTOK statement is performed for a step, the final status of the job is
ENDED NOTOK, even if was previously set to ENDED OK.

NOTE
A DO NOTOK statement is ignored if it is specified in an ON PGMST +EVERY statement.

Example
When PROCST UPDA in PGMST STEP06 finishes executing with a condition code of
C0004, it is considered NOTOK.

Figure 194 DO NOTOK Parameter Example

JOB: PRDKPL02 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST STEP06 PROCST UPDA CODES C0004 A/O
DO NOTOK
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.16.03

Chapter 3 Job Production Parameters 463

DO OK: Post–Processing Parameter

DO OK: Post–Processing Parameter

Set the status of the job step to OK if the accompanying ON step and code criteria are
satisfied. If specified in a SMART Table Entity, the termination status of the SMART
Table is set to OK.

Figure 195 DO OK Parameter Format

Optional. Type OK in the DO field and press Enter. DO OK has no subparameters.

General Information
A DO OK statement can change the status of a job step from NOTOK to OK. If all
steps of a job have a status of OK the job is assigned a final termination status of
ENDED OK.

When specified in a SMART Table Entity, a DO OK statement changes the

termination status of the SMART Table (not the status of jobs or job steps).

The relationship between job step status and the final termination status of the job is
as follows:

Control-M determines the status of each individual step in a job before determining
the final status of the job.

After examining the results of a job step, Control-M automatically assigns a status of
OK or NOTOK to the step:

■ By default, any job step ending with a condition code of C0000 through C0004 is
assigned a status of OK, but the INCONTROL administrator can change this.

■ If any other condition code, system or user abend code, or user event is generated,
the step is automatically assigned a status of NOTOK.

464 Control-M for z/OS User Guide

 DO OK: Post–Processing Parameter

In general, if any of the steps in a job ends with a status of NOTOK, the job is assigned
a final status of ENDED NOTOK. For a job to be assigned a final status of ENDED
OK, each step in the job must be assigned a status of OK.

This logic suits most situations. Do not change it. However, there may be a situation
in which Control-M assigned a step a status of NOTOK, but the status ought to be
changed to OK. Several such exceptional situations are described below:

■ The NOTOK status is inappropriate for the job step. For example, a condition code
greater than C0004 was returned for a step that had an acceptable result.

■ The NOTOK status is appropriate for the job step, but the job step is not critical,
and ought not to affect the final job status.

■ User events created using Exit CTMX003 always result in a NOTOK status unless
DO OK is specified.

DO OK cannot be specified for the same ON step and code event as DO NOTOK and
DO RERUN.

A DO OK statement specified in the job scheduling definitions is ignored if one of the

following occurs:

■ any of the following status codes apply to any step:

— EXERR
— JNSUB
— *REC0
— *UKNW

■ it was specified as part of an ON PGMSTEP ANYSTEP ..... CODE NOTOK

condition, because if that condition is satisfied, the status of the job has already
been set to NOTOK

■ it is specified in an ON PGMST +EVERY statement

For more information, see “Valid CODES Values” on page 560.

Chapter 3 Job Production Parameters 465

DO OK: Post–Processing Parameter

Example
When PROCST UPDA in PGMST STEP08 finishes executing with a condition code
less than C0008, it is considered OK.

Figure 196 DO OK Parameter Example

JOB: PRDKPL02 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST STEP08 PROCST UPDA CODES <C0008 A/O
DO OK
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.16.03

466 Control-M for z/OS User Guide

 DO REMEDY: Post–Processing Parameter

DO REMEDY: Post–Processing Parameter

Open a problem ticket within the Remedy Helpdesk System, for example, when a
specific job fails.

Figure 197 DO REMEDY Parameter Format

Optional. Type REMEDY in the DO field and press Enter. The DO REMEDY
subparameters are described in Table 182.

Table 182 DO REMEDY Subparameter Formats

Subparameters Description
URGENCY Urgency of the message. Mandatory. Valid values are:

■ ' ' (blank) – This is equivalent to L–Low. Default.

■ L–Low
■ M–Medium
■ H–High
■ U–Urgent
SUMM Text, summarizing the description of the reason for opening a
Remedy Helpdesk ticket, of up to 2 text lines, with a maximum
122 characters. Mandatory.

You can use any combination of text and valid AutoEdit variables.
DESC Text, describing the reason for opening a Remedy Helpdesk ticket, of
up to 15 text lines, with a maximum of 1018 characters. Mandatory.

You can use any combination of text and valid AutoEdit variables.

Chapter 3 Job Production Parameters 467

DO REMEDY: Post–Processing Parameter

General Information
An e-mail message is sent to the Remedy Helpdesk when the accompanying ON
statement criteria are satisfied. To close the ticket, you must access the Remedy online
service. You can use AutoEdit variables in the SUMM and DESC fields, in any
combination of text and valid AutoEdit variables.

NOTE
The resolved value of an AutoEdit variable is truncated after 70 characters.
For information on the use of AutoEdit variables, see Chapter 5, “JCL and AutoEdit Facility.”

Example
A job did not run due to a JCL error. This causes a Remedy Helpdesk ticket to be
opened.

Figure 198 DO REMEDY Example

JOB: SACALC01 LIB CTMP.V700.SCHEDULE TABLE: SALES
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
| =========================================================================== |
| OUT |
| AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS |
| RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP |
| SYSOUT OP (C,D,F,N,R) FROM |
| MAXRERUN RERUNMEM INTERVAL FROM |
| STEP RANGE FR (PGM.PROC) . TO . |
| ON PGMST ANYSTEP PROCST CODES JNRUN A/O |
| DO REMEDY URGENCY U |
| SUMM JCL ERROR IN SALES JOB |
| |
| DESC A JCL ERROR OCCURED IN THE SALES JOB. PLEASE CORRECT AND RERUN THE |
| JOB. |
| |
| DO |
| ON PGMST PROCST CODES A/O |
| DO |
| ON SYSOUT FROM 001 TO 132 A/O |
| DO |
| SHOUT WHEN TIME + DAYS TO URGN |
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 17.44.21

468 Control-M for z/OS User Guide

 DO RERUN: Post–Processing Parameter

DO RERUN: Post–Processing Parameter

Reschedules the job (for rerun) if the accompanying ON step and code criteria are
satisfied.

Figure 199 DO RERUN Parameter Format

Optional. Type RERUN in the DO field and press Enter. DO RERUN has no
subparameters.

General Information
The RERUN statement is intended for situations in which a job must be rescheduled
following an unsuccessful job run.

Rerun jobs remain in the Active Jobs file with a status of WAIT SCHEDULE, where
they wait to be submitted like any other job. However, other parameters, such as
CONFIRM and DO IFRERUN, can affect the status of the rerun job order and the
submission and processing of the job:

■ A Y value specified in the CONFIRM parameter indicates that manual

confirmation is required before submitting the rerun job order. In this case, the
rerun job order is placed in the Active Jobs file with a status of WAIT
CONFIRMATION (FOR SCHEDULE). The job can be confirmed by option C
(Confirm) in the Active Environment screen.

■ A DO IFRERUN statement before the DO RERUN statement indicates that a restart

is desired instead of a full rerun. The job order is placed in the Active Jobs file with
a status of WAIT SCHEDULE – WITH RESTART, where the job waits to be
submitted from the indicated restart step. Confirmation can also be required for
restart jobs. This, too, is performed from the Active Environment screen. For more
information, see “§Restart§DO IFRERUN: Post–Processing Parameter” on
page 453.

Chapter 3 Job Production Parameters 469

DO RERUN: Post–Processing Parameter

For information about confirmation, see “Confirm Rerun Window” on page 229 and
“§Restart§Rerun and/or Restart Window (Under Control-M/Restart)” on page 231.

Job rerun is also affected by the MAXRERUN, RERUNMEM and INTERVAL

parameters.

■ MAXRERUN specifies the maximum number of times the job must be scheduled
for rerun.

■ RERUNMEM specifies the JCL member to be used for the rerun (if different from
the normal JCL member of the job).

■ INTERVAL specifies the number of minutes to wait between reruns.

These parameters are described in this chapter.

DO RERUN cannot be specified for a cyclic job or a cyclic started task.

DO RERUN cannot be specified for the same ON step and code event as DO OK.

Do not specify DO RERUN for steps that have a specified ON statement code value of
OK.

Do not specify DO RERUN for steps that have a specified ON statement code value of
NOTOK because many of the causes of a NOTOK status, such as JCL not found,
preclude the possibility of a successful job rerun. Instead, specify an ON statement
code value of EXERR to accompany the DO RERUN statement.

When a DO RERUN statement is performed for a job (that is, the accompanying ON
step and code criteria are satisfied), the previously run job is automatically assigned a
final status of ENDED NOTOK, even if the job would have otherwise had a status of
ENDED OK.

470 Control-M for z/OS User Guide

 DO RERUN: Post–Processing Parameter

Example
If job EF145TS abends during step name COLLECT, try to run another job from
member EF145TSR that continues from the same place.

Figure 200 DO RERUN Parameter Example

JOB: EF145TS LIB CTM.PROD.SCHEDULE TABLE: EFPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
============================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST COLLECT PROCST CODES S*** U**** A/O
DO RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 471

DO SET: Post–Processing Parameter

DO SET: Post–Processing Parameter

Assigns a value to an AutoEdit variable that can be used to set up the JCL of the next
submission of a cyclic or rerun or restarted job, or to define a Global variable in the
IOA Global Variable Database.

NOTE
DO SET and SET VAR statements are similar, but not identical. The differences are outlined in
“Differences between DO SET and SET VAR” on page 474.

Figure 201 DO SET Parameter Format

Optional. Type SET in the DO field and press Enter. The DO SET subparameter is
described in Table 183.

Table 183 DO SET Subparameter

Subparameter Description
VAR User-defined variable and the value to be assigned. Mandatory.

Replace the %%?=? prompt with the desired parameter, in the

format:

%%variable=expression

For more information, see “SET VAR: General Job Parameter” on

page 630.

472 Control-M for z/OS User Guide

 DO SET: Post–Processing Parameter

General Information
A major advantage of using AutoEdit variables is that the JCL can be submitted with
different values for different executions without actually changing the JCL.

There are two types of AutoEdit variables:

■ System variables, which are assigned values by the system

■ User-defined variables, for which the user must supply values; these variables can
be either local or global

One method of supplying a value for a user-defined variable is by defining the

variable and its value in a DO SET statement.

During job processing, the value is assigned at time of job submission. However, DO
SET is a post-processing statement, which means that before it can be applied, its
accompanying ON criteria must be satisfied in a job run.

Therefore, the DO SET statement is generally useful for supplying local user-defined
variables for cyclic, rerun, or restarted jobs.

When the ON criteria of a DO SET statement that defines a local variable are satisfied
during a job run, Control-M creates a SET VAR statement equivalent to the DO SET
statement (that is, containing the same variable and value) in the subsequent job run.

At time of job submission, AutoEdit variables in the JCL are resolved in the order in
which they appear in the JCL. By default, if an AutoEdit variable cannot be resolved,
the job is not submitted. This default can be changed using an appropriate
%%RESOLVE AutoEdit control statement.

NOTE
If the JCL contains an AutoEdit variable that is resolved in a subsequent run by a DO SET
statement, the variable must be resolved by some other method, such as a SET VAR statement,
in the original run, or the job is not submitted.

DO SET statements can also be used to define and update Global Variables in the IOA
Global Variable database. The database is updated as part of job post-processing,
when the DO SET statement is processed. For more information on Global Variables,
including Global Variable syntax, see Chapter 5, “JCL and AutoEdit Facility.”

An unlimited number of DO SET statements can be specified.

JCL Setup and the AutoEdit facility are described in depth in Chapter 5, “JCL and
AutoEdit Facility.”

Chapter 3 Job Production Parameters 473

DO SET: Post–Processing Parameter

Differences between DO SET and SET VAR

DO SET and SET VAR statements are similar but have the following differences:

■ Local variables in SET VAR statements are always applied before the job is
submitted. DO SET is a post-processing statement that can only be applied after its
accompanying ON step and code criteria are satisfied. This means that a local
value specified in the DO SET statement can only be applied in the next
submission of the job (specifically, for cyclic and rerun or restarted jobs).

■ Global variables specified in a SET VAR statement are defined or updated in the
IOA Global Variable database before job submission. Global variables specified in
a DO SET statement are defined or updated in the IOA Global Variable database as
part of job post-processing

■ The SET VAR statement appears in each job scheduling definition. The DO SET
statement does not appear unless specified. To specify a DO SET statement, type
SET in an empty DO field and press Enter.

■ In the SET VAR statement, the parameter value is specified after the keyword
VAR. In the DO SET statement, the parameter value is specified after the keyword
VAR=.

474 Control-M for z/OS User Guide

 DO SET: Post–Processing Parameter

Example
If the job execution fails on any step due to a system or user abend, resolve the
%%PARM parameter in the JCL to RESTART, restart from the first abended step, and
automatically rerun.

Figure 202 DO SET Parameter Example

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
===========================================================================
OUT PRDKPL01-ENDED-OK ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 A/O
DO IFRERUN FROM $ABEND . TO . CONFIRM N
DO RERUN
DO SET VAR= %%PARM=RESTART
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 475

DO SHOUT: Post–Processing Parameter

DO SHOUT: Post–Processing Parameter

Specifies a message to be sent (“shouted”) to a specific destination when a specific
situation occurs.

NOTE
DO SHOUT and SHOUT statements are similar, but not identical. The differences are outlined
in “Differences between SHOUT and DO SHOUT” on page 480.

Figure 203 DO SHOUT Parameter Format

Optional. Type SHOUT in the DO field and press Enter. The DO SHOUT
subparameters are described in Table 184.

476 Control-M for z/OS User Guide

 DO SHOUT: Post–Processing Parameter

Table 184 DO SHOUT Subparameters (part 1 of 2)

Subparameter Description
TO Destination of the message (1 through 16 characters). Mandatory.
Valid values are:

■ U-userid or USERID-userid – Writes the message to the IOA Log

file under the specified user ID. userid must be 1 through 8
characters.

■ OPER[–n] – Sends a rollable message to the operator console. n is

an optional 2-digit route code. If a route code is not specified, the
default routes are Master Console and Programmer Information (1
and 11), and optionally, Control-M/Enterprise Manager. For more
detailed information regarding route codes, refer to the IBM
publication Routing and Descriptor Codes, GC38-1102.

■ OPER2[–n] – Sends an unrollable, highlighted message to the

operator console. n is an optional 2-digit route code. If a route
code is not specified, the default routes are Master Console and
Programmer Information (1 and 11), and optionally,
Control-M/Enterprise Manager. For more detailed information
regarding route codes, refer to the IBM publication Routing and
Descriptor Codes, GC38-1102.

■ [TSO - loginid | T - loginid] [;Nn | ;Mm | ;NnMm | ;Lname] – Sends

the message to the specified ID (groupid or logonid). ID is
mandatory.
If a groupid is specified, it must be a valid ID found within the IOA
Dynamic Destination Table.
If a logonid is specified, it must be 1 through 7 characters.
An optional second value, indicating the computer and/or node
(such as Mm) of the TSO logonid, can be specified, as follows:
Under JES2:
Valid values are: Nn, Mm or NnMm, where:
– m is the machine ID (the computer in JES2, not the
4-character SMF system ID). For more information, see
the discussion on specifying IOA CPUs in the description
of the customization process in the INCONTROL for
z/OS Installation Guide.
– n is the 1 to 2 character JES/NJE node ID.
Under JES3:
The only valid value is Lname, where Lname is the logical JES name
of the machine (that is, the name as used in JES3 command *T, not
the SMF system ID).
For more information, see the discussion on specifying IOA CPUs
in the description of the customization process in the
INCONTROL for z/OS Installation Guide.
Note: A shout to a TSO user performs a TSO SEND command, which
may require authorization at the receiving node.

Chapter 3 Job Production Parameters 477

DO SHOUT: Post–Processing Parameter

Table 184 DO SHOUT Subparameters (part 2 of 2)

Subparameter Description
■ U-M:mail-name-prefix – Sends a message by mail to the recipient
identified by mail-name-prefix (1 through 12 characters).

■ U-S:snmp_dest – Sends an SNMP trap (message) to the recipient

identified by snmp_dest.
snmp_dest consists of from 1 through 12 characters, and can be
any of the following:
— a host name
— an IP address
— a nickname defined in the SNMPDEST destination table
— a group name defined in the SNMPDEST destination table

■ U-ECS – Sends messages to the Control-M/Enterprise Manager

user. For more information on this feature, see “Shouting to
Control-M/Enterprise Manager” on page 479.
URGENCY Determines the priority level of the message. Valid values are:

■ R – Regular. Default.
■ U – Urgent
■ V – Very urgent
= Message text
Maximum length: 70 characters
AutoEdit variables (both system and user-defined) are supported and
automatically resolved (replaced) at the time the SHOUT message is
issued. For AutoEdit usage information, see Chapter 5, “JCL and
AutoEdit Facility.”

General Information
The message is sent to the required destination when the accompanying ON
statement criteria are satisfied.

DO SHOUT statements can also be defined in SMART Table Entities, where they are
used in a manner similar to jobs.

The TO Subparameter

Specify TO=USERID-userid to write the message to the IOA Log file under the user
ID specified in the parameter.

Specify TO=OPER[–n] to send the message to the operator console (route code n). If
the n value is omitted, the message is sent to all consoles to which route codes 1 or 11
are assigned. For more detailed information regarding route codes, refer to the IBM
publication Routing and Descriptor Codes, GC38-1102. Optionally, the message can
also be sent to the Control-M/Enterprise Manager user, as described in “Shouting to
Control-M/Enterprise Manager” on page 479.

478 Control-M for z/OS User Guide

 DO SHOUT: Post–Processing Parameter

Specify TO=OPER2[–n] to send a highlighted, unrollable message to the operator

console (route code n). If the n value is omitted, the message is sent to all consoles to
which route codes 1 or 11 are assigned. For more detailed information regarding
route codes, refer to the IBM publication Routing and Descriptor Codes, GC38-1102.
Optionally, the message can also be sent to the Control-M/Enterprise Manager user,
as described in “Shouting to Control-M/Enterprise Manager” on page 479.

Specify TO=TSO-id or T-id to send the message to a groupid or logonid. The Shout
facility first searches the IOA Dynamic Destination table for the specified ID. If the
table contains an entry (groupid) that matches the value, the content of the entry is
used as the target for the shouted message. The entire TO field is used. Therefore,
when directing the message to a remote user, do not append Nn or Mm. Instead, do
this in the IOA Dynamic Destination Table itself. For more information, see the
description of the Dynamic Destination Table in the INCONTROL for z/OS
Administrator Guide.

If no matching ID is found in the Dynamic Destination table, the Shout facility

assumes the specified ID is a logonid. It then creates a TSO message that it hands over
to MVS. MVS then sends the message to that logonid. (If the logonid does not exist,
MVS cannot send the message, but no error message is generated.) When a second
value is used, the message is sent to the TSO logonid in the specified computer or
node (machine ID). To determine the machine ID under JES2, specify JES command
$D MEMBER.

Specify TO=U-M: mail-name-prefix to send the message by e-mail to the recipient

identified by the prefix. The full mail name address is supplied by the MAILDEST
table in the IOA PARM library. For more information about mail destinations, see the
INCONTROL for z/OS Administrator Guide. The IOAPARM member includes
DFLTSFFX, the mail address suffix, such as MAIL.DOMAIN.COM, the SMTP STC
name, and the HOSTNAME. If installation parameter ATTSYSOT=Y, the job's
SYSOUT will be attached to the e-mail message.

Specify TO=U-S:snmp_dest to send the SNMP trap (message) to the recipient

identified by snmp_dest. This variable (snmp_dest) can be any of the following:

■ a host name
■ an IP address
■ a nickname defined in the SNMPDEST table
■ a group name defined in the SNMPDEST table

For more information about mail destinations, see the INCONTROL for z/OS
Administrator Guide.

Shouting to Control-M/Enterprise Manager

For Control-M to be able to shout to Control-M/Enterprise Manager, the following

conditions must be satisfied at the site:

Chapter 3 Job Production Parameters 479

DO SHOUT: Post–Processing Parameter

1. Control-M/Enterprise Manager must be installed and the ECS parameter must be

set to Y in member IOAPARM in the IOA PARM library.

2. File MG2 (the Control-M/Enterprise Manager Shout File) must be defined.

3. The following parameters in the IOAPARM member in the IOA PARM library
must be defined according to how messages are targeted to Control-M/Enterprise
Manager:

■ If TO=OPER and TO=OPER2 messages must be sent to Control-M/Enterprise

Manager, the OPER2ECS parameter must be set to Y (Yes). Otherwise, it must
be set to N (No).

When OPER2ECS is set to Y:

— If these messages must also be sent to the MVS operator console, the
OPER2CON parameter must also be set to Y (Yes).

— If these messages must not also be sent to the MVS operator console, the
OPER2CON parameter must also be set to N (No).

■ If TO=U-ECS messages must be sent to Control-M/Enterprise Manager, the

UECS2ECS parameter must be set to Y (Yes); otherwise, it must be set to N (No).
Regardless of the value of this parameter, these messages are also sent to
Control-M and the IOA Log.

Once the above conditions are satisfied, messages can be shouted to

Control-M/Enterprise Manager by specifying a destination of TO=OPER or
TO=OPER2 (without a route code qualifier), or TO=U-ECS.

Such messages are then placed by Control-M in the M2G file. Once the shouted
message is in the M2G file, the Control-M Application Server reads the file and sends
the message to the Control-M/Enterprise Manager user.

The URGENCY Subparameter

The URGENCY value indicates the urgency level of the message.

In addition, if the destination is USERID-userid (or U-userid), the user can control,
according to urgency, which messages are displayed when the IOA Log file is
accessed. Urgent and very urgent messages are highlighted on the screen. For more
details, see “IOA Log Facility” on page 303

Differences between SHOUT and DO SHOUT

SHOUT and DO SHOUT statements have the following differences:

480 Control-M for z/OS User Guide

 DO SHOUT: Post–Processing Parameter

■ A DO SHOUT statement is applied only if the accompanying ON criteria are

satisfied. Therefore a DO SHOUT statement does not contain subparameters for
specifying when to perform the shout.

By contrast, a SHOUT statement requires that a value be specified in subparameter

WHEN indicating when to shout the message. Messages can be shouted when the
job ends OK or NOTOK, when the job is late for submission or completion, or
when the job runs too long.

■ A SHOUT statement appears in each job scheduling definition. A DO SHOUT

statement does not appear unless specified. To specify a DO SHOUT statement,
type SHOUT in an empty DO field and press Enter.

■ The SHOUT URGN subparameter is equivalent to the DO SHOUT URGENCY

subparameter.

■ The SHOUT MS subparameter is equivalent to the DO SHOUT subparameter.

Example
If the job is not run because of a JCL error, notify the user who sent the job.

Figure 204 DO SHOUT Subparameter Example

JOB: SACALC01 LIB CTM.PROD.SCHEDULE TABLE: SALARY
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
============================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES JNRUN A/O
DO SHOUT TO TSO-U0014 URGENCY U
= *** JCL ERROR IN SALARY JOB ***
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

An urgent message is sent to the user ID that requested the job.

Chapter 3 Job Production Parameters 481

DO STOPCYCL: Post-Processing Parameter

DO STOPCYCL: Post-Processing Parameter

Stops recycling a cyclic task.

Figure 205 DO STOPCYCL Parameter Format

The DO STOPCYCL statement has no subparameters. Type the word STOPCYCL in

the DO field and press Enter.

General Information
DO STOPCYCL is intended for use with all cyclic tasks (cyclic job, cyclic STC,
emergency cyclic job and emergency cyclic STC). It interrupts a job cycle after the
current run, so that once the job completes its current run, it does not run again. This
parameter does not change the status (OK or NOTOK) assigned to job during the last
cycle.

After DO STOPCYCL has interrupted a job, commands RERUN or RESTART can be

used in the Active Environment screen to continue the job cycle from where it
stopped. Commands RERUN and RESTART resume the stopped cyclic tasks without
waiting for a cycling interval to occur. After the job restarts, it continues its normal
cyclic interval as before.

482 Control-M for z/OS User Guide

 DO STOPCYCL: Post-Processing Parameter

Example
If cyclic job SACALCO1 finishes with a status of NOTOK, the STOPCYCL parameter
interrupts the cycle.

Figure 206 DO STOPCYCL Parameter Example

JOB: SACALC01 LIB CTM.PROD.SCHEDULE TABLE: SALARY
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL 003 FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES NOTOK A/O
DO STOPCYCL
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 483

DO SYSOUT: Post-Processing Parameter

DO SYSOUT: Post-Processing Parameter

Controls handling of job output if the accompanying ON step and code criteria are
satisfied.

NOTE
DO SYSOUT and SYSOUT statements are similar, but not identical. The differences are
outlined below in “Differences between SYSOUT and DO SYSOUT” on page 490."

Figure 207 DO SYSOUT Parameter Format

Optional. Type the word SYSOUT in the DO field and press Enter. The DO SYSOUT
subparameters are described in Table 185.

Table 185 DO SYSOUT Subparameters

Subparameter Description
OPT SYSOUT option code. Mandatory. Valid values are:
■ F – Copy the job output to file.
■ C – Change the class of the job output.
■ N – Change the destination of the job output.
■ D – Delete (purge) the job output.
■ R – Release the job output.

PRM Relevant sysout data. Mandatory and valid only if the specified OPT
value is F, C or N. Valid values depend on the OPT value, as follows:
■ F – File name.
■ C – New class (1 character). An asterisk (*) indicates the original
MSGCLASS of the job.
■ N – New destination (1 through 8 characters).

FRM FROM class. Optional. Limits the sysout handling operation to only
sysouts from the specified class.
Note: If a FROM class is not specified, all sysout classes are treated as
a single, whole unit.

484 Control-M for z/OS User Guide

 DO SYSOUT: Post-Processing Parameter

General Information
The Control-M monitor, unless otherwise instructed, leaves the job SYSOUT in HELD
class in the output queue.

The DO SYSOUT parameter is used to request additional handling of these held

sysouts when the accompanying ON criteria are satisfied.

The Control-M monitor sends all SYSOUT handling requests to JES, which processes
the instructions. If, however, the copying of sysouts to a file is requested (option F),
Control-M requests the sysouts from JES and then Control-M directly writes the
sysouts to the file.

Since only one SYSOUT statement can be defined in a job scheduling definition, DO
SYSOUT statements can be used, as follows, to specify additional sysout handling
instructions when the job ends OK:

■ To define DO SYSOUT statements that operate like a SYSOUT statement (that is,
that operate only when the job ends OK), define their accompanying ON statement
with PGMST value ANYSTEP and code value OK.

■ The interrelationship between multiple SYSOUT operations (by SYSOUT and DO

SYSOUT statements) is described in “Multiple SYSOUT Operations” on page 487.

SYSOUT Handling Operations

The SYSOUTs that are affected by SYSOUT handling operations are determined by
whether the SYSOUTs are under JES2 or JES3, as described in Table 186.

Table 186 Varying Effect of SYSOUT Handling Operations

Operation Effect
Under JES2: Operations are performed on all of the held SYSOUTs, or held
portions of SYSOUTs, of the job, unless otherwise restricted to a
specific FROM class by the FRM subparameter.
Under JES3: Operations are performed only on the SYSOUTs of the job in the
Control-M held class, as specified in the Control-M installation
HLDCLAS parameter.

SYSOUT handling operations are listed below:

■ Copying SYSOUTs to a file (OPT=F)

The SYSOUTs of the job are copied (not moved) to the file specified in the data
subparameter.

Chapter 3 Job Production Parameters 485

DO SYSOUT: Post-Processing Parameter

The file name specified in the data subparameter can contain AutoEdit System
variables, and user-defined AutoEdit variables that are defined in the job
scheduling definition or the IOA Global Variable database, or are loaded into
AutoEdit cache. If the AutoEdit variables cannot be resolved, the sysout is not
copied.

Control-M allocates the file with DISP=(NEW,CATLG,DELETE) using the unit and
space attributes specified in the Control-M installation parameters. While the block
size (BLKSIZE) is automatically calculated by Control-M, the logical record length
(LRECL) is copied from the input SYSOUT file. The maximum LRECL allowed is
256 characters.

SYSOUTs can be archived by copying them. However, to reduce overhead, this

method is recommended only for small sysouts.

■ Deleting SYSOUTs (OPT=D)

The SYSOUTs of the job are deleted (purged) from the output queue.

NOTE
This operation works on all SYSOUTs under JES2 or JES3 (regardless of held status or class)
unless otherwise restricted by the FRM subparameter.

■ Releasing SYSOUTs (OPT=R)

The SYSOUTs of the job are released for printing.

■ Changing the class of SYSOUTs (OPT=C)

The SYSOUTs of the job are changed to the output class specified in the data
subparameter. Ensure that you specify a meaningful target output class.

Note the following points:

— Changing a SYSOUT class to a non-held class does not release the SYSOUT
because the SYSOUT attributes do not change (due to JES logic).

To ensure that the SYSOUT is released, use DO SYSOUT statements to release

the SYSOUT after changing its class. For example:

486 Control-M for z/OS User Guide

 DO SYSOUT: Post-Processing Parameter

DO SYSOUT OPT C PRM R FRM A

DO SYSOUT OPT R PRM FRM A

— Changing a SYSOUT class to a dummy class does not purge the SYSOUT
because the SYSOUT attributes do not change (due to JES logic).

— To save the original MSGCLASS of a job and to restore it at output processing

time, specify a data value of *. The SYSOUTs are changed to the original class of
the job.

■ Moving SYSOUTs to a new destination (OPT=N)

The SYSOUTs of the job are moved to the output destination specified in the data
subparameter. Ensure that you specify a meaningful target output destination.

Multiple SYSOUT Operations

If multiple DO SYSOUT (or SYSOUT/DO SYSOUT) operations are not specified for
the same FROM class, the order in which the operations are performed is not
significant.

However, if different DO SYSOUT (or SYSOUT/DO SYSOUT) operations affect the

same FROM class, or if multiple operations are specified without a FROM class, the
order and method of implementation is significant.

Control-M merges different operations for the same FROM class into a combined
instruction to JES. Likewise, Control-M merges different operations without a FROM
class into a combined instruction to JES.

Operations without a specified FROM class treat the entire held sysout as a whole
unit, and are therefore not merged with sysout handling requests for a specific FROM
class.

JES does not necessarily process multiple SYSOUT handling instructions in the order
they are issued by Control-M. Therefore, the processing results can vary if the
merged instructions to JES include both FRM equals a specified class and FRM equals
blank.

BMC Software therefore recommends that you do not include in a job scheduling
definition both “FROM class” and “no FROM class” sysout handling instructions that
become operational under the same situations.

When Control-M merges a set of operations into a combined instruction, some

operations override or cancel other operations, and some operations are performed
along with other operations. This is described below.

Chapter 3 Job Production Parameters 487

DO SYSOUT: Post-Processing Parameter

Operation Merging and Performance

Control-M performs all copy to file operations (option F) first.

After performing all copy to file operations, Control-M merges all operations
performed on a specific FROM class.

After merging operations on specific FROM classes, Control-M merges the operations
performed on the SYSOUT as a whole (where the FRM subparameter is set to blank).

Control-M then passes the merged sets of instructions to JES for processing.

The resulting combination of operations can vary depending on whether the

operation that was merged with a DO SYSOUT operation is a SYSOUT operation or
another DO SYSOUT operation.

Generally, DO SYSOUT operations override, or are performed along with, SYSOUT

statements.

The following chart and the accompanying numbered explanations indicate the result
of merging multiple DO SYSOUT statements. Note the following points about the
chart:

■ Operations are indicated by their symbols (F,D,R,C,N), at the top and side of the
chart. The operations at the top of the chart represent DO SYSOUT operations. The
operations at the side of the chart represent SYSOUT or DO SYSOUT operations.

■ Merging and processing operations are grouped, and explained, based on

operation type. Groups are delimited by lines, and are numbered (from 1 through
4). Within each group, operations are delimited by periods. Explanations of each
group are provided, by number, following the chart.

■ The handling of the combination of operations is generally reflected in the chart by

a single operation code (such as D) or pair of operation codes, such as FR. In some
cases, the operations are merged. This is indicated by the word “merged.” In some
cases, handling depends on whether the combination consists of both a SYSOUT
and a DO SYSOUT statement, or multiple DO SYSOUT statements (that is, without
a SYSOUT statement). This is indicated by an asterisk (*). These are all explained in
the numbered explanations that follow the chart.

NOTE
For information about merging a SYSOUT and a DO SYSOUT statement, see “Operation
Merging and Performance” on page 488.

488 Control-M for z/OS User Guide

 DO SYSOUT: Post-Processing Parameter

Figure 208 Effect of Merging Multiple SYSOUT Statements.

The order of precedence in which Control-M processes and merges operations is as

follows:

1. DO SYSOUT=F

Copy to file operations are performed first (directly by Control-M) for DO SYSOUT
statements, regardless of whether FROM class is specified. Other operations are
then performed.

2. DO SYSOUT=D (Delete)

This operation supersedes all other DO SYSOUT operations (except copy to file
operations described above). Superseded operations are ignored, that is, they are
not performed.

3. DO SYSOUT combinations of R, C and N

In general, combinations of R, C, and N requests are merged, that is, they are all
performed. The exceptional cases indicated in the chart are described below:

— If multiple C requests come from DO SYSOUT statements, perform only one of

the requests. Normally, do not specify this combination.

— If multiple N requests come from DO SYSOUT statements, perform the request

that occurs first.

Chapter 3 Job Production Parameters 489

DO SYSOUT: Post-Processing Parameter

Differences between SYSOUT and DO SYSOUT

SYSOUT and DO SYSOUT statements have the following differences:

■ The SYSOUT statement is applied only if the job ends OK. DO SYSOUT statements
are associated with accompanying ON statements and are applied only if the
accompanying ON step and code criteria are satisfied.

■ A SYSOUT statement appears in each job scheduling definition. A DO SYSOUT

statement is not displayed unless requested. To request a DO SYSOUT statement,
type SYSOUT in an empty DO field and press Enter.

■ Only one SYSOUT statement can be defined in the job scheduling definition. An
unlimited number of DO SYSOUT statements can be requested.

■ The SYSOUT OP subparameter is equivalent to the DO SYSOUT OPT

subparameter.

■ The SYSOUT data subparameter is equivalent to the DO SYSOUT PRM

subparameter.

■ The SYSOUT FROM subparameter is equivalent to the DO SYSOUT FRM

subparameter.

Examples

Example 1

If a job finishes executing OK, delete (purge) the sysout (DO SYSOUT OP D). If the
job finishes executing with condition code 0050-0059 in step STEP02, set the end
status of the job to OK and release the sysout for printing. If the job abends, move the
sysout to class D.

490 Control-M for z/OS User Guide

 DO SYSOUT: Post-Processing Parameter

Figure 209 DO SYSOUT Parameter – Example 1

JOB: SACALC01 LIB CTM.PROD.SCHEDULE TABLE: SALARY
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES OK A/O
DO SYSOUT OPT D PRM FRM
ON PGMST STEP02 PROCST CODES C005* A/O
DO OK
DO SYSOUT OPT R PRM FRM
DO
ON PGMST ANYSTEP PROCST CODES U**** S**** A/O
DO SYSOUT OPT C PRM D FRM
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Example 2 – Use of the Sysout Archiving Facility

The MSGCLASS of the job is X (a held class). Reports are produced in class D. The
desired actions are:

■ Archive the JCL messages and all the held output in class X, that is, the SYSPRINT
data sets, job log, and so on.

■ If the job finishes executing OK, release the reports for print and delete the
MSGCLASS sysouts.

■ If the job finishes executing NOTOK, delete the reports and keep the MSGCLASS
(JCL, job log, and so on) output in hold status.

Chapter 3 Job Production Parameters 491

DO SYSOUT: Post-Processing Parameter

Figure 210 DO SYSOUT Parameter – Example 2

JOB: GPLUPDT1 LIB CTM.PROD.SCHEDULE TABLE: PRODGPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
===========================================================================
OUT
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES ***** A/O
DO SYSOUT OPT F PRM GPL.%%JOBNAME.D%%ODATE.N%%JOBID.T%%TIME FRM X
DO
ON PGMST ANYSTEP PROCST CODES OK A/O
DO SYSOUT OPT D PRM FRM X
DO SYSOUT OPT R PRM FRM D
DO
ON PGMST ANYSTEP PROCST CODES NOTOK A/O
DO SYSOUT OPT D PRM FRM D
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Notice the use of the AutoEdit symbols in the name of the file to be archived. The
symbol %%JOBNAME, or %%$MEMNAME if the job name is not known, is replaced
with the job name, %%ODATE by the original scheduling date, and so on, producing
a file name such as “PRD.PADD0040.D010306.N01342.T170843.”

The file can be viewed by using ISPF Browse. A list of the outputs of the job can be
produced using ISPF option 3.4. For example, retrieval by the prefix
“PRD.PAPD0040.D0103” lists all the names of the sysouts of the job in the month of
March 2001. It is possible to browse, edit, and print the desired sysout.

NOTE
The File operation (SYSOUT archival) is intended for small sysouts (such as JCL, sort
messages) and not for large volume reports. When the Control-M monitor is performing file
operations, it does not analyze the results of other jobs. Therefore, if large files are archived,
production throughput may suffer.

492 Control-M for z/OS User Guide

 DOC: General Job Parameter

DOC: General Job Parameter

Detailed job documentation. This field can be displayed or hidden by request.

Figure 211 DOC Parameter Format

Optional. Upon filling in a DOC line with text and pressing Enter, a new DOC line is
opened for specifying additional documentation text.

General Information
DOC lines are used for specifying job documentation.

Upon entry to the job scheduling definition, DOC lines are displayed only if the value
Y was specified in field SHOW JOB DOCUMENTATION in the Scheduling
Definition Facility entry panel.

Command DOC can be used in the job scheduling definition to toggle between the
display and non display of job documentation.

The information specified in the DOC lines is saved in the member and library
specified in the DOCMEM and DOCLIB parameters. This member can also be edited
directly by ISPF edit.

When modifying DOC lines in the job scheduling definition, text must be left in at
least one DOC line in order to save the modifications. Changes resulting in an empty
DOCMEM member are not saved when exiting the job scheduling definition.

For more information regarding job documentation, including the saving of job
documentation changes, see “Job Documentation” on page 149.

Chapter 3 Job Production Parameters 493

DOC: General Job Parameter

Example
The steps performed by the L-file backup job are documented in the DOC lines.

Figure 212 DOC Parameter Example

JOB: BACKPL02 LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME BACKPL02 MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL APPL-L GROUP BKP-PROD-L
DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
OVERLIB CTM.OVER.JOBLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM BACKPL02 DOCLIB CTM.PROD.DOC
===========================================================================
DOC THIS JOB BACKS UP "L" FILES. IT PERFORMS THE FOLLOWING STEPS:
DOC 1: VERIFY SPACE REQUIREMENTS
DOC 2-5: BACKUP THE FILES
DOC 6: RECATALOG THE NEW FILES
DOC 7: PRINT THE SHORT-VERSION LISTING REPORT
DOC
====================================================================
DAYS ALL DCAL
AND/OR
WDAYS WCAL
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

494 Control-M for z/OS User Guide

 DOCLIB: General Job Parameter

DOCLIB: General Job Parameter

Name of the library in which the member specified in DOCMEM resides.

Figure 213 DOCLIB Parameter Format

Optional. The DOCLIB parameter identifies a valid data set name of 1 through 44
characters. The default is either defined at time of installation or is blank.

General Information
The library can be any standard partitioned data set. The record length must be 80.

Any number of documentation libraries can be used at a site. However, only one
documentation library can be specified in each job scheduling definition.

NOTE
Users with DOCU/TEXT installed at their sites can specify a DOCU/TEXT library and
member with up to 132 characters per line. However, if more than the first 71 characters in a
line are used, the line is truncated and Browse mode is forced. Browse mode is also forced if a
line contains an unprintable character. Changes to the documentation are not permitted in
Browse mode.

Chapter 3 Job Production Parameters 495

DOCLIB: General Job Parameter

Example
Job documentation is written to the PRDKPL01 member in the CTM.PROD.DOC
library.

Figure 214 DOCLIB Parameter Example

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL KPL GROUP PROD-KPL
DESC DAILY PRODUCTION - START OF APPL-PROD-KPL
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN START-DAILY-PROD-KPL ODAT
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

496 Control-M for z/OS User Guide

 DOCMEM: General Job Parameter

DOCMEM: General Job Parameter

Name of the member that contains job documentation.

Figure 215 DOCMEM Parameter Format

Optional. DOCMEM identifies a valid member name of 1 through 8 characters. The

default is either defined during installation or is blank.

General Information
DOCMEM identifies a member that is in the library identified by the DOCLIB
parameter. This member is used to save detailed documentation written in the DOC
lines of the Job Scheduling Definition screen (or Zoom screen).

When you enter the Job Scheduling Definition screen for the first time, DOCMEM
defaults to the value of MEMNAME. You can change this value, but it is
recommended that you not do so.

NOTE
Users with DOCU/TEXT installed at their sites can specify a DOCU/TEXT library and
member with up to 132 characters per line. However, if more than the first 71 characters in a
line are used, the line is truncated and Browse mode is forced. Browse mode is also forced if a
line contains an unprintable character. Changes to the documentation are not permitted in
Browse mode.

Chapter 3 Job Production Parameters 497

DOCMEM: General Job Parameter

Example
Job documentation is written to member PRDKPL01 in the library CTM.PROD.DOC.

Figure 216 DOCMEM Parameter Example

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL KPL GROUP PROD-KPL
DESC DAILY PRODUCTION - START OF APPL-PROD-KPL
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN START-DAILY-PROD-KPL ODAT
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

498 Control-M for z/OS User Guide

 DUE OUT: Runtime Scheduling Parameter

DUE OUT: Runtime Scheduling Parameter

Time and date by which a job must finish executing.

Figure 217 DUE OUT Parameter Format

Optional. The format for the DUE OUT TIME parameter is hhmm, where:

■ hh is the hour the job is due out (based on a 24-hour clock)

■ mm is the minute the job is due out

If the DUE OUT DAYS parameter is entered, the value must be a number between
zero and 120. This is the relative number of days by which the job must finish
execution. For example, assume that the ODATE is September 5, DUE OUT TIME is
17:00, and DUE OUT DAYS is 2. This means that the job must finish executing by
Control-M working date of September 7 at 17:00.

General Information
The DUE OUT parameters are used to specify the date and time by which the job
must finish executing.

When specified in a SMART Table Entity, the DUE OUT parameters are used to
specify the date and time by which all the jobs contained in the SMART Table must
finish executing.

When two jobs with the same priority are available for submission, Control-M
submits the job with the earlier DUE OUT date and time first.

When a DUE OUT date and time is specified, the Control-M monitor can calculate a
DUE IN date and time for the job.

The DUE IN date and time are the recommended date and time by which the job
must be submitted in order to finish executing by the DUE OUT date and time.

Chapter 3 Job Production Parameters 499

DUE OUT: Runtime Scheduling Parameter

If the DUEINCHK parameter in the CTMPARM member in the IOA PARM library
has been set to No, the job is always submitted, no matter what values are present in
the DUE IN date and time.

If the DUEINCHK parameter in the CTMPARM member in the IOA PARM library
has been set to Yes, job submission depends on the DUE IN date and time:

■ If the DUE IN date of a job has passed, the job is never submitted.

■ If the DUE IN date is not present, and the DUE IN time has passed, the job must
wait until the next day to be submitted.

To calculate the DUE IN time, the Control-M monitor subtracts the anticipated elapse
time of the job from the DUE OUT time. The anticipated elapse time is the average of
the execution times of the job recorded in the Control-M Statistics file.

If DUE OUT date is present, the DUE IN date is calculated as follows:

■ The DUE IN date is equal to the DUE OUT date.

■ If, when you move forward on the physical clock from the New Day Processing
time, you arrive at the DUE OUT TIME before you arrive at the DUE IN time, it
means that New Day processing falls between the DUE IN TIME and the DUE
OUT TIME. In this case, one day is subtracted from the DUE IN DATE.

If DUE OUT TIME is not specified, the default DUE OUT TIME is the last minute of
the working day.

Automatic adjustment of DUE OUT date and time can be requested from the Job
Dependency Network screen.

For more information, see “Automatic Job Flow Adjustment” on page 77, and “Job
Dependency Network Screen” on page 249. For an explanation of how DUE OUT
affects job submission in the QUIESCE command, see the description of setting a
planned shutdown time in the INCONTROL for z/OS Administrator Guide.

Please note that when specifying a DUE OUT date, the correct MAXWAIT parameter
value must be specified. For details, see “MAXWAIT: Basic Scheduling Parameter”
on page 528.

Example
Job DISKLOG2 must finish execution by 6:00 A.M., two days from today.

Figure 218 DUE OUT Parameter Example

JOB: DISKLOG2 LIB CTM.PROD.SCHEDULE TABLE: ADABAS
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+

500 Control-M for z/OS User Guide

 DUE OUT: Runtime Scheduling Parameter

SCHENV SYSTEM ID NJE NODE

SET VAR
CTB STEP AT NAME TYPE
DOCMEM DISKLOG2 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 99 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN DBA-CLEAN-LOG-2 ****
CONTROL
RESOURCE TAPE 0001
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME 0600 + 2 DAYS PRIORITY SAC CONFIRM
TIME ZONE:
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 17.14.10

Chapter 3 Job Production Parameters 501

GROUP: General Job Parameter

GROUP: General Job Parameter

Group to which a job belongs.

Figure 219 GROUP Parameter Format

The GROUP parameter identifies a group name of 1 through 20 characters. Only

trailing blanks are allowed.

■ In a table whose jobs are scheduled individually, the GROUP parameter is

optional. The same value does not have to be specified for all jobs in the table.

■ In a SMART Table, only jobs whose GROUP name is blank, inherit the GROUP
name specified in the SMART Table Entity. Jobs with a GROUP name specified
will not inherit the GROUP name specified in the SMART Table Entity.

General Information
The GROUP parameter affects the retrieval and display of information. It does not
affect job scheduling.

Job Scheduling of SMART Tables

When a SMART Table is created, specifying a value for the GROUP parameter in the
SMART Table Entity is optional. This value is only applied to job scheduling
definitions if the GROUP parameter of the job is blank.

Jobs in a SMART Table cannot be individually ordered. Jobs in this type of table can
only be ordered as a unit, though they can be individually forced.

Before jobs in the SMART Table can be scheduled, the set of jobs must be eligible for
scheduling, meaning that a set of basic scheduling criteria in the SMART Table Entity
must be satisfied.

502 Control-M for z/OS User Guide

 GROUP: General Job Parameter

Basic scheduling criteria, runtime scheduling criteria, and post-processing

parameters in the SMART Table Entity apply to all scheduled jobs in the SMART
Table.

For more information, see “Handling of Jobs” on page 70 and page 115, and
“Scheduling Jobs in SMART Tables” on page 388.

Retrieving and Displaying Information

The GROUP parameter can be used as a selection criteria that can make retrieval and
display of information more efficient.

For example, display of information in the Active Environment screen can be limited
to jobs belonging to a specific GROUP.

The group name appears in all important messages relating to the jobs in the GROUP.

NOTE
BMC Software recommends the use of the GROUP parameter in all job scheduling definitions
to facilitate implementation of Control-M/Enterprise Manager functions. For more
information, see the Control-M User Guide.

Chapter 3 Job Production Parameters 503

GROUP: General Job Parameter

Example
Job OPERCOMP (a table which handles jobs individually) belongs to the
MAINTENANCE group.

Figure 220 GROUP Parameter Example

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME OPERCOMP MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL OPER GROUP MAINTENANCE
DESC JOB RUN ON THE 1ST OF THE MONTH
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

504 Control-M for z/OS User Guide

 TBL MAXWAIT: Basic Scheduling Parameter

TBL MAXWAIT: Basic Scheduling Parameter

Number of extra days the SMART Table Entity can wait in the Active Jobs file if it
does not have an ENDED OK status. This parameter appears in and applies to the
SMART Table Entity only.

Figure 221 TBL MAXWAIT Parameter Format

Optional. Valid values are: any 2-digit number in the range of 00-98, or 99.

Table 187 TBL MAXWAIT Parameter Values

Value Description
00 If the SMART Table Entity did not receive an ENDED OK status on
its original scheduling date, it cannot remain in the Active Jobs file
beyond its original scheduling date, unless jobs belonging to the
SMART Table Entity are still in the Active Jobs file. Default.
nn Where nn = 01 – 98. If SMART Table Entity did not receive an
ENDED OK status on its original scheduling date, it can remain in
the Active Jobs file up to nn additional days awaiting that status.
99 SMART Table Entity remains in the Active Jobs file until deleted
manually, even if it has an ENDED OK status.

If no value is specified, the default value of 00 is automatically inserted. This default

value may be changed by your INCONTROL administrator, by means of Wish
WM2367 in member IOADFLT in the IOA IOAENV library.

Chapter 3 Job Production Parameters 505

TBL MAXWAIT: Basic Scheduling Parameter

General Information
The TBL MAXWAIT parameter enables the SMART Table Entity to remain in the
Active Jobs file for the specified number of days beyond the original scheduling date
if the SMART Table Entity did not receive an ENDED OK status.

This parameter is relevant only when there are no jobs belonging to the SMART Table
Entity in the Active Jobs file. As long as a job belonging to the SMART Table Entity is
still in the Active Jobs file, the SMART Table Entity remains in the Active Jobs file
regardless of the value in the TBL MAXWAIT field.

For more information, see “MAXWAIT: Basic Scheduling Parameter” on page 528.

Example
If the original scheduling date of the SMART Table Entity has passed, give it an extra
three days to receive a status of ENDED OK.

Figure 222 TBL MAXWAIT Parameter Example

TBL ACCOUNTS_GROUP CTM.PROD.SCHEDULE(TBL)
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
TABLE ACCOUNTS GROUP ACCOUNTS_GROUP
OWNER N04B
APPL
DESC
ADJUST CONDITIONS Y TBL MAXWAIT 03
SET VAR
DOCMEM ACCOUNTS DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC ALL_DAYS
DAYS ALL DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00
SCHEDULE RBC ACTIVE FROM UNTIL
===========================================================================
SCHEDULE RBC SUNDAYS
DAYS 01 DCAL
AND/OR
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 16.44.31

506 Control-M for z/OS User Guide

 IN: Runtime Scheduling Parameter

IN: Runtime Scheduling Parameter

Prerequisite conditions that must be satisfied before the job can run.

Figure 223 IN Parameter Format

Optional. A maximum of two prerequisite conditions can be specified in each

standard IN line. One prerequisite condition can be specified in each long IN line.
When you specify the second prerequisite condition in a standard IN line, or one
prerequisite condition in a long IN line, and press Enter, a new IN line is opened for
specifying additional prerequisite conditions. For more information, see “Specifying
Long IN Condition Names” on page 509.

Each specified prerequisite condition consists of the mandatory subparameters

described in Table 188.

Table 188 IN Subparameters (part 1 of 2)

Subparameter Description
cond_name User-supplied descriptive name of 1 through 39 characters used to
identify the condition. Mandatory.
Note: A condition name must not begin with the symbols “|”, “¬”,
or “\”, and must not contain parentheses ( ), because each of these
characters has a special meaning. For more information, see “Logical
Relations between Multiple Conditions” on page 510.
You can use an AutoEdit variable in a condition name, provided that
the AutoEdit variable has a value that is known before the job is
ordered.

Chapter 3 Job Production Parameters 507

IN: Runtime Scheduling Parameter

Table 188 IN Subparameters (part 2 of 2)

Subparameter Description
dateref 4-character date reference. Mandatory.
Valid values are:

■ date – Specific date (in either mmdd or ddmm format, depending

on the site standard).

■ ODAT – Resolves to the original scheduling date. Default.

■ +nnn – Resolves at job order time to ODATE+nnn calendar days.

nnn is three digits (000-999).

■ -nnn – Resolves at job order time to ODATE-nnn calendar days.

nnn is three digits (000-999).
Note: -001 is not necessarily the same as PREV, because PREV is
based on job scheduling criteria, while -nnn is based on calendar
days.
■ PREV – Resolves to the previous date on which the job ought to
have been scheduled, according to its basic scheduling criteria,
or ODATE–1 for a forced job.
Note: for SMART Table Scheduled Jobs: If the value of the
SCHEDULE RBC parameter has been set to * (asterisk), PREV is
resolved to the nearest previous date that satisfies one or more
Schedule RBCs in the SMART Table Entity.
■ STAT – Static. Indicates that the condition, such as IMS-ACTIVE,
is not date-dependent.
Note: Before STAT was introduced, date 0101 was recommended
to be used in conditions that were not date-dependent. Unlike
0101, STAT is not a date, and it operates differently. Always use
STAT when defining conditions that are not date-dependent.
■ **** – Any scheduling date

■ $$$$ – Any scheduling date

Note: If a date reference is not specified, value ODAT is
automatically inserted when you press Enter.

General Information
A job cannot be submitted unless all the prerequisite condition criteria specified in
the IN statements have been satisfied.

Prerequisite conditions are usually used to establish job dependencies or to ensure

manual intervention when required:

■ To establish job dependency, define a prerequisite condition in an OUT or DO

COND statement in the job that must run first, and in an IN statement in the job
that must run afterwards.

508 Control-M for z/OS User Guide

 IN: Runtime Scheduling Parameter

The job containing a prerequisite condition in its IN statement is not submitted

unless that prerequisite condition has been added manually or by the job
containing the OUT or DO COND statement.

— An OUT statement adds the prerequisite condition if the job ends OK.
— The DO COND statement adds the prerequisite condition if the step and code
event criteria specified in the accompanying ON statement are satisfied.

■ If the IN prerequisite condition can only be satisfied by manual intervention (for

example, TAPE1-ARRIVED is set by the operator after an external tape arrives
on-site), performance of the required manual intervention before job submission
can be ensured.

OUT and DO COND statements can also be used to delete prerequisite conditions
that are no longer needed. If an IN prerequisite condition for a job is not an IN
prerequisite condition for any other job, you can use the OUT statement of the job to
delete the prerequisite condition after the job ends OK.

The following are examples of prerequisite conditions:

IMS-ACTIVE
JOB_PAYCALC_ENDED_OK
TAPE1_LOADED

All prerequisite conditions are created with a date reference. When specifying a
prerequisite condition as an IN condition, you must specify the date for the condition.
Only a prerequisite condition with the specified date can satisfy the IN requirement.

For more information regarding prerequisite conditions, see “OUT: Post–Processing

Parameter” on page 571, “ON Statements: Post–Processing Parameter” on page 546,
and “DO COND: Post–Processing Parameter” on page 442, and see “Prerequisite
Conditions” on page 72

Specifying Long IN Condition Names

Regular prerequisite conditions are not more than 20 characters in length. If you want
to specify a longer condition name, up to 39 characters in length, enter the string
LONG in the date reference field of an empty IN condition line. An (L) appears at the
beginning of the line. If the field already contains data, entering the string LONG will
open a new long IN condition parameter, with (L) appearing at the beginning of the
line. You can now insert a long condition name, as illustrated in Figure 224 on
page 510.

Specify SHRT in the date reference field to revert back to condition names of standard
length.

Chapter 3 Job Production Parameters 509

IN: Runtime Scheduling Parameter

NOTE
Long condition names cannot be used in CMEM rule definitions.

Figure 224 Long IN Condition

JOB: J13 LIB CTMP.V610.SCHEDULE TABLE: REV1
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
IN CTMLDNRS-NMIS-OK ODAT CTMLDNRS-NMIS-OK1 ODAT
(L) THIS-IS-A-LONG-IN-CONDITION-NAMEXXXXXXX ODAT
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
============================================================================
OUT J1-ENDED ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) TO .
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN LATE TIME 1300 + DAYS TO TS0-N88 URGN R
MS BBB
SHOUT WHEN TIME + DAYS TO URGN
MS
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 09.06.50

Logical Relations between Multiple Conditions

The IN condition parameter differs from other parameters that may be defined more
than once.

Where there are multiple IN condition definitions, they are not independent
parameters, as might at first appear. Control-M takes them together and treats them
as a logical expression consisting of a series of connected terms, which appear as
condition names.

Control-M resolves every such condition to a value of “True” or “False,” and then
evaluates the whole expression, using the logical operators which may have been
specified as part of each condition name. The run-time criteria for prerequisite IN
conditions are only satisfied if the overall value of the expression is calculated as
“True”. A condition name is evaluated as “True” if the name of that condition
appears in the IOA Conditions file.

510 Control-M for z/OS User Guide

 IN: Runtime Scheduling Parameter

Conditions may be added to or deleted from the IOA Conditions file automatically or
manually. Some typical means of adding and/or deleting conditions are:

■ the Control-M Monitor, by means of OUT or DO COND statements

■ the IOA Conditions/Resources screen
■ the IOA Manual Conditions screen
■ the IOACND or IOACLND batch utilities

The following types of logical operator can be used to connect condition names:

■ unitary
■ binary
■ group

NOTE
These operators are not referred to as “Boolean”, because the rules of these operators do not
follow formal Boolean logic, as shown in the following paragraphs. Logical operators are the
first physical characters in condition names, but they are not part of the condition name.

Operators: Unitary
The logical NOT is the only unitary operator. It is represented in the condition name
by the symbol ¬ (Hex 5f) or \ (Hex e0). Conditions that have this type of symbol
associated with them are called “inverted” conditions. An inverted condition is only
“True” if that condition does not exist on the IOA Conditions File.

Operators: Binary
The following are the binary operators:

■ logical AND
This is implicit, and has no explicit representation in the condition name.

■ logical OR, represented by the symbol | (Hex 4f)

Where an expression contains conditions connected by an AND operator, both must

be present in the IOA Conditions File for the expression to be “True”.

An expression that contains conditions connected by an OR operator is “True” if

either expression is present in the IOA Conditions File.

Because logical OR operators are expressed as part of the condition name,

■ all conditions connected by the logical OR must specify the OR symbol in their
condition name

Chapter 3 Job Production Parameters 511

IN: Runtime Scheduling Parameter

This means that, for example, expressions of the form

A |B

must not be specified because their meaning is unclear, even though they will not
be syntactically rejected. In reality, because condition name A does not have an OR
symbol attached to it, no logical OR connection exists between A and B, and the
OR symbol attached to condition name B is ignored. The correct way to specify
“Condition A OR Condition B” is

(|A |B)

■ all condition names that specify an OR symbol are processed first, before those
specifying an AND symbol

This has the effect of creating implicit parentheses among the terms of the
expression (explained under “Operators: Group” below); the terms of the
expression may also be rearranged.

For example, the expression

|B |C D |E

is processed as if the expression had been

( |B |C |E ) D

Operators: Group
The group operator is the pair of parentheses, Open, represented by the symbol ( ,
and Close, represented by the symbol ) . These must always appear in matched pairs.
Parentheses affect the order in which the other logical operators are applied to the
terms of the expression. Always specify parentheses when coding an expression that
contains different logical operators, to ensure that the terms are combined in the way
you want.

Various combinations of logical operators are permitted, subject to the following

limitations:

■ only one level of parenthesis nesting is allowed

■ double NOT operators are not supported
■ an open parenthesis preceded by a NOT operator is not allowed

512 Control-M for z/OS User Guide

 IN: Runtime Scheduling Parameter

As in standard logic (de Morgan’s Rules), the following expressions express logical
equivalence:

A (|B |C) and |(A B) |(A C)

|A |(B C) and (|A |B) (|A |C)

A ¬ A is always “False”.

Example

IN |A B

¬C |¬D

|(¬E F)

A job containing this combination of IN conditions will be selected for execution

when the following statements are both “True”.

■ B exists and C does not exist

■ A exists, or D does not exist, or (E does not exist and F exists)

IN Parameter Examples
The following are examples of the IN parameter.

Example 1

Schedule the job that produces the salary statistics report for top management when
the set of jobs that calculates the salaries finishes OK.

When the set of jobs that calculates the salaries finishes OK, it creates the prerequisite
condition SALARY-OK.

The report is produced twice a month, for the 1st and for the 15th. The report for the
15th is produced only if the prerequisite condition for the 15th, SALARY-OK, exists,
signifying that the salary job for the 15th ended OK. The existence of the prerequisite
condition for the 1st, SALARY-OK, does not cause submission of the report for the
15th.

Chapter 3 Job Production Parameters 513

IN: Runtime Scheduling Parameter

Figure 225 IN Parameter – Example 1

JOB: EBDRPT1A LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
APPL EBD GROUP EBD-PRODUCTION
DESC EBD PRODUCTION SALARY REPORTS
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDRPT1A DOCLIB CTM.PROD.DOC
============================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS 0.15 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 06 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
============================================================================
IN SALARY-OK ODAT
CONTROL
RESOURCE
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Example 2

This example is similar to Example 1. A monthly total report must be produced based
on data from the last two runs, and the job must run when IMS is active.

Figure 226 IN Parameter – Example 2

JOB: EBDRPT1A LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
DESC EBD PRODUCTION REPORTS
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDRPT1A DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS 01,15 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 06 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN SALARY-OK ODAT SALARY-OK PREV
IMS-ACTIVE STAT
CONTROL

514 Control-M for z/OS User Guide

 IN: Runtime Scheduling Parameter

RESOURCE
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Prerequisite condition IMS-ACTIVE is based on a static condition that exists only

when IMS is active. IMS itself can be monitored by Control-M. When IMS is not
active, Control-M deletes the prerequisite condition IMS-ACTIVE, thus preventing
abends of jobs that depend on IMS.

Example 3

Assume that there is a set of jobs that runs every day of the week except Saturday and
Sunday. It is very important that some of the jobs scheduled for the different days of
the week do not run simultaneously. The order of these jobs must be maintained even
if there are delays.

Figure 227 IN Parameter – Example 3

JOB: EBDUPDT2 LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
APPL EBD GROUP EBD-PRODUCTION
DESC EBD PRODUCTION UPDATE
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDUPDT2 DOCLIB CTM.PROD.DOC
============================================================================
DAYS DCAL
AND/OR
WDAYS 2,3,4,5,6 WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 08 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
============================================================================
IN DEPOSITS PREV
CONTROL
RESOURCE
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

The job is submitted only if the prerequisite condition DEPOSITS of the previous
schedule date exists. The prerequisite condition DEPOSITS is created only after the
set of jobs called DEPOSITS finishes.

Example 4

This report must run after the database has been updated by either of two jobs,
EBDUPDT2 or EBDUPDT3, but only if IMS is active.

Chapter 3 Job Production Parameters 515

IN: Runtime Scheduling Parameter

Figure 228 IN Parameter – Example 4

JOB: EBDRPT6C LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
DESC EBD PRODUCTION DATABASE REPORTS
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDRPT6C DOCLIB CTM.PROD.DOC
============================================================================
DAYS 01,15 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
============================================================================
IN |EBD-EBDUPDT2-ENDED ODAT |EBD-EBDUPDT3-ENDED ODAT
IMS-ACTIVE STAT
CONTROL
RESOURCE
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

This job is submitted only if IMS is active and if job EBDUPDT2 (or EBDUPDT3)
finished executing.

Example 5

Use of parentheses in the IN conditions is demonstrated in the following example. Job

EDBCLEAN requires that two conditions be satisfied before submission. The first
must be either condition CICSP1-IS-UP or condition CICSP2-IS-UP. The second must
be either condition OPR-CLEAN-REQUEST or condition SYS-CLEAN-REQUEST.

516 Control-M for z/OS User Guide

 IN: Runtime Scheduling Parameter

Figure 229 IN Parameter – Example 5

JOB: EBDCLEAN LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OVERLIB CTM.OVER.JOBLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDCLEAN DOCLIB
============================================================================
DAYS ALL DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
============================================================================
IN (CICSP1-IS-UP 0101 |CICSP2-IS-UP) 0101
(OPR-CLEAN-REQUEST ODAT |SYS-CLEAN-REQUEST) ODAT

CONTROL
RESOURCE INIT 0001 CART 0001
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Example 6

The following example provides a further explanation of the concept of the schedule
date reference:

Figure 230 IN Parameter – Example 6

MEMNAME EBDRPT6D
MEMLIB EBD.PROD.JOB
DAYS 01,15,20
MONTHS 1- N 2- N 3- N 4- N 5- N 6- N 7- Y 8- N 9- Y 10- N 11- N 12- N
IN EBD-REPORTS-READY ****

Today is the 15th September. The date reference values resolved in this job are
written in mmdd date format:

Table 189 Date Reference Values – Example 6

Subparameter Value
ODAT 0915
PREV 0901
**** Any date reference.

Chapter 3 Job Production Parameters 517

INSTREAM JCL: General Job Parameter

INSTREAM JCL: General Job Parameter

Whether Control-M for z/OS submits a JCL stream defined within the job scheduling
definition, overriding the JCL in the member identified in the MEMLIB parameter
and the OVERLIB parameter (if specified).

Figure 231 INSTREAM JCL parameter format

Optional. Valid values for this parameter are:

■ Y – Submit the defined JCL statements as the JCL for the job
■ N – Use the JCL in the member identified in the MEMLIB parameter (default)

Under the INSTREAM JCL field is an empty line in which you can type a JCL
statement. No JCL statement can contain more than 72 characters, including spaces.
When you press Enter, a new line is opened in which another JCL statement can be
typed.

You can enter up to 50 lines of JCL statements. The contents of these lines can be
edited subsequently.

When the INSTREAM JCL parameter is set to Y, the library and member specified in
the job definition are ignored.

General Information
Prior to version 6.2.00 of Control-M for z/OS, user-defined JCL that was to be run in
the course of the execution of a job had to be defined in a JCL library.

The INSTREAM JCL parameter enables you to include JCL that is to be run in the
course of the execution of a job within the definition of the job itself.

When the job is ordered or forced, any JCL defined using the INSTREAM JCL
parameter resides in the Active Jobs file. The content of the JCL statements can then
be modified by means of the Zoom and Save commands.

518 Control-M for z/OS User Guide

 INSTREAM JCL: General Job Parameter

JCL that has been defined using the INSTREAM JCL parameter is processed by
submit-related user exits, such as CTMX002, in the same way as JCL retrieved
through the MEMLIB and MEMNAME parameters.

Chapter 3 Job Production Parameters 519

INTERVAL: Post–Processing Parameter

INTERVAL: Post–Processing Parameter

Minimum time to wait between automatic reruns or cyclic runs of a job.

A related topic, cyclic jobs, is discussed in “TASKTYPE: General Job Parameter” on

page 666.

Figure 232 INTERVAL Parameter Format

Optional. INTERVAL consists of the subparameters described in Table 190.

Table 190 INTERVAL Subparameters (part 1 of 2)

Subparameter Description
interval_number A number from 0 through 64800, depending on the value entered in
the interval_type field, specifying the minimum time to wait between
reruns or cyclic runs. Leading zeros are not required. Mandatory.

Default: 00000, indicating that there is no minimum time interval

between runs.

520 Control-M for z/OS User Guide

 INTERVAL: Post–Processing Parameter

Table 190 INTERVAL Subparameters (part 2 of 2)

Subparameter Description
interval_type A single character describing the type of data specified in the
INTERVAL field. Valid values are:

■ D (Days) – Maximum INTERVAL value is 45

■ H (Hours) – Maximum INTERVAL value is 1080
■ M (Minutes) – Maximum INTERVAL value is 64800. Default.
FROM Determinant of when the time to wait between reruns or cyclic runs
of a job begins. Valid values are:

■ STRT – Begin measuring the interval before the next cycle of the
job from the actual start of the current job run.

■ END – Begin measuring the interval before the next cycle of the
job from the end of the current job run. Default.

■ TRGT – Begin measuring the interval before the next cycle of the
job from when the current job run is scheduled.

General Information
The INTERVAL parameter defines a minimum interval between automatic reruns or
cyclic runs of the same job.

Once the job has run, the Control-M Monitor does not rerun or resubmit the job
unless both the following conditions are satisfied:

■ the specified time has passed

■ all runtime submission criteria, such as resources, conditions, and so on, are
satisfied

The FROM subparameter specifies the point from which the interval is measured.
The values set for this subparameter have the following effects:

■ If STRT is specified, the interval is measured from the start time of the previous
run.

■ If END is specified, the interval is measured from the time the previous run ended.

■ If TRGT is specified, the interval is measured from the scheduling time of the
current job run.

If no value was specified in the TIME FROM parameter, the interval is measured
from the time the Control-M Monitor scheduled the current job run.

Chapter 3 Job Production Parameters 521

INTERVAL: Post–Processing Parameter

For more information about the TIME FROM parameter, see “TIME + DAYS:
Runtime Scheduling Parameter” on page 671.

A job’s INTERVAL parameter is ignored when performing a Rerun (R) command for
a job in screen 3.

Example
A backup for an ADABAS database failed because the database was being used by
another user. Backups are tried every 15 minutes after the job ends, to a maximum of
nine attempts.

Figure 233 INTERVAL Parameter Example

JOB: ADBBKPS LIB CTM.PROD.SCHEDULE TABLE: ADABAS
COMMAND ===> SCROLL===> CRSR
+---------------------------------------------------------------------------+
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN 9 RERUNMEM INTERVAL 0015 M FROM END
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST BACKUP PROCST CODES U0034 A/O
DO RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
===== >>>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

522 Control-M for z/OS User Guide

 INTERVAL SEQUENCE: Post–Processing Parameter

INTERVAL SEQUENCE: Post–Processing

Parameter
The job runs are separated according to the specified sequence of intervals.

Optional. INTERVAL SEQUENCE consist of the subparameters described in

Table 191.

Table 191 INTERVAL SEQUENCE Subparameters

Subparameter Description
interval_number A number, depending on the value entered in the interval_type
subparameter, specifying the interval sequence of time to wait
between reruns or cyclic runs. Leading zeros are not required. Valid
values are:

■ for D – 0 through 45
■ for H – 0 through 1080
■ for M – 0 through 64800

Default: 64800 M

For example: +00030 M, +00004 H, +00007 D

interval_type A single character describing the type of data specified in the
interval_number subparameter. Valid values are:

■ D (Days)
■ H (Hours)
■ M (Minutes). Default.
FROM Indicates whether the interval between runs of a cyclic job or until
the start of a rerun job is measured from the start or the end of the
previous job run. Valid values are:

■ STRT - interval begins from the start of the previous job.

■ END - interval begins from the end of the previous job. Default.

General Information
The INTERVAL SEQUENCE parameter defines an interval sequence between reruns
or cyclic runs of the same job.

Once the job has run, the Control-M Monitor does not rerun or resubmit the job
unless both the following conditions are satisfied:

■ the defined interval of time for the next rerun has passed

Chapter 3 Job Production Parameters 523

INTERVAL SEQUENCE: Post–Processing Parameter

■ all runtime submission criteria, such as resources, conditions, and so on, are
satisfied

The FROM subparameter specifies the point from which the interval is measured.
The values set for this subparameter have the following effects:

■ When the value of FROM is STRT, the time until the next job run is counted from
the moment that the current job run begins.

■ When the value of FROM is END, the time until the next job run is counted from
the moment that the current job run is complete.

A Rerun command (R) can be performed only after all planned intervals have been
completed.

The figure below shows an example of the INTERVAL SEQUENCE parameter.

Figure 234 INTERVAL SEQUENCE Parameter Example

JOB: ADBBKPS LIB CTM.PROD.SCHEDULE TABLE: ADABAS
COMMAND ===> SCROLL===> CRSR
+---------------------------------------------------------------------------+
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN 9 RERUNMEM
CYCLICAL TYPE: V INTERVAL FROM
INTERVAL SEQUENCE: + 00030 M + 00004 H + 00007 D + +
+ + + + +
SPECIFIC TIMES: TOLERANCE
+ + + + +

524 Control-M for z/OS User Guide

 MAXRERUN: Post–Processing Parameter

MAXRERUN: Post–Processing Parameter

Maximum number of automatic reruns to be performed for the job. Called RERUN –
MAXRERUN prior to version 6.0.00.

Figure 235 MAXRERUN Parameter Format

Optional. For non-cyclic jobs, valid values are 0 through 255. For cyclic jobs, valid
values are 0 through 9999. Default: 0 (no automatic reruns or cyclic iterations).

General Information
When a job is first run, the MAXRERUN field in the Active environment, that is, in
the Zoom screen, contains the same value as the MAXRERUN parameter in the job
scheduling definition. However, in the Active environment MAXRERUN works as a
“reverse-counter” of automatic reruns. Each time the job is automatically rerun, the
value is decreased by one until the field contains a value of zero.

The automatic rerun process works as follows:

1. The Control-M monitor determines that automatic rerun is possible only if the job
ENDS NOTOK and a specified DO RERUN statement is activated during
post-processing. If the monitor determines that automatic rerun is possible, it sets
the status of the job to ENDED NOTOK – RERUN NEEDED.

2. The monitor then checks the value of MAXRERUN in the Active environment. If
the value is zero, automatic rerun is not possible and the job is not submitted for
rerun. If the value is greater than zero, rerun is possible and the monitor submits
the job for rerun when all runtime criteria are satisfied. Runtime criteria include
not only criteria in the Runtime Scheduling parameters, but also the INTERVAL
parameter, which specifies the minimum allowable interval between runs of the
same job.

Chapter 3 Job Production Parameters 525

MAXRERUN: Post–Processing Parameter

3. The JCL for the rerun job is taken from the member specified in the RERUNMEM
parameter. If no RERUNMEM value is specified, the JCL for the rerun is taken
from the regular JCL member of the job that is specified in the MEMNAME
parameter.

MAXRERUN applies only to automatic reruns. The MAXRERUN counter is not

affected by reruns performed manually using the Rerun option in the Active
Environment screen.

If a job is defined as cyclic by setting the TASKTYPE parameter to CYC, the

MAXRERUN parameter can be used to specify the number of iterations. This number
includes the initial run of the job.

Examples

Example 1

A tape I/O error occurred. Try two more times. If there are two more failures,
terminate:

MAXRERUN 2 RERUNMEM INTERVAL 0015 M FROM END

ON PGMST STEP01 PROCST CODES S613
DO RERUN

526 Control-M for z/OS User Guide

 MAXRERUN: Post–Processing Parameter

Example 2

When a job abends for any reason, try to restart it two more times (at the abended
step).

Figure 236 MAXRERUN Parameter Example 2

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+---------------------------------------------------------------------------+
===========================================================================
OUT PRDKPL01-ENDED-OK ODAT +
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN 2 RERUNMEM INTERVAL 0015 M FROM END
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 A/O
DO IFRERUN FROM $ABEND . TO . CONFIRM N
DO RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 527

MAXWAIT: Basic Scheduling Parameter

MAXWAIT: Basic Scheduling Parameter

Number of extra days the job can wait in the Active Jobs file for submission.

Figure 237 MAXWAIT Parameter Format

Optional. Valid values are: any 2-digit number in the range from 00 through 98, or 99.

Table 192 MAXWAIT Parameter Values

Value Description
00 Job is not executed if it did not execute on the original scheduling
date. Default.
nn Where nn = 01 – 98. If the job did not execute on its original
scheduling date, it is given an additional number of days to execute.
It can remain in the Active Jobs file up to nn days awaiting
execution.
99 Job remains in the Active Jobs file until deleted manually, even if the
job finished executing.

If no value is specified, the default value of 00 is automatically inserted. This default

value may be changed by your INCONTROL administrator, by means of Wish
WM2367 in the IOADFLT member in the IOA IOAENV library.

General Information
The MAXWAIT parameter is used to overcome the problem of delays in production.
A job that is scheduled for execution on a specific day does not always get executed
that same day. This can be due to a number of reasons, such as hardware failure or a
heavy production workload. Therefore, it may be desirable to specify an additional
number of days that the job must remain in the Active Jobs file awaiting execution.

When a job cannot be submitted for execution within the specified time limits, an
appropriate message is written to the IOA Log file, and the job is deleted from the
Active Jobs file.

528 Control-M for z/OS User Guide

 MAXWAIT: Basic Scheduling Parameter

Jobs scheduled as a result of a Y value in the RETRO parameter are always given at
least one day within which to execute, even if the MAXWAIT parameter indicates
that they must no longer be in the Active Jobs file. This occurs when the current
working date exceeds the original scheduling date (ODATE) by more than the
number of days specified in the MAXWAIT parameter on the day the job is scheduled
by RETRO=Y. For more information, see “RETRO: Basic Scheduling Parameter” on
page 616.

Emergency jobs not belonging to a group (parameter) are discarded if their specified
MAXWAIT periods have passed. An emergency job that belongs to a specific group
(specified in the GROUP parameter) and whose MAXWAIT period has not passed is
not deleted from the Active Jobs file until all of the regular jobs that belong to the
same group have finished executing. This is in case the job is needed at a later stage.

If the DUE OUT DAYS or TO DAYS parameter is specified, the job may stay in the
Active Jobs file for the number of days equal to the larger value of days specified in
these parameters.

For jobs containing a time zone later than the local Control-M time, one day is added
to MAXWAIT so that the job will stay one additional day on the Active Jobs file.

MAXWAIT Values for Jobs in a SMART Table

The MAXWAIT value for jobs in a SMART Table is normally determined by the
MAXWAIT parameter in rule-based calendars defined in the SMART Table Entity.
However:

■ If the RBCMAXWT parameter in the CTMPARM member in the IOA PARM

library is set to N (No), the MAXWAIT value for each job in the SMART Table is
instead determined by the value of the MAXWAIT parameter in its job scheduling
definition.

■ If AND is specified in the RELATIONSHIP parameter, the MAXWAIT value from

the job scheduling definition is used (regardless of the value of the RBCMAXWT
parameter).

■ If a job in a SMART Table is forced, the MAXWAIT value is determined by the

value of the MAXWAIT parameter in the job scheduling definition, regardless of
the value of the RBCMAXWT parameter.

MAXWAIT Values for Cyclic Jobs

If a cyclic job is executing at the time the New Day procedure is run and the job's
MAXWAIT value is reached, the New Day procedure changes the job to a non-cyclic
job so that it can subsequently be deleted during the next New Day procedure.

Chapter 3 Job Production Parameters 529

MAXWAIT: Basic Scheduling Parameter

Examples

Example 1

If the original scheduling date of the job has passed, give the job an extra three days to
be submitted.

Figure 238 MAXWAIT Parameter Example 1

JOB: OPERJOB LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME OPERJOB MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL OPER GROUP MAINTENANCE
DESC JOB RUN IN FIRST HALF OF THE MONTH
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERJOB DOCLIB CTM.PROD.DOC
==========================================================================
DAYS 02,04,06 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 03 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
==========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Assume that the job does not run due to the absence of the required runtime
resources. The job that is scheduled for the 2nd of the month can wait from the 2nd
through the 5th to be executed.

On the 6th, the MAXWAIT period expires and the job scheduled for the 2nd is not
executed. The jobs scheduled for the 4th and 6th wait for execution until the 7th and
9th.

Example 2

The job can wait for execution indefinitely, until the runtime requirements for the job
are satisfied:

MAXWAIT 99

530 Control-M for z/OS User Guide

 MAXWAIT: Basic Scheduling Parameter

Example 3

Schedule the job for every working day, even if the computer is not active. Give the
job an extra day in which to be submitted.

Assume that calendar WORKDAYS, specified in the DCAL parameter, contains the
values 15, 16, 18, and 19. The computer was offline from the 16th up to and including
the 18th, and the 15th was the last date that the job was scheduled for execution.

Figure 239 MAXWAIT Parameter Example 3

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL KPL GROUP PROD-KPL
DESC DAILY PRODUCTION - START OF APPL-PROD-KPL
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL WORKDAYS
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 01 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Today is the 19th. The job is scheduled three times with the different original
scheduling dates of the 16th, 18th and 19th.

The jobs on the 16th and 18th are disregarded on the 20th if they have not yet
executed. The job on the 19th is disregarded only on the 21st.

Example 4

Schedule the job for every working day, even if the computer is not active. If it does
not execute within the scheduled day, remove it from the Active Job file:

MAXWAIT 00

Chapter 3 Job Production Parameters 531

MEMLIB: General Job Parameter

MEMLIB: General Job Parameter

For a job (or warning messages): Name of the library containing the member specified
in the TABLE parameter.

For a started task: Required started task information.

A related parameter is discussed in “OVERLIB: General Job Parameter” on page 580.

Figure 240 MEMLIB Parameter Format

Mandatory. Format of the parameter depends on whether the job scheduling

definition applies to a job (or warning messages) or a started task:

■ For a job (or warning messages):

Valid values are a valid data set name of 1 through 44 characters, or one of the
reserved values shown in Table 193.

Table 193 MEMLIB Parameter Values for Non-Started Tasks

Value Description
DUMMY For dummy jobs.

For warning messages, do not use DUMMY as a value for this

parameter.
USER=name For user-defined libraries.
GENERAL Specifies the library referenced by the DALIB DD statement in the
Control-M procedure.
DDNAME=ddname Specifies the library/member pointed to by the ddname DD
statement in the Control-M monitor procedure from which the JCL is
to be submitted. Sample user exit CTMX002G in the IOA SAMPEXIT
library must be installed.

532 Control-M for z/OS User Guide

 MEMLIB: General Job Parameter

■ For a started task:

Any of the formats shown in Table 194 can be used for the MEMLIB value.

Table 194 MEMLIB Parameter Formats for Started Tasks

Format Description
*.taskid Where taskid is the task ID. The STC is activated in the computer in
which the Control-M monitor is active.
cpuid, stcparms Where cpuid is the ID of the computer in which the STC is to be
activated (see the following value “cpuid”); stcparms represents STC
parameters.
cpuid.taskid Where cpuid is the ID of the computer in which the STC is to be
activated (see the following value "cpuid"); taskid is the identifier to be
specified on the start command.
cpuid Where cpuid is the ID of the computer in which the STC is to be
activated. Valid cpuid values are:

■ * – The same computer where the Control-M monitor is active.

Under JES2:

■ Nn – Where n is the JES/NJE node ID.

■ Mm – Where m is the machine ID.
■ NnMm – Where n is the JES/NJE node ID, and m is the machine
ID.

When using the cpuid,stcparms format (see above), any quotes

specified in the stcparms must be doubled.

Under JES3

■ Lname – Where name is the logical JES name of the machine, that
is, the name as used in the JES3 command *T, not the SMF system
ID.

General Information
Whether the job scheduling definition applies to a job, warning messages, or a started
task is determined by the values defined in the TASKTYPE parameter, which is
described in “TASKTYPE: General Job Parameter” on page 666.

AutoEdit variables can be specified and are resolved. Even the machine ID, which is
relevant for started task initiation, can be automatically replaced based on resource
allocation. For more information, see Chapter 5, “JCL and AutoEdit Facility.”

Chapter 3 Job Production Parameters 533

MEMLIB: General Job Parameter

For Jobs (or Warning Messages)

The library can be any standard cataloged partitioned data set (PDS or PDSE),
LIBRARIAN or PANVALET. The record length must be 80.

The library and the member do not have to exist when the job production parameters
are defined. Their existence is checked by Control-M before actual submission of the
job.

If, during the access to a library by Control-M (before submission), the library is held
exclusively by another user, such as a TSO user or job, the monitor tries to access the
library every few seconds until the library is released and the job can be submitted. If
the library is migrated, for example, through HSM, Control-M remains in a WAIT
state until the library is recalled.

Use of the library name DUMMY is intended for scheduling events, for example,
adding a prerequisite condition without actually running the job. If the library name
DUMMY is used, the job is not submitted; submission and sysout checking are
skipped. In this case, the job is assumed to have ended OK (ON PGMST...DO
processing is not performed), and Post-Processing parameters associated with an
ENDED OK status are activated (OUT, SHOUT WHEN OK).

If the library name is GENERAL:

■ The job is submitted from the library referenced by the DALIB DD statement of the
Control-M procedure. This library must be a partitioned data set or a
concatenation of partitioned data sets.

■ The standard ISPF Editor cannot process more than four concatenated libraries.
The editor saves the edited member in the first library in the concatenation.

Control-M Exit CTMX014 (the CTMX014G member in the IOA SAMPEXIT library)
enables you to bypass these limitations if the members are going to be edited
online through the J (JCL) option in the Job List screen or the Active Environment
screen.

■ The prefix USER= must be specified when a special type of user library is used.
When using this prefix, the member is not read by Control-M using the normal
mechanism. Instead Control-M submission Exit CTMX002 must be coded to
handle access and submission of the library and member. In such cases, the
Control-M monitor ignores the data specified in the MEMLIB/MEMNAME
parameters; however, the substring following the USER= may be used by the exit.
For examples of the exit, see the IOA SAMPEXIT library.

534 Control-M for z/OS User Guide

 MEMLIB: General Job Parameter

When specifying option J (JCL) in the Job List screen or the Active Environment
screen in order to edit the JCL member, Control-M must determine which library
(MEMLIB or OVERLIB) to use.

NOTE
The algorithm for this decision is described in “Editing A Member through The J (JCL)
Option” on page 582.

For Started Tasks

A started task is activated in the specified computer ID. This is the ID of the computer
in JES, not the 4-character SMF ID. You can use the $D MEMBER JES command to
determine the JES ID. For more information, see the discussion on specifying IOA
CPUs in the description of the customization process in the INCONTROL for z/OS
Installation Guide. If the computer ID is followed by a comma and parameters, the
parameters are applied to the started task.

Examples

Example 1

Submit the job from the IMSBKUP member in the SYS2.IMS.JOB library:

MEMNAME IMSBKUP
MEMLIB SYS2.IMS.JOB

Example 2

Activate started task COLCTSMF in the computer where the Control-M monitor is
operating:

MEMNAME COLCTSMF
MEMLIB *,DATE=%%ODATE

On September 5, the STC is activated by issuing the operator command:

S COLCTSMF,DATE=000905

Chapter 3 Job Production Parameters 535

MEMLIB: General Job Parameter

Example 3

Activate started task GTF in the computer in which the Control-M monitor is
operating; task ID is G01:

MEMNAME GTF
MEMLIB *.G01

The STC is activated by issuing the operator command:

S GTF.G01

Example 4

Activate started task COLCTSMF on JES node 1:

MEMNAME COLCTSMF
MEMLIB N1,DATE=%%ODATE

Example 5

Activate started task COLCTSMF on machine 1 on JES node 1:

MEMNAME COLCTSMF
MEMLIB N1M1,DATE=%%ODATE

Example 6

Activate started task STAMSTC on MAS member 2 with identifier IDNTFIER:

MEMNAME STAMSTC
MEMLIB M2.IDNTFIER

The STC is activated by issuing the operator command:

$M2,'S STAMSTC.IDNTFIER'

536 Control-M for z/OS User Guide

 MEMNAME: General Job Parameter

MEMNAME: General Job Parameter

Name of the member that contains one of the following (depending on the defined
task type):

■ JCL of the job

■ Started task procedure
■ Warning messages

NOTE
For a SMART Table Entity, this parameter has a different meaning, which is explained in “For
a SMART Table Entity” on page 538.

For more information, see “MEMLIB: General Job Parameter” on page 532.

Figure 241 MEMNAME Parameter Format

Mandatory. MEMNAME identifies a valid member name of 1 through 8 characters.

For On Spool jobs, mask characters * and ? are supported. For details, see “Character
Masking” on page 87 and “On Spool Jobs” on page 695.

NOTE
Control-M does not support members that have been compressed using the ISPF PACK
option.

Chapter 3 Job Production Parameters 537

MEMNAME: General Job Parameter

General Information
The MEMNAME parameter identifies a member whose contents are determined by
the task type of the job scheduling definition. For more information, see “TASKTYPE:
General Job Parameter” on page 666.

■ If TASKTYPE contains the value JOB, CYC, EMR or ECJ, the job scheduling
definition is defined for a job and the MEMNAME parameter identifies the
member that contains the JCL of the job.

■ If TASKTYPE contains the value STC, CST, EST or ECS, the job scheduling
definition is defined for a started task and the MEMNAME parameter identifies
the member that contains the started task procedure.

■ If TASKTYPE contains the value WRN, the job scheduling definition is defined for
warning messages and the MEMNAME parameter identifies the member that
contains the warning messages.

For a Job

The member name may be the same as or different than the job name.

The member can contain the JCL of more than one job. By default, Control-M
processes only the first job in the member. If, however, the MULTJOBS parameter in
the CTMPARM member in the IOA PARM library is set to Y (Yes), Control-M
submits all the jobs in the member, but still only monitors the execution and results of
the first job in the member. Therefore, BMC Software recommends that each member
contain the JCL of only one job.

For a SMART Table Entity

In a SMART Table Entity, the MEMNAME parameter does not indicate a member
name. Instead, MEMNAME is used for descriptive purposes in certain screens, such
as in the NAME field of the Active Environment screen.

When working with a table created in version earlier than version 7.0, the TABLE
name does not have to be equal to the table name in the scheduling library, and the
TABLE name can be modified.

When defining a new table, the TABLE name will be set to be equal to the table name
in the scheduling library, and it will be protected.

538 Control-M for z/OS User Guide

 MEMNAME: General Job Parameter

Example
The JCL for job OPERCOMP is located in the OPERCOMP member in the library
CTM.PROD.JCL.

Figure 242 TABLE Parameter Example

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
TABLE OPERCOMP MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL OPER GROUP MAINTENANCE
DESC JOB RUN ON THE 1ST OF THE MONTH
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
==========================================================================
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
==========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 539

MINIMUM: Basic Scheduling Parameter

MINIMUM: Basic Scheduling Parameter

Minimum number of free tracks required by the library specified in the PDS
parameter.

A related parameter is discussed in “PDS: Basic Scheduling Parameter” on page 588.

Figure 243 MINIMUM Parameter Format

Optional. However, if PDS is specified, MINIMUM is mandatory. The MINIMUM

parameter specifies the minimum number of free tracks required. This must be a
positive 3-digit number; leading zeros are inserted if necessary.

The MINIMUM parameter cannot be used with the DAYS, WDAYS, MONTHS,
CONFCAL, RETRO and DATES parameters.

General Information
The MINIMUM and PDS parameters are always used together and are never used
with other Basic Scheduling parameters.

The PDS parameter identifies a library, and the MINIMUM parameter specifies the
minimum number of free tracks required by that library.

These parameters are intended for use (that is, definition) in jobs and started tasks
that compress, clean and/or enlarge libraries, or which issue a warning message to
the IOA Log file (that is, if TASKTYPE=WRN) if the minimum number of free tracks
is not available.

If the MINIMUM and PDS parameters are defined for a job, the scheduling of the job
is not related to or dependent upon any date criteria. Instead, the job is scheduled if
the actual number of free tracks available in the specified library is below the
specified minimum at time of daily job ordering. The job or started task can then
compress, clean, or enlarge the library (or issue the appropriate warning).

540 Control-M for z/OS User Guide

 MINIMUM: Basic Scheduling Parameter

NOTE
MINIMUM does not work with PDSE-type libraries because they always appear to be 100
percent full. MINIMUM only checks current extents.

Examples

Example 1

Schedule the job when there are less than 20 unused tracks in the library
ALL.PARMLIB.

Figure 244 MINIMUM Parameter – Example 1

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME OPERCOMP MEMLIB GENERAL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL OPER GROUP OPER-MAINT
DESC COMPRESS OF ALL.PARMLIB
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
==========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- 2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12-
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM 020 PDS ALL.PARMLIB
DEFINITION ACTIVE FROM UNTIL
==========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Example 2

Send a warning message when there are less than 50 unused tracks in the library
USER.LIBRARY:

Figure 245 MINIMUM Parameter – Example 2

MEMNAME MSG001
TASKTYPE WRN
PDS USER.LIBRARY
MINIMUM 050

Chapter 3 Job Production Parameters 541

MONTHS: Basic Scheduling Parameter

MONTHS: Basic Scheduling Parameter

Months of the year in which the job must be scheduled.

Figure 246 MONTHS Parameter Format

Optional. The months in the year are represented by the numbers 1 through 12. A
value can be specified for each month. Valid values are:

Table 195 MONTHS Parameter Values

Value Description
Y (Yes) Schedule the job in that month. Default.
N (No) or blank Do not schedule the job in that month.

General Information
In general, the job is scheduled for execution only during the months in which a value
of Y is specified and only if the job would have also been scheduled due to some other
basic scheduling parameter (such as DAYS, WDAYS, and so on); that is, the
MONTHS parameter serves as a limiting filter. There are certain exceptions that are
noted below.

The MONTHS parameter cannot be used with the PDS and MINIMUM parameters.

If values are set for both the MONTHS parameter and the DATES parameter, the
MONTHS parameter setting is ignored.

A job can be scheduled in a month not specified as a working month if a greater than
or less than qualifier in the DAYS specification shifts the scheduling out of the current
month, and the month to which it shifts is a non-scheduled month, the job is
nevertheless scheduled in that non-scheduled month.

542 Control-M for z/OS User Guide

 MONTHS: Basic Scheduling Parameter

Example

If the values of the DAYS parameter >31, the MONTHS parameter indicates
JANUARY and MARCH (but not FEBRUARY).

The associated calendar has all days except JANUARY 31 as working days.

Then the job is scheduled on February 1.

Examples

Example 1

Schedule a job only in March and September:

MONTHS 1- N 2- N 3- Y 4- N 5- N 6- N 7- N 8- N 9- Y 10- N 11- N 12- N

Example 2

Schedule job OPERCOMP on the first day of every month.

Figure 247 MONTHS Parameter – Example 2

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME OPERCOMP MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL OPER GROUP MAINTENANCE
DESC JOB RUN ON THE 1ST OF THE MONTH
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
==========================================================================
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
==========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 543

NJE NODE: General Job Parameter

NJE NODE: General Job Parameter

Identifies the node in the JES network at which the job is to execute.

Figure 248 NJE NODE Parameter Format

NJE NODE specifies a node name of 1 through 8 characters. Only trailing blanks are
allowed.

By default, the NJE NODE parameter is optional.

General Information
The NJE NODE parameter is used to identify the node in the JES network at which
the job is to execute.

If a value is specified for the NJE NODE parameter, a JCL statement is generated. The
precise form of the statement depends on whether Control-M is running under JES2
or JES3.

If the task type is a started task, NJE NODE is protected. If the task type is changed
from a job to a started task, NJE NODE is erased and protected.

Under JES2
If Control-M is running under JES2, the NJE NODE parameter generates the
following JCL statement:

/*ROUTE XEQ node_name

544 Control-M for z/OS User Guide

 NJE NODE: General Job Parameter

Under JES3
If Control-M is running under JES3, the JCL statement generated by the NJE NODE
parameter differs slightly, taking the following form:

//*ROUTE XEQ node_name

Note that if a JES3 NJB job statement is not present in the job, the //*ROUTE XEQ
JCL statement is not generated.

If a value is specified for the NJE NODE parameter, it will not override any node
name specified in the job statement unless the OVERJCLM parameter in the
CTMPARM library is set to Y.

Examples

Example 1

Control-M is running under JES2. The following is specified:

DESC
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE OS35

The following statement is added to the JCL of the job:

/*ROUTE XEQ OS35

and the job is executed at node OS35.

Example 2

Control-M is running under JES3. The following is specified:

DESC
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE OS35

The following statement is added to the JCL of the job:

//*ROUTE XEQ OS35

and the job is executed at node OS35.

Chapter 3 Job Production Parameters 545

ON Statements: Post–Processing Parameter

ON Statements: Post–Processing Parameter

Job processing criteria that determine whether the accompanying DO statements are
performed.

Figure 249 ON Statement Format Example

ON statements identify specific steps in the execution of a Control-M job or group.

The types of ON statement are described in Table 196. Each type is discussed in detail
in this chapter.

Table 196 ON Statement types

ON Statement Type Description
ON TABLE-END Group processing criteria that determine whether the accompanying
DO statements are performed
For more information, see “ON TABLE-END: Post–Processing
Parameter” on page 548.
ON PGMST Job processing step and code event criteria that determine whether
the accompanying DO statements are performed
For more information, see “ON PGMST: Post–Processing Parameter”
on page 551.
ON SYSOUT Search for a string in the sysout of the job, and perform the
accompanying DO statements if the string is found
For more information, see “ON SYSOUT: Post–Processing Parameter”
on page 568.

Multiple ON statements can be specified.

Multiple ON PGMST and ON SYSOUT statements can be linked by Boolean logic.

546 Control-M for z/OS User Guide

 ON Statements: Post–Processing Parameter

General Information
ON statements are usually, but not necessarily, followed by user-specified DO
actions. The implied relationship between ON statements and associated DO
statements is: if ON statement criteria are satisfied, perform the associated DO
statement actions.

The combination of ON statements and DO statements enables you to specify

post-processing actions that depend on the execution results of job steps executed
under Control-M.

Multiple ON Statements and ON Blocks

In a new job scheduling definition, an empty ON statement is followed by an empty

DO statement. Additional ON statements can be opened in the job scheduling
definition as required.

For more information, see the topic, “Multiple ON Statements and ON Blocks,” under
the relevant ON statement type.

Chapter 3 Job Production Parameters 547

ON TABLE-END: Post–Processing Parameter

ON TABLE-END: Post–Processing Parameter

Table processing criteria that determine whether the accompanying DO statements
are performed. Found in SMART Table Entities only.

Figure 250 ON TABLE-END Parameter Format

Optional. Valid values are shown in Figure 197.

Table 197 ON TABLE-END Values

Value Description
OK Process the accompanying DO statements if all scheduled jobs in the
group ended OK.
NOTOK Process the accompanying DO statements if not every job in the
group ended OK.

General Information
The ON TABLE-END parameter enables specification of DO statements to be
performed when the processing of the group ends with the indicated status.

By default, if not all jobs in the group ended OK, the DO statements accompanying an
ON TABLE-END NOTOK parameter are performed. This applies if at least one job
ended NOTOK, and it can also apply if a job in the group was deleted and all
remaining jobs in the group ended OK. However, if the TBLDELJB parameter in the
CTMPARM member in the IOA PARM library is set to Y (Yes), deleted jobs are not
considered, and status END NOTOK applies only if at least one job ended NOTOK.

If the job that ended NOTOK is subsequently successfully rerun, so that the
termination status of the SMART Table changes to OK, the DO statements
accompanying an ON TABLE-END OK parameter are then performed.

548 Control-M for z/OS User Guide

 ON TABLE-END: Post–Processing Parameter

The following DO statements can be specified following an ON TABLE-END

statement:

■ DO COND
■ DO FORCEJOB
■ DO NOTOK
■ DO OK
■ DO SET
■ DO SHOUT
■ DO MAIL

DO OK or DO NOTOK statements change the final status of the group, not the status
of each job or job step in the table.

Use of the ON TABLE-END parameter in the SMART Table Entity can frequently
reduce the number of individual DO statements that would otherwise require
definition in individual job scheduling definitions.

For example, suppose that following the processing of the group, you want to force a
particular job if any of the jobs in the group ENDED NOTOK.

■ This result can be achieved by defining an ON TABLE-END NOTOK DO

statement (in the SMART Table Entity) followed by the appropriate DO
FORCEJOB statement.

■ To achieve this result without use of the ON TABLE-END parameter, the following
steps would be necessary:

— In each job scheduling definition in the table, define an appropriate condition

that would be added to the IOA Conditions file when the job ends NOTOK.

— In the table, define an additional job to be performed after the other jobs in the
table have terminated. This job would have as an IN condition the condition
added by the jobs that ended NOTOK, and would trigger the appropriate job.

Multiple ON TABLE END Statements and ON TABLE END Blocks

Multiple ON TABLE-END parameters can be defined. Upon specifying an ON

TABLE-END value and pressing Enter, a new ON TABLE-END statement, followed
by a blank DO statement, is opened.

Chapter 3 Job Production Parameters 549

ON TABLE-END: Post–Processing Parameter

Example
If a job in the Group ACCOUNTS_GROUP ended NOTOK, add condition
ACCTS-CHK-REQUIRED.

Figure 251 ON TABLE-END Parameter Example

TBL ACCOUNTS_GROUP CTM.PROD.SCHEDULE(TBL)
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
===========================================================================
SCHEDULE RBC
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00
SCHEDULE RBC ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT
ON TABLE-END NOTOK
DO COND ACCTS-CHK-REQUIRED ODAT +
SHOUT WHEN TIME + DAYS TO URGN
MS
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 18.19.14

Confirmation panel
If the DFJCONF profile variable is set to Y, and the JOB parameter in the DO
FORCEJOB request is blank, a confirmation panel is displayed when exiting the Job
Scheduling Definition screen. The confirmation panel is displayed only once for each
DO FORCEJOB statement.

Figure 252 ON TABLE-END Confirmation Panel

+----------------------------------------------------------+
| |
| THIS JOB CONTAINS ONE OR MORE DO FORCEJOB STATEMENTS. |
| WHEN THE JOB IS ORDERED: |
| ARE YOU SURE YOU WANT TO FORCE THE WHOLE TABLE IN THE |
| FORCEJOB STATEMENT(S)? (Y/N) |
| |
+----------------------------------------------------------+

Enter Y to save the table and return to the Job List screen, or N to return to the table
without saving it.

550 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

ON PGMST: Post–Processing Parameter

Job processing step and code event criteria that determine whether the accompanying
DO statements are performed.

For more information, see “STEP RANGE: Post–Processing Parameter” on page 652.

Figure 253 ON Parameter Format

Optional. ON PGMST statements define event criteria that identify specific

Control-M job steps and possible codes that result from the execution of those job
steps.

The ON PGMST statement consists of the subparameters described in Table 198.

When used, at least one step and one code must be specified.

Chapter 3 Job Production Parameters 551

ON PGMST: Post–Processing Parameter

Table 198 ON PGMST Parameter Subparameters (part 1 of 2)

Subparameter Description
PGMST Job step. The execution results of the program executed by the job
step are checked against the specified CODES criteria. From
1 through 8 characters. Mandatory. Valid values are:

■ pgmstep – Name of the step (EXEC statement):

//pgmstep EXEC PGM=program
The ON PGMST statement is satisfied only when the program
execution results from the specified step satisfy the specified
code criteria. For more information, see “PGMST” on page 556.

■ *rangename – Range name. rangename is the name of a step range

defined in the STEP RANGE parameter. The asterisk (*)
preceding the name indicates to Control-M that the specified
name is a range name, not a step name. For more information,
see “STEP RANGE” on page 556, and “STEP RANGE: Post–
Processing Parameter” on page 652.
Note: Some third party products produce JCL step names that begin
with an * (asterisk) character. If you specify a JCL step name of this
type in an ON PGMST statement, Control-M interprets this step
name as a step range.

The solution is to define a workaround step range that includes only

the problematic step name.

For example, to process the step name *OMVTEX, use the following:
STEP RANGE ONESTEP FR (PRM.PROC) *OMVTEX . TO *OMVTEX
ON PGMST *ONESTEP PROCST CODES xxxxx
■ ANYSTEP – any job step
Generally, the ON PGMST statement is satisfied when the
program execution results from any job step satisfy the specified
code criteria. For more information, including the exceptions, see
“Step Name: ANYSTEP” on page 557.

■ +EVERY – every job step

The ON PGMST statement is satisfied if the program execution
results from every job step that satisfies the specified code
criteria. For more information, see “Step Name: +EVERY” on
page 557.

■ $FIRST – the first-executed job step

■ $LAST – the last-executed job step

Note: The $FIRST and $LAST values have these special meanings
only if the LASTSTEP parameter in the CTMPARM member is set to
Y.

Neither Control-M/Restart steps nor FLUSHed steps are considered

the first or last step for this purpose.

552 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

Table 198 ON PGMST Parameter Subparameters (part 2 of 2)

Subparameter Description
PROCST Procedure step (EXEC statement) that invokes a procedure from
which the specified PGMST program is executed. 1 to 8 characters.
Optional. Valid values are:

■ " " (blank) – When the PROCST field is left blank, matching
program step names (PGMST) are checked regardless of whether
they are directly from the job or from a called procedure.
Default.
The ON PGMST statement is satisfied if the PGMST criteria are
satisfied from any procedure directly from the job.

■ procstep – Name of a specific procedure step:

//procstep EXEC procedure
If a specific procedure step is specified, only program steps from
the invoked procedure are checked to see if they satisfy the code
criteria. Program steps directly from the job are not checked.

■ +EVERY
Matching program step names (PGMST) are checked from all
called procedures and from the job itself.
The ON PGMST statement is satisfied only when the code
criteria for the program step are satisfied for all occurrences
(called procedures and directly in the job stream). For more
information, see “Step Name: +EVERY” on page 557.
CODES Return codes or statuses that can satisfy the step or code event
criteria if returned upon termination of the specified job steps. At
least one code must be specified. CODES can be condition codes,
user abend codes, system abend codes, various end codes and
statuses, and certain keywords. CODES are discussed in “General
Information,” immediately below this table.
A/O Optional. Specifying either A (And) or O (Or) opens a new ON
PGMST statement in the ON PGMST block (described in “Multiple
ON PGMST Statements and ON PGMST Blocks” below this table)
and links the new statement to the statement containing the A/O
specification, as follows:

■ A (And) – Indicates AND logic between the two ON PGMST

statements. ON PGMST block criteria are satisfied only if both
ON PGMST statements are satisfied.

■ O (Or) – Indicates OR logic between the two ON statements. ON

PGMST block criteria are satisfied if either (or both) ON PGMST
statements are satisfied.

Chapter 3 Job Production Parameters 553

ON PGMST: Post–Processing Parameter

General Information
ON PGMST statements are usually, but not necessarily, followed by user-specified
DO actions. The implied relationship between ON PGMST statements and associated
DO statements is described in “General Information” on page 547.

Multiple ON PGMST Statements and ON PGMST Blocks

In a new job scheduling definition, an empty ON PGMST statement is followed by an

empty DO statement. Additional ON PGMST statements can be opened in the job
scheduling definition as follows:

■ When you set values for ON PGMST, PROCST, and CODE, and press Enter, an
empty ON PGMST and DO statement is opened following the current ON PGMST
and DO statements. The new ON PGMST and DO statements, if filled in, are not
logically connected to the preceding ON PGMST and DO statements. They
constitute a new ON PGMST block and DO block.

Multiple ON PGMST blocks are normally interpreted sequentially. If the

conditions of an ON PGMST block are satisfied, the accompanying DO actions are
performed. The conditions of more than one ON PGMST block can be satisfied;
therefore, more than one set of DO statements can be performed.

Example

One ON PGMST block specifies STEP1 as the program step, and >C0004 as the
CODE.

A second ON PGMST block specifies ANYSTEP as the program step, and >C0008
as the CODE.

If STEP1 results in a condition code of C0016, the ON PGMST step and CODE
event criteria for both ON PGMST statements are satisfied, and the DO actions
accompanying both ON PGMST blocks are performed.

■ When you fill in the A/O (And/Or) subparameter of an ON PGMST statement, an

empty ON PGMST statement is opened immediately, that is, before the
accompanying DO statement. The specified A/O value logically connects the new
ON PGMST statement to the preceding ON PGMST statement. These two ON
PGMST statements constitute a single ON PGMST block.

Example

ON PGMST STEP1 ... CODES C0004 ... A/O A

ON PGMST STEP5 ... CODES S0C4 ... A/O
DO SHOUT ...

554 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

In the above ON PGMST and DO statements, for the DO SHOUT action to be

performed, STEP1 must end with a condition code of C0004, and STEP5 must end
with an S0C4 system abend.

To add an empty ON PGMST statement between two existing ON PGMST

statements, type the > character over the first letter in the ON PGMST value of the
previous ON PGMST line, and press Enter.

Example

If the program step name is STEP1, type the following and press Enter:

ON PGMST >TEP1

This adds an “empty” ON PGMST line after the current ON PGMST statement.
The STEP1 step name is restored to its original value when Enter is pressed (that is,
the > character disappears and the S character is restored).

To delete unwanted ON PGMST statements, specify appropriate Line Editing

commands in the Edit environment. For information on the Edit environment, see
Appendix C, “Editing Job Scheduling Definitions in the Edit Environment,” and in
particular “Line Editing Commands” on page 929.

§Restart§ Using All Runs of a Job Including Restarts

When processing ON PGMST blocks, Control-M can incorporate the results of all
previous runs and restarts, filtering them for jobs restarted with the RESTART,
RECAPTURE CONDITION, and ABEND CODES parameters. Control-M/Restart
searches previous runs to determine which steps must be considered part of the
restarted job.

For example, if one step finished successfully during its original run and another step
finished successfully after a restart, the ON block check for the successful finish for
both steps produces a TRUE result and the ON statement is satisfied.

Activation of this facility requires that the ALLRUNS parameter in the CTRPARM
member be set to YES. When activated, this facility can apply to any specified step,
step range, or to the ON PGMST step value +EVERY. §Restart§

NOTE
Post-processing of ON PGMST statements during a RESTART or RERUN is independent of
the post-processing of the same ON PGMST statements during the earlier run. In these
situations, you may get duplicate actions.

Chapter 3 Job Production Parameters 555

ON PGMST: Post–Processing Parameter

Step Values

PGMST

Within an ON PGMST statement, the specified step is generally a program step,

specified in the PGMST field. It may be a program executed directly within the job
stream, in which case no PROCST value is specified, or it may be a program executed
by a called procedure, in which case the called procedure is specified in PROCST.

If the JCL contains nested procedures, the name of the EXEC procedure statement
that invokes the most deeply nested procedure, that is, the procedure that
immediately invokes the PGM step, must be specified in PROCST.

The same step name can appear in different ON PGMST statements in the same ON
PGMST block, or in different ON PGMST blocks.

STEP RANGE

To check codes in a range of steps, first define the step range and assign it a name in
the STEP RANGE statement, which is described in “STEP RANGE: Post–Processing
Parameter” on page 652. Then specify the name, preceded by an asterisk, in the
PGMST field. The * indicates that the specified name is a range name, not a step
name. The range of steps is displayed, and you can check the codes that are displayed
within the defined range.

If the LASTSTEP parameter is set to Y in the CTMPARM member, Control-M treats

the job step named $LAST as the job step executed last, and the job step named
$FIRST as the job step executed first.

If Control-M adds a Control-M/Restart step to a job, for example, if a job is restarted

by Control-M/Restart, or if PREVENT NCT2 is specified in the job scheduling
definition, the Control-M/Restart step is processed like all other job steps.

Control-M does not treat the Control-M/Restart step or any FLUSHED step as the
step executed last or first.

Example 1

In the STEP RANGE statement, name DF2 is assigned to the range of program steps
STEP20 through STEP29A.

If *DF2 is specified in ON PGMST, the ON step and code criteria is satisfied if any of
the codes result from any of the steps in the range STEP20 through STEP29A.

556 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

Example 2

You want to define a job in such a way that its status depends on the result of the last
step executed. If the last step ended with a condition code of 0, give the job the status
ENDED OK. If the last step ended with any other condition code, the job status is to
be ENDED NOTOK.

The following are sample ON PGMST statements for such a job:

ON PGMST ANYSTEP PROCST CODES C**** U**** S*** A/O

DO OK
ON PGMST $LAST PROCST CODES >C0000 U**** S*** A/O
DO NOTOK

Step Name: ANYSTEP

You can specify ANYSTEP as the value in the PGMST field. In general, it indicates
that the DO statements must be performed if the specified codes are found in any
steps.

However, if ANYSTEP is specified with codes OK, NOTOK, EXERR, JLOST, JNRUN,
JSECU, JNSUB or *UKNW, the ON criteria are satisfied only if the entire job ends
with the specified code criteria.

If ANYSTEP is specified with code FORCE, no other codes can be specified in the
same ON block, and the PROCST parameter must be left blank. For a description of
code FORCE, see “Valid CODES Values” on page 560.

Step Name: +EVERY

The value +EVERY is used without being accompanied by limiting step values when
the code criteria must be satisfied for every step. The following examples all have the
same impact – the code criteria must be satisfied for every step in the job without
exception.

NOTE
A DO OK or DO NOTOK statement is ignored if it is specified in an ON PGMST +EVERY
statement.

Chapter 3 Job Production Parameters 557

ON PGMST: Post–Processing Parameter

Examples

■ ON PGMST +EVERY PROCST

■ ON PGMST ANYSTEP PROCST +EVERY

The ANYSTEP value is not a limiting value. In this case, it has the same meaning as
+EVERY.

■ ON PGMST +EVERY PROCST +EVERY

Value +EVERY is generally accompanied by a limiting step value when the code
criteria must be satisfied for every step within the specified limits, as follows:

■ If the limiting value is a PROCST value, the code criteria must be satisfied by all job
steps from within the specified procedure.

Example

— ON PGMST +EVERY PROCST STEP1

Every program step of procedure step STEP1 must be satisfied.

■ If the limiting value is a PGMST value, the code criteria must be satisfied by all
executions of the specified job step (or range of steps if a range is specified), from
within the job steam and within all procedures.

Examples

— ON PGMST StepA PROCST +EVERY

All executions of job step STEPA from within the job stream and within every
procedure must be satisfied.

— ON PGMST *Range1 PROCST +EVERY

Executions of all job steps in Range1, from within the job stream and within every
procedure, must be satisfied.

Step name +EVERY can be specified with the following codes: Cnnnn, Sxxx,
Unnnn, *xxxx, FLUSH, SNRUN and *****.

558 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

■ When step name +EVERY is specified with codes Cnnnn, Sxxx, Unnnn and *xxxx,
the following conditions must be satisfied to satisfy the ON statement:

— If the steps that run (excluding FLUSH steps) satisfy the PGMST and PROCST
criteria, they must also not contradict the Cnnnn, Sxxx, Unnnn or *xxxx codes.

— At least one step runs and fulfills the above conditions.

■ When step name +EVERY is specified with codes FLUSH, SNRUN or *****, the
following apply:

— ON PGMST +EVERY CODES FLUSH is satisfied if in each job step, a JCL

COND or JCL IF/THEN/ELSE statement caused the step not to run.

— ON PGMST +EVERY CODES SNRUN is satisfied if each job step did not run.

— ON PGMST +EVERY CODES ***** is satisfied if each defined job step ran and no
job step was flushed (that is, due to a JCL COND or JCL IF/THEN/ELSE
statement).

CODES Values
CODES can be condition codes, user abend codes, system abend codes, various end
codes and statuses, and certain keywords. They can also be prefaced by certain
qualifiers. All of these are described below.

A maximum of 245 values can be specified for CODES in any ON PGMST statement,
as follows:

■ Each line of an ON PGMST statement contains fields for specification of up to four

values for CODES.

■ Whenever a fourth value is specified on a line for CODES, and Enter is pressed, a
new line within the same ON PGMST statement is opened, allowing specification
of as many as four additional CODES values.

Chapter 3 Job Production Parameters 559

ON PGMST: Post–Processing Parameter

Valid CODES Values

NOTE
A DO OK statement specified in the job scheduling definitions is ignored if:

■ any of the following status codes apply to the job:

— EXERR
— JNSUB
— *REC0
— *UKNW

-or-

■ the DO OK statement was specified as part of an ON PGMSTEP ANYSTEP pgmstep CODE

NOTOK condition, because if that condition is satisfied, the status of the job has already
been set to NOTOK

Table 199 ON PGMST Parameter CODES Values (part 1 of 3)

Value Description
$EJ Job was queued for re-execution.
***** Any step that executes (including steps with JCL errors and steps
returned with an ABEND code). For reasons of backward
compatibility, the CODES value ***** does not include steps with
code FLUSH or SNRUN (described below). The CODES value *****
does, however, include jobs not submitted and jobs whose sysout
was lost if ON PGMST ANYSTEP is specified.
Note: Although the CODES value **** includes steps which have
returned any system abend code, the preferred method of indicating
these steps is S***.
*NCT2 A NOT CATLGD 2 or NOT RECATLGD 2 event occurred in the job
step. The default result of this event is a NOTOK status for the step.
A message containing the data set name is written to the IOA Log
file.
Note: If you do not want to be alerted to NOT RECATLGD 2 events,
see your INCONTROL administrator.
*REC0 Rerun (recovery) is needed, but no more reruns are available.
Note: This status code is REC followed by a zero (not the letter O).
*TERM Job terminated by CMEM due to an NCT2 event.
*UKNW An unknown error occurred, usually as a result of a computer crash
during job execution. This value can only be specified with step
value ANYSTEP.
*xxxx Any step completion code (condition, system abend, user abend)
that matches the string, where x can be any hexadecimal character
(0 through 9, A through F) in user-defined events, which are turned
on by Exit 3. Regarding usage, see your INCONTROL administrator.
Cnnnn Step condition code, where nnnn is a 4-digit value.

560 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

Table 199 ON PGMST Parameter CODES Values (part 2 of 3)

Value Description
EXERR Any type of execution error. It is the same as NOTOK, but is
triggered only if the job has actually started executing. This value
can only be specified with step value ANYSTEP.
FLUSH A JCL COND or JCL IF/THEN/ELSE statement caused a step to not
run. This CODES value is described in more detail below.
FORCE This code applies when a job is FORCEd OK from the Active
Environment screen (Screen 3). To specify a code of FORCE, all of
the following must apply:

■ No other code can be specified in the same statement.

■ The PGMST value must be ANYSTEP.
■ No PROCST value can be specified.
■ No other ON statements can appear in the ON PGMST block.

Valid DO statements for the FORCE code are:

■ DO SHOUT
■ DO COND
■ DO FORCEJOB
■ DO SETVAR
■ DO MAIL
JFAIL Job failed due to JCL error.
JLOST Job sysout was lost. This value can be specified only with step value
ANYSTEP.
JNRUN Job was canceled during execution or re-execution. This value can be
specified only with step value ANYSTEP.
JNSUB Job not submitted. Submission of a job or initiation of a started task
failed for any reason. This value can be specified only with step
value ANYSTEP.
JSECU Job failed due to security requirements (only under ACF2). This
value can be specified only with step value ANYSTEP.
NOTOK A status of execution of the whole job.

This CODES value can only be specified with step value ANYSTEP.
It indicates that at least one PGM step, or the whole job, finished
executing NOTOK, meaning, with a condition code greater than that
set as the upper limit. By default, this limiting condition code is
C0004, but the MAXCCOK parameter in the CTMPARM member in
the IOA PARM library can be used to set the default condition code
to another value, such as C0000.

This CODES value covers all types of failures, including

non-execution errors such as job not run, JCL error, or job not
submitted.

Chapter 3 Job Production Parameters 561

ON PGMST: Post–Processing Parameter

Table 199 ON PGMST Parameter CODES Values (part 3 of 3)

Value Description
OK A status of execution of the whole job.

This CODES value can only be specified with step value ANYSTEP.
It indicates that all non-flushed PGM steps finished executing OK,
meaning, with a condition code equal to or less than the condition
code set as the upper limit. By default, this limiting condition code is
C0004, but the MAXCCOK parameter in the CTMPARM member in
the IOA PARM library can be used to set the default condition code
to another value, such as C0000.

If a job is FORCEd OK, the DO statements following an ON PGMST

ANYSTEP pgmstep CODES OK statement are processed only if the
FRCOKOPT parameter in the CTMPARM member in the IOA
PARM library is set to Y (Yes).
SNRUN A step did not run. This CODES value is described in more detail
below.
Sxxx Step system abend code, where xxx is a 3-character hex value.
Unnnn Step user abend code, where nnnn is a 4-digit value.

FLUSH
The CODES value FLUSH generally applies when a step does not run but no error is
indicated. This CODES value is assigned in the following cases:

■ A JCL COND or JCL IF/THEN/ELSE statement caused the step not to run.
Control-M detects CODES value FLUSH steps by message IEF272I (Step was not
executed).

■ §Restart§ If a job was restarted by Control-M/Restart, and Control-M is to

consider all job runs during post-processing (the ALLRUNS parameter is set to
YES in the CTRPARM member), a step is defined as FLUSH if:

— either the step did not previously run, or Control-M/Restart did not recapture a
completion or abend code from a previous run

and either

— it was not executed during the RESTART run because of a JCL COND or JCL
IF/THEN/ELSE statement

or

— it was not executed due to a RESTART decision (message CTR103I)

562 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

Because a CODES value of FLUSH does not indicate that an error occurred during job
execution, assignment of this status does not cause a job status of NOTOK.

If a JCL statement other than the COND or IF/THEN/ELSE statement caused the
step not to run, it is not defined as a FLUSH step.

If the failure of a step causes subsequent steps not to be executed, these subsequent
steps are not defined as FLUSH steps.

For reasons of backward compatibility, that is, to ensure that the application of
CODES value ***** remains unchanged, CODES value ***** does not include FLUSH
steps.

SNRUN
A step is defined as CODES value SNRUN if it did not run. This code includes

■ any step with a CODES value of FLUSH

■ any step that does not appear in the job

■ instances where a step does not run because of a JCL error in a prior step (the step
with the JCL error does not have a status of SNRUN)

■ §Restart§ if a job was restarted by Control-M/Restart, and Control-M is to

consider all job runs during post-processing (the ALLRUNS parameter is set to
YES in the CTRPARM member), a step is defined as SNRUN if one of the following
conditions are satisfied:

— The step did not previously run, or Control-M/Restart did not recapture a
completion or abend code from a previous run.

— The step was not executed during the RESTART run.

SNRUN cannot be specified together with ANYSTEP. Because SNRUN includes steps
that do not exist in a job, and ANYSTEP includes all step names even if they do not
exist in a job, specifying both in the same job causes a condition that SNRUN cannot
process.

A status of SNRUN does not indicate that an error occurred during a job execution,
nor does it cause a job status of NOTOK. It merely indicates that it did not run.

For reasons of backward compatibility, that is, to ensure that the application of
CODES value ***** remains unchanged, CODES value ***** does not include SNRUN
steps.

Chapter 3 Job Production Parameters 563

ON PGMST: Post–Processing Parameter

Code Qualifiers and Relationships

Any character in a condition code, system abend code or user abend code may be
replaced by an asterisk (*). An asterisk means “any value” for the character it
replaces. For example, if S*13 is specified, the code criteria for the step is satisfied by
codes S013, S613, S913, and so on.

The qualifiers described in Table 200 can be used in certain cases.

Table 200 ON PGMST Parameter Code Qualifiers

Qualifier Description
> Greater than. Valid as a qualifier for condition codes and user abend
codes.
< Less than. Valid as a qualifier for condition codes and user abend
codes.
N Specifies not to perform the accompanying DO statements if the
specified code exists in the step. Valid as a qualifier for condition
codes, user abend codes and system abend codes.

NOTE
The N qualifier indicates that the DO statements must not be performed if the specified
condition exists. It does not indicate that the DO statements must be performed if the specified
condition does not exist.

The relationship between multiple codes in an ON PGMST statement is OR, that is,
the appearance of any of the codes in the specified step satisfies the ON criteria,
except for range specifications such as >C0010 or <C0040.

However, code criteria qualified by N take precedence over all other code criteria. If a
code that is specified with an N qualifier is generated by the specified step,
accompanying DO actions are not performed even if other ON code criteria are
satisfied.

Examples
■ If >C0008 NC0020 is specified, the codes criteria is satisfied (and the DO statements
performed) by the appearance of any condition code greater than 8 except
condition code 20.

■ If the following are specified:

>U0999 NU1341 S*** NS*37 <C0004

564 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

The DO actions are triggered by one of the following:

— a condition code less than C0004

— a user abend code greater than U0999 except U1341
— any system abend code except Sx37 (that is, except S037, S137, and so on)

■ If only code NC0008 is specified:

The accompanying DO statements are never performed. The specified value only
indicates when not to perform the DO actions. There is no indication when the DO
actions are to be performed.

Example 1

Any program step resulting in condition code C0008 or C0016 is considered OK.

Figure 254 ON PGMST Parameter – Example 1

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST UPDA CODES C0008 C0016 A/O
DO OK
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.16.03

Chapter 3 Job Production Parameters 565

ON PGMST: Post–Processing Parameter

Example 2

When procedure step UPDA in program step STEP08 finishes executing with a
condition code less than C0008, it is considered OK.

Figure 255 ON PGMST Parameter – Example 2

JOB: PRDKPL02 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST STEP08 PROCST UPDA CODES <C0008 A/O
DO OK
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< ====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.16.03

566 Control-M for z/OS User Guide

 ON PGMST: Post–Processing Parameter

Example 3

When any program step in the step range DF2 (STEP20 – STEP29A) finishes executing
with any system or user abend code, except U2030, rerun the job, and shout the
indicated message to TSO logon ID P43.

Figure 256 ON PGMST Parameter – Example 3

JOB: PRDKPL03 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST *DF2 PROCST CODES S*** U**** NU2030 A/O
DO RERUN
DO SHOUT TO TSO-P43 URGENCY R
= JOB PRDKPL03 ABENDED; THE JOB IS RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.16.03

Chapter 3 Job Production Parameters 567

ON SYSOUT: Post–Processing Parameter

ON SYSOUT: Post–Processing Parameter

Search for a string in the sysout of the job, and perform the actions in the
accompanying DO statements if the string is found.

Figure 257 ON SYSOUT Parameter

Optional. Multiple ON SYSOUT parameters can be defined. Upon specifying an ON

SYSOUT value and pressing Enter, a new ON SYSOUT statement, followed by a
blank DO statement, is opened. Valid values are shown in Table 201.

Table 201 ON SYSOUT Values (part 1 of 2)

Value Description
string Mandatory if ON SYSOUT is used. The string to search for. This
string may not consist of more than 40 alphanumeric characters. If
you want this string to contain blanks, enclose the blanks, or the
phrase containing the blanks, within single or double quotation
marks.

In addition:

■ * – Use this character as a mask to match any string.

■ &*– Use this to indicate an asterisk within a string where the

asterisk is not a mask character.

■ ? – Use this character as a mask to match any single character.

■ &?– Use this to indicate a question mark within a string where

the question mark is not a mask character.
FROM The column in the SYSDATA files where the search must start. Valid
values are from 1 through 132.

568 Control-M for z/OS User Guide

 ON SYSOUT: Post–Processing Parameter

Table 201 ON SYSOUT Values (part 2 of 2)

Value Description
TO The column in the SYSDATA files where the search must end. Valid
values are from 1 through 132.
Note: BMC Software recommends the use of the FROM and TO parameters, if possible, to
narrow the area searched and thereby make the search more efficient.
A/O Optional. Boolean And/Or indicator. Valid values are:

■ A (And) – indicates AND logic between the two ON SYSOUT

statements
ON SYSOUT block criteria are satisfied only if both ON SYSOUT
statements are satisfied.

■ O (Or) – indicates OR logic between the two ON SYSOUT

statements
ON SYSOUT block criteria are satisfied if either (or both) ON
SYSOUT statements are satisfied.

If you specify A or O, an empty ON SYSOUT line is displayed.

Two or more ON SYSOUT statements connected by a Boolean

indicator constitute an ON SYSOUT block.

The first DO statement is displayed after the last line of the ON

SYSOUT block.

General Information
The ON SYSOUT parameter enables you to specify DO statements that are to be
performed if the SYSDATA of the job contains a specified string. For this purpose, the
SYSDATA of the job means the data contained in the following sysout files:

■ JESMSGLG
■ JESJCL
■ JESYSMSG

If you know the location of the string, you can set values for the FROM and TO
subparameters in order to restrict the search to a limited number of columns. This
results in a more efficient search.

For a more advanced search, you can use the mask characters * and ? as described in
Table 201.

Each ON SYSOUT line is checked against each line of the SYSDATA until a match is
found or the end of the SYSDATA is reached. Each ON SYSOUT line is assigned a
value of TRUE or FALSE.

Chapter 3 Job Production Parameters 569

ON SYSOUT: Post–Processing Parameter

Once the specified string is found, the following occurs:

■ If there is only one ON SYSOUT line

— Searching for that string ends.

— The DO statement is performed.

■ If an ON SYSOUT block has been specified, Control-M

— checks and assigns a value of TRUE or FALSE to each line

— checks the value of the entire block to determine if it is TRUE or FALSE

If the result of that check is TRUE, the associated DO statements are performed.

Example 1

ON SYSOUT IEF206I*STEP3 FROM 001 TO 050 A/O

DO FORCEJOB

Control-M searches from Column 1 through Column 50 in each line for any string
beginning IEF206I and ending STEP3.

Example 2

ON SYSOUT IEF206I*&*STEP3 FROM 001 TO 050 A/O

DO FORCEJOB

Control-M searches from Column 1 through Column 50 in each line for any string
beginning IEF206I and ending *STEP3.

Example 3

ON SYSOUT 'IEF206I STEP3' FROM 001 TO 050 A/O

DO FORCEJOB

The string IEF206I STEP3 contains a blank space, but is enclosed within quotation
marks. Control-M searches for the string from Column 1 through Column 50 in each
line.

570 Control-M for z/OS User Guide

 OUT: Post–Processing Parameter

OUT: Post–Processing Parameter

Add or delete prerequisite conditions when the job ends OK.

NOTE
OUT and DO COND statements are similar. If you are familiar with one of them, you can
easily use the other. However, familiarize yourself with the differences outlined below in
“Differences between OUT and DO COND” on page 575.

Figure 258 OUT Parameter Format

Optional. A maximum of two prerequisite conditions can be specified in an OUT line.

One prerequisite condition can be specified in each long OUT line. When you specify
the second prerequisite condition in a standard OUT line, or one prerequisite
condition in a long OUT line, and press Enter, a new OUT line is opened for
specifying additional prerequisite conditions. For more information, see “Specifying
Long OUT Condition Names” on page 574.

Each specified prerequisite condition consists of the mandatory subparameters

described in Table 202.

Table 202 OUT Mandatory Subparameters (part 1 of 2)

Subparameter Description
cond_name User-supplied descriptive name of 1 through 39 characters used to
identify the condition.
Note: A condition name must not begin with the symbols “|”, “¬”,
or “\”, and must not contain parentheses (), because each of these
characters has a special meaning.
You can use an AutoEdit variable in a condition name, provided that
the AutoEdit variable has a value that is known before the job is
ordered.

Chapter 3 Job Production Parameters 571

OUT: Post–Processing Parameter

Table 202 OUT Mandatory Subparameters (part 2 of 2)

Subparameter Description
dateref 4-character date reference. Valid values are:

■ date – Specific date (in either mmdd or ddmm format, depending

on the site standard).

■ ODAT – Resolves to the original scheduling date. Default.

■ +nnn – Resolves at job order time to ODATE+nnn calendar days.

nnn is three digits (000-999).

■ -nnn – Resolves at job order time to ODATE-nnn calendar days.

nnn is three digits (000-999).
Note: +001 and -001 are not necessarily the same as NEXT and
PREV, because NEXT and PREV are based on job scheduling criteria,
while +nnn and -nnn are based on calendar days.
■ PREV – Resolves to the previous date on which the job ought to
have been scheduled, according to its basic scheduling criteria
(or ODATE–1 for a forced job).

■ NEXT – Resolves to the next date on which the job is scheduled

according to its basic scheduling criteria (or ODATE+1 for a
forced job).

■ STAT – Static. Indicates that the condition, such as IMS-ACTIVE,

is not date-dependent.
Note: Before STAT was introduced, date 0101 was recommended
to be used in conditions that were not date-dependent. Unlike
0101, STAT is not a date, and it operates differently. Always use
STAT when defining conditions that are not date-dependent.
■ **** – Any scheduling date. Valid only when opt is set to – .

■ $$$$ – Any scheduling date. Valid only with opt is set to – .

If a date reference is not specified, value ODAT is automatically

inserted when you press Enter.
opt Indicates whether to add or delete the specified prerequisite
condition. Valid values are:

■ + (Plus) – Add (create) the prerequisite condition

■ - (Minus) – Delete the prerequisite condition

572 Control-M for z/OS User Guide

 OUT: Post–Processing Parameter

General Information
If the job ends OK, the prerequisite conditions are added to or deleted from the IOA
Conditions file according to the value set for opt.

Prerequisite conditions are usually used to establish job dependencies or to ensure

manual intervention when required:

■ To establish job dependency, define a prerequisite condition in an OUT or DO

COND statement in the job that must run first, and in an IN statement in the job
that must run afterwards.

The job containing a prerequisite condition in an IN statement is not submitted

unless that prerequisite condition has been added manually or by a job containing
the OUT or DO COND statement.

— An OUT statement is used to add the prerequisite condition if the job ends OK.

— The DO COND statement is used to add the prerequisite condition if the step
and code event criteria specified in the accompanying ON statement are
satisfied.

■ If the IN condition can only be satisfied by manual intervention, for example, if

TAPE1-ARRIVED is set by the operator after an external tape has arrived on-site,
performance of the required manual intervention before job submission can be
ensured.

OUT and DO COND statements can also be used to delete prerequisite conditions.
The OUT statement of the job can be used to delete a prerequisite condition after the
job ends OK. A DO COND statement can be used to delete prerequisite conditions if
the accompanying ON step and code criteria are satisfied.

These statements are generally used to delete prerequisite conditions either to

prevent a particular job from running or when the condition is no longer needed by
any other jobs in the Active Jobs file.

DO COND functions are performed after the functions of the OUT parameter:

■ If a prerequisite condition is added by the OUT parameter and deleted by the DO

COND parameter, the combined effect is the deletion of the prerequisite condition.

■ If a prerequisite condition is deleted by the OUT parameter and added by the DO

COND parameter, the combined effect is the addition of that prerequisite
condition.

Chapter 3 Job Production Parameters 573

OUT: Post–Processing Parameter

The following are examples of prerequisite conditions:

■ IMS-ACTIVE
■ JOB_PAYCALC_ENDED_OK
■ TAPE1_LOADED

All prerequisite conditions are associated with a date reference that is used to
distinguish between different runs of the same job with different scheduling dates. If,
for example, a condition is being deleted, only the condition matching the specified
date is deleted. The same condition from a different date is not deleted.

Prerequisite conditions created by the OUT parameter can trigger the execution of
other jobs or processes.

Prerequisite conditions deleted by the OUT parameter can prevent the scheduling of
jobs and processes that require those prerequisite conditions in their IN parameter.

For more information regarding prerequisite conditions, see “IN: Runtime

Scheduling Parameter” on page 507, “ON Statements: Post–Processing Parameter” on
page 546, and “DO COND: Post–Processing Parameter” on page 442, and see
“Prerequisite Conditions” on page 72

Specifying Long OUT Condition Names

Regular prerequisite conditions are not more than 20 characters in length. If you want
to specify a longer condition name, up to 39 characters in length, enter the string
LONG in the date reference field of an empty OUT condition line. An (L) appears at
the beginning of the line. If the field already contains data, entering the string LONG
will open a new long OUT condition line, with (L) appearing at the beginning of the
line. You can now insert a long condition name, as illustrated in Figure 259.

Specify SHRT in the date reference field to revert back to condition names of standard
length.

NOTE
Long condition names cannot be used in CMEM rule definitions.

574 Control-M for z/OS User Guide

 OUT: Post–Processing Parameter

Figure 259 Long OUT Condition

JOB: IEFBR14 LIB CTMP.V610.SCHEDULE TABLE: PHILL1
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
IN CTMLDNRS-NMIS-OK ODAT CTMLDNRS-NMIS-OK1 ODAT
CTMLDNRS-NMIS-OK2 ODAT
CONTROL CECI-ZEBRA-CONT E
RESOURCE INITOS 0002
PIPE
FROM TIME 0800 + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY *1 SAC CONFIRM N
TIME ZONE:
============================================================================
OUT CTMLDNRS-NMIS-OK ODAT - CTMLDNRS-NMIS-OK1 ODAT -
(L) THIS-LINE-CONTAINS-A-LONG-OUT-CONDITION-XXXX ODAT -

AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS

RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES **** A/O
DO COND
DO
ON PGMST ANYSTEP PROCST CODES **** A/O
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.49.13

OUT Conditions for SMART Table Entities

Prerequisite conditions that are specified for SMART Table Entities in OUT
statements and/or in ON TABLE-END DO COND statements enable you to establish
dependencies between tables and other jobs.

When all jobs in a SMART table are ended or deleted, prerequisite conditions are
added to or deleted from the IOA Conditions file according to the OUT statements
and/or ON TABLE-END DO COND statements in the SMART Table Entity.

NOTE
A SMART Table Entity can be reassigned a status of ACTIVE after specified prerequisite
conditions have already been added or deleted. For example, if a job in the SMART Table was
deleted while in WAIT SCHEDULE status and was then undeleted after the prerequisite
conditions were added or deleted, the SMART Table Entity returns to ACTIVE status.

Differences between OUT and DO COND

OUT and DO COND statements are similar but have the following differences:

■ An OUT statement is applied only if the job ends OK. DO COND statements are
associated with ON statements and are applied only if the associated ON step and
code criteria are satisfied.

Chapter 3 Job Production Parameters 575

OUT: Post–Processing Parameter

■ An OUT statement appears in each job scheduling definition. No DO COND

statement appears unless specified. To specify a DO COND statement, type COND
in an empty DO field and press Enter.

■ DO COND statements are processed after OUT statements and can therefore
override OUT statements.

Examples

Example 1

This example consists of two jobs (screens):

SACALC01 – Calculates salaries

SARPT001 – Generates the Salary Statistics report

The report must be generated after the salaries have been successfully calculated.

Job SACALC01 runs first.

Figure 260 OUT Parameter Example 1 – First Job

JOB: SACALC01 LIB CTM.PROD.SCHEDULE TABLE: SALARY
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
CTB STEP AT NAME TYPE
DOCMEM SACALC01 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS 01,15 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT SALARY-OK ODAT +
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

When job SACALC01 ends OK, the prerequisite condition SALARY-OK is added.
This triggered the execution of job SARPT001 that requires the condition in order to
run.

576 Control-M for z/OS User Guide

 OUT: Post–Processing Parameter

Job SARPT001 is not run unless job SACALC01 ended OK.

Figure 261 OUT Parameter Example 1 – Second Job

JOB: SARPT001 LIB CTM.PROD.SCHEDULE TABLE: SALARY
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
SET VAR
CTB STEP AT NAME TYPE
DOCMEM SARPT001 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS 01,15 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN SALARY-OK ODAT
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

The report (job SARPT001) is produced twice a month for the 1st and for the 15th. The
report of the 15th is produced only if the prerequisite condition of the 15th,
SALARY-OK, exists. The existence of the prerequisite condition of the 1st,
SALARY-OK, does not cause submission of the report of the 15th (job SARPT001).

The jobs on the 1st, SACALC01 and SARPT001 (report), do not have to run on the 1st
of the month. Suppose the salary job (SACALC01) finishes executing (OK) on the 3rd,
the prerequisite condition SALARY-OK for the 1st is added, because the prerequisite
condition is schedule date dependent.

Example 2

Some jobs (such as IMSBDUPD) must run only when the IMS is active
(IMS-ACTIVE):

MEMNAME IMSDBUPD
DAYS 1,15
IN IMS-ACTIVE STAT

Chapter 3 Job Production Parameters 577

OUT: Post–Processing Parameter

The prerequisite condition IMS-ACTIVE is “generic,” and it only exists when IMS is
active. IMS itself is monitored by Control-M. When IMS is brought down
successfully, Control-M deletes the prerequisite condition IMS-ACTIVE for all
schedule dates. This prevents the abending of jobs that depend on IMS, such as job
IMSDBUPD in the above example. Job IMSDBUPD is not submitted if the
prerequisite condition IMS-ACTIVE does not exist.

Figure 262 OUT Parameter – Example 2

JOB: IMSPROD LIB CTM.PROD.SCHEDULE TABLE: IMSPROD
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
CTB STEP AT NAME TYPE
DOCMEM IMSPROD DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 99 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN DEPOSITS PREV
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT IMS-ACTIVE **** -
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Example 3

A group of jobs runs every day of the week except Saturday and Sunday. Several of
the different jobs for the different days must not run in parallel, and job sequence
must be maintained even in case of delay.

578 Control-M for z/OS User Guide

 OUT: Post–Processing Parameter

Figure 263 OUT Parameter – Example 3

JOB: EBDUPDT2 LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
OVERLIB STAT CAL
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDUPDT2 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS 2,3,4,5,6 WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 08 D-CAT
MINIMUM PDS
===========================================================================
IN DEPOSITS PREV
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
===========================================================================
OUT DEPOSITS ODAT +
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

The job is submitted only if the prerequisite condition DEPOSITS of the previous
schedule date exists. If the job finishes OK, the prerequisite condition DEPOSITS of
the same schedule date is added. This, in turn, triggers the next job in the sequence.

Example 4

The following example serves as a further explanation of the schedule date reference
concept:

MEMNAME EBDUPDT2
MEMLIB EBD.PROD.JOB
DAYS 1,15,20
MONTHS 1- N 2- N 3- N 4- N 5- N 6- N 7- Y 8- N 9- Y 10- N 11- Y 12- N
OUT EBD-INPUT-READY **** -

Today is September 15. The date reference values resolved in this job are in mmdd
date format:

■ ODAT – 0915
■ PREV – 0901
■ NEXT – 0920
■ **** – Any date reference

Chapter 3 Job Production Parameters 579

OVERLIB: General Job Parameter

OVERLIB: General Job Parameter

Name of a JCL library that can override the library specification in the MEMLIB
parameter, which is discussed on page 532.

Figure 264 OVERLIB Parameter Format

Optional. Valid values are:

■ a valid data set name of 1 through 44 characters. AutoEdit variables can be

specified.

■ the reserved value DUMMY (for dummy jobs).

General Information
The OVERLIB parameter enables submission of a modified copy of the actual JCL of
the job, without changes to either the regular JCL (in the MEMLIB library) or the job
scheduling definition.

The library containing the regular JCL member of the job is specified in the MEMLIB
parameter. When temporary changes are desired, the JCL member can be copied to
the library specified in the OVERLIB field and modified as needed.

NOTE
When copying the regular JCL member to the OVERLIB library, do not change the member
name. Control-M always looks for a JCL member whose name matches the MEMNAME
value.

If the MEMNAME member is found in the OVERLIB JCL library, that member is
used. Otherwise, the member is taken from the MEMLIB library.

580 Control-M for z/OS User Guide

 OVERLIB: General Job Parameter

When the job is scheduled, the OVERLIB field is scanned. If it is not empty,
Control-M resolves AutoEdit variables in the field, if any are specified, and then
searches the OVERLIB library for the member specified in field MEMNAME.

The override can be canceled by deleting the MEMNAME member from the
OVERLIB library. If the MEMNAME member is not found in the OVERLIB library,
the member is taken from the MEMLIB library. Alternatively, the override can be
canceled by deleting the OVERLIB specification from the job scheduling definition.

NOTE
OVERLIB cannot be specified for a started task.

The library can be any cataloged, standard partitioned data set, LIBRARIAN or
PANVALET. The record length must be 80.

GENERAL or USER=name, which are valid MEMLIB values, cannot be specified in

field OVERLIB.

The library and the member do not have to exist when the OVERLIB parameter is
defined. Their existence is checked by Control-M before actual submission of the job.

If, during the access to a library by Control-M (before submission) the library is held
exclusively by another user (such as TSO user, job), the monitor re-tries to access the
library every few seconds until the library is released and the job can be submitted.

Use of the library name DUMMY is intended for scheduling events (for example,
adding a prerequisite condition without actually running the job). If the library name
DUMMY is used, the job is not submitted (submission and sysout checking is
skipped). The job is assumed to have ended OK; ON PGMST...DO processing is not
performed. All Post-processing parameters associated with an ENDED OK status are
activated (OUT, SHOUT WHEN OK, and so on).

Three optional functions that were performed by the CTMX015C and CTMX015O
exits in previous versions are now incorporated into the Control-M monitor. These
functions are controlled by the following installation parameters:

■ COPMEM2O – Copy the JCL member from the MEMLIB library to the OVERLIB
library if the job ended NOTOK.

■ DELOVRER – Delete the JCL member from the OVERLIB library if the rerun of the
job ended OK.

■ DELOVRUN – Delete the JCL member from the OVERLIB library if any run of the
job ended OK

Chapter 3 Job Production Parameters 581

OVERLIB: General Job Parameter

For a description of these parameters, see the chapter that discusses customizing
INCONTROL products in the INCONTROL for z/OS Installation Guide.

Editing A Member through The J (JCL) Option

NOTE
You can only perform this function in an ISPF environment.

When specifying option J (JCL) in the Job List screen or the Active Environment
screen to edit the JCL member, Control-M must determine which library (MEMLIB or
OVERLIB) to use.

The algorithm for this decision depends on:

■ where the member exists, that is, whether it is only in the MEMLIB library, only in
the OVERLIB library, in both libraries, or in neither library)

■ what CTMIMACx REXX EXECs (if any) are defined

■ from which screen the J (JCL) option was requested

Table 203 indicates which libraries are used, depending on the above criteria.

Table 203 OVERLIB Parameter: Algorithm for LIbraries Used when Option J (JCL) is Specified
(part 1 of 2)
...the member exists in ...and the screen of the J (JCL)
When the following either library MEMLIB, request is: ... and the edit is
CTMIMAC is defined OVERLIB, both, or Job List, Active Environment, or performed in the
(if any)... neither either screen following library
None (default) MEMLIB only Either screen MEMLIB
OVERLIB only Either screen OVERLIB
Both Either screen OVERLIB
Neither Either screen MEMLIB

582 Control-M for z/OS User Guide

 OVERLIB: General Job Parameter

Table 203 OVERLIB Parameter: Algorithm for LIbraries Used when Option J (JCL) is Specified
(part 2 of 2)
...the member exists in ...and the screen of the J (JCL)
When the following either library MEMLIB, request is: ... and the edit is
CTMIMAC is defined OVERLIB, both, or Job List, Active Environment, or performed in the
(if any)... neither either screen following library
CTMIMAC1 MEMLIB only Job List MEMLIB
Active Environment OVERLIB (copied
from MEMLIB)
OVERLIB only Job List MEMLIB (open
empty member)
Active Environment OVERLIB
Both Job List MEMLIB
Active Environment OVERLIB (not
copied)
Neither Job List MEMLIB
Active Environment OVERLIB
CTMIMAC2 MEMLIB only Either screen MEMLIB
OVERLIB only Either screen OVERLIB
Both Either screen OVERLIB
Neither Either screen OVERLIB
CTMIMAC3 MEMLIB only Job List MEMLIB
(But saved only if
changed)
Active Environment OVERLIB
OVERLIB only Job List MEMLIB (open
empty member)
Active Environment OVERLIB
Both Job List MEMLIB
Active Environment OVERLIB
Neither Job List MEMLIB
Active Environment OVERLIB

Note the following points:

■ When using CTMIMAC1 or CTMIMAC2, more than four libraries cannot be

concatenated.

Chapter 3 Job Production Parameters 583

OVERLIB: General Job Parameter

■ When using CTMIMAC3, Exit CTMX014G, in the IOA SAMPEXIT library, is

required if libraries are concatenated.

For concatenated libraries, if the &COPYMEM parameter in Exit CTMX014G is set

to YES, the saved member is placed in the first library of concatenation. If the
&COPYMEM parameter is set to NO, the saved member is placed back in the
original JCL library.

■ The CTMIMACx REXX EXECs can be found in the IOA CLIST library. Instructions
for installing these REXX EXECs can be found in comments in the members
themselves.

■ PANVALET and LIBRARIAN considerations when performing online JCL edits:

— For PANVALET or LIBRARIAN support, sample exits CTMX014P or

CTMX014L, respectively, must be installed. However, Control-M does not
support both products simultaneously.

— When both MEMLIB and OVERLIB exist, and MEMLIB is either PANVALET or
LIBRARIAN, the edit function first copies the member to the OVERLIB before
performing the edit, unless the member already exists in the OVERLIB.

— IF only MEMLIB exists, and it is LIBARIAN, the edit is performed directly in

MEMLIB.

— If the MEMLIB library is PANVALET, editing can only be performed if a non-

PANVALET OVERLIB is defined.

584 Control-M for z/OS User Guide

 OVERLIB: General Job Parameter

Example
If a special, modified version of BACKPL02 JCL is required, it is defined in
CTM.OVER.JOBLIB. This JCL is used instead of the JCL in CTM.PROD.JOBLIB.

Figure 265 OVERLIB Parameter Example

JOB: BACKPL02 LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME BACKPL02 MEMLIB CTM.PROD.JOBLIB
OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL APPL-L GROUP BKP-PROD-L
DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
OVERLIB CTM.OVER.JOBLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM BACKPL02 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL WORKDAYS SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN START-DAILY-BACKUP ODAT
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 585

OWNER: General Job Parameter

OWNER: General Job Parameter

User who requests Control-M services.

Figure 266 OWNER Parameter Format

Mandatory. OWNER must be 1 through 8 characters.

General Information
The OWNER parameter is used by the internal security mechanism of Control-M to
determine which operations each user is authorized to perform and which
information each user is authorized to access. For example, access to options and
information on the Active Environment screen can be limited by the OWNER
parameter.

The OWNER parameter can also facilitate selection and handling of production jobs.

The OWNER parameter is passed to external security products, such as RACF, ACF2
and TOP SECRET. Certain security products require that the owner name not exceed
seven characters.

Default OWNER is dependent on the online environment of the site (CICS, TSO, and
so on). For TSO and TSO/ISPF environments, the TSO user ID is the default. For
non-TSO environments, such as CICS, the default is the terminal ID.

586 Control-M for z/OS User Guide

 OWNER: General Job Parameter

Example
Job OPERCOMP belongs to owner SYS1.

Figure 267 OWNER Parameter Example

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME OPERCOMP MEMLIB GENERAL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL OPER GROUP MAINTENANCE
DESC JOB RUN ON THE 1ST OF THE MONTH
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
===========================================================================
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Chapter 3 Job Production Parameters 587

PDS: Basic Scheduling Parameter

PDS: Basic Scheduling Parameter

Partitioned data set (library) that must be checked for the minimum number of
required free tracks. That number is specified in the MINIMUM parameter, which is
described on page 540.

Figure 268 PDS Parameter Format

Optional; however, if MINIMUM is specified, PDS is mandatory. The PDS parameter

specifies a data set name of 1 through 44 characters.

The PDS parameter cannot be used with any of the following parameters: DAYS,
WDAYS, MONTHS, CONFCAL, RETRO and DATES.

General Information
The data set must be cataloged, and it must be a partitioned data set.

The MINIMUM and PDS parameters are always used together and are never used
with other Basic Scheduling parameters.

The PDS parameter identifies a library. The MINIMUM parameter specifies the
minimum number of free tracks required by that library.

These parameters are intended for use (that is, definition) in jobs or started tasks that
compress, clean and/or enlarge libraries, or which issue a warning message to the
IOA Log file, that is, if the TASKTYPE parameter is set to WRN.

If the MINIMUM and PDS parameters are defined for a job, the scheduling of the job
is not related to or dependent upon any date criteria. Instead, the job is scheduled if
the actual number of free tracks available in the specified library is below the
specified minimum when the New Day procedure is run. The job or started task can
then compress, clean, or enlarge the library, or issue the appropriate warning.

588 Control-M for z/OS User Guide

 PDS: Basic Scheduling Parameter

NOTE
The PDS parameter does not work with PDSE-type libraries because they always appear to be
100 percent full.

Example
Check the SYS1.LINKLIB library for a minimum of 20 unused tracks.

Figure 269 PDS Parameter Example

JOB: MSG001 LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME MSG001 MEMLIB GENERAL
OWNER SYS1 TASKTYPE WRN PREVENT-NCT2 DFLT N
APPL OPER GROUP OPER-MAINT
DESC INDICATE COMPRESS IS NEEDED FOR SYS1.LINKLIB
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM MSG001 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- 2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12-
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM 020 PDS SYS1.LINKLIB
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

The MSG001 member in the Control-M GENERAL JCL library contains a warning
message to compress the library.

Chapter 3 Job Production Parameters 589

PIPE: General Job Parameter

PIPE: General Job Parameter

Indicates a data set to be replaced by a pipe with the same name. Displayed only if
MAINVIEW Batch Optimizer (MVBO) is installed.

Figure 270 PIPE Parameter Format

Optional. Valid value is a valid data set name (1 through 44 characters).

Each time a data set or pipe name is specified and Enter is pressed, a new empty line
is displayed to allow specification of an additional data set or pipe name.

General Information
Pipes are storage buffers that are used to replace data sets. Pipes are defined in, and
used by, MVBO/Job Optimizer Pipes to replace sequential processing with parallel
processing.

For example, normally, that is, without pipes, if JOB1 writes to data set DS1 and then
JOB2 reads data set DS1, JOB2 waits until JOB1 is terminated before reading the data
set. However, if a pipe is used to replace data set DS1, then as JOB1 writes data to
pipe DS1, JOB2 can use the data without waiting for termination of JOB1.

Each pipe and its relevant parameters are defined in a MBVO/Job Optimizer Pipes
rule. Each pipe must be defined with the same name as the data set it is replacing.

When a job is to use a pipe instead of a data set, the name of the data set or pipe must
be specified in the PIPE parameter of the Control-M job scheduling definition for the
job.

For more information about Pipe processing, see “Job-Related Considerations for
Pipes” on page 835

590 Control-M for z/OS User Guide

 PIPE: General Job Parameter

Example
This example consists of two job scheduling definitions.

In job CTLIVPWR and job CTLIVPRD, data set CTL.IVP.FILE is replaced by a pipe
with the same name. Jobs such as CTLIVPWR below and CTLIVPRD on page 592 are
called a “Collection” because they are pipe participants of the same pipe.

Figure 271 PIPE Parameter Example – Job CTLIVPWR

JOB: CTLIVPWR LIB CTMT.PROD.SCHEDULE TABLE: CTLIVP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME CTLIVPWR MEMLIB CTM.IVP.JCL
OWNER E02A TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL GROUP
DESC MAINVIEW BATCH OPTIMIZER VERIFICATION - WRITER JOB
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM CTLIVPWR DOCLIB CTMT.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT.
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN CTLIVPWR-IN ODAT
CONTROL
RESOURCE
PIPE CTL.IVP.FILE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:

Chapter 3 Job Production Parameters 591

PIPE: General Job Parameter

Figure 272 PIPE Parameter Example – Job CTLIVPRD

JOB: CTLIVPRD LIB CTMT.PROD.SCHEDULE TABLE: CTLIVP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME CTLIVPRD MEMLIB CTM.IVP.JCL
OWNER E02A TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL GROUP
DESC MVBO VERIFICATION - READER JOB
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM CTLIVPRD DOCLIB CTMT.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN CTLIVPWR-OUT ODAT
CONTROL
RESOURCE
PIPE CTL.IVP.FILE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 13.22.07

592 Control-M for z/OS User Guide

 §Restart§PREVENT-NCT2:General Job Parameter

§Restart§PREVENT-NCT2:General Job
Parameter
Performs data set cleanup before the original job run.

Figure 273 §Restart§ PREVENT-NCT2 Parameter Format

Optional. PREVENT-NCT2 consists of the subparameters described in Table 204.

Table 204 §Restart§ PREVENT-NCT2 Subparameters

Subparameter Description
PREVENT-NCT2 Whether, and how, to perform data set cleanup before the original
run of the job. Optional. Valid values are:

■ Y (Yes) – Perform data set cleanup before the original job run;
this value is not valid for started tasks

■ N (No) – Do not perform data set cleanup before the original job
run

■ F (Flush) – Halt processing of the job if any data set cleanup error
is detected, even if MVS would not have stopped processing the
job

■ L (List) – Do not perform data set cleanup before the original job
run; but generate the messages that would be required for GDG
adjustment during restart
DFLT Protected field indicating the PREVENT-NCT2 default value for the
site. The default is set in parameter NCAT2 in the CTRPARM
member in the IOA PARM library. A value specified in the
PREVENT-NCT2 parameter overrides the site default.

Chapter 3 Job Production Parameters 593

§Restart§PREVENT-NCT2:General Job Parameter

General Information
If a job tries to create a data set that already exists, the job may fail with a
DUPLICATE DATASET ON VOLUME error. If a job tries to create a data set whose
name is already cataloged, the job may fail with an error message that indicates a
reason of NOT CATLGD for reason code 2; the Control-M/Restart term PREVENT-
NCT2 is derived from this error situation.

These problems can be avoided by performing data set cleanup. During data set
cleanup, Control-M/Restart does the following:

■ Deletes and uncatalogs the old data sets. This prevents DUPLICATE DATSET ON
VOLUME and NOT CATLGD 2 errors.

■ Performs Generation Dataset (GDG) Adjustment, which is described in the

Control-M/Restart User Guide

Control-M/Restart automatically performs data set cleanup prior to restarts and

reruns. However, it may be desirable to perform data set cleanup before the original
job run, because data sets accessed by the job can have file-related errors that were
generated by an entirely different job.

When data set cleanup is performed as part of the original job request, it is called
PREVENT-NCT2 processing.

The site-defined default in NCAT2 in the CTRPARM member determines whether

data set cleanup is to be performed before the original job run. The value of this site-
defined default is displayed in protected field DFLT.

The PREVENT-NCT2 parameter can be used to override this default to determine

what data set cleanup instructions are provided to the original job run. Possible
values, and their effects, are described below:

■ When value Y is specified:

Control-M/Restart performs data set cleanup before the original job run. It deletes
and uncatalogs all data sets that can cause NCT2 and duplicate data set errors
during execution, and performs GDG adjustment if necessary.

■ When value F is specified:

If a file catalog error is detected, processing is halted, even if normal MVS

processing would not handle the problems as a fatal error, and an appropriate
error message is generated.

594 Control-M for z/OS User Guide

 §Restart§PREVENT-NCT2:General Job Parameter

■ When value L is specified:

Data set cleanup is not performed for the original run, but messages that would be
required for GDG adjustment during restart are generated. Without these
messages, GDG adjustment might not be properly performed during restart. In
addition to the GDG adjustment messages, the same messages that are generated
during simulation of data set cleanup are also generated.

NOTE
If you would normally specify N, meaning Control-M/Restart processing is not desired for
the original run, but the JCL requires GDG processing, it is recommended that you specify
value L instead of value N.

■ When value N is specified:

No special action is taken by Control-M/Restart. Data set cleanup is not

performed.

If a value of Y, F, or L is specified, that is, if some kind of special NCT2 processing is

desired, a CONTROLR step is automatically added as a first step of the submitted job.

The PREVENT NCT2 parameter has no impact on restarts, because

Control-M/Restart automatically performs data set cleanup prior to restarts.

NOTE
When PREVENT-NCT2 is active for a job, it is possible to automatically collect certain
statistical information on the job. For more details, see the AUTOXREF parameter in the
INCONTROL for z/OS Installation Guide.

Chapter 3 Job Production Parameters 595

§Restart§PREVENT-NCT2:General Job Parameter

Example
Prevent NOT CATLGD 2 errors for job PRDKPL01.

Figure 274 §Restart§ PREVENT-NCT2 Parameter Example

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
APPL KPL GROUP PROD-KPL
DESC DAILY PRODUCTION - START OF APPL-PROD-KPL
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN START-DAILY-PROD-KPL ODAT
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

596 Control-M for z/OS User Guide

 PRIORITY: Runtime Scheduling Parameter

PRIORITY: Runtime Scheduling Parameter

Internal Control-M job priority.

Figure 275 PRIORITY Parameter Format

Optional. The PRIORITY parameter indicates a 1 to 2 character alphanumeric

priority. An asterisk (discussed later) may also be specified.

The default is blank, which is the lowest priority.

General Information
Priority helps determine the order in which jobs in the Active Jobs file are processed
by Control-M.

Priority is determined in ascending order where: blank < A < Z < 0 < 9 < *

In general, the job with the highest priority code executes first if all its other runtime
scheduling requirements are satisfied.

When not all runtime requirements for a high priority job are satisfied, for example,
where a job requires two tape drives but only one is available, a job with a lower
priority whose other runtime requirements are satisfied may be run earlier.

This, however, is not always desirable. A job may be so important that lower priority
jobs must not be submitted until the important job has executed.

Such a job is called a critical path job. Critical path priority can be indicated by
prefixing the priority with an asterisk (*).

Chapter 3 Job Production Parameters 597

PRIORITY: Runtime Scheduling Parameter

A priority prefixed by an asterisk, such as priority *5, indicates that Control-M must
submit the job before submitting any regular (non-*) priority jobs, such as priority 10,
and before submitting any critical path jobs of lower priority, such as priority *3, even
if the resources required for those other jobs are available.

Critical path priority is applied only after all the IN conditions for the job exist.

NOTE
Critical path priority applies to contention for Quantitative resources and for Control
resources required in exclusive state. Critical path priority does not apply to contention for
Control resources required in shared state.

Examples

Example 1

The priority level of job EBDIN001 is 07, and it requires three tapes. The priority level
of job EBDIN002 is 02, and it requires only one tape:

MEMNAME EBDIN001
RESOURCE TAPE 0003
PRIORITY 07
MEMNAME EBDIN002
RESOURCE TAPE 0001
PRIORITY 02

If only two tapes are available, job EBDIN002 is submitted.

Example 2

The priority level of job EBDUPDT is *5, and it requires two tapes. The priority level
of job EBDEXEC is 04, and it requires one tape:

MEMNAME EBDUPDT
RESOURCE TAPE 0002
PRIORITY *5
MEMNAME EBDEXEC
RESOURCE TAPE 0001
PRIORITY 04

If one tape is available, neither job is submitted. When two tapes become available,
job EBDUPDT is submitted.

598 Control-M for z/OS User Guide

 PRIORITY: Runtime Scheduling Parameter

Example 3

The priority level of job EBDBKP is *8, and it requires three tapes. The priority level of
job EBDMAINT is *7, and it requires one tape:

MEMNAME EBDBKP
RESOURCE TAPE 0003
PRIORITY *8
MEMNAME EBDMAINT
RESOURCE TAPE 0001
PRIORITY *7

If one tape is available, neither job is submitted. When three tapes become available,
job EBDBKP is submitted.

Chapter 3 Job Production Parameters 599

RELATIONSHIP: Basic Scheduling Parameter

RELATIONSHIP: Basic Scheduling Parameter

Indicates the relationship (AND/OR) between rule-based calendar criteria and the
basic scheduling criteria of the job, that is, whether either set of criteria, or both sets of
criteria, are to be satisfied. This parameter appears in job scheduling definitions in
Group tables only.

Figure 276 RELATIONSHIP Parameter Format

SCHEDULE RBC
RELATONSHIP (AND/OR)
DAYS DCAL

Optional. Valid values are described in Table 205.

Table 205 RELATIONSHIP Parameter Values

Value Description
O (Or) If either set of criteria (a rule-based calendar or the basic
scheduling criteria of the job) are satisfied, the job is scheduled.
Default.
A (And) Both a rule-based calendar and the basic scheduling criteria of the
job must be satisfied.

General Information
For jobs, two types of basic scheduling criteria can be specified:

Table 206 RELATIONSHIP Parameter Scheduling Types

Type Description
Schedule RBCs Rule-based calendars used as sets of table criteria (that is, basic
scheduling criteria defined for the table in the SMART Table Entity
or IOA Calendar Facility).
Basic scheduling Basic scheduling criteria defined in, and belonging to, the job
scheduling definition. They are not connected to table criteria.

In some cases, it may be required that both sets of criteria be satisfied. In other cases,
satisfaction of either set of criteria is sufficient for job scheduling. This parameter
allows specification of the required combination:

■ When either set of criteria is sufficient, specify value O (OR relationship).

■ When both sets of criteria are required, specify value A (AND relationship).

600 Control-M for z/OS User Guide

 RELATIONSHIP: Basic Scheduling Parameter

If an AND relationship is specified when no schedule rule-based calendars are

defined in the job, the job is never scheduled.

For more information, see Figure 141 on page 390.

Example
Create a table of employee hours each payday and on the last day of the year.

Figure 277 RELATIONSHIP Parameter Example

JOB: TABHOURS LIB CTM.PROD.SCHEDULE TABLE: ACCOUNTS
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME TABHOURS MEMLIB CTM.PROD.JCL
OWNER N04B TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL GROUP ACCOUNT_GROUP
DESC TABULATE EMPLOYEE HOURS
OVERLIB STAT CAL
SET VAR
CTB STEP AT NAME TYPE
DOCMEM TABHOURS DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC PAYDAYS
SCHEDULE RBC
RELATIONSHIP (AND/OR) O
DAYS 31 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- N 2- N 3- N 4- N 5- N 6- N 7- N 8- N 9- N 10- N 11- N 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
MINIMUM PDS
===========================================================================
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 18.36.07

Chapter 3 Job Production Parameters 601

RERUNMEM: Post–Processing Parameter

RERUNMEM: Post–Processing Parameter

Name of the JCL member to use when the job is automatically rerun. (Called RERUN
– RERUNMEM prior to version 6.0.00.)

Figure 278 RERUNMEM Parameter Format

Optional. The RERUNMEM parameter identifies a valid member name of 1 through 8

characters.

General Information
Although the RERUNMEM parameter can be used to specify the name of a JCL
member to use for automatic rerun, note the following points:

■ The DO FORCEJOB parameter provides a more flexible alternative to the

RERUNMEM parameter.

■ Control-M/Restart users can use the DO IFRERUN parameter to restart the failed
job instead of using RERUNMEM to rerun the job.

The automatic rerun process works as follows:

■ The Control-M monitor determines that automatic rerun is possible only if the job
ENDS NOTOK and a specified DO RERUN statement is activated during
post-processing. If the monitor determines that automatic rerun is possible, it sets
the status of the job to ENDED NOTOK – RERUN NEEDED.

602 Control-M for z/OS User Guide

 RERUNMEM: Post–Processing Parameter

■ The monitor then checks the value of MAXRERUN in the Active environment. If
the value is zero, or no MAXRERUN value was specified, automatic rerun is not
possible and the job is not submitted for rerun. If the value is greater than zero,
rerun is possible, and the monitor submits the job for rerun when all runtime
criteria are satisfied. Runtime criteria include not only the Runtime Scheduling
parameters, but also the INTERVAL parameter, which specifies the minimum
allowable interval between runs of the same job.

■ The JCL for the rerun job is taken from the member specified in the RERUNMEM
parameter. If no RERUNMEM value is specified, the JCL for the rerun is taken
from the regular JCL member of the job specified in the MEMNAME parameter.

Rules applying to the MEMNAME parameter also apply to the RERUN parameter.

The member name can be the same as, or different from, the job name.

The member specified in RERUNMEM must be in the library specified in the

MEMLIB parameter.

The RERUNMEM parameter overrides the MEMNAME value in the JCL, and the
MEMNAME value becomes irrelevant for reruns.

The RERUNMEM parameter cannot be specified for cyclic jobs and cyclic started
tasks.

The RERUNMEM parameter cannot be specified if a DO IFRERUN statement is

specified.

Chapter 3 Job Production Parameters 603

RERUNMEM: Post–Processing Parameter

Example
If job EF145TS abends during step name COLLECT, try to run another job from the
member EF145TSR that continues from the same place.

Figure 279 RERUNMEM Parameter Example

JOB: EF145TS LIB CTM.PROD.SCHEDULE TABLE: EFPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN 2 RERUNMEM EF145TSR INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST COLLECT PROCST CODES S*** U**** A/O
DO RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

604 Control-M for z/OS User Guide

 RESOURCE: Runtime Scheduling Parameter

RESOURCE: Runtime Scheduling Parameter

Quantitative resources and their quantities required by the job.

Figure 280 RESOURCE Parameter Format

Optional. A maximum of two Quantitative resources can be specified in each

RESOURCE line. Upon specifying the second Quantitative resource in a line and
pressing Enter, a new line is opened, for specifying additional Quantitative resources.

Each specified Quantitative resource consists of the mandatory subparameters

described in Table 207 and may include the optional parameters described in
Table 209.

Table 207 Mandatory RESOURCE Subparameters

Subparameter Description
res_name User-supplied, descriptive name of 1 through 20 characters to
identify the Quantitative resource.
quantity Quantity of the Quantitative resource required by the job. The
specified value must be four digits (leading zeros must be specified).

Table 208 Optional RESOURCE Subparameters (part 1 of 2)

Subparameter Description
onOk Whether to keep the Quantitative resource tied to the job if the job
ends OK. Valid values are:

■ ' ' (blank) – release the resource

The resource is not kept, and is returned to the total quantity
available for other jobs. Default.

■ D – discard the resource

The resource is not reusable. The quantity of the resource is
permanently removed from the total quantity available for other
jobs.

Chapter 3 Job Production Parameters 605

RESOURCE: Runtime Scheduling Parameter

Table 208 Optional RESOURCE Subparameters (part 2 of 2)

Subparameter Description
onFail Whether the Quantitative resource remains allocated to the job if the
job ends NOTOK. Valid values are:

■ ' ' (blank) – release the resource

The resource does not remain allocated to the job. Default.

■ K – keep the resource

The resource remains allocated to the job until one of the
following occurs:
— the job is rerun and ends OK
— the job is deleted
— the job is FORCEd OK

Example

TAPE 2 D K

Assume that the total number of TAPE resources is 5.

If the job ends OK, the total number of TAPE resources stays at 3, since 2 TAPE
resources are permanently discarded.

If the job is rerun, and there are enough TAPE resources, Control-M allocates a
quantity of 2 TAPE resources for the job. The total number of TAPE resources is then
reduced to 1.

If the job ends NOTOK, the total number of TAPE resources stays at 5, but the
available number of resources will be 3. The job keeps the 2 TAPE resources.

If the job is rerun, Control-M reallocates a quantity of 2 TAPE resources for the job.
The total number of TAPE resources stays at 5, and the available number of resources
stays at 3.

General Information
Quantitative resource specification can be used to prevent resource contention.

Quantitative resources, such as tape drives, CPU, and access rates to the spool, and
their maximum available quantities are defined for the site in the IOA
Conditions/Resources screen (Screen 4).

606 Control-M for z/OS User Guide

 RESOURCE: Runtime Scheduling Parameter

NOTE
If the AUTOTAPE parameter in the CTMPARM member in the IOA PARM library is set to Y,
any tape drive value defined in the RESOURCE parameter is ignored. Instead, a value
determined by the Automatic Tape Adjustment facility is used. For more information, see
“Tape Device Usage Statistics” on page 248, and the description of using the Automatic Tape
Adjustment facility in the INCONTROL for z/OS Administrator Guide.

To remove selected Quantitative resources from job scheduling definitions, use the
CTMTBUPD utility described in the INCONTROL for z/OS Utilities Guide.

Examples

TAPE 12
CPU 80
WORK-SPACE 3000

To eliminate bottlenecks and maximize throughput, a site can quantify processing

power and assign it a resource name, such as CPU or LPU (logical processing units).
The more powerful the CPU, the greater the maximum quantity that can be assigned
to it.

The RESOURCE parameter is used to specify the quantity of a resource required by

the job.

Before a job is submitted, Control-M verifies that the required quantities of resources,
defined through RESOURCE statements, are available, that is, that they are not in use
by another job:

■ If they are available, Control-M allocates them to the job, and they become
unavailable to other jobs until they are freed.

■ If the resources required by the job are unavailable, the job is not submitted.

Resource Allocation in Multi-CPU Environments

In multi-CPU environments, several resource allocation possibilities exist.

One possibility is to operate as if there is one large CPU and resource pool. In this
case, no logical differentiation between CPUs is made, and the Control-M monitor
assigns resources, including CPU processing power, from the total resources
available.

Another possibility is to differentiate between CPUs and optionally to logically

associate quantities of resources with specific CPUs.

This is generally achieved through the use of common identifiers, such as a suffix.

Chapter 3 Job Production Parameters 607

RESOURCE: Runtime Scheduling Parameter

For example, suppose a site has three CPUs of differing processing capability. The
following representative resources and quantities might be defined in the IOA
Resources file:

CPU-A 50
CPU-B 75
CPU-C 100

In this example, it might also be desired to logically categorize other resources

according to CPU. For example, if 12 tape drives are available, the following
resources and quantities might also be defined in the IOA Resources file:

TAPE-A 3
TAPE-B 4
TAPE-C 5

If this kind of differentiation is used, different resources in the job scheduling

definition can be specified with different suffixes, and the job still runs. For example,
a quantity of CPU-A can be specified along with a quantity of TAPE-B.

Rather than specifying a particular identifier when requesting a resource, resources

can be requested generically by specifying a $ in place of the identifier, for example
CPU-$ or TAPE-$. The $ indicates to Control-M that it must select a specific resource,
that is, a resource with an identifier, to replace the generic resource, that is, the
resource with the $.

NOTE
If you use the $ to request generic resources, the $ must appear at the end of the resource
name.

If a $ is specified for all required resource identifiers, the Control-M monitor does not
assign the resources unless it can assign all resources with the same identifier, for
example, all resources with identifier A or all resources with identifier B.

When using the generic $ identifier, you can use one of the following methods to
ensure a specific CPU is used for processing the job:

■ Use JCL AutoEdit System variable %%$SIGN to extract the CPU identifier
assigned by the Control-M monitor and then to assign the job to that same CPU.
System variable %%$SIGN is discussed in Chapter 5, “JCL and AutoEdit Facility.”

■ Use Control-M submit Exit CTMX002.

Control-M Exit CTMX004 can also be used to help prevent bottlenecks caused by
resource contention.

608 Control-M for z/OS User Guide

 RESOURCE: Runtime Scheduling Parameter

For more information on Control-M exits CTMX002 and CTMX004, see the
INCONTROL for z/OS Administrator Guide.

Example 1A

There are 12 tape drives in the data center connected to a single computer. Two tape
drives must always remain free for emergencies. Therefore, only 10 drives can be
used for production. The defined available quantity is set as follows: TAPE 0010.

Any user (job) wanting to use tape drives must specify the number of tapes required
in the job parameters.

Figure 281 RESOURCE Parameter – Example 1A

JOB: EBDINPUT LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDINPUT DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12-Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
RESOURCE TAPE 0002
PIPE CTM.PROD.PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Control-M checks if there are two tape drives available. If there are, the tape drives
are “given” to the job. The total number of free tapes is now eight. When the job
finishes executing, the tape drives are returned to the general pool.

Suppose that many jobs are using tapes, and the available quantity is only one. A job
that requires two tape drives must wait. The job is not submitted until the required
number of tapes are available.

An authorized person decides that only one tape unit is needed for emergencies and
adds one tape unit to the global quantity available for use. Now the maximum
number of tape drives is eleven, and the number of available tape drives is two. The
job is submitted.

Chapter 3 Job Production Parameters 609

RESOURCE: Runtime Scheduling Parameter

Example 1B

The data center discussed in the previous example is expanding. It now has two
computers and 20 tape drives. The tape drive distribution is:

■ CPU1 only – 8
■ CPU2 only – 8
■ Transferables – 6

Currently, CPU1 is connected to four transferable drives, one transferable drive is

connected to CPU2, and one transferable drive is out of order. The situation is
presented to Control-M as follows:

TAPE1 12
TAPE2 7

A job requests three tape drives, on any computer.

Figure 282 RESOURCE Parameter – Example 1B

JOB: EBDINPUT LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDINPUT DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12-Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
RESOURCE TAPE$ 0003
PIPE CTM.PROD.PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

The result is that the available quantity of either TAPE1 or TAPE2 is reduced by three.

The Control-M scheduling algorithm makes the optimal decision as to which of the
two computers to send the job. It is possible to intervene in this selection process. For
more information, see user Exit CTMX004 in the INCONTROL for z/OS Administrator
Guide.

610 Control-M for z/OS User Guide

 RESOURCE: Runtime Scheduling Parameter

Example 1C

A job requests three tape drives on CPU1.

Figure 283 RESOURCE Parameter – Example 1C

JOB: EBDINPUT LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDINPUT DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12-Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
RESOURCE TAPE1 0003
PIPE CTM.PROD.PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

The result is that the available quantity of the resource TAPE1 is reduced by three.

The tape drive that was out of order has been fixed. An operator makes it available
for use by jobs running on CPU2 by correcting the global available quantities to:

TAPE2 8

The shift manager decides to assign two tapes from CPU1 to CPU2. The new situation
as seen by Control-M:

TAPE1 10
TAPE2 10

Chapter 3 Job Production Parameters 611

RETENTION: # OF DAYS TO KEEP: Post–Processing Parameter

RETENTION: # OF DAYS TO KEEP: Post–

Processing Parameter
Number of days to retain the job in the History Jobs file.

NOTE
At sites that do not use the History Jobs file, this parameter is not relevant and is not
displayed.

Figure 284 RETENTION: # OF DAYS TO KEEP Parameter Format

Optional. Valid values are described in Table 209.

Table 209 RETENTION: # OF DAYS TO KEEP Parameter Values

Value Description
0 through 999 Retain the job for the specified number of days. Default: 0.
‘ ‘ (Blank) Retain the job according to the RETENTION: # OF GENERATIONS
TO KEEP parameter.

General Information
Jobs in the History Jobs file are easier to restore to the Active Jobs file, for example, for
restart, than jobs archived to CDAM. Therefore, it may be desirable to retain a job in
the History Jobs file for a period of time.

# OF DAYS TO KEEP enables specification of a fixed number of days to keep the job
in the History Jobs file. Once the specified number of days has been reached, the job is
automatically deleted from the History Jobs file during the next New Day processing.

612 Control-M for z/OS User Guide

 RETENTION: # OF DAYS TO KEEP: Post–Processing Parameter

# OF DAYS TO KEEP and # OF GENERATIONS TO KEEP are mutually exclusive. A

value can be specified for either, but not both.

NOTE
When changing job criteria from retention-days to retention-generation (or vice-versa),
previous job criteria are lost and are not acted upon.

For retention criteria to hold across job executions, the jobs must be identical in all respects.
For example, if a job is transferred to a different group, it is treated as a different job for
purposes of retention. In this case, retention values are reset, and retention is calculated from
the moment of transfer.

Example
Retain the archived job in the History Jobs file for 30 days.

Figure 285 RETENTION: # OF DAYS TO KEEP Parameter Example

JOB: PRDKPL02 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
RESOURCE
PIPE
TIME: FROM UNTIL PRIORITY DUE OUT SAC CONFIRM
TIME ZONE:
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
CODES
DO IFRERUN FROM $ABEND . TO . CONFIRM Y
DO RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 07.06.04

Chapter 3 Job Production Parameters 613

RETENTION: # OF GENERATIONS TO KEEP: Post–Processing Parameter

RETENTION: # OF GENERATIONS TO KEEP:

Post–Processing Parameter
Maximum number of generations of the job to keep in the History Jobs file.

NOTE
At sites that do not use the History Jobs file, this parameter is not relevant and is not
displayed.

Figure 286 RETENTION: # OF GENERATIONS TO KEEP Parameter Format

Optional. Valid values are described in Table 210.

Table 210 RETENTION: # OF GENERATIONS TO KEEP Values

Value Description
0 through 99 Retain the specified number of generations of the job.
‘ ‘ (Blank) Retain the job according to the RETENTION: # OF DAYS TO KEEP
parameter.

The default is 0.

General Information
Jobs in the History Jobs file are easier to restore to the Active Jobs file, for example, for
restart, than jobs archived to CDAM. Therefore, it may be desirable to retain several
of the most current generations of the job in the History Jobs file.

614 Control-M for z/OS User Guide

 RETENTION: # OF GENERATIONS TO KEEP: Post–Processing Parameter

# OF GENERATIONS TO KEEP enables specification of the number of generations of

the job to keep in the History Jobs file. Once the specified number of generations has
been reached, as a new generation is added to the History Jobs file, the earliest
remaining generation is deleted.

# OF DAYS TO KEEP and # OF GENERATIONS TO KEEP are mutually exclusive. A

value can be specified for either, but not both.

NOTE
When changing job criteria from retention-days to retention-generation, or vice versa,
previous job criteria are lost and are not acted upon.

For retention criteria to hold across job executions, the jobs must be identical in all respects.
For example, if a job is transferred to a different group, it is treated as a different job for
purposes of retention. In this case, retention values are reset, and retention is calculated from
the moment of transfer.

Example
Retain up to 10 generations of the archived job in the History Jobs file.

Figure 287 RETENTION: # OF GENERATIONS TO KEEP Parameter Example

JOB: PRDKPL02 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
RESOURCE
PIPE
TIME: FROM UNTIL PRIORITY DUE OUT SAC CONFIRM
TIME ZONE:
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP # OF GENERATIONS TO KEEP 10
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
CODES
DO IFRERUN FROM $ABEND . TO . CONFIRM Y
DO RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 07.6.04

Chapter 3 Job Production Parameters 615

RETRO: Basic Scheduling Parameter

RETRO: Basic Scheduling Parameter

Enables the job to be scheduled after its original scheduling date has passed.

WARNING
BMC does not recommend the use of the RETRO parameter, which is documented here for
backward compatibility reasons only. For workload scheduling after the original scheduling
date has passed, use enhanced Control-M Newday functionality. For more information, see
the INCONTROL for z/OS Administrator Guide, “Control-M,” “Special Newday Parameters.”

The RETRO=Y parameter should be removed from any job scheduling definitions.

Figure 288 RETRO Parameter Format

Optional. Valid values are described in Table 211.

Table 211 RETRO Values

Value Description
Y (Yes) Allow scheduling of the job after its original scheduling date has
passed
N (No) Do not allow scheduling of the job after its original scheduling date
has passed. Default.

General Information
The RETRO parameter is used to control situations where the computer has not been
working for a day or more due to holiday, hardware failure, and so on.

When such situations occur, it is necessary to instruct Control-M whether the job is to
be retroactively scheduled for the days when the computer (or Control-M) was
inactive.

616 Control-M for z/OS User Guide

 RETRO: Basic Scheduling Parameter

■ When Y is specified for the RETRO parameter, job orders are placed in the Active
Jobs file for all the days the job ought to have been originally scheduled.
Scheduling occurs from the last scheduling date to the current working date,
provided that those days were included in one of the Basic Scheduling parameters
(DAYS, DCAL, and so on). Each job order placed on the Active Jobs file is
associated with a different original scheduling date. For additional information see
“MAXWAIT: Basic Scheduling Parameter” on page 528.

■ When N is specified for the RETRO parameter, the job is scheduled only if the
current working date is a date on which the job is normally scheduled.

The RETRO parameter cannot be used with the MINIMUM and PDS parameters, nor
in group scheduled jobs; if specified in Group scheduled jobs, the parameter is
ignored.

Examples

Example 1

Schedule the job only on specified days of the month. If the date has passed, do not
schedule the job.

Figure 289 RETRO Parameter – Example 1

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL KPL GROUP PROD-KPL
DESC DAILY PRODUCTION - START OF APPL-PROD-KPL
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS 15,16,18,19,20 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Assume the computer was offline from the 16th up to and including the 18th, and the
15th was the last date that the job was scheduled for execution. Today is the 19th.
Therefore, the job is only scheduled for execution on the 19th.

Chapter 3 Job Production Parameters 617

RETRO: Basic Scheduling Parameter

Example 2

Schedule the job for all working days, even if the computer is not active:

DCAL WORKDAYS
RETRO Y

Assume the WORKDAYS calendar contains the dates 15, 16, 18, and 19, and the same
conditions as above exist. The job is scheduled three times with the original
scheduling dates: the 16th, the 18th and the 19th.

618 Control-M for z/OS User Guide

 SAC: Run Time Parameter

SAC: Run Time Parameter

This parameter is specifically designed for users who have converted from third-
party vendor job scheduling products. BMC Software does not recommend its use
otherwise. It enables all scheduled runs of the job to be shifted to their proper
scheduling days.

NOTE
Do not use the SAC parameter unless specifically required in conjunction with the conversion.
Check the Conversion Guide for your specific application.

A related parameter is discussed in “DESC: General Job Parameter” on page 438.

Figure 290 SAC Parameter Format

Optional. Valid values are shown in Table 212.

Table 212 SAC Parameter Values

Value Description
P (Previous) Changes the scheduling of the job to the previous day.
N (Next) Changes the scheduling of the job to the next day.
– (Group Previous) For jobs in Group tables only. Changes the scheduling of the job to
the previous day.
+ (Group Next) For jobs in a Group table only. Changes the scheduling of the job to
the next day.
‘ ‘ (Blank) No changes need be made. Default.

Chapter 3 Job Production Parameters 619

SAC: Run Time Parameter

General Information
Many scheduler products do not allow the site to define the time of the new working
day. Instead, those products fix the time, such as midnight. Control-M, however,
allows the site to define when the new working day starts.

In most cases, this added Control-M flexibility can be utilized without additional
adjustment. Occasionally, however, an adjustment to the job schedule may be
required due to the differences between the start of the working day. The SAC
parameter is used to perform such an adjustment.

For information on the correct usage of the SAC parameter, see the Conversion Guide
provided for your specific product.

NOTE
Unless you are certain that SAC must be used, and you are certain how to use it, leave this
parameter blank.

Example
Due to differences in the time of the start of the new working day, shift the
scheduling of the following converted job back to the previous day.

Figure 291 SAC Parameter Example

JOB: CAPRKL1 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
DOCMEM IEFBR14 DOCLIB CTMP.DOC
===========================================================================
DAYS ALL DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 04 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL MK-1 E
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC P CONFIRM
TIME ZONE:
===========================================================================
OUT COND1 ODAT + COND2 ODAT -
COND3 ODAT + COND4 ODAT -
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.24.05

620 Control-M for z/OS User Guide

 SCHEDULE RBC: Basic Scheduling Parameter

SCHEDULE RBC: Basic Scheduling Parameter

Identifies a set of scheduling criteria for table scheduling.

Mandatory for SMART Table Entities. Any alphanumeric value of 1 to 20 characters.

Optional for job scheduling definitions. Must be either a rule-based calendar value
defined in the SMART Table Entity or IOA Calendar Facility, or have the value *.

A related parameter is RELATIONSHIP, which is described on page 600.

Figure 292 SCHEDULE RBC Parameter Format

SCHEDULE RBC
RELATONSHIP (AND/OR)
DAYS DCAL

Upon specifying a rule-based calendar value and pressing Enter, a new SCHEDULE
RBC field is opened, for specifying additional schedule RBCs. In SMART Table
Entities, a new set of basic scheduling parameters is opened with the new
SCHEDULE RBC field to allow specification of criteria to be associated with the new
rule-based calendar.

General Information
A SMART Table Entity contains sets of basic scheduling criteria to be applied to job
scheduling definitions in the SMART Table. Each set of basic scheduling criteria in
the SMART Table Entity is assigned a unique label, specified in the SCHEDULE RBC
field, which is used for referencing that set of criteria.

There are two types of rule-based calendars:

■ Table Level RBC (TBL) - Rule-based calendars that are managed using the SMART
Table definition and are defined on the table level.

■ Control-M Level RBC (CTM)- Rule-based calendars that are defined from the
calendar manager in the Control-M/Desktop or IOA Calendar Facility. These
calendars are referred to by name, and are not included in scheduling definitions.

At least one rule-based calendar, with basic scheduling criteria, must be defined in
the SMART Table Entity.

To apply any sets of SMART Table Entity basic scheduling criteria to a job scheduling
definition, specify the rule-based calendar names of the desired criteria in the
SCHEDULE RBC fields in the job scheduling definition.

Chapter 3 Job Production Parameters 621

SCHEDULE RBC: Basic Scheduling Parameter

Any job may specify CTM Level RBCs however, only jobs that belong to SMART
tables may specify Table Level RBCs. All RBCs specified in jobs belonging to SMART
Tables should be defined in the corresponding SMART Table Entity.

If multiple SCHEDULE RBC values are specified in the job scheduling definition, the
calendars are checked sequentially during job scheduling to determine if the criteria
are satisfied. The SCHEDULE RBC set is satisfied, when at least one SCHEDULE RBC
in the set is satisfied.

An asterisk (*) can be specified as a SCHEDULE RBC value in the job scheduling
definition belonging to a SMART Table. When checks are performed for a rule-based
calendar with a value of *, the SMART Table Entity's rule-based calendars are
searched to determine which set of basic scheduling criteria are satisfied on the
particular day, and the chosen calendar is applied to the job.

Each job scheduling definition can have its own basic scheduling criteria defined,
independent of the rule-based calendar criteria in the SMART Table Entity.

Jobs in a SMART Table are checked for scheduling on a particular day only if at least
one set of basic scheduling criteria in the SMART Table Entity are satisfied.

If the SMART Table is eligible for scheduling on a particular day, a job in the table is
scheduled in any of the following cases:

■ The value in the RELATIONSHIP parameter is O (OR), and either the basic
scheduling criteria of the job or a set of its rule-based calendar criteria (or both) are
satisfied.

■ The value in the RELATIONSHIP parameter is A (AND), and its basic scheduling
criteria and a set of its rule-based calendar criteria are both satisfied.

When the name of a SCHEDULE RBC definition is modified or deleted, a

confirmation panel is displayed. If "Y" is entered, the changed or deleted name is
propagated throughout all of the table's job definitions, that is, all the corresponding
rule-based calendar references in the job definition are changed or deleted. If "N" is
entered, no changes are made.

622 Control-M for z/OS User Guide

 SCHEDULE RBC: Basic Scheduling Parameter

Examples

Example 1

For a SMART Table Entity:

The SMART Table Entity for SMART Table ACCOUNTS (group

ACCOUNTS_GROUP) contains the following four sets of basic scheduling
parameters for the rule-based calendars:

■ Defined in the SMART Table Entity:

■ ALL_DAYS with Level TBL

■ SUNDAYS with Level TBL

■ Defined by the IOA Calendar Facility:

■ WORKDAYS with Level CTM

■ FRIDAYS with Level CTM

Figure 293 SCHEDULE RBC Parameter – Example 1

TBL ACCOUNTS_GROUP CTM.PROD.SCHEDULE(TBL)
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
TABLE ACCOUNTS GROUP ACCOUNTS_GROUP
OWNER N04B
APPL
DESC
ADJUST CONDITIONS N TBL MAXWAIT
SET VAR
DOCMEM ACCOUNTS DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC ALL_DAYS LEVEL TBL
DAYS ALL DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
SCHEDULE RBC ACTIVE FROM UNTIL
===========================================================================
SCHEDULE RBC WORKDAYS LEVEL CTM
===========================================================================
SCHEDULE RBC FRIDAYS LEVEL CTM
===========================================================================
SCHEDULE RBC SUNDAYS LEVEL TBL
DAYS DCAL
AND/OR
WDAYS 01 WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
SCHEDULE RBC ACTIVE FROM UNTIL
===========================================================================
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 18.19.14

Chapter 3 Job Production Parameters 623

SCHEDULE RBC: Basic Scheduling Parameter

Example 2

For a job scheduling definition:

Schedule job TABHOURS when the basic scheduling criteria identified by rule-based
calendar ALL_DAYS in the SMART Table Entity (in Example 1A) are satisfied.

Figure 294 SCHEDULE RBC Parameter – Example 2

JOB: TABHOURS LIB CTM.PROD.SCHEDULE TABLE: ACCOUNTS
COMMAND ===> SCROLL===> CRSR
+---------------------------------------------------------------------------+
MEMNAME TABHOURS MEMLIB CTM.PROD.JCL
OWNER N04B TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL GROUP ACCOUNT_GROUP
DESC TABULATE EMPLOYEE HOURS
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM TABHOURS DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC ALL_DAYS
SCHEDULE RBC
RELATONSHIP (AND/OR) O
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
===========================================================================
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 18.36.07

624 Control-M for z/OS User Guide

 SCHEDULE RBC ACTIVE: Basic Scheduling Parameter

SCHEDULE RBC ACTIVE: Basic Scheduling

Parameter
Specifies the time limits (FROM, UNTIL) for using the rule-based calendar.

Figure 295 SCHEDULE RBC ACTIVE Parameter Format

DATES
CONFCAL SHIFT RETRO N MAXWAIT 00 D-CAT
SCHEDULE RBC ACTIVE FROM UNTIL

Optional. The parameter includes the subparameters described in Table 213.

Table 213 SCHEDULE RBC ACTIVE Subparameters

Subparameter Description
FROM 6-digit date. A job that refers to this rule-based calendar is only
ordered if the ordering date is later than the date specified.
Default: ‘ ‘ (Blank)
UNTIL 6-digit date. A job that refers to this rule-based calendar is only
ordered if the ordering date is earlier than the date specified.
Default: ‘ ‘ (Blank)

The format of either the FROM or UNTIL subparameters may be ddmmyy, mmddyy,
or yymmdd, depending on your local site standard, as set by the DATETYP
parameter in the IOAPARM member in the IOA PARM library.

General Information
The FROM and UNTIL dates together define a time frame for ordering jobs that have
a specific rule-based calendar that defines that calendar.

The following cases apply:

■ If you specify both the FROM and UNTIL subparameters for a particular rule-
based calendar, jobs that refer to that rule-based calendar can only be ordered on
or later than the date specified in the FROM subparameter, and on or earlier than
the date specified in the UNTIL subparameter. There are two possibilities:

1. The date specified in the FROM subparameter is earlier than that specified in the
UNTIL subparameter.

For example,

SCHEDULE RBC ACTIVE FROM 091001 UNTIL 011101

Chapter 3 Job Production Parameters 625

SCHEDULE RBC ACTIVE: Basic Scheduling Parameter

Jobs that refer to this rule-based calendar can only be ordered on or between
October 9, 2001 and November 1, 2001.

2. The date specified in the FROM subparameter is later than that specified in the
UNTIL subparameter.

For example,

SCHEDULE RBC ACTIVE FROM 090501 UNTIL 010401

Jobs that refer to this rule-based calendar can only be ordered on or after May 9,
2001, or before or on April 1, 2001, but not between those dates.

■ If you specify the FROM subparameter for a particular rule-based calendar, but not
the UNTIL subparameter, jobs that refer to that rule-based calendar cannot be
ordered before the date specified, but can be ordered on that date or any date later
than that date.

For example,

SCHEDULE RBC ACTIVE FROM 091001 UNTIL

Jobs that refer to this rule-based calendar can only be ordered on or after October 9,
2001.

■ If you do not specify the FROM subparameter for a particular rule-based calendar,
but specify the UNTIL subparameter, jobs that refer to the same rule-based
calendar cannot be ordered after the date specified, but can be ordered on that date
or any date earlier than that date.

For example,

SCHEDULE RBC ACTIVE FROM UNTIL 011101

Jobs that refer to this rule-based calendar can only be ordered before or on
November 1, 2001.

■ If you do not specify either the FROM or UNTIL subparameters, there is no

restriction on the date when jobs can be ordered.

For example,

SCHEDULE RBC ACTIVE FROM UNTIL

Jobs that refer to this rule-based calendar can be ordered on any date.

626 Control-M for z/OS User Guide

 SCHEDULE RBC ACTIVE: Basic Scheduling Parameter

■ If a job specifies more than one rule-based calendar and one of the rule-based
calendar definitions is such that the job can be ordered on a particular day, the job
is ordered even if it would not be ordered under the terms of another of its rule-
based calendar definitions.

For example, if within a SMART Table Entity one rule-based calendar is specified
as

SCHEDULE RBC ACTIVE FROM 091001 UNTIL 011101

and another rule-based calendar is specified as

SCHEDULE RBC ACTIVE FROM UNTIL

jobs that have both these rule-based calendars can be ordered on any date.

Example
Rule-based calendar A schedules jobs to run on the 5th of each month. Job B should
be scheduled according to the criteria of Rule-based calendar A; however, it should
only run until January 15, 2010.

In the SMART Table definition:

SCHEDULE RBC A
DAYS 05

In job definition B:

SCHEDULE RBC A
RELATIONSHIP (AND/OR) A
DAYS ALL
DEFINITION ACTIVE FROM UNTIL 100115

Chapter 3 Job Production Parameters 627

SCHENV: General Job Parameter

SCHENV: General Job Parameter

Name of the workload management scheduling environment that is to be associated
with the job.

Figure 296 SCHENV Parameter Format

SCHENV specifies a scheduling environment of 1 through 16 characters. Only

trailing blanks are allowed.

By default, the SCHENV parameter is optional.

General Information
If a value is specified for the SCHENV parameter, the JCL job statement is modified
by the addition of a statement in the following form:

// SCHENV=schedule_environment

If a value is specified for the SCHENV parameter, it will not override any scheduling
environment specified in the job statement unless the OVERJCLM parameter in the
CTMPARM library is set to Y.

If a value is specified for the SCHENV parameter, before job submission, Control-M
checks whether the specified WLM scheduling environment is available before
actually submitting the job. If the scheduling environment is not available, Control-M
places the job in WAIT SCHEDULE status and waits until the WLM scheduling
environment is available, before submitting the job.

If the task type is a started task, SCHENV is protected. If the task type is changed
from a job to a started task, SCHENV is erased and protected.

628 Control-M for z/OS User Guide

 SCHENV: General Job Parameter

Example
If the scheduling environment of job ACCT01 is to be SCHD2, specify the following:

DESC
OVERLIB STAT CAL
SCHENV SCHD2 SYSTEM ID NJE NODE

The job statement is modified as follows:

//ACCT01 JOB ,PROD1,CLASS=A,MSGCLASS=X,

// MSGLEVEL=(1,1),
// SCHENV=SCHD2

Chapter 3 Job Production Parameters 629

SET VAR: General Job Parameter

SET VAR: General Job Parameter

Assigns a value to an AutoEdit variable that can be used to set up the JCL of the job or
to define a Global variable in the IOA Global Variable Database.

NOTE
SET VAR and DO SET statements are similar, but not identical. The differences are outlined
below in “Differences between SET VAR and DO SET” on page 632.

Figure 297 SET VAR Parameter Format

Optional. Valid values must comply with the following requirements:

■ They must not contain blanks. If you want to specify an embedded blanks in a
SET VAR expression, use the %%BLANKn AutoEdit variable.

For example,

%%A=TODAY%%BLANK1%%.IS%%BLANK1%%.SUNDAY

resolves to

TODAY IS SUNDAY

For more information see “Non-Date System Variables” on page 760.

■ They must be specified in the format

%%variable=expression

630 Control-M for z/OS User Guide

 SET VAR: General Job Parameter

In this format:

— %%variable is a user-defined AutoEdit variable

— expression is any of the following components, provided it resolves to a single
value:
— a value (for example, 5)
— an AutoEdit System variable or previously defined user-defined variable, for
example, %%ODATE
— a compound expression that contains constants, AutoEdit variables, or
AutoEdit functions, or any combination of these, for example
%%$CALCDTE.%%BLANK.%%ODATE.%%BLANK%%.+5

WARNING
AutoEdit function %%SUBSTR should not be used in the expression portion of a
SET VAR variable definition. Doing so may cause errors when trying to resolve the
variable’s value.

General Information
A major advantage of using AutoEdit variables is that the JCL can be submitted with
different values for different executions without actually changing the JCL.

There are two types of AutoEdit variables:

■ System variables that are assigned values by the system

■ user-defined variables for which the user must supply values .
These variables can be either local or global.

One method of supplying a value for a user-defined variable is by defining the

variable and its value in a SET VAR statement. The value is assigned at time of job
submission.

At the time of job submission, AutoEdit variables in the JCL are resolved in sequence.
By default, if an AutoEdit variable cannot be resolved, the job is not submitted. This
default can be changed using an appropriate %%RESOLVE AutoEdit control
statement.

SET VAR statements can also be used to define and update Global Variables in the
IOA Global Variable Database. For more information on Global Variables, including
Global Variable syntax, see “Global Variables” on page 773.

As of version 6.0.00, SET VAR variables defined in a SMART Table Entity are
available to all the jobs in the SMART Table. However, they do not override SET VAR
variables defined in the job scheduling definition.

An unlimited number of SET VAR statements can be specified.

Chapter 3 Job Production Parameters 631

SET VAR: General Job Parameter

Upon filling in a SET VAR statement and pressing Enter, a new blank SET VAR
statement is displayed.

JCL Setup and the AutoEdit facility are described in depth in Chapter 5, “JCL and
AutoEdit Facility.”

Differences between SET VAR and DO SET

SET VAR and DO SET statements are similar but have the following differences:

■ Local variables in SET VAR statements are always applied before the job is
submitted. DO SET is a post-processing statement that can only be applied after its
accompanying ON step and code criteria are satisfied. This means that a local
value specified in the DO SET statement can only be applied in the next
submission of the job (that is, for cyclic and rerun or restarted jobs).

■ Global variables specified in a SET VAR statement are defined or updated in the
IOA Global Variable database before job submission. Global variables specified in
a DO SET statement are defined or updated in the IOA Global Variable database as
part of job post-processing.

■ A SET VAR statement appears in each job scheduling definition. A DO SET

statement does not appear unless specified. To specify a DO SET statement, type
SET in an empty DO field and press Enter.

■ In a SET VAR statement, the parameter value is specified after the keyword VAR.
In a DO SET statement, the parameter value is specified after the keyword VAR.

Examples

Example 1

In this example, AutoEdit statements in the job scheduling definition and the JCL
allocate space for the job. If the job abends due to insufficient space, the AutoEdit
statements adjust the allocated space and rerun or restart the job.

The following step in the JCL of the job sets the quantity of available space to five
units of whatever type (track or cylinder) is specified in the job scheduling definition.

//STEP10 EXEC PGM=MYPGM

//OUTFILE DD DSN=NEWFILE,DISP=(NEW,CATLG,DELETE),
// SPACE=(%%SPACE_TYPE,5),UNIT=SYSDA

The job scheduling definition contains the following SET VAR statement that sets the
space type to “track”:

632 Control-M for z/OS User Guide

 SET VAR: General Job Parameter

SET VAR %%SPACE_TYPE=TRK

In this case, the second line in the above DD statement resolves to:

// SPACE=(TRK,5),UNIT=SYSDA

The job scheduling definition also contains the following statements that are
activated if the job abends due of lack of space (code S*37). These statements change
the space type to “cylinder”, which provides enough space, and rerun the job. If
Control-M/Restart is active, the job is restarted from the abended step.

ON PGMST STEP10 CODES S*37

DO SET %%SPACE_TYPE = CYL
[DO IFRERUN FROM $ABEND] ===> If CONTROL-R is active
DO RERUN

If the job abends due to insufficient space, the second line of the earlier JCL
DD statement resolves to:

// SPACE=(CYL,5),UNIT=SYSDA

when the job is submitted for rerun (or restart).

Examples 2A and 2B

The following examples show how one job scheduling definition and one JCL
member can be used for both the test environment and the production environment
by changing the value of only one parameter, the SET VAR parameter.

Assume the following JCL for the job:

//PRDKPL01 JOB 0,M22,CLASS=A,MSGCLASS=X,REGION=4000K

//STEP01 EXEC %%PROC%%.INPT
//STEP02 EXEC %%PROC%%.UPDT
//STEP03 EXEC %%PROC%%.RPTS

Chapter 3 Job Production Parameters 633

SET VAR: General Job Parameter

Example 2A

The following job scheduling definition replaces the %%PROC variable in the EXEC
statements of the JCL with procedure name prefix TEST.

Figure 298 SET VAR Parameter Example – 2A

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL KPL GROUP PROD-KPL
DESC DAILY PRODUCTION - START OF APPL-PROD-KPL
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR %%PROC=TEST
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR)
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 18.36.07

When a SET VAR statement is used to specify %%PROC=TEST, the JCL is resolved as
follows:

//PRDKPL01 JOB 0,M22,CLASS=A,MSGCLASS=X,REGION=4000K

//STEP01 EXEC TESTINPT
//STEP02 EXEC TESTUPDT
//STEP03 EXEC TESTRPTS

634 Control-M for z/OS User Guide

 SET VAR: General Job Parameter

Example 2B

The job scheduling definition has now been modified to replace the procedures
(%%PROC) used in the job with production (PROD) procedures.

Figure 299 SET VAR Parameter Example 2B

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME PRDKPL01 MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL KPL GROUP PROD-KPL
DESC DAILY PRODUCTION - START OF APPL-PROD-KPL
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR %%PROC=PROD
SET VAR
CTB STEP AT NAME TYPE
DOCMEM PRDKPL01 DOCLIB CTM.PROD.DOC
===========================================================================
SCHEDULE RBC
RELATIONSHIP (AND/OR)
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 18.36.07

When a SET VAR statement is used to specify %%PROC=PROD, the JCL is resolved
as following:

//PRDKPL01 JOB 0,M22,CLASS=A,MSGCLASS=X,REGION=4000K

//STEP01 EXEC PRODINPT
//STEP02 EXEC PRODUPDT
//STEP03 EXEC PRODRPTS

Chapter 3 Job Production Parameters 635

SHOUT: Post–Processing Parameter

SHOUT: Post–Processing Parameter

Sends (“shouts”) a message to a destination when a specific situation occurs.

NOTE
DO SHOUT and SHOUT statements are similar, but not identical. The differences are outlined
below in “Differences between SHOUT and DO SHOUT” on page 644.

Figure 300 SHOUT Parameter Format

Optional. Upon filling in the SHOUT statement and pressing Enter, a new SHOUT
statement is opened.

Each SHOUT statement consists of four subparameters: WHEN (situation), TO

(destination), URGN (urgency), and MS (message text).

636 Control-M for z/OS User Guide

 SHOUT: Post–Processing Parameter

Table 214 SHOUT Subparameters (part 1 of 4)

Subparameter Description
WHEN Situation in which to send the message. Valid values are:

■ OK – The message is sent if the job ends OK.

■ NOTOK – The message is sent if the job ends NOTOK.

■ RERUN – The message is sent if the job is rerun and DO RERUN

is specified in ON PGMST.

■ LATESUB time + days – The message is sent if the job was not
submitted by the specified day and time offset, where:

— If Days is entered, it must be a number between zero and 120.

— Time is in the format hhmm or an *. If * is specified, the
Control-M monitor uses the calculated DUE IN date and time
of the job, as displayed in the Zoom screen, to determine if the
job was not submitted at the correct date and time. For more
information, see “Automatic Job Flow Adjustment” on
page 77.
— Note that if the time is *, Days must be blank.

■ LATE time + days – The message is sent if the job was submitted
but did not finish executing by the specified day and time offset,
where:

— If Days is entered, it must be a number between zero and 120.

— Time is in the format hhmm or an *. If * is specified, the
Control-M monitor uses the calculated DUE IN date and time
of the job, as displayed in the Zoom screen, to determine if the
job was late. For more information, see “Automatic Job Flow
Adjustment” on page 77.
— Note that if the time is *, Days must be blank.

Chapter 3 Job Production Parameters 637

SHOUT: Post–Processing Parameter

Table 214 SHOUT Subparameters (part 2 of 4)

Subparameter Description
■ EXECTIME limit – The message is sent if the elapsed runtime of
the job is outside a specified limit. The limit can be expressed as a
runtime limit, or as a deviation from the average runtime of the
job. Valid formats for limit are (where n is a 3-digit nonzero
value):
>n – The elapsed runtime of the job is greater than n
minutes. n cannot exceed 999.
<n – The elapsed runtime of the job is less than n
minutes. n cannot exceed 999.
+n – The elapsed runtime of the job exceeds the average
execution time of the job by at least n minutes.
n cannot exceed 999.
–n – The elapsed runtime of the job is at least n minutes
less than its average execution time. n cannot
exceed 999.
+n% – The elapsed runtime of the job exceeds its average
execution time by at least n%. n cannot exceed 900
–n% – The elapsed runtime of the job is at least n% less
than its average execution time. n cannot exceed
99.

SHOUT WHEN LATE and SHOUT WHEN LATESUB are only

activated for the first run of a job, not for subsequent job reruns.

SHOUT WHEN EXECTIME limits coded in SMART Table Entities

are not continuously checked, but only when each job in the SMART
Table finishes executing.
TO Destination of the message (1 through 16 characters).

Mandatory. Valid values are:

■ U-userid or USERID-userid – Writes the message to the IOA Log

file under the specified user ID. userid must be 1 through 8
characters.

■ OPER[–n] – Sends a rollable message to the operator console. n is

an optional 2-digit route code. If a route code is not specified, the
default routes are Master Console and Programmer Information
(1 and 11), and optionally, Control-M/Enterprise Manager. For
more detailed information regarding route codes, refer to the
IBM publication Routing and Descriptor Codes, GC38-1102.

■ OPER2[–n] – Sends an unrollable, highlighted message to the

operator console. n is an optional 2 through digit route code. If a
route code is not specified, the default routes are Master Console
and Programmer Information (1 and 11), and optionally,
Control-M/Enterprise Manager. For more detailed information
regarding route codes, refer to the IBM publication Routing and
Descriptor Codes, GC38-1102.

638 Control-M for z/OS User Guide

 SHOUT: Post–Processing Parameter

Table 214 SHOUT Subparameters (part 3 of 4)

Subparameter Description
■ [TSO - loginid | T - loginid] [;Nn | ;Mm | ;NnMm | ;Lname] –
Sends the message to the specified ID (groupid or logonid). ID is
mandatory.
If a groupid is specified, it must be a valid ID found within the
IOA Dynamic Destination Table.
If a logonid is specified, it must be 1 through 7 characters.
An optional second value, indicating the computer and/or node
(such as Mm) of the TSO logonid, can be specified, as follows:
Under JES2:
Valid values are: Nn, Mm or NnMm, where:
– m is the machine ID (the computer in JES2, not the
4-character SMF system ID). For more information, see
the description of specifying IOA CPUs in the discussion
of the customization process in the INCONTROL for
z/OS Installation Guide.
– n is the 1 to 2 character JES/NJE node ID.
Under JES3:
The only valid value is Lname, where Lname is the logical JES
name of the machine (that is, the name as used in JES3 command
*T, not the SMF system ID.
For more information, see the description of specifying IOA
CPUs in the discussion of the customization process in the
INCONTROL for z/OS Installation Guide.)
Note: A shout to a TSO user performs a TSO SEND command, which
may require authorization at the receiving node.
■ U-M:mail-name – Sends a message by mail to the recipient
identified by the mail-name prefix (1 through 12 characters).

■ U-S:snmp_dest – Sends an SNMP trap (message) to the recipient

identified by snmp_dest.
snmp_dest consists of from 1 through 12 characters, and can be
any of the following:
— a host name
— an IP address
— a nickname defined in the SNMPDEST destination table
— a group name defined in the SNMPDEST destination
table

■ U-ECS – Sends messages to the Control-M/Enterprise Manager

user.
Note: If you want SHOUT Messages to be sent to the
Control-M/Enterprise Manager, you must install Sample Exit
IOAX034W, which is in the IOA SAMPEXIT library.

Chapter 3 Job Production Parameters 639

SHOUT: Post–Processing Parameter

Table 214 SHOUT Subparameters (part 4 of 4)

Subparameter Description
URGN Determines the priority level of the message. Valid values are:
■ R – Regular. Default.
■ U – Urgent.
■ V – Very urgent.

MS Message text. Maximum length: 70 characters.

AutoEdit variables (both system and user-defined) are supported and

automatically resolved (replaced) at the time the SHOUT message is
issued. For AutoEdit usage information, see Chapter 5, “JCL and
AutoEdit Facility.”

General Information
The message is sent to the specified destination when the WHEN condition is
satisfied. The relationship between multiple SHOUT statements is OR (that as, each
statement is evaluated and performed independently of the others).

AutoEdit variables (system- and/or user-defined) in the message text are supported
and automatically resolved (replaced) when the SHOUT message is issued. For more
information, see Chapter 5, “JCL and AutoEdit Facility.”

SHOUT statements can also be defined in SMART Table Entities, where they are used
in a manner similar to jobs. For example, SHOUT WHEN OK is activated when all the
jobs in the SMART Table end OK.

The WHEN Subparameter

If SHOUT WHEN EXECTIME values are stated with a + or – sign, that is, when
elapsed runtime is compared to average runtime, the shout applies only if there is a
Job Statistics record for the job, containing statistics for at least one of the last 200 runs
of the job.

If a Job Statistics record exists, all available elapsed-time statistics for the last 200 job
runs are averaged to generate the average runtime, and the current runtime is
compared to this figure according to the specified criteria.

If no Job Statistics file exists, or a record for the job does not exist, that is, there are no
elapsed-time statistics for any of the last 200 job runs, the SHOUT is not activated.

NOTE
Your INCONTROL administrator can tell you if the job has a Statistics file, and if the Statistics
file is updated after each job run.

640 Control-M for z/OS User Guide

 SHOUT: Post–Processing Parameter

If EXECTIME values are negative (that is, if they are –n or –n%), the check can be
performed only after the job has finished running.

When EXECTIME values are positive (that is, if they are +n or +n%), the check can be
performed (and if the elapsed runtime limits are exceeded, the message can be
“shouted”) before the job has finished running.

When Control-M calculates EXECTIME values, such as job start time, average
execution time, actual elapsed time, shout message time, and so on, calculations are
made only in minutes, and seconds are ignored. Therefore, the results of expressions
such as SHOUT WHEN EXECTIME >001 (or +001) are unpredictable. BMC Software
recommends that you use SHOUT WHEN EXECTIME only when you need to
monitor jobs of more than a few minutes duration.

Relative EXECTIME limits must not exceed 24 hours. When relative EXECTIME
limits exceed 24 hours (such as if +n(%) of the average runtime exceeds 24 hours), the
message is “shouted” if and when processing reaches 24 hours.

If a relative EXECTIME is not specified prior to job submission, but is specified

afterwards (that is, the job is held, the parameters changed in the Zoom screen, and
the job is then freed), the EXECTIME value is ignored.

When the New Day procedure runs, any unexecuted SHOUT statements that relate to
jobs ordered on the previous day are automatically cancelled.

If, when you order jobs, you often specify a LATE or LATESUB time that crosses the
New Day time, you should consider implementing Wish WM2344. This Wish enables
jobs to operate with a “shifted” New Day time for SHOUT purposes. You can find
Wish WM2344 in the IOADFLT member in the IOA IOAENV library.

If you want only some specific jobs to operate with a “shifted” New Day time for
SHOUT purposes, you may not want to implement Wish WM2344. An alternative
method for use in such a case is illustrated in Example 4 on page 646.

The TO Subparameter

Specify TO=USERID-userid to write the message to the IOA Log file under the user
ID specified in the parameter.

Specify TO=OPER[–n] to send the message to the operator console (route code n). If
the n value is omitted, the message is sent to all consoles to which route codes 1 or 11
are assigned. For more detailed information regarding route codes, refer to the IBM
publication Routing and Descriptor Codes, GC38-1102. Optionally, the message can
also be sent to the Control-M/Enterprise Manager user. This is described in
“Shouting to Control-M/Enterprise Manager” on page 479.

Chapter 3 Job Production Parameters 641

SHOUT: Post–Processing Parameter

Specify TO=OPER2[–n] to send a highlighted, unrollable message to the operator

console (route code n). If the n value is omitted, the message is sent to all consoles to
which route codes 1 or 11 are assigned. For more detailed information regarding
route codes, refer to the IBM publication Routing and Descriptor Codes, GC38-1102.
Optionally, the message can also be sent to the Control-M/Enterprise Manager user,
as described in the following section, “Shouting to Control-M/Enterprise Manager”.

Specify TO=TSO-id or T-id to send the message to a groupid or logonid. The Shout
facility first searches the IOA Dynamic Destination table for the specified ID. If the
table contains an entry (groupid) that matches the value, the content of the entry is
used as the target for the shouted message. (The entire TO field is used. Therefore,
when directing the message to a remote user, do not append Nn or Mm. Instead, do
this in the IOA Dynamic Destination Table itself. For more information, see the
discussion of Destination Tables in the INCONTROL for z/OS Administrator Guide.)

If no matching ID is found in the Dynamic Destination table, the Shout facility

assumes the specified ID is a logonid. It then creates a TSO message that it hands over
to MVS. MVS then sends the message to that logonid. (If the logonid does not exist,
MVS cannot send the message, but no error message is generated.) When a second
value is used, the message is sent to the TSO logonid in the specified computer or
node (machine ID). To determine the machine ID under JES2, specify JES command
$D MEMBER.

Specify TO=U-M: mail-name-prefix to send the message by e-mail to the recipient

identified by the prefix. The full mail name address is supplied by the MAILDEST
table in the IOA PARM library. For more information about mail destinations, see the
INCONTROL for z/OS Administrator Guide. The IOAPARM member includes
DFLTSFFX, the mail address suffix, such as MAIL.DOMAIN.COM, the SMTP STC
name, and the HOSTNAME. If installation parameter ATTSYSOT=Y, the job's
SYSOUT will be attached to the e-mail message.

Specify TO=U-S:snmp_dest to send the SNMP trap (message) to the recipient

identified by snmp_dest. This variable (snmp_dest) can be any of the following:

■ a host name
■ an IP address
■ a nickname defined in the SNMPDEST table
■ a group name defined in the SNMPDEST table

For more information about mail destinations, see the INCONTROL for z/OS
Administrator Guide.

Shouting to Control-M/Enterprise Manager

For Control-M to be able to shout to Control-M/Enterprise Manager, the following

conditions must be satisfied at the site:

642 Control-M for z/OS User Guide

 SHOUT: Post–Processing Parameter

1. Control-M/Enterprise Manager must be installed and the ECS parameter must be

set to Y in the IOAPARM member in the IOA PARM library.

2. File MG2 (the Control-M/Enterprise Manager Shout File) must be defined.

3. The following parameters in the IOAPARM member in the IOA PARM library
must be defined according to how messages must be targeted to
Control-M/Enterprise Manager:

■ If TO=OPER and TO=OPER2 messages must be sent to Control-M/Enterprise

Manager, set the OPER2ECS parameter to Y (Yes). Otherwise, set it to N (No).

When OPER2ECS is set to Y:

— If these messages must also be sent to the MVS operator console, set the
OPER2CON parameter to Y (Yes).

— If these messages must not also be sent to the MVS operator console, set the
OPER2CON parameter to N (No).

■ If TO=U-ECS messages must be sent to Control-M/Enterprise Manager, set the

ECS2ECS parameter to Y (Yes); otherwise, set it to N (No). Regardless of the
value of this parameter, these messages are (also) sent to Control-M and the IOA
Log.

Once the above conditions are satisfied, messages can be shouted to

Control-M/Enterprise Manager by specifying a destination of TO=OPER or
TO=OPER2 (without a route code qualifier) or TO=U-ECS.

Such messages are then placed by Control-M in the M2G file. Once the shouted
message is in the M2G file, the Control-M Application Server reads the file and sends
the message to the Control-M/Enterprise Manager user.

The URGN Subparameter

The URGN value indicates the urgency level of the message.

In addition, if the destination is USERID–userid (or U–userid), the user can control,
according to urgency, which messages are displayed when the IOA Log file is
accessed. Urgent and very urgent messages are highlighted on the screen. For more
details, see “IOA Log Facility” on page 303

Chapter 3 Job Production Parameters 643

SHOUT: Post–Processing Parameter

Differences between SHOUT and DO SHOUT

SHOUT and DO SHOUT statements have the following differences:

■ A DO SHOUT statement is applied only if the accompanying ON criteria are

satisfied. Therefore a DO SHOUT statement does not contain subparameters for
specifying when to perform the shout.

By contrast, a SHOUT statement requires that a value be specified, in the WHEN

subparameter, indicating when to shout the message. Messages can be shouted
when the job ends OK or NOTOK, when the job is late for submission or
completion, or when the job runs too long.

■ A SHOUT statement appears in each job scheduling definition. A DO SHOUT

statement does not appear unless specified. To specify a DO SHOUT statement,
type SHOUT in an empty DO field and press Enter.

■ The SHOUT URGN subparameter is equivalent to the DO SHOUT URGENCY

subparameter.

The SHOUT MS subparameter is equivalent to the DO SHOUT subparameter.

Examples

Example 1

If the job finishes executing OK, write a message to the IOA Log file under the
specified user ID:

MEMNAME GPLSP0007
DAYS 01,15
SHOUT WHEN OK TO U-SHIFTMNGR URGN R
MS I HAVE FINISHED FOR TONIGHT

The message is written to the log under Control-M userid-SHIFTMNGR.

644 Control-M for z/OS User Guide

 SHOUT: Post–Processing Parameter

Example 2

When IMS is not active, send a message to all operators.

Figure 301 SHOUT Parameter Example 2

JOB: IMSPROD LIB CTM.PROD.SCHEDULE TABLE: IMSPROD
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN OK TIME + DAYS TO OPER2 URGN R
MS ******* IMS IS NOT ACTIVE *******
SHOUT WHEN NOTOK TIME + DAYS TO OPER2 URGN R
MS ******* IMS IS NOT ACTIVE - ENDED ABNORMALLY *******
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

If IMS finishes executing, an unrollable message is sent to the operator. A different

message is sent if IMS terminates abnormally.

Chapter 3 Job Production Parameters 645

SHOUT: Post–Processing Parameter

Example 3

If the job is not run because of a JCL error, notify the user who sent the job.

Figure 302 SHOUT and DO SHOUT Example

JOB: SACALC01 LIB CTM.PROD.SCHEDULE TABLE: SALARY
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST ANYSTEP PROCST CODES JNRUN A/O
DO SHOUT TO TSO-U0014 URGENCY U
= *** JCL ERROR IN SALARY JOB ***
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

An urgent message is sent to the user ID that requested the job.

Example 4

Perform a LATE shout after the New Day time has passed and a new working day
has begun.

Assume the following:

■ New Day time at the site is 0600.

■ A job, LONGWAIT, is ordered at 1400.
■ The job LONGWAIT must shout if it has not finished executing by 0700 on the
following day.

However, the New Day process automatically cancels any shout requirements of jobs
ordered on any previous day.

There are two ways to achieve the required LATE shout:

646 Control-M for z/OS User Guide

 SHOUT: Post–Processing Parameter

Method 1

1 Create a DUMMY job scheduling definition named TRIGGER, containing the

following elements:

■ The TIME FROM parameter is set to 1400.

■ The OUT parameter is set to TRIGGER-SHOUT.

2 Create a DUMMY job scheduling definition named SHOUT. This job must be
ordered at the New Day time, and must contain the following elements:

■ The TIME FROM parameter is set to 0700.

■ The TIME UNTIL parameter is set to 1300.
■ The MAXWAIT parameter is set to 02.
■ The IN parameter is set to TRIGGER-SHOUT.
■ The SHOUT parameter is set to WHEN LATESUB 0700.

3 Add to the LONGWAIT JOB an OUT condition, TRIGGER-SHOUT, that deletes

the TRIGGER-SHOUT condition when it ends.

This procedure works as follows:

■ The IN condition in the SHOUT job prevents it from executing between 0600
and 1359.

■ At 1400 the TRIGGER job adds the IN condition.

■ The TIME FROM and UNTIL parameter values prevent the SHOUT job from
running until after the next New Day procedure, but the MAXWAIT parameter
value ensures that the job remains on the Active Jobs file for the following day.

■ At 0700 on the following day

— if the LONGWAIT job has ended, it has removed the IN condition required
before the SHOUT job can run, so that there is no false shout at 0700

— if the LONGWAIT job has not ended, the SHOUT job runs, and the shout is
produced as required

Method 2

Use IOA Exit 34, and set values for the SET VAR parameter in the job scheduling
definition.

For more information, see the IOAX034H sample exit in the IOA SAMPEXIT library.

Chapter 3 Job Production Parameters 647

SPECIFIC TIMES: Post–Processing Parameter

SPECIFIC TIMES: Post–Processing Parameter

This parameter defines the specific times that cyclic jobs will run.

Optional. SPECIFIC TIMES consist of the subparameters described in Table 215.

Table 215 SPECIFIC TIMES Subparameters

Subparameter Description
specific_time Time of day that the cyclic jobs will run, specified in 24-hour format,
without a colon separating the hours from the minutes. Valid values
are: 0000 through 2400.

Default: 0000

For example: 1500 specifies 3:00 P.M

days_offset A number indicating the number of days in the future, relative to the
actual order date. Valid values are: 0 through 30.

Default: 0
tolerance A number indicating the maximum number of minutes after the
specific_time permitted for a late submission. Valid values are: 0
through 60.

Default: 15

In the example below the job will run at 10:00 a.m. and 11:00 a.m.

Figure 303 SPECIFIC TIMES Parameter Example

OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM
CYCLICAL TYPE: S INTERVAL FROM
INTERVAL SEQUENCE: + + + + +
SPECIFIC TIMES: TOLERANCE 0011
1000 + 000 1100 + 000 + + +
+ + + + +
STEP RANGE FR (PGM, PROC) TO
ON PGMST PROCST CODES A/O

The SPECIFIC TIMES and TOLERANCE parameters can be set to enable a job to run
after the specified time. If the job being executed runs over the proceeding job’s
specified time, the proceeding job’s execution time window is extended to the
number of minutes set in the Tolerance field. For example, if the Tolerance field is set
to 15 minutes, the proceeding job can still be executed 0-15 minutes after the specified
time. If the tolerance time interval has passed, the proceeding job will not be
performed.

648 Control-M for z/OS User Guide

 SPECIFIC TIMES: Post–Processing Parameter

The TOLERANCE subparameter indicates the maximum number of minutes

permitted for a late submission when selecting a specific time. The tolerance
permitted in the example is 11 minutes. Therefore the jobs can be submitted as late as
10:11 and 11:11 a.m.

Job run times can be defined with days offset. The value in the field represents the
number of days in the future, relative to the actual order date. For example, if the
specified times were:

1300, 1500, 1400+1, 1700+2,

then 13:00 and 15:00 would be submitted at those times on the day of order, 14:00+1
would be submitted at 14:00 on the next order day and 17:00+2 would be submitted at
17:00 two days after the order day.

Chapter 3 Job Production Parameters 649

STAT CAL: General Job Parameter

STAT CAL: General Job Parameter

Name of a periodic calendar that will be used to gather average runtime statistics for
the job, based on a period.

Figure 304 STAT CAL Parameter Format

Optional. Valid values are any valid periodic calendar name consisting of from 1
through 8 characters.

For more information on defining, modifying, and using periodic calendars, see “IOA
Calendar Facility” on page 313.

General Information
As part of the post-processing for each job, Control-M for z/OS determines the
elapsed run time of the job. All accumulated information regarding job execution,
including the elapsed run time, is written to the IOA Log file. If a STAT CAL calendar
is specified in the job scheduling definition, unlike other calendars (DCAL, WCAL, or
CONFCAL), it must exist in the IOA Calendar library at the time that the job is
ordered or forced.

Periodically, a statistics utility may be used to scan and analyze the IOA Log file. This
utility gathers information about the start time of each job, its elapsed run time, CPU
utilization time, and so on. The utility places this information in the Statistics file,
where averages of these values can be maintained for each job.

For more information on the Statistics file, see “Statistics Screen” on page 245.

When a job is ordered, Control-M takes the average run time of this job from Statistics
file and places it in the job record in the Active Jobs file. Control-M then uses this
average run time to calculate the anticipated ELAPSE time, that is, the job execution
time, of the job, and hence the Due In time of the job.

650 Control-M for z/OS User Guide

 STAT CAL: General Job Parameter

If the STAT CAL parameter is not used to specify a periodic calendar, the statistics
relating to a job are based on all run times of the job.

If the STAT CAL parameter is present, statistics for the job are based on an average of
all runtimes for the indicated period on the date on which the job is ordered or forced.

Further information is available in the Active Jobs file Zoom screen (Screen 3.z),
which contains the STAT CAL PERIOD field. This is a read-only field that may
contain one alphabetical character when the job has run. This character identifies the
actual days within the Control-M periodic calendar that were used in calculating
statistics relating to the job.

By using the STAT CAL parameter together with the information displayed in the
STAT CAL PERIOD field, you can obtain more precise statistical information about
the running of the job, as shown in the following example.

Example

Assume that a job runs daily, weekly, and monthly, and that the STAT CAL
parameter identifies a periodic calendar that contains a number of months each
specified in a manner similar to the following:

-----S--------------S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 +
09 D D W D D D D D W D D D D D W D D D D D W D D D D M

In this example, the job runs daily in Period D, weekly in Period W, and monthly in
Period M.

If the job runs on the 3rd of the month, its statistics are collected for Period W. If it
runs on the 6th of the month, its statistics are collected for Period D, and so on.

When displaying the Statistics Panel (Screen 3.S), the statistics for daily, weekly, and
monthly runs of the job are grouped under the D, W, and M PER(iod), as appropriate.

Chapter 3 Job Production Parameters 651

STEP RANGE: Post–Processing Parameter

STEP RANGE: Post–Processing Parameter

Step range in the job that can be used in an ON PGMST statement. For more
information, see “ON Statements: Post–Processing Parameter” on page 546.

Figure 305 STEP RANGE Parameter Format

Optional. STEP RANGE consists of the subparameters described in Table 216.

Table 216 STEP RANGE Subparameters

Subparameter Description
STEP RANGE Name for the range. A name of 1 through 7 characters can be
specified. Only trailing blanks are allowed in this field.
FR (PGM,PROC) First pgmstep or pgmstep,procstep in the range.
Note: pgmstep is the step name in the EXEC statement that identifies
the program to be executed:

//pgmstep EXEC PGM=pgmname

procstep is the step name in the EXEC statement that invokes the
procedure: //procstep EXEC procname

pgmstep values and procstep values can each be 1 through 8 characters

in length.
TO Last pgmstep or pgmstep,procstep in the range. For more information,
see the note to the preceding subparameter, FR.
Note: The TO subparameter is optional. If blank, its value defaults to
the last step in the job.

652 Control-M for z/OS User Guide

 STEP RANGE: Post–Processing Parameter

General Information
Whenever a STEP RANGE statement is specified, it eliminates the need to define
separate ON PGMST, ON PROCST, and ON CODES statements and accompanying
DO actions for each step in the range. The defined STEP RANGE name can be used,
without redefining the range, in subsequent ON PGMST, ON PROCST, and ON
CODES statements, by specifying the step range name, preceded by an asterisk, in the
ON PGMST field. For more information on ON PGMST and ON PROCST, see “ON
Statements: Post–Processing Parameter” on page 546. For more information on ON
CODES, see “CODES Values” on page 559.

Any number of step ranges can be specified. After entering a STEP RANGE
parameter, another STEP RANGE parameter line is automatically displayed.

If the EXCLUDED STEP RANGE facility is activated (that is, EXSTPRNG=Y in the
CTMPARM parameter) and the name of the step range starts with a minus sign, then
that step range defines an EXCLUDED STEP RANGE (all steps in the job, excluding
the steps from one step to another).

For example:

STEP RANGE -ERANG1 FR (PGM.PROC) STEP10 . TO STEP20

defines a step range called -ERANG1, which contains all the job steps except the steps
from step STEP10 to step STEP20.

Examples

Triggers a SHOUT if any step, except step STEP3 through step STEP6, finishes with
code 16.

STEP RANGE -ERANG1 FR (PGM.PROC) STEP3 . TO STEP6

ON PGMST *-ERANG1 PROCST CODES C0016
DO SHOUT ....

Triggers a SHOUT if every job step, except those from step STEP6 to step STEP9,
finishes with a code greater than 8.

STEP RANGE -ERANG2 FR (PGM.PROC) STEP6 . TO STEP9

ON PGMST *-ERANG2 PROCST +EVERY CODES >C0008
DO SHOUT ...

Triggers a SHOUT if every job step, except step STEPA, finish with a zero code.

STEP RANGE -ERANG3 FR (PGM.PROC) STEPA . TO STEPA

ON PGMST *-ERANG3 PROCST +EVERY CODES C0000
DO SHOUT ...

Chapter 3 Job Production Parameters 653

STEP RANGE: Post–Processing Parameter

§Restart§ Using All Runs of a Job Including Restarts

When processing ON blocks, Control-M can incorporate the results of all previous
runs and restarts, filtering them for jobs restarted with the parameters RESTART,
RECAPTURE CONDITION and/or ABEND CODES. Control-M/Restart searches
previous runs to determine which steps must be considered part of the restarted job.

For example, if one step finished successfully during its original run and another step
finished successfully after a restart, the ON block check for the successful finish for
both steps produces a TRUE result and the ON statement is satisfied.

Activation of this facility requires that the ALLRUNS parameter in the CTRPARM
parameter be set to YES. When activated, this facility may apply to any specified step,
step range, or to step value +EVERY.

Example
Define program steps STEP20 through STEP29A as step range DF2. If any of these
steps produce any system or user abend (except user abend U2030), rerun the job and
shout a message to TSO-P43.

Figure 306 STEP RANGE Parameter Example

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
==========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP (C,D,F,N,R) FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE DF2 FR (PGM.PROC) STEP20 . TO STEP29A .
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST *DF2 PROCST CODES S**** U**** NU2030 A/O
DO RERUN
DO SHOUT TO TSO-P43 URGENCY R
= JOB PRDKPL03 ABENDED, THE JOB IS RERUN
DO
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< ======

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

654 Control-M for z/OS User Guide

 SYSOUT: Post–Processing Parameter

SYSOUT: Post–Processing Parameter

Controls handling of job output after the job ended OK.

NOTE
SYSOUT and DO SYSOUT statements are similar, but not identical. The differences are
outlined below in “Differences Between SYSOUT and DO SYSOUT” on page 661.

Figure 307 SYSOUT Parameter Format

Optional. SYSOUT consists of the subparameters described in Table 217.

Table 217 SYSOUT Subparameters

Subparameter Description
OP Sysout option code. Mandatory. Valid values are:

■ F – Copy the job output to file.

■ D – Delete (purge) the job output.
■ R – Release the job output.
■ C – Change the class of the job output.
■ N – Change the destination of the job output.
sysout_data Relevant sysout data. Mandatory and valid only if the specified OP
value is F, C, or N. Valid values depend on the OP value, as follows:

■ F – File name
■ C – New class (1 character). An asterisk (*) indicates the original
MSGCLASS of the job
■ N – New destination (1 through 8 characters)
FROM FROM class. Optional. Limits the sysout handling operation to only
those sysouts from the specified class.
Note: If a FROM class is not specified, all sysout classes are treated as
a single, whole unit.

Chapter 3 Job Production Parameters 655

SYSOUT: Post–Processing Parameter

General Information
When a job ends OK, the Control-M monitor, unless otherwise instructed, leaves the
job sysout in HELD class in the output queue.

The SYSOUT parameter is used to request additional handling of these held sysouts
when the job ends OK.

The Control-M monitor sends all sysout handling requests to JES, which processes
the instructions. If, however, the copying of sysouts to a file is requested (option F),
Control-M requests the sysouts from JES and then Control-M directly writes the
sysout to the file.

Only one SYSOUT statement can be defined in a job scheduling definition. To specify
additional sysout handling instructions in addition to the one SYSOUT statement,
define appropriate DO SYSOUT statements:

DO SYSOUT statements are activated when their accompanying ON step and code
event criteria are satisfied. To define DO SYSOUT statements that act like a SYSOUT
statement, that is, those that operate only when the job ends OK, define their
accompanying ON statement with PGMST set to ANYSTEP and CODES set to OK.

For more information, see “ON Statements: Post–Processing Parameter” on page 546,
and “DO SYSOUT: Post-Processing Parameter” on page 484.

The interrelationship between multiple SYSOUT operations, as in SYSOUT and DO

SYSOUT statements, is described in “Multiple Sysout Operations” on page 658.

Sysout Handling Operations

Which sysouts are affected by sysout handling operations depends on whether the
sysouts are under JES2 or JES3, as follows:

■ Under JES2, operations are performed on all of the held sysouts, or held portions of
sysouts, of the job, unless otherwise restricted to a specific FROM class by the
FROM subparameter.

■ Under JES3, operations are performed only on the sysouts of the job in the
Control-M held class, which is specified in the Control-M installation parameter
HLDCLAS.

656 Control-M for z/OS User Guide

 SYSOUT: Post–Processing Parameter

Sysout handling operations are listed below:

■ Copying sysouts to a file (OPT=F)

The job sysouts are copied (not moved) to the file specified in the data
subparameter.

The file name specified in the data subparameter can contain AutoEdit System
variables, and/or user-defined AutoEdit variables, which are defined in the job
scheduling definition or the IOA Global Variable database, or which are loaded
into AutoEdit cache. If the AutoEdit variables cannot be resolved, the sysout is not
copied.

Control-M allocates the file with DISP=(NEW,CATLG,DELETE) using the unit and
space attributes specified in the Control-M installation parameters. While the block
size (BLKSIZE) is automatically calculated by Control-M, the logical record length
(LRECL) is copied from the input SYSOUT file. The maximum LRECL allowed is
256 characters.

Sysouts can be archived by copying them to a file. However, to reduce overhead,

this method is recommended only for small sysouts.

■ Deleting sysouts (OPT=D)

The job sysouts are deleted (purged) from the output queue.

NOTE
This operation works on all sysouts under JES2 or JES3, regardless of held status or class,
unless otherwise restricted by the FROM subparameter.

■ Releasing sysouts (OPT=R)

The job sysouts are released for printing.

■ Changing the class of sysouts (OPT=C)

The job sysouts are changed to the output class specified in the data subparameter.
Ensure that you specify a meaningful target output class.

Note the following points:

— Changing a sysout class to a non-held class does not release the sysout because
the sysout attributes do not change (due to JES logic).

Chapter 3 Job Production Parameters 657

SYSOUT: Post–Processing Parameter

— To ensure that the sysout is released, use DO SYSOUT statements to release the
sysout after changing its class. For example,

DO SYSOUT OPT C PRM R FRM A

DO SYSOUT OPT R PRM FRM A

— Changing a sysout class to a dummy class does not purge the sysout because the
sysout attributes do not change (due to JES logic).

— To save the original MSGCLASS of the job and to restore it at output processing
time, specify a data value of *. The sysouts are changed to the original class of
the job.

■ Moving sysouts to a new destination (OPT=N)

The job sysouts are moved to the output destination specified in the data
subparameter. Ensure that you specify a meaningful target output destination.

Multiple Sysout Operations

If multiple SYSOUT or DO SYSOUT operations are not specified for the same FROM
class, the order in which the operations are performed is not significant.

However, if different SYSOUT or DO SYSOUT operations affect the same FROM

class, or if multiple operations are specified without a FROM class, the order and
method of implementation is significant.

Control-M merges different operations for the same FROM class into a combined
instruction to JES. Likewise, Control-M merges different operations without a FROM
class into a combined instruction to JES.

Operations without a specified FROM class treat the entire held sysout as a whole
unit, and are therefore not merged with sysout handling requests for a specific FROM
class.

JES does not necessarily process multiple sysout handling instructions in the order
they are issued by Control-M. Therefore, the processing results can vary if the
merged instructions to JES include both FROM equals a specified class and FROM
equals blank.

BMC Software therefore recommends that a job scheduling definition not contain
both “FROM class” and “no FROM class” sysout handling instructions, which
becomes operational under the same situations.

When Control-M merges a set of operations into a combined instruction, some

operations override or cancel other operations, and some operations are performed
along with other operations. This is described below.

658 Control-M for z/OS User Guide

 SYSOUT: Post–Processing Parameter

Operation Merging and Performance

Control-M performs all copy to file operations (option F) first.

After performing all copy to file operations, Control-M merges all operations
performed on a specific FROM class.

After merging operations on specific FROM classes, Control-M merges the operations
performed on the sysout as a whole (that is, subparameter FROM is set to blank).

Control-M then passes the merged sets of instructions to JES for processing.

Generally, DO SYSOUT operations override, or are performed along with, SYSOUT

statements.

The following chart and the accompanying numbered explanations indicate the result
of merging SYSOUT and DO SYSOUT statements. Note the following points about
the chart:

■ Operations are indicated by their symbols (F,D,R,C,N), at the top and side of the
chart. The operations at the top of the chart represent DO SYSOUT operations. The
operations at the side of the chart represent SYSOUT operations.

■ Merging and processing operations are grouped, and explained, based on

operation type.

Groups are delimited by lines, and are numbered (from 1 through 4). Within each
group, operations are delimited by periods.

Explanations of each group are provided, by number, following the chart.

■ The handling of the combination of operations is generally reflected in the chart by

a single operation code (such as D) or pair of operation codes (such as FR).

In some cases, the operations are merged. This is indicated by the word “merged.”

Operations are explained in the numbered descriptions that follow the chart.

Chapter 3 Job Production Parameters 659

SYSOUT: Post–Processing Parameter

Figure 308 Merging SYSOUT and DO SYSOUT Statements

The order of precedence in which Control-M processes or merges operations is as

follows:

1. SYSOUT=F and DO SYSOUT=F

Copy to file operations are performed first, directly by Control-M, for both
SYSOUT and DO SYSOUT statements, whether FROM class is specified or not.
Then, other operations are performed.

2. DO SYSOUT=D (Delete)

This operation supersedes all SYSOUT operations, except copy to file operations
described above. Superseded operations are ignored (that is, not performed).

3. DO SYSOUT=R, C, or N, accompanied by a SYSOUT D (Delete) request

The DO SYSOUT statement is performed, and the SYSOUT delete request is

ignored.

660 Control-M for z/OS User Guide

 SYSOUT: Post–Processing Parameter

4. SYSOUT or DO SYSOUT combinations of R, C and N

In general, combinations of R, C, and N requests are merged, that is, they are all
performed. The exceptional cases are described below:

— For DO SYSOUT=R (Release job output) accompanied by a SYSOUT C (Change

class) request:

Perform just the DO SYSOUT R request and ignore the SYSOUT C request.

— For C (Change class) requests from both a SYSOUT and a DO SYSOUT

statement:

Perform just the DO SYSOUT request and ignore the SYSOUT request.

— For N (New Destination) requests from both a SYSOUT and a DO SYSOUT

statement:

Perform just the DO SYSOUT request and ignore the SYSOUT request.

Differences Between SYSOUT and DO SYSOUT

SYSOUT and DO SYSOUT statements have the following differences:

■ The SYSOUT statement is applied only if the job ends OK. DO SYSOUT statements
are associated with accompanying ON statements and are applied only if the
accompanying ON step and code criteria are satisfied.

■ A SYSOUT statement is displayed in each job scheduling definition. A DO

SYSOUT statement is not displayed unless requested. To request a DO SYSOUT
statement, type SYSOUT in an empty DO field and press Enter.

■ Only one SYSOUT statement can be defined in the job scheduling definition. An
unlimited number of DO SYSOUT statements can be requested.

■ The SYSOUT OP subparameter is equivalent to the DO SYSOUT OPT

subparameter.

■ The SYSOUT data subparameter is equivalent to the DO SYSOUT PRM

subparameter.

■ The SYSOUT FROM subparameter is equivalent to the DO SYSOUT FRM

subparameter.

Chapter 3 Job Production Parameters 661

SYSOUT: Post–Processing Parameter

Examples

Example 1

Delete the sysout after the job has finished executing OK:

MEMNAME EBMANT1
DAYS 1,15
SYSOUT OP D (C,D,F,N,R)

Example 2

If the job finishes OK, reroute the sysout to printing class A.

Figure 309 SYSOUT Parameter – Example 2

JOB: EBDMANT2 LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
===========================================================================
IN
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT
AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
SYSOUT OP C (C,D,F,N,R) A FROM
MAXRERUN RERUNMEM INTERVAL FROM
STEP RANGE FR (PGM.PROC) . TO .
ON PGMST PROCST CODES A/O
DO
SHOUT WHEN TIME + DAYS TO URGN
MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< ====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

662 Control-M for z/OS User Guide

 SYSTEM ID: General Job Parameter

SYSTEM ID: General Job Parameter

In JES2, the identity of the system in which the job must be initiated and executed.

In JES3, the identity of the processor on which the job must execute.

Figure 310 SYSTEM ID Parameter Format

SYSTEM ID specifies a system identity of 1 through 5 characters. Only trailing blanks

are allowed.

Use the following format for the SYSTEM ID parameter:

[/]sysid

where sysid is a 1 to 4 character system ID. The optional “/” can only be used on JES3
systems to indicate that a job should not run on the indicated system ID.

By default, the SYSTEM ID parameter is optional.

General Information
The SYSTEM ID parameter has different effects, depending on which release of JES is
in use.

If a value is specified for the SYSTEM ID parameter, it will not override any system
identity specified in the job statement unless the OVERJCLM parameter in the
CTMPARM library is set to Y.

If the task type is a started task, SYSTEM ID is protected. If the task type is changed
from a job to a started task, SYSTEM ID is erased and protected.

Chapter 3 Job Production Parameters 663

SYSTEM ID: General Job Parameter

Under JES2
If Control-M is running under JES2, the SYSTEM ID parameter is used to specify the
JES2 system on which the job is to be initiated and executed.

If a value is specified for the SYSTEM ID parameter, the following JCL statement is
generated:

/*JOBPARM SYSAFF=sys_id

Under JES3
If Control-M is running under JES3, the SYSTEM ID parameter is used to specify the
JES3 processor which is to execute the job.

If a value is specified for the SYSTEM ID parameter, the following JCL statement is
generated:

//*MAIN SYSTEM=processor_id

Examples

Example 1: JES2

The following is entered:

DESC
OVERLIB STAT CAL
SCHENV SYSTEM ID SYS3 NJE NODE

The following statement is added to the JCL of the job:

/*JOBPARM SYSAFF=SYS3

and the job is executed on the JES2 system SYS3.

Example 2: JES3

The following is entered:

DESC
OVERLIB STAT CAL
SCHENV SYSTEM ID PRC3 NJE NODE

The following statement is added to the JCL of the job:

664 Control-M for z/OS User Guide

 SYSTEM ID: General Job Parameter

//*MAIN SYSTEM=PRC3

and the job is executed on processor PRC3.

Chapter 3 Job Production Parameters 665

TASKTYPE: General Job Parameter

TASKTYPE: General Job Parameter

Type of task.

Figure 311 TASKTYPE Parameter Format

Mandatory. Valid TASKTYPE values are described in Table 218.

Table 218 TASKTYPE Parameter Values

Value Description
JOB Batch job. Default
CYC Cyclic job
STC Started task (STC)
CST Cyclic STC
EMR Emergency job
ECJ Emergency cyclic job
EST Emergency STC
ECS Emergency cyclic STC
WRN Warning message

General Information
The job scheduling definition can belong to one of three basic types of tasks:

■ Job
■ Started Task
■ Warning Message

Jobs and started tasks can be “normal”, that is, submitted or activated once, or cyclic.
Furthermore, it is possible to define emergency versions of jobs and started tasks
(normal and/or cyclic).

666 Control-M for z/OS User Guide

 TASKTYPE: General Job Parameter

The three basic types of tasks are indicated by the TASKTYPE values described in
Table 219:

Table 219 TASKTYPE Basic Type Values

Task Values
Job: JOB, CYC, EMR, ECJ
Started Task: STC, CST, EST, ECS
Warning: WRN

Jobs and Started Tasks

A regular job is submitted to the JES input queue for execution; it then waits in the
queue like any job submitted under the operating system.

After the job finishes executing, Control-M analyzes the results and determines what
actions to take. The job is not submitted again unless the RERUN statement is
performed. For additional information, see “MAXRERUN: Post–Processing
Parameter” on page 525.

Started tasks differ from jobs in that they are not submitted to the queue; instead, they
are invoked by an operator START command issued by Control-M. For details on
passing parameters to started tasks, see “MEMLIB: General Job Parameter” on
page 532.

NOTE
PREVENT-NCT2=Y cannot be specified for started tasks (STCs).

A cyclic job or a cyclic started task is recycled for additional possible executions after
Control-M has analyzed its execution results. The job or started task executes again
only after the number of minutes specified in the INTERVAL parameter has passed
since the last execution and the rest of its runtime scheduling criteria have been
satisfied.

NOTE
BMC Software recommends that a cyclic job delete the prerequisite conditions that triggered
its operation. Otherwise the job might continually be resubmitted.

If a cyclic job is executing at the time the New Day procedure is run, and the value of
the job’s MAXWAIT parameter has expired, the New Day procedure changes the job
to a non-cyclic job and handles the job accordingly.

Chapter 3 Job Production Parameters 667

TASKTYPE: General Job Parameter

Use of the cyclic option precludes the use of RERUNMEM and DO RERUN
parameters.

Emergency Jobs and Started Tasks

NOTE
Emergency jobs and started tasks are supported for backward compatibility, but BMC
Software recommends redefining them as regular jobs and started tasks that are activated by
DO FORCEJOB statements. Control-M/Restart users can also use a DO IFRERUN statement.
The DO FORCEJOB statement is described in “DO FORCEJOB: Post–Processing Parameter”
on page 450, and the DO IFRERUN statement in “§Restart§DO IFRERUN: Post–Processing
Parameter” on page 453.

An emergency job or emergency started task can be used to overcome any

irregularities in normal execution. The job remains in the Active Jobs file, waiting to
be scheduled, until all regular jobs of the same SMART Table finish executing OK and
are checked by Control-M. Then, when the emergency job is no longer needed, the job
is automatically removed from the Active Jobs file. For additional information, see
“MAXWAIT: Basic Scheduling Parameter” on page 528.

NOTE
BMC Software recommends that the GROUP parameter be specified if you define emergency
jobs. If it is not specified, the job may stay indefinitely in the Active Jobs file.

Emergency jobs can be filtered out of the job display in the Active Environment
screen and filtered out of reports.

Warning Messages

NOTE
The IOANOTE utility, which is described in the INCONTROL for z/OS Utilities Guide, can also
be used to issue warning messages. BMC Software recommends that the IOANOTE utility be
used in place of this tasktype wherever possible.

For tasktype WRN, warning messages are sent to the IOA Log file when the job is
ordered. The messages are taken from the member specified in the MEMNAME
parameter.

NOTE
A job defined with tasktype WRN is not placed in the Active Jobs file.

668 Control-M for z/OS User Guide

 TASKTYPE: General Job Parameter

Examples

Example 1

Submit a regular job:

MEMNAME GNRLDR01
TASKTYPE JOB

Example 2

Start a started task:

MEMNAME CICSPROD
TASKTYPE STC

Example 3

Start an emergency job:

MEMNAME RESTORE2
TASKTYPE EMR

Example 4

Job OPERCOMP is a regular job.

Chapter 3 Job Production Parameters 669

TASKTYPE: General Job Parameter

Figure 312 TASKTYPE Parameter – Example 4

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE TABLE: OPER
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
MEMNAME OPERCOMP MEMLIB CTM.PROD.JCL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL OPER GROUP MAINTENANCE
DESC JOB RUN ON THE 1ST OF THE MONTH
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPERCOMP DOCLIB CTM.PROD.DOC
===========================================================================
DAYS 01 DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

670 Control-M for z/OS User Guide

 TIME + DAYS: Runtime Scheduling Parameter

TIME + DAYS: Runtime Scheduling Parameter

Time and day limits (FROM, UNTIL) for submitting a job or making a SMART Table
active.

Figure 313 TIME + DAYS Parameter Format

Optional. This parameter consists of four subparameters:

■ FROM TIME
■ FROM DAYS
■ UNTIL TIME
■ UNTIL DAYS

Any or all subparameters may be specified.

The FROM TIME and UNTIL TIME subparameters can contain valid times in the
format hhmm (where hh is hour and mm is minute). Character > can be entered in the
UNTIL TIME field.

The FROM DAYS and UNTIL DAYS subparameters can contain valid numbers from
zero through 120.

General Information
The FROM TIME and FROM DAYS, and UNTIL TIME and UNTIL DAYS,
subparameters define a window of opportunity for job submission. A job can only be
submitted during the specified submission window.

FROM DAYS and UNTIL DAYS are not entered

If either a FROM TIME or an UNTIL TIME subparameter is missing, that is, not
specified, the New Day Processing time is used as the default for the missing value.

Chapter 3 Job Production Parameters 671

TIME + DAYS: Runtime Scheduling Parameter

To create a submission window from a particular time until the New Day processing
time, enter the desired FROM TIME and leave the UNTIL TIME subparameter blank.

Example

FROM TIME 2200 + DAYS UNTIL TIME (blank) + DAYS

creates a submission window from 10:00 PM until the New Day Processing time.

To create a submission window from the New Day processing time until a particular
time, enter the desired UNTIL TIME and leave the FROM TIME subparameter blank.

Example

FROM TIME (blank) + DAYS UNTIL TIME 1300 + DAYS

creates a submission window from New Day processing time until 1:00 P.M. When
both a FROM TIME and an UNTIL TIME value are specified, the relationship of New
Day Processing time to these values (on a physical clock) determines the submission
window. The logic is as follows:

If, when you move forward on the physical clock from the New Day Processing time,
you arrive at the FROM TIME before you arrive at the UNTIL TIME, it means that
New Day processing does not fall between the FROM TIME and the UNTIL TIME. In
this case, the submission window runs from the FROM TIME to the UNTIL TIME,
regardless of when the job was ordered.

Example

Assume a New Day Processing time of 8:00 A.M.:

FROM TIME 1400 + DAYS UNTIL TIME 2200 + DAYS

creates a submission window from 2:00 P.M. until 10:00 P.M., a period of 8 hours.

Example

Assume a New Day Processing time of 10:00 P.M.:

FROM TIME 2300 + DAYS UNTIL TIME 0500 + DAYS

creates a submission window from 11:00 P.M. until 5:00 A.M., a period of 6 hours.

672 Control-M for z/OS User Guide

 TIME + DAYS: Runtime Scheduling Parameter

Example

Assume a New Day Processing time of 10:30 P.M.:

FROM TIME 2300 + DAYS UNTIL TIME 2200 + DAYS

creates a submission window from 11:00 P.M. until 10:00 P.M., a period of 23 hours.

If, when you move forward on the physical clock from the New Day Processing time,
you arrive at the UNTIL TIME before you arrive at the FROM TIME, it means that
New Day processing falls between the FROM TIME and UNTIL TIME.

Batch jobs are frequently scheduled for submission from night until the morning.
Therefore, when the New Day Processing time intervenes between the FROM TIME
and the UNTIL TIME, it is likely that, following New Day Processing, the site still
wants the job to be submitted up until the UNTIL TIME, without first waiting for the
FROM time of the New Day.

For this reason, if New Day Processing comes between the FROM TIME and the
UNTIL TIME, then regardless of when the job was ordered, the job is eligible for
submission from both

■ the FROM TIME until New Day Processing time

■ New Day Processing time until the UNTIL TIME

The actual effect is that the submission window consists of all times except the
interval from the UNTIL TIME until the FROM TIME.

Example

Assume a New Day Processing time of 4:00 A.M.:

FROM TIME 2300 + DAYS UNTIL TIME 0600 + DAYS

creates a submission window from 11:00 P.M. until 4:00 A.M. and from 4:00 A.M.
until 6:00 A.M., giving a net submission window from 11:00 P.M. until 6:00 A.M. The
job cannot be submitted from 6:00 A.M. until 11:00 P.M.

The character > in the UNTIL TIME subparameter indicates that Control-M must
attempt to submit the job at the FROM TIME if specified, and if this is not possible,
Control-M must submit the job as soon afterwards as possible, even at a later date
(unless the MAXWAIT period has expired).

Chapter 3 Job Production Parameters 673

TIME + DAYS: Runtime Scheduling Parameter

Example

Assume a New Day Processing time of 8:00 A.M.:

FROM TIME 2200 + DAYS UNTIL TIME > + DAYS

creates a submission window that begins at 10:00 P.M. If the job has not been
submitted by the end of day, it can be submitted at any time from the beginning of the
next day.

The FROM TIME subparameter is ignored when a job is rerun or restarted on a

subsequent day.

Specifying the same time in both the FROM TIME and the UNTIL TIME
subparameters has the same impact as entering no value in both fields.

Example

Submit the job after midnight:

Figure 314 FROM TIME Parameter Example

JOB: OPGENBKP LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPGENBKP DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
RESOURCE
PIPE
FROM TIME 0000 + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM

In this example, if the start time of the new workday is 6:00 A.M., this job can only be
submitted between the hours of midnight and 6:00 A.M.

674 Control-M for z/OS User Guide

 TIME + DAYS: Runtime Scheduling Parameter

FROM DAYS and UNTIL DAYS are entered

The FROM DAYS and UNTIL DAYS subparameters, together with the FROM TIME
and TO TIME subparameters, can be used to define a window of opportunity for job
submission that will take place on a future date, at a time more than 24 hours in the
future.

If the FROM DAYS and UNTIL DAYS subparameters are entered, the job's
submission window is calculated as follows:

■ start date is the job's ODATE plus FROM DAYS

■ end date is the job's ODATE plus UNTIL DAYS

If either the FROM TIME or UNTIL TIME subparameter is missing, that is, not
specified, the New Day Processing time is used as the default for the missing value.

To create a submission window from a particular date and time until the date and
time of New Day processing, enter the desired FROM TIME and leave UNTIL TIME
blank.

For all examples in this section, assume an ODATE of September 5.

Example

FROM TIME 2200 + 1 DAYS UNTIL TIME (blank) + 3 DAYS

creates a submission window from Control-M working date September 6 at

10:00 P.M. until New Day Processing time on Control-M working date
September 8th.

To create a submission window from a particular date and time of New Day
processing until a particular date and time, enter the desired UNTIL TIME and leave
FROM TIME blank.

Example

FROM TIME (blank) + 1 DAYS UNTIL TIME 1300 + 3 DAYS

creates a submission window from New Day processing on Control-M working date
September 6 until 1:00 P.M. on Control-M working date September 8.

When both a FROM TIME and an UNTIL TIME value are specified, the relationship
of the New Day Processing time to these values (on a physical clock) determines the
submission window. The logic is as follows:

Chapter 3 Job Production Parameters 675

TIME + DAYS: Runtime Scheduling Parameter

If, when you move forward on the physical clock from the New Day Processing time,
you arrive at the FROM TIME before you arrive at the UNTIL TIME, it means that
New Day processing does not fall between the FROM TIME and UNTIL TIME. In this
case, the submission window runs from the FROM TIME to the UNTIL TIME,
regardless of when the job was ordered.

Example

Assume a New Day Processing time of 8:00 A.M.:

FROM TIME 1400 + 1 DAYS UNTIL TIME 2200 + 3 DAYS

creates a submission window from 2:00 P.M. on Control-M working date September 6
until 10:00 P.M. on Control-M working date September 8, a period of 56 hours.

Example

Assume a New Day Processing time of 10 P.M.:

FROM TIME 2300 + 1 DAYS UNTIL TIME 0500 + 3 DAYS

creates a submission window from 11:00 P.M. on Control-M working date

September 6 until 5:00 A.M. on Control-M working date September 8, a period of
54 hours.

Example

Assume a New Day Processing time of 10:30 P.M.:

FROM TIME 2300 + 1 DAYS UNTIL TIME 2200 + 3 DAYS

creates a submission window from 11:00 P.M. on Control-M working date

September 6 until 10:00 P.M. on Control-M working date September 8, a period of
47 hours.

If, when you move forward on the physical clock from the New Day Processing time,
you arrive at the UNTIL TIME before you arrive at the FROM TIME, it means that
New Day processing falls between the FROM TIME and UNTIL TIME.

676 Control-M for z/OS User Guide

 TIME + DAYS: Runtime Scheduling Parameter

Batch jobs are frequently scheduled for submission during the night. Therefore, when
the New Day Processing time intervenes between the FROM TIME and the UNTIL
TIME, it is likely that, following New Day Processing, the site still wants the job to be
submitted up until the UNTIL TIME, without first waiting for the FROM TIME of the
new day. For this reason, if the New Day Processing time comes between the
FROM TIME and the UNTIL TIME, then regardless of when the job was ordered, the
job is eligible for submission from both:

■ the FROM TIME until the New Day Processing time

■ the New Day Processing time until the UNTIL TIME

Example

Assume New Day Processing time of 4:00 A.M.:

FROM TIME 2300 + 1 DAYS UNTIL TIME 0600 + 3 DAYS

creates a submission window from 11:00 P.M. on Control-M working date

September 6 until 4:00 A.M. on Control-M working date September 8, and from
4:00 A.M. on Control-M working date September 8 until 6:00 A.M. on Control-M
working date September 8, giving a net submission window from 11:00 P.M. on
Control-M working date September 6 until 6:00 A.M. on Control-M working date
September 8.

The character > in the UNTIL TIME subparameter indicates that Control-M must
attempt to submit the job at the FROM TIME if specified, and if this is not possible,
Control-M must submit the job as soon afterwards as possible, even at a later date
(unless the MAXWAIT period has expired).

On Control-M screens 2 and 3, if the UNTIL TIME is >, the UNTIL DAYS
subparameter can not be entered.

Example

Assume a New Day Processing time of 8:00 A.M.:

FROM TIME 2200 + 1 DAYS UNTIL TIME > + DAYS

creates a submission window that begins at 10:00 P.M. on Control-M working date
September 6. If the job has not been submitted by the end of the day, it can be
submitted at any time from the beginning of the following day.

The FROM parameter is ignored when a job is rerun or restarted on a subsequent day.

Specifying the same time and day in both the FROM TIME/DAYS subparameters
and the UNTIL TIME/DAYS subparameters has the same impact as entering no
value in both fields.

Chapter 3 Job Production Parameters 677

TIME + DAYS: Runtime Scheduling Parameter

Example

Submit the job after midnight:

Figure 315 TIME + DAYS Parameter Example

JOB: OPGENBKP LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM OPGENBKP DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 00 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN
CONTROL
RESOURCE
PIPE
FROM TIME 0000 + 1 DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM

In this example, if New Day Processing time is 6:00 A.M., this job can only be
submitted between the hours of midnight and 6:00 A.M. on Control-M working date
September 6.

Time Zone Considerations

The TIME ZONE parameter affects the FROM TIME+DAYS and
UNTIL TIME+ DAYS parameters. For details, please refer to “TIME ZONE: Runtime
Scheduling Parameter” on page 679.

MAXWAIT Considerations
The FROM DAYS and UNTIL DAYS parameters affect the MAXWAIT parameter. For
details, please refer to “MAXWAIT: Basic Scheduling Parameter” on page 528.

678 Control-M for z/OS User Guide

 TIME ZONE: Runtime Scheduling Parameter

TIME ZONE: Runtime Scheduling Parameter

Adjusts the values specified in the TIME parameter to those in a different time zone.

A related parameter is “TIME + DAYS: Runtime Scheduling Parameter” on page 671.

Figure 316 TIME ZONE Parameter Format

Optional. TIME ZONE specifies a time zone using three characters.

General Information
The TIME ZONE parameter appears in the Job Scheduling Definition screen (Screen
2) and the Active Environment Zoom screen (Screen 3.z).

The TIME ZONE parameter uses three characters to define a time zone by reference
to Greenwich Mean Time (UTC). This enables automatic adjustment of the times
specified in some fields of the Job Scheduling Definition screen to the corresponding
times in a time zone other than that in which the system is operating. The fields that
are automatically adjusted are the following:

■ FROM TIME+DAYS
■ UNTIL TIME+DAYS
■ DUE OUT TIME+DAYS
■ SHOUT WHEN TIME+DAYS

If you set the TIME ZONE parameter appropriately, Control-M calculates the
corresponding times automatically, and the job runs only during the hours you
require.

The three-character values used in the TIME ZONE parameter are defined in the
TIMEZONE member in the IOA PARM library. A sample TIMEZONE member is
provided, but you can edit the values as needed. For example, you can use “EST” or
“NYC” instead of “G-5”, which is the default value for US Eastern Standard Time.

Chapter 3 Job Production Parameters 679

TIME ZONE: Runtime Scheduling Parameter

NOTE
Daylight Saving Time is defined differently in different time zones. For more information on
Daylight Savings Time, see the Control-M chapter in the INCONTROL for z/OS Administrator
Guide.

Example
You are running Control-M in London, but want a job to run only when the New
York Stock Exchange is open, between 0900 (9 A.M.) and 1600 (4 P.M.) in New York
(US Eastern Standard Time). US Eastern Standard Time is five hours behind London
time (GMT-5 hours).

1. In the Job Definition screen (Screen 2) or the Active Environment Zoom screen
(Screen 3.Z) set the TIME FROM parameter to 0900 and the UNTIL parameter to
1600.

2. The TIMEZONE member defines GMT-5 hours as EST.

3. Set the TIME ZONE parameter in the same screen to EST. When you press the
Enter key, the Control-M interpretation of your specification is also displayed in
the format (GMTxhh:mm)

where:

■ x is + (Plus) or - (Minus)
■ hh is the hours figure you specified
■ mm is the minutes figure specified, either 00 or 30

4. The job will run between 2 P.M. and 9 P.M. at your site in London. These times
correspond respectively to 9 A.M. and 4 P.M. in New York, the hours when the
New York Stock Exchange is open. In other words, the job runs as if the TIME
FROM was set to 1400 and UNTIL to 2100.

NOTE
In the Job Scheduling Definition screen (Screen 2) and the Active Environment Zoom screen
(Screen 3.Z), the times appear as you specified, as 0900 and 1600 respectively. In the Active
Environment Why screen (Screen 3.?), the times appear with their converted values of 1400
and 2100 respectively.

680 Control-M for z/OS User Guide

 WDAYS: Basic Scheduling Parameter

WDAYS: Basic Scheduling Parameter

Days of the week on which the job must be scheduled.

Related parameters are “DAYS: Basic Scheduling Parameter” on page 426, and
“CONFCAL: Basic Scheduling Parameter” on page 408.

Figure 317 WDAYS Parameter Format

Optional. The WDAYS parameter specifies days of the week on which jobs must be
scheduled, provided other basic scheduling criteria are met.

Values for WDAYS can be specified alone, or they can be specified together with a
calendar specified in the WCAL subparameter. WDAYS and WCAL can also be
specified together with DAYS and DCAL, which are described under “DAYS: Basic
Scheduling Parameter” on page 426.

WDAYS subparameters are described in Table 220.

Table 220 WDAYS Subparameters (part 1 of 2)

Subparameter Description
WDAYS Days of each week in the month on which to schedule a job. (The
months in which to order jobs are specified in the MONTHS
parameter.) Various formats (described later) can be used to specify
WDAYS; for example, 2 means the second day of the week, L2 means
the day before the last day of the week.
Note: At time of installation, the INCONTROL administrator selects
either Sunday or Monday as the “first” day of the week. Your
INCONTROL administrator can tell you whether the week begins on
Sunday or Monday at your site.

The first six days of the week are coded 1 through 6. The last day of
the week is coded 0 (zero). All examples in this chapter assume
Monday is the first day of the week. In these examples, Monday = 1,
Tuesday = 2, ..., Saturday = 6, and Sunday = 0.

Chapter 3 Job Production Parameters 681

WDAYS: Basic Scheduling Parameter

Table 220 WDAYS Subparameters (part 2 of 2)

Subparameter Description
WCAL Name of a calendar containing a predefined set of dates, referred to
as working days, on which a job is to be scheduled. A specified value
must be either a valid member name of 1 through 8 characters, or an
* to indicate that the calendar specified in the CONFCAL parameter
must be used for scheduling. For more information about how to
define, use and modify calendars, see “IOA Calendar Facility” on
page 313.
Note: A calendar specified in WCAL does not have to exist when
defining the WDAYS parameter. However, it must exist when the
job is to be ordered.

Assuming all other basic scheduling criteria are met:

■ When WDAYS are specified without WCAL, the job is scheduled on the specified
days of the week.

■ When WCAL is specified without WDAYS, the job is scheduled on the working
days marked in the WCAL calendar.

■ When WDAYS and WCAL are both specified, scheduling depends on the
combination of working days defined in the calendar and the values or format of
the WDAYS parameter (described below).

■ When both DAYS and WDAYS criteria are specified, scheduling depends on the
connecting AND/OR value specified. For more information, see subparameter
AND/OR in Table 171 on page 426.

Valid Formats for WDAYS

Valid formats for the WDAYS parameter, and how they relate to WCAL, are
described below.

In the non-periodic scheduling formats described in Table 221, n is an integer from 1

through 6 or 0 (zero), where 1 = the first day of the week (Sunday or Monday,
depending on the standard at your site) and 0 = the last day of the week (Saturday or
Sunday).

■ Multiple values can be expressed, separated by commas, in any order.

■ WCAL must not contain the name of a periodic calendar.

682 Control-M for z/OS User Guide

 WDAYS: Basic Scheduling Parameter

Table 221 Non-Periodic Scheduling Formats

Format Description
ALL All days of the week. If ALL is specified, other WDAYS values
cannot be specified with it.
If a WCAL calendar is not defined, schedule the job on all days in the
week.
If a WCAL calendar is defined, schedule the job only on the working
days indicated in the calendar.
n,... Specific days of the week.
If a WCAL calendar is not defined, schedule the job on the specified
days.
If a WCAL calendar is defined, schedule the job only when a day is
defined as a working day both in the WDAYS parameter and in the
WCAL calendar.
+n,... Days of the week in addition to the working days specified in the
WCAL calendar. WCAL is mandatory.
–n,... Order the job on all days except the nth day from the beginning of
the week. WCAL is mandatory.
>n,... Order the job on the indicated day if it is a working day in the WCAL
calendar; otherwise, order the job on the next working day (within
the next seven daysa) that is not negated by a –n value in the
parameter. This format is frequently used for holiday handling.
WCAL is mandatory.
<n,... Order the job on the indicated day if it is a working day in the WCAL
calendar; otherwise, order the job on the last previous working day
(within the preceding seven daysa) that is not negated by a –n value
in the parameter. This format is frequently used for holiday
handling. WCAL is mandatory.
Dn,... Order the job on the nth working day from the beginning of the
week. WCAL is mandatory.
–Dn,... Order the job on all working days except the nth working day from
the beginning of the week. WCAL is mandatory.
Ln,... Order the job on the nth working day counting from the end of the
week. WCAL is mandatory.
–Ln,... Order the job on all working days except the nth working day
counting backward from the end of the week. WCAL is mandatory.
DnWm,... (Where m = 1 through 6). If WCAL is defined, order the job on the
nth working day of the mth week of the month. If WCAL is not
defined, order the job on the mth appearance of the nth day of the
week during the month. A maximum of eleven DnWm values can be
specified. WCAL is optional.
a If none of those seven days is a working day, the job is not ordered.

In the periodic scheduling formats described in Table 222

■ n is any integer from 0 through 6, and i is any valid period identifier.

Chapter 3 Job Production Parameters 683

WDAYS: Basic Scheduling Parameter

■ WDAYS periodic identifiers are counted on a week by week basis. Calculations do

not cross week boundaries, unlike DAYS periodic identifiers, which can cross
month boundaries.

■ The name of a periodic calendar must be specified in WCAL. For details

concerning periodic calendars, see “IOA Calendar Facility” on page 313.

■ A maximum of eight periodic values can be specified in any desired order.

Table 222 Periodic Scheduling Formats

Format Description
DnPi,... Order the job on the nth day of period i in each week, from the
beginning of the week. An * can be entered as the i value to represent
all periods.
–DnPi,... Order the job on all days except the nth day of period i in each week,
from the beginning of the week. An * can be entered as the i value to
represent all periods.
LnPi,... Order the job on the nth day of period i in each week, counting
backward from the last periodic day of the week. An * can be entered
as the i value to represent all periods.
–LnPi,... Order the job on all days in period i except the nth day of period i in
each week, counting from the last periodic day of the week. An * can
be entered as the i value to represent all periods.

WARNING
Before you use the P* format of the periodic scheduling criteria, review example 11 below to
ensure that you are aware of its proper functioning.

General Information
Negative values take precedence over positive values when determining whether a
job is scheduled on a certain date. If a negative value (that is, format –n, –Dn, –Ln,
- DnPi, or –LnPi) in either the DAYS or WDAYS field prevents a job from being
scheduled on a date, the job is not scheduled on that date even if a positive value
(such as Ln) in a basic scheduling parameter would otherwise result in the job being
scheduled on that date.

If periodic and non-periodic values are mixed when specifying the WDAYS
parameter, processing depends on the calendar type specified in the WCAL
parameter:

■ If a non-periodic calendar is specified in the WCAL parameter, only non-periodic

values in the WDAYS parameter are processed; periodic values are ignored. In this
case, negative periodic values (that is, –DnPi, –LnPi) are also ignored and do not
supersede other values.

684 Control-M for z/OS User Guide

 WDAYS: Basic Scheduling Parameter

■ If a periodic calendar is specified in the WCAL parameter, all periodic values and
the negative non-periodic value -n in the WDAYS parameter are processed; all
nonnegative non-periodic values are ignored.

The WDAYS parameter cannot be used with the PDS and MINIMUM parameters.

Examples
The examples in this chapter are based on the following assumptions:

■ The current month is December, 2001.

■ Working days are defined in calendar WORKDAYS, which contains the following
working days (indicated by Y) for December, 2001.

---S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

■ Periodic calendar PERIDAYS contains the following periodic definition for

December 2001. These examples assume that all other days of this calendar are
blank.

---S-------------S-------------S-------------S-------------S---
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
B C A A B B C A A B B C A A B B C A A B B

■ Start of the week is defined as Monday. Weeks start on the following dates in
December 2001: 3rd, 10th, 17th, 24th, and 31st.

At the end of each example, asterisks in a December 2001 calendar indicate the days
on which the job is scheduled.

Example 1

Schedule the job on every Sunday and Monday.

WDAYS 0,1

The job is scheduled on the days of the month indicated by an asterisk:

Chapter 3 Job Production Parameters 685

WDAYS: Basic Scheduling Parameter

Figure 318 WDAYS Parameter Example 1

Example 2

Schedule the job on all working days and on all Saturdays.

WDAYS +6
WCAL WORKDAYS

The job is scheduled on the days of the month indicated by an asterisk:

Figure 319 WDAYS Parameter Example 2

Example 3

Schedule the job on Sunday, if it is a working day. If Sunday is not a working day,
schedule the job on the first preceding working day that is not a Friday.

WDAYS -5,<0
WCAL WORKDAYS

The job is scheduled on the days of the month indicated by an asterisk:

Figure 320 WDAYS Parameter Example 3

Example 4

Schedule the job on Monday of the 1st week.

WDAYS D1W1

686 Control-M for z/OS User Guide

 WDAYS: Basic Scheduling Parameter

The job is scheduled on the days of the month indicated by an asterisk:

Figure 321 WDAYS Parameter Example 4

Example 5

Schedule the job on all working days except Mondays and Fridays.

WDAYS -D1,-L1
WCAL WORKDAYS

The job is scheduled on the days of the month indicated by an asterisk:

Figure 322 WDAYS Parameter Example 5

Example 6

Each week, schedule the job on the 1st day of period A in that week, and on all days
of period B except the second day of period B in any week.

WDAYS D1PA,-D2PB
WCAL PERIDAYS

The job is scheduled on the days of the month indicated by an asterisk:

Figure 323 WDAYS Parameter Example 6

Chapter 3 Job Production Parameters 687

WDAYS: Basic Scheduling Parameter

Example 7

Schedule the job on each Monday and on the 1st day of the month.

DAYS 1
AND/OR OR
WDAYS 1

The job is scheduled on the days of the month indicated by an asterisk:

Figure 324 WDAYS Parameter Example 7

Example 8

Schedule the job on the 3rd day of the month provided it is a Monday.

DAYS 3
AND/OR AND
WDAYS 1

The job is scheduled on the days of the month indicated by an asterisk:

Figure 325 WDAYS Parameter Example 8

Example 9

Schedule the job on the last Monday of the month.

DAYS L1,L2,L3,L4,L5,L6,L7
AND/OR AND
WDAYS 1

The job is scheduled on the days of the month indicated by an asterisk:

688 Control-M for z/OS User Guide

 WDAYS: Basic Scheduling Parameter

Figure 326 WDAYS Parameter Example 9

Example 10

Schedule the job on the 1st, 7th and 15th day of the month if they are both Saturdays
and working days. If the day of the month (1st, 7th, 15th) is not a Saturday, do not
schedule the job. If the day of the month is a Saturday, but it is not a working day,
schedule the job on the next working day.

DAYS 1,7,15
AND/OR AND
WDAYS 6
CONFCAL WORKDAYS
SHIFT >

The job is scheduled on the days of the month indicated by an asterisk:

Figure 327 WDAYS Parameter Example 10

Example 11

■ Schedule a job, on a weekly basis, on the first day of period C, using periodic
calendar PER, in the month of August 2006. The first day of the week is defined as
Monday (SWEEK=MON) :

The months of July and August are defined in the periodic calendar PER as
follows:

J S M
U 30 31
L C C

A T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T
U 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
G C C C C C D D D D D D D A A A A A A A B B B B B B B C C C C C

WDAYS D1PC WCAL PER

Chapter 3 Job Production Parameters 689

WDAYS: Basic Scheduling Parameter

The job will be scheduled on the following days in August: Sunday the 27th and
Monday the 28th.

The job is not scheduled on August 1st, because August 1st is contained in the
week July 31 through August 6, and therefore, the first day of period C in that
week is July 31.

The job is scheduled on August 27, because it is the first (and only) day in period C
of the week August 21 through August 27. The job is also obviously scheduled on
August 28.

■ Schedule a job, on a weekly basis, according to the criteria D1P* (the first day of
any period), using periodic calendar PER (defined above), in the month of August
2006.

WDAYS D1P* WCAL PER

The job will be scheduled on August 7, 14, 21, and 28 only. The job will not be
scheduled on August 6, 13, 20, or 27, because even though those dates contain the
first day of a period in the respective week, the D1P* criterion has already been
satisfied by a previous day (in a different period) in that same week.

690 Control-M for z/OS User Guide

 Chapter

4
4 CONTROL-M Event Manager (CMEM)
This chapter includes the following topics:

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Types of Events Managed by CMEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Types of Actions That CMEM Can Perform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
CMEM Rule Ordering, Triggering and Deactivation. . . . . . . . . . . . . . . . . . . . . . . 694
CMEM AutoEdit Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
On Spool Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Support for ON DSNEVENT and ON STEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
CMEM Support for FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
CMEM Support for IBM FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Rule Parameters – Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Event Selection Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Action Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Parameter Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
DESCRIPTION: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
DO statement: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
DO COND: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
DO FORCEJOB: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
DO RULE: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
DO SHOUT: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
DO STOPJOB: Action Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
GROUP: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
MODE: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
ON statement: Event Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
ON DSNEVENT: Event Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
ON JOBARRIV: Event Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
ON JOBEND: Event Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
ON STEP: Event Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
OWNER: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
RUNTSEC: General Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
THRESHOLD: Runtime Scheduling Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

Chapter 4 CONTROL-M Event Manager (CMEM) 691

Overview

Overview
The CONTROL-M Event Manager (CMEM) facility enables CONTROL-M to perform
specified actions in response to external events. External events are events in the
system that occur outside the direct control of CONTROL-M, such as submission of a
job not under the control of the CONTROL-M monitor.

The CMEM facility is an optional facility based on a monitor and a subsystem.

The CMEM facility utilizes sets of user-defined rules that specify events to monitor
and actions to perform if a specified event occurs. These rules are defined online
through the CMEM Rule Definition facility.

Multiple rules can be defined in a table (member) in a standard partitioned data set
(library). Related rules are usually defined in the same table. Multiple tables can be
defined in a library, and multiple CMEM rule libraries can be defined.

Types of Events Managed by CMEM

The CMEM facility handles the following events. These can be specified in ON
statements in the rule:

Table 223 Events handled by CMEM

Event Description
DSNEVENT Data set disposition, such as cataloged, deleted or kept, during step
termination or dynamic decollation, or the occurrence of a NOT
CATLGD 2 event, when a data set name is created in a job step but
not cataloged because its name already exists in the MVS catalog.
Specified in an ON DSNEVENT statement in the rule.
JOBARRIV Arrival of a job on the JES spool from any source.

Examples are:

■ jobs submitted by a TSO user or by CICS

■ jobs received over an NJE network

Specified in an ON JOBARRIV statement in the rule.

JOBEND Completion of a job regardless of its source. Specified in an ON
JOBEND statement in the rule.
STEP Termination of a job step. Specified in an ON STEP statement in the
rule.

692 Control-M for z/OS User Guide

 Types of Actions That CMEM Can Perform

Types of Actions That CMEM Can Perform

Any combination of the following actions can be performed when the specified event
occurs. They are specified in DO statements in the rule:

■ add or delete a prerequisite condition

Prerequisite conditions can be added to or deleted from the IOA Conditions file.
This may trigger the submission of jobs in the Active Jobs file. Specified in a DO
COND statement in the rule.

■ force a job or table

A CONTROL-M table or individual job can be forced (that is, ordered to the Active
Jobs file regardless of its basic scheduling criteria). Specified in a DO FORCEJOB
statement in the rule.

Jobs can be forced for one of the following reasons:

— to start a new process in CONTROL-M (that is, new job submission)

— to enable CONTROL-M to assume full control of an externally submitted job

that triggers the event; these jobs are referred to as On Spool jobs, discussed
under “On Spool Jobs” on page 695.

■ stop the job in which the event occurs

At the end of the current job step, terminate the job in which the event occurred.
Specified in a DO STOPJOB statement in the rule.

The following actions can be defined if CONTROL-O is active:

■ invoke a CONTROL-O rule

CONTROL-O rules can be invoked within the current rule. Specified in a DO

RULE statement in the rule.

■ send a message

Messages can be sent to specified locations through the CONTROL-O Shout

facility. Specified in a DO SHOUT statement in the rule.

Chapter 4 CONTROL-M Event Manager (CMEM) 693

CMEM Rule Ordering, Triggering and Deactivation

CMEM Rule Ordering, Triggering and Deactivation

CMEM tables, along with their rules, are usually ordered (loaded to memory) when
CMEM is started. They can also be refreshed or loaded by an operator command, or
manually using the FORCE option in the CMEM Table List screen.

Once a CMEM rule has been loaded in memory, the occurrence of the events
specified in its ON statements trigger the rule. All DO statements in the rule are then
performed.

More than one rule can be triggered by the occurrence of an event. An event triggers
each rule whose ON statement matches the event.

Generally, all actions from all triggered rules are performed.

The one exception occurs when multiple rules are triggered by the same job arrival
event and each of the triggered rules contains DO FORCEJOB statements. In this case,
the DO FORCEJOB statements of the first triggered rule are performed, but the DO
FORCEJOB statements of the other rules triggered by the event are not performed.
For more information, see “On Spool Jobs” on page 695.

CMEM rules remain activated, that is, they remain in memory, until they are
overridden by the reloading of the rule table or deleted by an operator command.

CMEM AutoEdit Variables

The CMEM facility supports its own set of AutoEdit variables. No other AutoEdit
variables can be used by the CMEM facility. Furthermore, in CONTROL-M, these
variables can only be specified in CMEM rules, not in job scheduling definitions or
JCL.

CMEM AutoEdit variables are resolved upon triggering of the rule. Available CMEM
AutoEdit variables are:

Table 224 CMEM AutoEdit Variables (part 1 of 2)

Variable Description
%%$Dn nth qualifier of the data set name. For example, if the data set name is
AAA.BBB.CCC, %%$D2 resolves to BBB. Valid only for rules
containing an ON DSNEVENT statement.
%%$DSN Name of the data set handled by the rule. Valid only for rules
containing an ON DSNEVENT statement.

694 Control-M for z/OS User Guide

 On Spool Jobs

Table 224 CMEM AutoEdit Variables (part 2 of 2)

Variable Description
%%$DSNDISP Disposition of the data set handled by the rule. Valid only for rules
containing an ON DSNEVENT statement.
Possible values are:
■ C – cataloged
■ D – deleted
■ K – kept
■ N – NOT CATLG2
■ R – retained
■ S – scratched
■ U – uncataloged

%%$JNAME Job name. Valid in rules for all types of events.

%%$SABEND System abend code of the step whose termination triggered the rule.
%%$STEPCC Completion code of the step whose termination triggered the rule.
%%$UABEND User abend code of the step whose termination triggered the rule.

On Spool Jobs
On Spool jobs are jobs or started tasks that are submitted externally to CONTROL-M,
such as jobs submitted by TSO users or CICS, or jobs received over the NJE network,
but are brought under the control of the CONTROL-M monitor using a CMEM rule.

The CMEM rule that causes a job to be an On Spool job, that is, a CMEM rule that
brings the external job under the control of the CONTROL-M monitor, must be an
ON JOBARRIV rule or CONTROL-O event (ON DSNEVENT or ON STEP) with a DO
FORCEJOB statement. To inform CONTROL-M that this is an On Spool job and not a
regular FORCEJOB request, the job scheduling definition forced by the DO
FORCEJOB must "match" the arriving job, as described below.

CONTROL-M controls the entire life cycle of the job, from determining when to
execute the job to performing job post-processing, according to the forced job
scheduling definition.

CONTROL-M processes On Spool jobs slightly differently than it processes regular

jobs. CONTROL-M does not submit the job because the job has already been
submitted. Instead, CONTROL-M releases the job (if held) when the runtime
scheduling criteria are met.

Once the job starts execution, whether the job previously required releasing or not, it
is controlled by CONTROL-M in the same way that CONTROL-M controls regular
jobs. CONTROL-M waits for the job to finish, reads its sysout, and performs all
post-processing actions defined in the job scheduling definition.

Chapter 4 CONTROL-M Event Manager (CMEM) 695

On Spool Jobs

Creating On Spool Jobs

The following components are necessary to create On Spool jobs:

1. job on spool

2. CMEM rule

3. job scheduling definition

Below is a detailed explanation of what must be defined for each of the above
components to create an On Spool job.

Job On Spool
The job must have the following characteristics:

■ The job must be submitted with TYPRUN=HOLD to delay its execution and
permit CONTROL-M to determine when to run the job.

■ The MSGCLASS sysout of the job:

— for JES3 users: must be equal to the CONTROL-M SYSOUT held class
— for JES2 users: can be any held SYSOUT class

This enables CONTROL-M to read the job sysout and perform post-processing
according to the job scheduling definition.

CMEM Rule
The CMEM rule definition must contain the following:

■ ON JOBARRIV or CONTROL-O Event (ON DSNEVENT or ON STEP) statement

The job name specified in the ON JOBARRIV/ON DSNEVENT/ON STEP

statement in this rule must match the name of the job to be monitored. It can be a
full job name, or it can be a mask if a group of jobs is to be monitored. For more
information, see “ON JOBARRIV: Event Parameter” on page 741, “ON
DSNEVENT: Event Parameter” on page 736, or “ON STEP: Event Parameter” on
page 745.

NOTE
CONTROL-O users are advised that message rules triggered by $HASP395 (under JES2) or
IEF404I (under JES3) are treated the same as JOBEND rules.

696 Control-M for z/OS User Guide

 On Spool Jobs

■ DO FORCEJOB statement

The first DO FORCEJOB statement in the rule must force a matching job
scheduling definition, described immediately below. For more information, see
“DO FORCEJOB: Action Parameter” on page 715.

When monitoring for a group of jobs via job name masking, the JOB parameter in
the DO FORCEJOB statement must specify the CMEM AutoEdit variable
%%$JNAME. This allows the CONTROL-M monitor to use the job name mask
when performing the job name match process in the table. Using this method
allows a single CMEM rule to act together with a single job scheduling definition
(whose MEMNAME specifies the same job name mask) for jobs that require
similar tracking requirements.

Job Scheduling Definition

The job scheduling definition must have the following characteristics:

■ The job scheduling definition must be forced by the first DO FORCEJOB statement
in the CMEM rule.

■ The MEMNAME value in the job scheduling definition must match the name of
the external job. A mask can be specified in the MEMNAME field if the same job
scheduling definition is used for more than one job.

■ Appropriate runtime scheduling criteria for the job must be defined in the job
scheduling definition. This enables CONTROL-M to control the execution of the
job, that is, when the job must be run.

■ Desired post-processing actions must be defined in the job scheduling definition.

Handling On Spool Jobs

On Spool jobs are handled as follows:

■ When the job arrival event occurs, CONTROL-M forces the requested table or job.

If the MEMNAME value in the requested table or job does not match the name of
the arriving job, the table or job is forced and processed regularly by CONTROL-M
(a job is submitted when its runtime scheduling criteria are met, and so on).

Chapter 4 CONTROL-M Event Manager (CMEM) 697

On Spool Jobs

If the MEMNAME value in the requested table or job matches the name of the
arriving job, the job becomes an On Spool job and CONTROL-M performs the
following actions:

— replaces the MEMNAME mask (if a mask was specified in MEMNAME) with
the name of the arriving job

— assigns the job ID of the job that triggered the event to the forced job

— forces the job; for details and exceptions see “On Spool Job Scheduling
Definition Considerations” on page 698

The forced job appears in the Active Environment screen with status WAIT
SCHEDULE ON SPOOL.

■ CONTROL-M starts processing the forced job when all runtime scheduling criteria
defined in the job scheduling definition are satisfied. If there are no runtime
scheduling criteria in the job scheduling definition, CONTROL-M starts processing
the job immediately.

■ CONTROL-M looks for the job in the spool, to release it, if required.

— If the external job is waiting for execution in HELD state, that is, if the job arrives
on spool with TYPRUN=HOLD, CONTROL-M releases it for execution.

— Otherwise, CONTROL-M verifies that the job is still in the spool (waiting for
execution, executing or ended) before deciding to perform post-processing.

■ CONTROL-M waits for the job to finish execution, reads its SYSOUT, analyzes the
execution results and performs all the post-processing actions defined in the job
scheduling definition.

NOTE
CONTROL-M can only handle NJE jobs as On Spool jobs when they originate on the same
NJE node as that on which CONTROL-M is running.

On Spool Job Scheduling Definition Considerations

Job Forcing Considerations

Only one On Spool job can be created in response to a job arrival event. However, in
several cases, multiple DO FORCEJOB actions might match the arriving job. Each of
these cases and the job forcing logic applied to them, to prevent multiple On Spool
processes for the same external job, are described below.

698 Control-M for z/OS User Guide

 On Spool Jobs

■ The job arrival rule contains multiple DO FORCEJOB requests. Each might match
the arriving job. In this case, job forcing logic is as follows.

The On Spool process, the match between the external job name and MEMNAME,
is performed for the first DO FORCEJOB in the first matching job arrival rule only:

— If a match is found, the job is an On Spool job.

— If a match is not found, the job is not an On Spool job, even if subsequent DO
FORCEJOB actions might match.

In either case, all subsequent DO FORCEJOB statements in the same rule (if they
exist) are handled normally, that is, not as forcing On Spool jobs.

■ The DO FORCEJOB forces a table in which more than one MEMNAME matches
the arriving job. In this case, job forcing logic is as follows.

If a table containing more than one job is forced, by the first DO FORCEJOB
statement in the rule, as described above, the first matching job causes the job to be
an On Spool job. All the other jobs in the table are forced as regular CONTROL-M
jobs, even if they match the job name of the external job.

■ Multiple job arrival rules are triggered by the same job arrival event, and each rule
contains one or more DO FORCEJOB statements that might match the arriving job.
In this case, job forcing logic is as follows.

Only the DO FORCEJOB statements from the first triggered rule are executed, as
described above. DO FORCEJOB from all other triggered job arrival rules are
ignored.

NOTE
If an On Spool job was purged from the spool but still remains in the Active Jobs file, and
another job with the same name arrives on spool and is assigned the same job ID, that later job
is not forced.

JCL Management Considerations

When defining JCL, the following issues must be considered:

■ Any attempt to rerun the job, that is, as a cyclic job, by a DO RERUN statement, or
by a manual rerun request, might fail if the JCL of the job is not found in the library
specified in the MEMLIB parameter of the job scheduling definition.

Chapter 4 CONTROL-M Event Manager (CMEM) 699

Support for ON DSNEVENT and ON STEP

■ If the job is not submitted with TYPRUN=HOLD, CONTROL-M cannot determine

when the job runs, even if runtime scheduling criteria are defined. In this case, the
job might start executing before all the runtime scheduling criteria are satisfied.
Post-processing, however, is not performed by CONTROL-M until the runtime
scheduling criteria are satisfied.

■ Since On Spool jobs are not submitted by CONTROL-M:

— The JCL of the On Spool job cannot contain AutoEdit statements, and SETVAR
statements in the job definition are ignored. This is because the job is not
submitted by CONTROL-M.

— Because the job is not submitted by CONTROL-M, the following job scheduling
definition parameters are ignored:

■ SCHENV
■ SYSTEM ID
■ NJE NODE

— NJE enhanced tracking support is inoperative

Support for ON DSNEVENT and ON STEP

A DSNEVENT occurs when a file is deallocated, on the happening of one of the
following events:

■ the dynamic deallocation of a file

■ deallocation of a file on the termination of a job STEP
■ deallocation of a file on the termination of a job

A STEP event occurs when a step ends.

To support the ON DSNEVENT and ON STEP parameters, CMEM intercepts the

messages written by JES2 or JES3 to JESYSMSG. JESYSMSG is the third SYSOUT of
the job.

The DSNEVENT process consists of the following parts:

700 Control-M for z/OS User Guide

 Support for ON DSNEVENT and ON STEP

1. When a job, or STC, or TSO user session starts, the system issues either the IEF403I
message or the IEF125I message. CMEM intercepts this message, and checks
whether there is at least one ON DSNEVENT or ON STEP rule for the job. If there
is at least one rule for the job, CMEM creates the DSNEVENT environment in the
address space.

NOTE
A job can only be handled by one CMEM. Therefore, in an environment where more than one
CMEM can be active, for example, TEST and production, you must be accurate in defining the
ON DSEVENT.

The DSNEVENT environment for an address space remains intact when a new CONTROL-O
instance is started while the previous CONTROL-O instance is still active.

2. CMEM intercepts allocation, deallocation, and step termination messages, and

determines whether there is at least one ON DSEVENT or ON STEP event. If so,
CMEM determines

■ whether the DSNEVENT or STEP events fulfil the selection criteria in the rule
■ whether, in the case of a DSNEVENT, the file is a new file or already exists

NOTE
A DSNEVENT can be triggered only on the CONTROL-O/CMEM that runs on the same
z/OS system on which the event occurs. Even a focal CONTROL-O or CMEM in a Sysplex
environment is insufficient. This is because CONTROL-O or CMEM intercepts the messages
written to JESYSMSG while they are being written, which can be done only on the same
system where the event happens.

3. CMEM triggers the rule according to the following principles:

A. An ON STEP rule is always triggered when a STEP ends. However, a STEP is

ignored when a rule is not executed due to one of the following:

■ a JCL error
■ failure to encounter a previous step condition code

B. An ON DSNEVENT can occur when a deallocation message is written, or when

a step terminates. Whether it occurs depends on

■ how the file is deallocated

■ the setting of the STEPRC field in the DSNEVENT criteria, as follows:

— If the value of STEPRC is null, the rule is triggered at the time of deallocation.
— If the value of STEPRC is other than null, the rule is rechecked at the
termination of the step to ascertain the STEPRC criteria.

Chapter 4 CONTROL-M Event Manager (CMEM) 701

Support for ON DSNEVENT and ON STEP

C. Deallocation occurs when

■ the file is dynamically deallocated

■ the step ends, in the case of all allocated files in this step, whether the files
were allocated by JCL or were dynamically allocated
■ the job terminates, in the case of any file that was not released on step
termination, for example, if DISP is set to PASS

For CMEM actions to be triggered in this way, the following conditions must be
satisfied:

■ Either the IEF403I message or the IEF125I message must appear in the job log.

■ The job, STC, or TSO user session must have its MSGLEVEL set to (x,1), to ensure
that allocation, deallocation and step termination messages are written to the
JESYSMSG. It is not sufficient for these messages to appear only in the system log
or job log.

■ At least one ON DSNEVENT or ON STEP rule must be ordered and ready before
the job, STC, or TSO user session starts.

NOTE
If the value of ON DSNEVENT is * (asterisk), every job, STC, or TSO user session is within the
DSNEVENT environment. BMC Software recommends that you do not use this type of
DSNEVENT because of
■ the overhead that results from CMEM analyzing every message written to the JESYSMSG
■ the CMEM limitation that only one CMEM can handle a DSNEVENT for a job
In an environment where more than one CMEM is active on the same system, this
definition may cause the wrong CMEM to trap the event.

Regular Allocation and Deallocation

In the case of regular files, meaning files not managed by SMS, CMEM traps the
following deallocation messages:

■ IEF283I
■ IEF285I
■ IEF287I

702 Control-M for z/OS User Guide

 CMEM Support for FTP

SMS Support
In the case of SMS-managed data sets, CMEM traps the IGD101I and IGD104I
allocation and deallocation messages, and determines whether the file is new
according to the following rules:

■ If both messages are issued, the file is new.

■ If the IGD101I message is not found, CMEM treats the file as not new.

Generation Data Sets (GDG)

For CMEM to support Generation Data Sets (GDG), the following messages must be
found:

■ IGD105I
■ IGD107I
■ IGD108I
■ IGD17101

NOTE
The messages that are required by CMEM for the purposes of this and the preceding sections
are liable to be changed as a result of IBM changes in data set processing.

CMEM Support for FTP

CMEM actions can be triggered by the transfer of files by FTP products.

In order to enable CMEM rules to be triggered by such file transfers, do the following:

1. Use one of the following methods to insert the expression MSGLEVEL=(1,1) in

the STC of the FTP product:

■ Customize the JESxPARM member in the SYS1.PARMLIB library.

■ Modify the job statement in the PROCLIB library member that contains the
procedure JCL for the STC of the FTP product.

2. Start the CMEM monitor with at least one DSNEVENT rule that refers to the STC
of the FTP product. You can use a dummy DSNEVENT rule that forces CMEM to
monitor the STC of the FTP product.

3. Start the FTP product.

Chapter 4 CONTROL-M Event Manager (CMEM) 703

CMEM Support for IBM FTP

4. Modify existing rules, or order new rules (or do both). Rules that have been
modified or ordered before a file reaches the FTP server are applied to all files
subsequently transferred by the FTP product.

CMEM triggers rules when the requirements of an ON DSNEVENT statement are

satisfied. If an FTP product fails to transmit a data set and issues a message relating to
this failure, CMEM cannot react to that message. However, you can use CMEM rules
to react to FTP product messages.

NOTE
Do not use the STEPRC subparameter in conjunction with the FTP* setting for ON
DSNEVENT, because the same FTP procedure can serve many requests before being
terminated.

CMEM Support for IBM FTP

The IBM FTP process is executed under the OMVS address space, which is BPXAS.
BPXAS address spaces do not usually write messages to the JESYSMSG.

In order to enable CMEM DSNEVENT support for IBM FTP, the following occurs:

1. When the CMEM monitor starts, it activates the OpenEdition interface for
processes in the BPXAS. Having done this, CMEM issues the following messages:

CTO782I SUBSYSTEM REGISTERED WITH OPENEDITION INTERFACE

CTO783I INITIALIZATION OF OPENEDITION ENVIRONMENT ENDED

SUCCESSFULLY

When CMEM initialization is complete, message CTO147I is displayed. After this,

CMEM gets control every time that an OpenEdition process starts in the BPXAS
address space.

2. When a new process starts in the BPXAS, the interface routine issues the CTO403I
pseudo-message. This pseudo-message causes CMEM to simulate IEF403I
processing, which is described in “Support for ON DSNEVENT and ON STEP” on
page 700.

3. Under z/OS, IBM FTP functions as a UNIX process running under z/OS.
Therefore it follows the UNIX standard, one aspect of which is that the name of the
job is set to the user ID of the person who issued the FTP request. This UNIX
standard creates a problem, because the operator who writes the CMEM rule must
know at that stage which user will issue an FTP request.

704 Control-M for z/OS User Guide

 Rule Parameters – Summary

The solution to this problem is to use the statement ON DSNEVENT FTP*. The
result is that any FTP process will trigger the rule.

NOTE
Do not use the STEPRC subparameter in conjunction with the FTP* setting for ON
DSNEVENT, because the same FTP procedure can serve many requests before being
terminated.

Rule Parameters – Summary

Figure 328 CMEM Rule Definition Screen
RL: JOBNAM1 LIB CTM.PROD.RULES TABLE: CMEMRULE
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBARRIV = JOBNAM1 JTYPE SMFID SYSTEM And/Or/Not
OWNER CTMCTLM GROUP MODE PROD RUNTSEC NONE
THRESHOLD
DESCRIPTION CONVERSION: ON JOB JOBNAM1 ARRIVAL FORCEJOB
DESCRIPTION
===========================================================================
DO FORCEJOB = TABLE TABLE1 JOB DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

The parameters of the CMEM Rule Definition screen are divided into the following
categories:

■ Event Selection Parameters

■ General Parameters
■ Action Parameters

A brief summary of the parameters in each category is provided on the following

pages. This is followed by a detailed description of each parameter in alphabetical
order.

Chapter 4 CONTROL-M Event Manager (CMEM) 705

Event Selection Parameters

Event Selection Parameters

The following parameters identify the events that trigger the rule.

Table 225 CMEM Event Selection Parameters

Parameter Description
ON statement Event criteria that must be satisfied for the rule to be triggered.
Subparameters may be displayed. Valid ON statements are:
■ ON DSNEVENT – name (or mask) of the job to be monitored for
data set or NCT2 events
■ ON JOBARRIV – job name (or mask) of a job or started task that
arrived on the JES spool from any source
■ ON JOBEND – job name (or mask) of a job or started task that
terminated
■ ON STEP – job step whose termination is to be monitored for a
specified return code or status

Subparameters of these parameters are described in the detailed description of each

parameter later in this chapter.

General Parameters
The following parameters contain general information about the rule.

Table 226 CMEM General Parameters

Parameter Description
OWNER ID of user who requests CMEM services
GROUP Name of a group of rules
MODE CMEM rule operation mode
RUNTSEC Type of runtime security checks to be performed for the rule
DESCRIPTION Free-text description of the rule definition

706 Control-M for z/OS User Guide

 Action Parameters

Action Parameters
The following parameters (DO statements) specify actions to be performed.

Table 227 CMEM Action Parameters

Parameter Description
DO statement Action to be performed when the rule is triggered. Subparameters
may be displayed. Valid DO statements are:
■ DO COND – add or delete a prerequisite condition
■ DO FORCEJOB – force a job order under CONTROL-M
■ DO STOPJOB – stop execution of the remaining steps of the job
that triggered the rule
The following actions can be defined if CONTROL-O is active:
■ DO RULE – invoke a CONTROL-O rule from within the current
rule
■ DO SHOUT – issue a message to a specified destination using
the Shout facility

Chapter 4 CONTROL-M Event Manager (CMEM) 707

Parameter Descriptions

Parameter Descriptions
The following pages contain detailed descriptions of all parameters available in the
CMEM Rule Definition screen. Parameters are arranged in alphabetical order. Within
each parameter, subparameters are arranged according to the order of the fields on
the screen.

Each parameter begins on a new page, including:

■ a brief explanation of the purpose of the parameter

■ the format required for defining the parameter within an extract of the CMEM
screen

■ general information explaining the parameter and its usage

■ where applicable, some practical examples illustrating implementation of the

parameter

For more information on the CMEM Rule Definition facility, see Chapter 2, “Online
Facilities.”

708 Control-M for z/OS User Guide

 DESCRIPTION: General Parameter

DESCRIPTION: General Parameter

Description of the rule to be displayed in the Rule List screen.

Figure 329 DESCRIPTION Parameter Format

Optional. The DESCRIPTION parameter consists of one or more lines that can
contain free text. Each line is 61 characters in length. Upon typing text in a
DESCRIPTION line and pressing Enter, a new DESCRIPTION line is opened.

General Information
The DESCRIPTION parameter does not affect rule processing. The text entered in the
first DESCRIPTION line appears to the right of the rule name in the Rule List screen.
It is intended to let the user know at a glance the purpose of, or some other key
information about, the rule. The text can be typed in any language.

Example
The description START THE BATCH SHIFT appears next to the rule name in the Rule
List screen.

Chapter 4 CONTROL-M Event Manager (CMEM) 709

DESCRIPTION: General Parameter

Figure 330 DESCRIPTION Parameter Example

RL: CICSPROD LIB CTM.PROD.RULES TABLE: STCS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBEND = CICSPROD JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP CICS MODE PROD RUNTSEC
THRESHOLD
DESCRIPTION START THE BATCH SHIFT
DESCRIPTION
===========================================================================
/* INFORM CONTROL-M THAT THE BATCH CAN BE STARTED
DO COND = START-BATCH ODAT +
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

710 Control-M for z/OS User Guide

 DO statement: Action Parameter

DO statement: Action Parameter

Actions to perform when the rule is triggered.

Figure 331 DO Parameter Format

At least one DO statement must be specified in each rule. Specify DO statements as

follows:

■ Type the action keyword (such as COND) in the DO field and press Enter.

■ When required, subparameter fields are displayed. Fill in the subparameters and
press Enter again.

Multiple DO statements can be specified. After entering a DO statement, another DO

line is automatically displayed. Multiple DO statements have an AND relationship
and are performed sequentially.

The following are valid DO actions. Each is discussed individually in this chapter.

Table 228 DO Parameter Actions

Action Description
DO COND Adds and/or deletes one or more prerequisite conditions
DO FORCEJOB Forces a job
DO STOPJOB Stops execution of the job that triggered the rule, at the end of the
current step
If CONTROL-O is active:
DO RULE Invokes a CONTROL-O rule
DO SHOUT Sends a message to a specified destination

Chapter 4 CONTROL-M Event Manager (CMEM) 711

DO COND: Action Parameter

DO COND: Action Parameter

Add or delete prerequisite conditions.

Figure 332 DO COND Parameter Format

Optional. Type the word COND (or its abbreviation CON) in the DO field and press
Enter. The following subparameters are displayed:

Table 229 DO COND Subparameters (part 1 of 2)

Subparameter Description
condition User-supplied, descriptive name of 1 through 20 characters used to
identify the condition. Only trailing blanks are permitted.
dateref 4-character date reference associated with the condition. Valid
values are:

■ date – specific date, in mmdd or ddmm format, depending on the

site standard
■ ODAT – resolves to the current installation working date
Default.
■ DATE – resolves to the current system date
■ STAT – static
Indicates that the condition, such as IMS-ACTIVE, is not
date-dependent
Note: Before STAT was introduced, date 0101 was recommended
to be used in conditions that were not date-dependent. Unlike
0101, STAT is not a date, and it operates differently. Always use
STAT when defining conditions that are not date-dependent.
■ **** /$$$$ – all dates
Valid only for deleting prerequisite conditions. Either value (****
or $$$$) results in the deletion of all matching prerequisite
conditions regardless of date.

712 Control-M for z/OS User Guide

 DO COND: Action Parameter

Table 229 DO COND Subparameters (part 2 of 2)

Subparameter Description
cond_opt Indicator of whether to add or delete the prerequisite condition.
Valid values are:

■ + – add the prerequisite condition

■ - – delete the prerequisite condition

General Information
When a rule containing a DO COND statement is triggered, the designated
prerequisite conditions are added or deleted (as specified) from the IOA Conditions
file by the CONTROL-M monitor.

A prerequisite condition can define any user-specified situation. The following are a
few examples of prerequisite conditions:

IMS-ACTIVE
WEEKEND
SALARY-OK

Prerequisite conditions created or deleted by the DO COND parameter can activate

or deactivate CONTROL-O rules, or trigger (or stop) the execution of processes (jobs,
and so on) in CONTROL-M, CONTROL-D and other environments.

CMEM AutoEdit System variable %%$JNAME and, for ON DSNEVENT events,

variables %%$Dx, %%$DSN, or %%$DSNDISP can be specified in condition names in
DO COND statements and are replaced (resolved) at time of rule triggering. For more
information, see “CMEM AutoEdit Variables” on page 694.

Representative dates (such as ODAT) are resolved to the actual corresponding date in
the site-standard format.

NOTE
Long condition names cannot be used in CMEM rule definitions.

Example

Example 1

When job CICSPROD ends, this rule sets the condition necessary for the batch shift to
begin.

Chapter 4 CONTROL-M Event Manager (CMEM) 713

DO COND: Action Parameter

Figure 333 DO COND Parameter – Example 1

RL: CICSPROD LIB CTM.PROD.RULES TABLE: STCS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBEND = CICSPROD JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP CICS MODE PROD RUNTSEC
THRESHOLD
DESCRIPTION START THE BATCH SHIFT
DESCRIPTION
===========================================================================
/* INFORM CONTROL-M THAT THE BATCH CAN BE STARTED
DO COND = START-BATCH ODAT +
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

Example 2

When a data set with name prefix TRAN arrives by file transfer product CONNECT
DIRECT (formerly called NDM), add prerequisite condition FILE-RECEIVED to
notify CONTROL-M that the data set was received.

Figure 334 DO COND Parameter – Example 2

RL: NDM LIB CTM.PROD.RULES TABLE: MGT
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON DSNEVENT = NDM JTYPE SMFID SYSTEM
DSN TRAN.* DISP CATLG
PROCSTEP PGMSTEP STEPRC OK And/Or/Not
OWNER ADMIN GROUP NDM MODE RUNTSEC
THRESHOLD
DESCRIPTION NOTIFY CONTROL-M THAT TRAN DATASET ARRIVED VIA NDM
DESCRIPTION
===========================================================================
DO COND = FILE-RECEIVED ODAT +
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

714 Control-M for z/OS User Guide

 DO FORCEJOB: Action Parameter

DO FORCEJOB: Action Parameter

Force a job.

Figure 335 DO FORCEJOB Parameter Format

Optional. Type the word FORCEJOB (or its abbreviation F) in the DO field and press
Enter. The following subparameters are displayed:

Table 230 DO FORCEJOB Subparameters

Subparameter Description
TABLE Name of a table, up to eight characters. Mandatory.
JOB Name of the job to be triggered. Optional. If blank, all jobs in the table
are forced.

If AutoEdit System variable %%$JNAME is specified, it resolves to the

name of the job that triggered the rule.
DATE Scheduling date of the job. Valid values are:

■ date – specific 6-digit date, in format mmddyy, ddmmyy, or

yymmdd, depending on the site standard
■ ODAT – resolves to the current installation working date
Default.
■ DATE – resolves to the current system date
LIBRARY Name of the scheduling library containing the specified table.
Mandatory.

Chapter 4 CONTROL-M Event Manager (CMEM) 715

DO FORCEJOB: Action Parameter

General Information
DO FORCEJOB places a job order in the CONTROL-M Active Jobs file, even if the
basic scheduling criteria of the job are not satisfied. For more information, see “Job
Ordering and Job Forcing” on page 68.

The DO FORCEJOB statement in CMEM enables CONTROL-M to order

CONTROL-M tables based on the occurrence of an event, for example, job arrival, job
end, data set event, or step event.

The DO FORCEJOB statement is executed by the CONTROL-M monitor.

If the CONTROL-M monitor is not active, the DO FORCEJOB request is queued and
performed when the CONTROL-M monitor becomes active.

DO FORCEJOB logic works differently for job arrival events than for job end, data set
or step events:

Job End Events

DO FORCEJOB statements specified in a job end event rule are performed only if the
terminating job is not under CONTROL-M.

Data set or Step Events

Data set or step event rules are performed regardless of where the job was submitted.
However, if the triggering job was ordered or submitted by CONTROL-M, the job
will not become an On Spool job. For more information about On Spool jobs, see “On
Spool Jobs” on page 695.

Job Arrival Events

For the first DO FORCEJOB statement in a rule:

■ If the job that triggered the job arrival event was submitted by CONTROL-M, the
DO FORCEJOB statement is ignored.

■ If the job that triggered the job arrival event was not submitted by CONTROL-M,
CONTROL-M forces the requested table or job. CONTROL-M scans the forced
table looking for a job whose MEMNAME value matches, or is a mask for, the
name of the job whose arrival triggered the rule.

— If a matching job is found, it becomes an On Spool job. For more information,

see “Creating On Spool Jobs” on page 696.

— If a matching job is not found, or more than one job is ordered, all other jobs are
not On Spool jobs, and are processed normally by CONTROL-M.

716 Control-M for z/OS User Guide

 DO FORCEJOB: Action Parameter

For other DO FORCEJOB statements in the same rule:

■ DO FORCEJOB is performed regardless of the source of the job.

■ The table is forced.

DO FORCEJOB is not executed if a preceding ON JOBARRIV rule with a DO

FORCEJOB action was already executed for this event.

NOTE
When a DO FORCEJOB request fails because the table is in use, CONTROL-M may try again
to execute the job, depending on the values set for the FORCE# RT and FORCE# WI
installation parameters. For more information on the FORCE# RT and FORCE# WI installation
parameters, see the customization chapter of the INCONTROL for z/OS Installation Guide.

Examples

Example 1

Control all jobs not submitted by CONTROL-M.

Figure 336 DO FORCEJOB – Example 1

RL: * LIB CTM.PROD.RULES TABLE: JOBS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBARRIV = * JTYPE J SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP EXTJOBS MODE RUNTSEC
THRESHOLD
DESCRIPTION CONTROL ALL JOBS NOT SUBMITTED BY CONTROL-M
DESCRIPTION
==========================================================================
DO FORCEJOB = TABLE ANYJOB JOB DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
DO
==========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

Table ANYJOB must contain at least one job scheduling definition.

Chapter 4 CONTROL-M Event Manager (CMEM) 717

DO FORCEJOB: Action Parameter

Example 2

Control all jobs submitted by CICS. These fall into the following groups: Jobs whose
name starts with A and jobs whose name starts with C.

Figure 337 DO FORCEJOB – Example 2

RL: A* LIB CTM.PROD.RULES TABLE: JOBS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBARRIV = A* JTYPE J SMFID SYSTEM And/Or/Not O
ON JOBARRIV = C* JTYPE J SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP CICS MODE RUNTSEC
THRESHOLD
DESCRIPTION CONTROL ALL JOBS SUBMITTED BY CICS (BEGINNING WITH A* OR C*)
DESCRIPTION
===========================================================================
DO FORCEJOB = TABLE CICSJOB JOB %%$JNAME DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

Table CICSJOB must contain at least two job scheduling definitions:

■ One must contain a MEMNAME value beginning with A.

■ Another must contain a MEMNAME value beginning with B.

718 Control-M for z/OS User Guide

 DO RULE: Action Parameter

DO RULE: Action Parameter

Invoke a CONTROL-O rule from within the current rule. Available only if
CONTROL-O is active.

Figure 338 DO RULE Parameter Format

Optional. Type the word RULE (or its abbreviation RU) in the DO field and press
Enter. The following subparameters are displayed:

Table 231 DO RULE Subparameters

Subparameter Description
rulename Name of the CONTROL-O rule to be executed. A maximum of eight
characters can be entered.
Note: The rule to be executed must contain an ON RULE statement
with the same rule name specified in this parameter.
args Optional input and output arguments to be passed to the rule can be
specified, following the rulename and separated from it by a blank.
Arguments must be valid AutoEdit expressions separated by
commas. An unlimited number of arguments can be specified.
However, the combined length of the rulename and arguments
cannot exceed 45 characters.
OWNER Value of the OWNER field in the invoked rule. This subparameter is
used for security purposes. Optional.
TABLE Name of the CONTROL-O rule table in which the invoked rule
resides. When ALL is entered, it implies that the invoked rule may
reside in any rule table. If a table name is not entered, the current
rule table is assumed by default.
LIBRARY Name of the CONTROL-O rule table library where the invoked rule
resides. When ALL is entered, it implies that the invoked rule may
reside in any rule table library. If a library name is not specified, the
current rule table library is assumed by default.

Chapter 4 CONTROL-M Event Manager (CMEM) 719

DO RULE: Action Parameter

General Information
To define a DO RULE statement in a CMEM rule, and to access a CMEM rule
containing a DO RULE statement, CONTROL-O must be installed.

NOTE
To order a CMEM rule containing a DO RULE statement and to invoke the CONTROL-O rule
specified in the CMEM DO RULE statement, CONTROL-O must be active.

When a DO RULE statement is encountered during rule processing, CONTROL-O

invokes the specified rule. When processing of the invoked rule is completed,
processing continues sequentially from the point after the DO RULE statement in the
initial (calling) rule.

When a DO RULE statement is executed, the specified rule is searched for among the
loaded rules according to the specified rule name, table, library, and owner. If the rule
is found but is not active, for example, if the runtime scheduling criteria are not
satisfied, the “invoked” rule is not executed and the calling rule continues execution
with the next DO statement.

The CMEM calling rule can pass an argument string as input to the called rule. This
argument string can contain CMEM AutoEdit expressions that are resolved at time of
rule execution. The argument string can be accessed by the called rule through
CONTROL-O System variable %%$ARGS. If a called rule calls another CONTROL-O
rule, the %%$ARGS values passed in the earlier call are overwritten by the
%%$ARGS values passed by the later call. For information about the AutoEdit facility
in CONTROL-O, see the CONTROL-O User Guide.

A CONTROL-O rule specified with an ON RULE statement can be invoked any

number of times by DO RULE calls.

A called CONTROL-O rule can invoke other CONTROL-O rules using DO RULE
statements. Nesting of DO RULE calls, for example, rule 1 calls rule 2, that calls rule 3,
up to 20 deep is supported. A CONTROL-O rule can be called recursively.

720 Control-M for z/OS User Guide

 DO RULE: Action Parameter

Example
When a data set named PROD.TRAN.* is cataloged by TCPIP, invoke a CONTROL-O
rule that starts a task to process it.

Figure 339 DO RULE Example

RL: TCPIP LIB CTM.PROD.RULES TABLE: TRANS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON DSNEVENT = TCPIP JTYPE SMFID SYSTEM
DSN PROD.TRAN.* DISP CATLG
PROCSTEP PGMSTEP STEPRC OK And/Or/Not
OWNER ADMIN GROUP TCPIP MODE RUNTSEC
THRESHOLD
DESCRIPTION WHEN DATASET PROD.TRAN.* IS CATALOGED BY TCIP,
DESCRIPTION START A TASK TO PROCESS IT
DESCRIPTION
===========================================================================
/* START A STARTED TASK TO PROCESS THE RECEIVED FILE.
/* WHEN THE DATASET IS CATALOGED, INVOKE RULE PROCFILE.
/* PARAMETERS PASSED ARE THE STC NAME AND THE TIMEOUT VALUE.
DO RULE = PROCFILE %%$DSN OWNER PROD
TABLE PRODRULE LIBRARY CTO.PROD.RULES
SYSTEM SHARELOC TIMEOUT
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< ======

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF, 21.00.36

Chapter 4 CONTROL-M Event Manager (CMEM) 721

DO SHOUT: Action Parameter

DO SHOUT: Action Parameter

Send (“shout”) a message to a specific destination. Available only if CONTROL-O is
active.

Figure 340 DO SHOUT Parameter Format

Optional. Type SHOUT in the DO field and press Enter. The following
subparameters are displayed:

Table 232 DO SHOUT Subparameters (part 1 of 3)

Subparameter Description
TO Destination of the message (1 through 16 characters). Mandatory.
Valid values are:

■ U-userid or USERID-userid – Writes the message to the IOA Log

file under the specified user ID. userid must be 1 through 8
characters.
■ OPER [dd] [-{rrr | -ccc}] – Sends the message to operator
consoles, according to the optional subparameters dd, rrr, and ccc
— dd – Descriptor code (from 0 through 16). For more detailed
information regarding descriptor codes, refer to the IBM
publication Routing and Descriptor Codes, GC38-1102.
— rrr – Route code (from 0 through 128). For more detailed
information regarding route codes, refer to the IBM
publication Routing and Descriptor Codes, GC38-1102. Route
code and console ID are mutually exclusive.
— -ccc – Console ID number (preceded by a hyphen) of the
console to which the message is to be shouted. Console ID
and route code are mutually exclusive.

722 Control-M for z/OS User Guide

 DO SHOUT: Action Parameter

Table 232 DO SHOUT Subparameters (part 2 of 3)

Subparameter Description
TSO - loginid [;Nn | ;Mm | ;NnMm | ;Lname] – Sends the message to
the user identified by the specified logon ID. logonid is mandatory (1
through 7 characters).
An optional second value, indicating the computer and/or node
(such as Nn) of the TSO logonid, can be entered, as follows:
Under JES2:
Valid values are: Mm, Nn or NnMm, where:
■ m is the machine ID (the computer in JES2, not the 4-character
SMF ID). For more information, see the description of specifying
IOA CPU in the discussion of the customization process in the
INCONTROL for z/OS Installation Guide.
■ n is the 1 or 2 character JES/NJE node ID.
Under JES3:
The only valid value is Lname, where name is the logical JES name of
the machine (that is, the name as used in JES3, command *T, not the
SMF system ID).
For more information, see the description of specifying IOA CPU in
the discussion of the customization process in the INCONTROL for
z/OS Installation Guide.
Note: A shout to a TSO user performs a TSO SEND command that
may require authorization at the receiving node.
■ U-M: mail-name-prefix – Sends a message by mail to the recipient
identified by mail-name-prefix (1 through 12 characters).
■ U-ECS – Sends messages to the CONTROL-M/Enterprise
Manager user. For more information on this feature, see the
section on shouting to CONTROL-M/Enterprise Manager in
Chapter 3, “Job Production Parameters.”
URGENCY Determines the priority level of the message. For more information,
see “The URGENCY subparameter” on page 725. Valid values are:

■ R - Regular. Default.
■ U - Urgent.
■ V - Very urgent.
SYSTEM Name of the system (computer) where the message must be directed.
A name of one to eight alphanumeric characters can be entered.
Mask characters (* and ?) are supported for this subparameter.
Note: If no SYSTEM value is specified, the message is sent to the
system identified by reserved user-defined variable
%%$COMMSYS in a preceding DO SET statement. For a
description of %%$COMMSYS, see the CONTROL-O User Guide.
If %%$COMMSYS is not specified, the message is issued on the
current system.
Can be used only when CONTROL-O is installed.
CTO282I Indicates if the message ID is prefixed by CTO282I. Optional. Valid
values are:

■ Y (Yes) – The message ID is prefixed by CTO282I. Default.

■ N (No) – The message ID is the first word of the message text.

Chapter 4 CONTROL-M Event Manager (CMEM) 723

DO SHOUT: Action Parameter

Table 232 DO SHOUT Subparameters (part 3 of 3)

Subparameter Description
MESSAGE Message text. Maximum Length: 60 characters. Mandatory.

General Information
The message is sent to the required destination when the accompanying ON
statement criteria are satisfied.

It is also possible to shout to a ROSCOE user. For additional information, see your
INCONTROL administrator.

Subparameter TO

Type TO=USERID-userid to write the message to the IOA Log under the user ID
specified in the parameter.

Type TO=OPER[dd]-{rrr,-ccc} to send the message to all operator consoles, or to

operator consoles selected according to route code (rrr) or console ID number (-ccc).
The descriptor code (dd) determines the type of message displayed. The dd, rrr, and -
ccc parameters are optional and can be assigned any valid value. Dashes (–) are used
to separate the parameters specified.

For more detailed information regarding route and descriptor codes, refer to the IBM
publication Routing and Descriptor Codes, GC38-1102.

Examples

Table 233 DO SHOUT OPER Subparameter Examples

Subparameter Description
OPER Send the message to all operator consoles.
OPER2 Send a highlighted unrollable message (descriptor code 2) to all
operator consoles.
OPER-5 Send a message to operator consoles associated with route code 5.
OPER2-5 Send a highlighted unrollable message to operator consoles
associated with route code 5.
OPER-4 Send a message to operator console ID 04.
OPER2-4 Send a highlighted unrollable message (descriptor code 2) to
operator console ID 04.

724 Control-M for z/OS User Guide

 DO SHOUT: Action Parameter

Type TO=TSO-logonid to send the message to a groupid or logonid. The Shout facility
first searches the IOA Dynamic Destination table for the specified ID. If the table
contains an entry that matches the value, the content of the entry is used as the target
for the shouted message. The entire TO field is used. Therefore, when directing the
message to a remote user, do not append Nn or Mm. Instead, do this in the IOA
Dynamic Destination Table itself. For more information, see the description of
Dynamic Destination Tables in the INCONTROL for z/OS Administrator Guide.

If no matching ID is found in the Dynamic Destination table, the Shout facility

assumes the specified ID is a logonid. It then creates a TSO message that it hands over
to MVS. MVS then sends the message to that logonid. If the logonid does not exist,
MVS cannot send the message, but no error message is generated. When a second
value is used, the message is sent to the TSO logonid in the specified computer or
node (machine ID). To determine the machine ID under JES2, enter JES command
$D MEMBER.

The URGENCY subparameter

The URGENCY value indicates the urgency level of the message.

In addition, if the destination is USERID-userid (or U-userid), the user can control,
according to urgency, which messages are displayed when the IOA Log file is
accessed. Urgent and very urgent messages are highlighted on the screen. For more
details, see “IOA Log Facility” on page 303

The CTO282I Subparameter

By default, the CTO282I subparameter has a value of Y, and CTO282I is placed as the
message ID preceding the message text. When CTO282I is set to N, the first word of
the message text becomes the message ID.

CONTROL-O AutoEdit Variables

CONTROL-O AutoEdit variables embedded in the TO and MSG subparameters are

automatically resolved at time of rule activation. For more information about the
AutoEdit facility, see Chapter 5, “JCL and AutoEdit Facility,”.

Chapter 4 CONTROL-M Event Manager (CMEM) 725

DO SHOUT: Action Parameter

Example
When started task DB2MSTR ends, issue a message to the DBA who is on duty.
Notice the use of the generic TSO user name, that the Dynamic Destination table
interprets to be one or more TSO users.

Figure 341 DO SHOUT Parameter Example

RL: DB2MSTR LIB CTM.PROD.RULES TABLE: STCS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBEND = DB2MSTR JTYPE S SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP DB2 MODE RUNTSEC
THRESHOLD
DESCRIPTION WARN DBA THAT DB2 MASTER ENDED
DESCRIPTION
===========================================================================
DO SHOUT = TO TSO-DBA URGENCY U SYSTEM CTO282I
MESSAGE DB2 MASTER ENDED - PLEASE CHECK!
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

726 Control-M for z/OS User Guide

 DO STOPJOB: Action Parameter

DO STOPJOB: Action Parameter

Stop execution of the job that triggered the rule after the current step.

Figure 342 DO STOPJOB Parameter Format

Optional. Type STOPJOB, or its abbreviation ST, in the DO field and press Enter.

General Information
When DO STOPJOB is performed, the job that triggered the rule is terminated after
the current step, and no further steps (including those marked COND=EVEN or
COND=ONLY) are executed. An appropriate message is written to the job log. If the
stopped job is controlled by CONTROL-M, it terminates with a status of ENDED
NOTOK.

DO STOPJOB is not executed for TSO users.

DO STOPJOB is meaningful only:

■ for data set events or step events

■ when there are additional steps in a job or started task

Chapter 4 CONTROL-M Event Manager (CMEM) 727

DO STOPJOB: Action Parameter

Example
If the production data set disposition is NOT CATLGD 2, stop the job.

Figure 343 DO STOPJOB Parameter Example

RL: PROD* LIB CTM.PROD.RULES TABLE: JOB
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON DSNEVENT = PROD* JTYPE J SMFID SYSTEM
DSN PROD.* DISP NCT2
PROCSTEP PGMSTEP STEPRC And/Or/Not
OWNER ADMIN GROUP PRODJOBS MODE RUNTSEC
THRESHOLD
DESCRIPTION STOP THE JOB ON NCT2 DISPOSITION
DESCRIPTION
===========================================================================
/* STOP THE JOB
DO STOPJOB
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

728 Control-M for z/OS User Guide

 GROUP: General Parameter

GROUP: General Parameter

Name of the group to which the rule belongs.

Figure 344 GROUP Parameter Format

Optional. Name of 1 through 20 characters, with no embedded blanks.

General Information
The GROUP parameter is used to provide more convenient handling of rules. It
enables retrieval of information on a group basis. The group name appears in all
important IOA Log file messages relating to the rules of the group.

Chapter 4 CONTROL-M Event Manager (CMEM) 729

GROUP: General Parameter

Example
The rule that instructs CONTROL-M to start the batch shift when CICSPROD ends
belongs to group CICS.

Figure 345 GROUP Parameter Example

RL: CICSPROD LIB CTM.PROD.RULES TABLE: STCS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBEND = CICSPROD JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP CICS MODE PROD RUNTSEC
THRESHOLD
DESCRIPTION START THE BATCH SHIFT
DESCRIPTION
===========================================================================
/* INFORM CONTROL-M THAT THE BATCH CAN BE STARTED
DO COND = START-BATCH ODAT +
DO
===========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

730 Control-M for z/OS User Guide

 MODE: General Parameter

MODE: General Parameter

Rule operation mode.

Figure 346 MODE Parameter Format

Optional. Valid values, and their abbreviations, for the MODE parameter are:

Table 234 MODE Parameter Values

Value Description
PROD (P) Standard Production mode. The rule is processed normally. Default.
TEST (T) Test mode. Actions are not performed, but are written to a test
journal.
LOG (L) Log mode. The rule is processed normally and all identified events
and actions are written to a test journal.

General Information
Test mode provides the opportunity to test the effects of a rule definition without
actually performing the specified DO actions.

Log mode provides a transition between Test and Production mode. Like Production
mode, Log mode enables performance of the specified DO actions. However, Log
mode also records the trace information in the test journal for tracking purposes.

When tracking of the performed actions for test purposes is no longer required, the
rule can be placed in Production mode.

For sites in which CONTROL-O is not installed, or in which the CONTROL-O

Automation Log facility is not active, the trace information is written to the sysout
referenced by DD statement DAACTLOG.

Chapter 4 CONTROL-M Event Manager (CMEM) 731

MODE: General Parameter

For CONTROL-O sites in which the Automation Log facility is active, the trace
information is recorded in the Automation log. For more information, see the
CONTROL-O User Guide.

Example
The rule that instructs CONTROL-M to start the batch shift when CICSPROD ends is
activated in Production mode.

Figure 347 MODE Parameter Example

RL: CICSPROD LIB CTM.PROD.RULES TABLE: STCS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBEND = CICSPROD JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP CICS MODE PROD RUNTSEC
DESCRIPTION START THE BATCH SHIFT
DESCRIPTION
===========================================================================
/* INFORM CONTROL-M THAT THE BATCH CAN BE STARTED
DO COND = START-BATCH ODAT +
DO
===========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

732 Control-M for z/OS User Guide

 ON statement: Event Parameter

ON statement: Event Parameter

Event selection criteria that trigger performance of the rule.

Figure 348 ON Parameter Format

Mandatory. At least one ON statement must be entered. Type an ON statement, or its

abbreviation, in the ON field and press Enter. Additional subparameters are
displayed.

The following are valid ON statements (and their abbreviations). Each is described in
detail later in this chapter.

Table 235 ON Parameter Statements

Statement Description
ON DSNEVENT (D) Name (or mask) of a job, started task, or TSO user to be monitored
for data set events
ON JOBARRIV (JA) Job name (or mask) of a job or started task that arrived on the JES
spool from any source
ON JOBEND (JE) Job name (or mask) of a job or started task that terminated
ON STEP (S) Name (or mask) of a procedure step (and optionally, program step)
to be monitored for termination

The And/Or/Not subparameter is always displayed in each specified ON statement.

It is a conjunctional parameter for linking ON statements. Optional.

Entering a value for this subparameter opens a new ON statement and links the
newly opened statement to the current ON statement.

When multiple ON statements are entered, the combinations of ON statements that

can satisfy the selection criteria depend on the And/Or/Not values linking those ON
statements. The logic applied to And/Or/Not subparameters is described in
“General Information”, which follows.

Chapter 4 CONTROL-M Event Manager (CMEM) 733

ON statement: Event Parameter

Valid values are:

■ A (And) – indicates AND logic between the two statements

If both ON statements are true, the event criteria are satisfied.

■ O (Or) – indicates OR logic between the preceding and following ON statements

If either statement is true, the event criteria are satisfied.

■ N (Not) – indicates AND NOT logic between the two statements

If the prior statement is true and the subsequent statement is false, the event
criteria are satisfied.

General Information
Upon typing an ON parameter and pressing Enter, additional fields (subparameters)
are displayed. Each ON parameter and its subparameters comprise an ON statement.
At least one ON statement is required in a rule definition. Additional ON statements
can be entered using the And/Or/Not option.

The first eight characters of the event name appear as the name of the rule in the Rule
List screen.

And/Or/Not Subparameter Logic

The following logic is applied:

■ AND and NOT logic are applied before OR logic

■ NOT means AND NOT as represented below
■ A NOT B is interpreted as A AND (NOT B)
■ A OR B AND C is interpreted as A OR (B AND C)
■ A AND B OR C NOT D is interpreted as [(A AND B) OR (C AND NOT D)]

Use of OR logic reduces the amount of redundant data in the CMEM rule library and
improves rule management.

NOTE
When entering multiple ON statements, ensure that the statements are not mutually exclusive
or not connected by an AND parameter. Rules containing mutually exclusive ON statements
connected by an AND parameter are never triggered. For example:

ON DSNEVENT JOBA STEPA

AND

ON DSNEVENT JOBA STEPB

734 Control-M for z/OS User Guide

 ON statement: Event Parameter

Character Masking

The following mask characters can be used when entering ON statement values:

■ * represents any number of characters, including no characters

■ ? represents any one character

Chapter 4 CONTROL-M Event Manager (CMEM) 735

ON DSNEVENT: Event Parameter

ON DSNEVENT: Event Parameter

Monitor a data set disposition event.

Figure 349 ON DSNEVENT Parameter Format

Optional. Type D (DSNEVENT) in the ON field and press Enter. The following
subparameters are displayed:

Table 236 DSNEVENT Subparameters (part 1 of 3)

Subparameter Description
jobname Name (or mask) of the job to be monitored for data set events.
Mandatory.
JTYPE Type of job to be monitored for data set events:

■ J (Job) – batch job

■ S (STC) – started task
■ T (TSU) – TSO user
■ blank – any type of job; valid only if STEPRC is blank, that is, the
rule is processed immediately upon detection of the data set
event. Default.
If JTYPE is entered, only a data set event occurring in a job of the
specified type can trigger the rule.
SMFID SMF ID of the CPU to monitor for data set events. Mask characters
(* and ?) are supported. Default: current CPU.
SYSTEM Name of the system to monitor for data set events. Mask characters
(* and ?) are supported. Default: current system.

736 Control-M for z/OS User Guide

 ON DSNEVENT: Event Parameter

Table 236 DSNEVENT Subparameters (part 2 of 3)

Subparameter Description
DSN Name of data set (or mask) to be monitored for this event within the
selected jobs. Mandatory. Valid values are:

■ DISP – data set disposition

Mandatory. The abbreviation (that is, the first letter) of the

desired value can be entered. Valid values are:

— CATLG – cataloged (including SMS-managed files and

ROLLED-IN SMS-managed GDG files)
— DELETE – deleted
— UNCATLG – uncatalogued
— KEEP – kept (including SMS-managed files)
— RETAIN – cataloged or kept
— SCRATCH – deleted and uncatalogued (SMS managed files)
— ALL – any of the above dispositions
— NCT2 – occurrence of a NOT CATLG 2 event – when a data
set was created in a previous job step, but not cataloged at
deallocation because its name already exists in the MVS
catalog
— * – any of the above data set dispositions (including NCT2)
PROCSTEP Name or mask of a step invoking a procedure or, for a started task,
task ID. Optional.
If omitted, all procedure steps in the selected jobs are monitored.
Note: When a started task is initiated, it can be assigned a task ID.
For example, in command S GTF.G, the task ID of GTF is G. If a task
ID is not entered, MVS assigns a default task ID to the started task, as
follows:
■ For a system started task with stepname IEFPROC, MVS sets an
internal task ID.
■ For other started tasks, the default task ID equals the procedure
(started task) name.
Therefore, when using CMEM to monitor system started tasks, if no
task ID is entered in the START command, the PROCSTEP
parameter must not be specified.
PGMSTEP Name (or mask) of a step invoking a program. Optional.
If omitted, all program steps in the selected jobs are monitored.
Note: When a system started task with stepname IEFPROC is
initiated, MVS assigns the step a default program step name.
Therefore, when using CMEM to monitor these system started tasks,
the PGMSTEP parameter must not be specified.

Chapter 4 CONTROL-M Event Manager (CMEM) 737

ON DSNEVENT: Event Parameter

Table 236 DSNEVENT Subparameters (part 3 of 3)

Subparameter Description
STEPRC Determines at which point in the job step, and under what
conditions in the job step, the DO statements are performed. Valid
values are:

■ blank – if no completion code is entered, the rule is executed

immediately upon detection of the specified data set event
If any of the following values is entered for STEPRC, execution of the
DO statements is delayed until the end of the monitored job step and
is dependent upon how the jobstep ended:
■ OK – step ended with a condition code of zero
■ NOTOK – step ended with a nonzero code
■ **** – step ended (with any code)
■ Cnnnn – step ended with the indicated condition code
■ Snnn – step ended with the indicated system abend code
■ Unnnn – step ended with the indicated user abend code
Asterisks can be entered instead of code digits; condition codes and
abends can be preceded by code qualifiers (<, >, N). For more
information, see the following section, “General Information”.
And/Or/Not Conjunctional parameter that opens a new ON statement and links it
to the previous ON statement. Optional. Valid values are:
■ A (And) – indicates AND logic between the two ON statements
■ O (Or) – indicates OR logic between the preceding and following
sets of ON statements
■ N (Not) – indicates AND NOT logic between the two ON
statements

General Information
ON DSNEVENT rules are triggered by the setting of data set disposition at time of
deallocation (during step termination or dynamic deallocation).

DO statements in the rule are executed either immediately upon detection of the data
set event or at the end of the job step that caused the data set event, depending on the
value entered in the STEPRC subparameter (described above).

Immediate execution is useful for performing actions when data sets are dynamically
de-allocated using long running address spaces (for example, CICS, TSO users, and
file transfer monitors).

CMEM must be active before any tasks tracked by ON DSNEVENT rules begin;
moreover, ON DSNEVENT rules only intercept data set events for jobs, started tasks,
or TSO users that started after the rule was ordered.

738 Control-M for z/OS User Guide

 ON DSNEVENT: Event Parameter

NOTE
To monitor data set events for a job, started task or TSO user, the job, started task or TSO user
must have MSGLEVEL=(1,1) and message IEF403I or IEF125I must appear in the job log.

A DSNEVENT can be triggered only on the CONTROL-O/CMEM that runs on the same
z/OS system on which the event occurs. Even a focal CONTROL-O or CMEM in a Sysplex
environment is insufficient. This is because CONTROL-O or CMEM intercepts the messages
written to JESYSMSG while they are being written, which can be done only on the same
system where the event happens.

ON DSNEVENT rules do not intercept data set events, such as cataloging,

uncataloging, or scratching, when they are performed using MVS CATALOG or
SCRATCH macros.

The following restrictions apply to ON DSNEVENT statements:

■ Do not specify an ON DSNEVENT statement with any other type of ON statement

in a rule.

■ Do not specify different STEPRC values in the same rule. If you do, the last
specified value is used.

Entering values for the optional subparameters PROCSTEP, PGMSTEP and STEPRC
limits the situations that can satisfy the step termination event. Conversely, if a
subparameter is blank, that subparameter is ignored.

Example

■ If a PGMSTEP and PROCSTEP value are both entered, the rule is triggered only if
the specified PGMSTEP is completed in the specified PROCSTEP.

■ If a PGMSTEP value is entered without a PROCSTEP value, the rule is triggered if

the PGMSTEP is completed anywhere within the job stream.

The STEPRC Subparameter

When entering a condition code or abend code in the STEPRC subparameter, any
characters in the code can be replaced by an asterisk (*). An asterisk means “any
value” for the character it replaces. For example, if S*13 is entered, the code criteria is
satisfied by codes S013, S613, S913, and so on.

Chapter 4 CONTROL-M Event Manager (CMEM) 739

ON DSNEVENT: Event Parameter

When entering condition and/or abend codes, the following qualifiers can be used as
indicated:

Table 237 Valid STEPRC Code Qualifiers

Qualifier Description
< Greater than. Valid for condition codes and user abend codes.
> Less than. Valid for condition codes and user abend codes.
N Triggers the rule if the specified code does not exist in the step. Valid
as a qualifier for condition codes, user abend codes, and system
abend codes.

The SMFID and SYSTEM Subparameters

The default values for the SMFID and SYSTEM subparameters are the current system.
If no value is entered for either SMFID or SYSTEM, the rule is triggered only by
events that occur in the current system.

Example
When a new production data set is created, trigger a backup job.

Figure 350 ON DSNEVENT Parameter Example

RL: PRDJ0003 LIB CTM.PROD.RULES TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON DSNEVENT = PRDJ0003 JTYPE SMFID SYSTEM
DSN PROD.* DISP CATLG
PROCSTEP PGMSTEP STEPRC OK And/Or/Not
OWNER ADMIN GROUP BACKUP MODE PROD RUNTSEC
THRESHOLD
DESCRIPTION NEW DATASET CREATED - TRIGGER A BACKUP JOB
DESCRIPTION
===========================================================================
/* SCHEDULE A CONTROL-M JOB TO HANDLE THE BACKUP
/*
DO FORCEJOB = TABLE BACKUP JOB BACKUP DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
/*
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF, 21.00.36

740 Control-M for z/OS User Guide

 ON JOBARRIV: Event Parameter

ON JOBARRIV: Event Parameter

Monitor a job arrival event on the JES spool.

Figure 351 ON JOBARRIV Parameter Format

Optional. Type JA (JOBARRIV) in the ON field and press Enter. The following
subparameters are displayed:

Table 238 ON JOBARRIV Subparameters

Subparameter Description
jobname Job name (or mask). Mandatory. For more information, see
“Character Masking” on page 87.
JTYPE Type of job that can trigger the rule. Optional. Valid values are:

■ J (JOB) – batch job

■ S (STC) – started task
■ T (TSU) – TSO user
■ blank – if no value is entered, the rule can be triggered by any
type of job. Default.
SMFID SMF ID of the CPU to monitor for job arrival events. Mask characters
(* and ?) are supported. Default: current CPU.
SYSTEM Name of the system to monitor for job arrival events. Mask
characters (* an ?) are supported. Default: current system.
And/Or/Not Conjunctional parameter that opens a new ON statement and links it
to the previous ON statement. Optional. Valid values are:

■ A (And) – indicates AND logic between the two ON statements

■ O (Or) – indicates OR logic between the preceding and following
sets of ON statements
■ N (Not) – indicates AND NOT logic between the two ON
statements

Chapter 4 CONTROL-M Event Manager (CMEM) 741

ON JOBARRIV: Event Parameter

General Information
ON JOBARRIV statements can be used to trigger CONTROL-M actions based on the
appearance of a job on the JES spool.

Combination of an ON JOBARRIV statement and a DO FORCEJOB statement can be

used to control an external job through CONTROL-M. Such a job is called an On
Spool job. For more information, see “On Spool Jobs” on page 695.

The default values for the SMFID and SYSTEM subparameters are the current system.
If no value is entered for either SMFID or SYSTEM, the rule is triggered only by
events that occur in the current system.

NOTE
For JES3 users: JOBARRIV rules are processed on the global CPU.

Example
Backup jobs submitted outside CONTROL-M must be monitored by CONTROL-M.

Figure 352 ON JOBARRIV Parameter Example

RL: BKP* LIB CTM.PROD.RULES TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBARRIV = BKP* JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP BACKUP MODE PROD RUNTSEC
DESCRIPTION MONITOR EXTERNAL BACKUP JOBS
DESCRIPTION
===========================================================================
/* TELL CONTROL-M TO MONITOR THIS JOB
/*
DO FORCEJOB = TABLE BACKUP JOB DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
/*
DO
===========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

742 Control-M for z/OS User Guide

 ON JOBEND: Event Parameter

ON JOBEND: Event Parameter

Monitor a job termination event.

Figure 353 ON JOBEND Parameter Format

Optional. Type JE (JOBEND) in the ON field and press Enter. The following
subparameters are displayed:

Table 239 JOBEND Subparameters

Subparameters Description
jobname Job name (or mask). Mandatory.
JTYPE Type of job whose termination can trigger the rule. Optional. Valid
values are:

■ J (JOB) – batch job

■ S (STC) – started task
■ T (TSU) – TSO user
■ blank – if no value is entered, the rule can be triggered by the
termination of any type of job. Default.
SMFID SMF ID of the CPU to monitor for job termination events. Mask
characters (* and ?) are supported. Default: current CPU.
SYSTEM Name of the system to monitor for job termination events. Mask
characters (* and ?) are supported. Default: current system.
And/Or/Not Conjunctional parameter that opens a new ON statement and links it
to the previous ON statement. Optional. Valid values are:

■ A (And) – indicates AND logic between the two ON statements

■ O (Or) – indicates OR logic between the preceding and following
sets of ON statements
■ N (Not) – indicates AND NOT logic between the two ON
statements

Chapter 4 CONTROL-M Event Manager (CMEM) 743

ON JOBEND: Event Parameter

General Information
ON JOBEND statements can be used to trigger CONTROL-M actions based on the
termination of a job.

The default values for the SMFID and SYSTEM subparameters are the current system.
If no value is entered for either SMFID or SYSTEM, the rule is triggered only by
events that occur in the current system.

NOTE
For JES3 users: JOBEND rules are processed on the same CPU that executed the specified job.

Example
Instruct CONTROL-M to start the batch shift when CICSPROD ends.

Figure 354 ON JOBEND Parameter Example

RL: CICSPROD LIB CTM.PROD.RULES TABLE: STCS
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBEND = CICSPROD JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP CICS MODE PROD RUNTSEC
DESCRIPTION START THE BATCH SHIFT
DESCRIPTION
===========================================================================
/* INFORM CONTROL-M THAT THE BATCH CAN BE STARTED
DO COND = START-BATCH ODAT +
DO
===========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

744 Control-M for z/OS User Guide

 ON STEP: Event Parameter

ON STEP: Event Parameter

Monitor a job step termination event.

Figure 355 ON STEP Parameter Format

Optional. Type S (STEP) in the ON field and press Enter. The following
subparameters are displayed:

Table 240 ON STEP Subparameters (part 1 of 2)

Subparameter Description
job Name (or mask) of the job to be monitored for step termination.
Mandatory.
JTYPE Type of job to be monitored for step termination. Optional. Valid
values are:

■ J (Job) – batch job

■ S (STC) – started task
■ T (TSU) – TSO user task
■ blank – any type of job. Default.

If JTYPE is entered, only the termination of steps from the specified

type of job can trigger the rule.
SMFID SMF ID of the CPU to monitor for data set events. Mask characters
(* and ?) are supported. Default: current CPU.
SYSTEM Name of the system to monitor for data set events. Mask characters
(* and ?) are supported. Default: current system.
PROCSTEP Name (or mask) of a step invoking a procedure or, for a started task,
task ID. Optional. If omitted, all procedure steps in the selected jobs
are monitored.

Chapter 4 CONTROL-M Event Manager (CMEM) 745

ON STEP: Event Parameter

Table 240 ON STEP Subparameters (part 2 of 2)

Subparameter Description
Note: When a started task is initiated, it can be assigned a task ID.
For example, in command S GTF.G, the task ID of GTF is G. If a task
ID is not entered, MVS assigns a default task ID to the started task, as
follows:

■ For a system started task with stepname IEFPROC, MVS sets an

internal task ID.
■ For other started tasks, the default task ID equals the procedure
(started task) name.

Therefore, when using CMEM to monitor system started tasks, if no

task ID is entered in the START command, do not specify the
PROCSTEP parameter.
PGMSTEP Name (or mask) of a step invoking a program. Optional. If omitted,
all program steps in the selected jobs are monitored.
Note: When a system started task with stepname IEFPROC is
initiated, MVS assigns the step a default program step name.
Therefore, when using CMEM to monitor these system started tasks,
do not specify the PGMSTEP parameter.
STEPRC Return codes and/or statuses returned upon termination of the
specified steps that satisfy the step termination criteria. Valid values
are:

■ ‘ ‘ (Blank) or **** – step ended with any code or status

If no value or four asterisks are entered, the return code or status
is irrelevant.
■ OK – step ended with a condition code of 0
■ NOTOK – step ended with a nonzero code
■ Cnnnn – step ended with the indicated condition code
■ Snnn – step ended with the indicated system abend code
■ Unnnn – step ended with the indicated user abend code

Asterisks can be entered instead of code digits; condition codes and

abends can be preceded by code qualifiers (<, >, N). For more
information, see the following section, “General Information”.
And/Or/Not Conjunctional parameter that opens a new ON statement and links it
to the previous ON statement. Valid values are:

■ A (And) – indicates AND logic between the two ON statements

■ O (Or) – indicates OR logic between the preceding and following
sets of ON statements
■ N (Not) – indicates AND NOT logic between the two ON
statements

746 Control-M for z/OS User Guide

 ON STEP: Event Parameter

General Information
ON STEP rules are triggered when specified job steps terminate with specified return
codes or statuses.

Entering values for the optional subparameters PROCSTEP, PGMSTEP and STEPRC
limits the situations that can satisfy the step termination event. Conversely, if a
subparameter is blank, that subparameter is ignored.

■ If a PGMSTEP and PROCSTEP value are both entered, the rule is triggered only if
the specified PGMSTEP is completed in the specified PROCSTEP.

■ If a PGMSTEP value is entered without a PROCSTEP value, the rule is triggered if

the PGMSTEP is completed anywhere within the job stream.

CMEM must be active before any tasks tracked by ON STEP rules begin; moreover,
ON STEP rules only intercept data set events for jobs, started tasks, or TSO users that
started after the rule was ordered.

NOTE
To monitor data set events for a job, started task or TSO user, the job, started task or TSO user
must have MSGLEVEL=(1,1) and message IEF403I or IEF125I must appear in the job log.

A DSNEVENT can be triggered only on the CONTROL-O/CMEM that runs on the same
z/OS system on which the event occurs. Even a focal CONTROL-O or CMEM in a Sysplex
environment is insufficient. This is because CONTROL-O or CMEM intercepts the messages
written to JESYSMSG while they are being written, which can be done only on the same
system where the event happens.

The SMFID and SYSTEM Subparameters

The default values for the SMFID and SYSTEM subparameters are the current system.
If no value is entered for either SMFID or SYSTEM, the rule is triggered only by
events that occur in the current system.

The STEPRC Subparameter

When entering a condition code or abend code in the STEPRC subparameter, any
characters in the code can be replaced by an asterisk (*). An asterisk means “any
value” for the character it replaces. For example, if S*13 is entered, the code criteria is
satisfied by codes S013, S613, S913, and so on. When entering condition and/or abend
codes, the following qualifiers can be used as indicated:

Chapter 4 CONTROL-M Event Manager (CMEM) 747

ON STEP: Event Parameter

Table 241 ON STEP Subparameter STEPRC Qualifiers

Qualifier Description
> Greater than. Valid for condition codes and user abend codes.
< Less than. Valid for condition codes and user abend codes.
N Triggers the rule if the specified code does not exist in the step. Valid
as a qualifier for condition codes, user abend codes, and system
abend codes.

Example
When step STEP2 in job PRD00010 is completed, add a prerequisite condition
indicating that a file has been created.

Figure 356 ON STEP Parameter Example

RL: PRD00010 LIB CTM.PROD.RULES TABLE: CMEMRULE
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON STEP = PRD00010 JTYPE SMFID SYSTEM
PROCSTEP STEP2 PGMSTEP STEPRC OK And/Or/Not
OWNER CTMCTLM GROUP MODE PROD RUNTSEC NONE
THRESHOLD
DESCRIPTION FOLLOWING STEP2 IN JOB PRD00010 ADD A CONDITION
DESCRIPTION INDICATING THAT THE FILE WAS CREATED
DESCRIPTION
===========================================================================
DO COND = FILE-CREATED ODAT +
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

748 Control-M for z/OS User Guide

 OWNER: General Parameter

OWNER: General Parameter

Identifies the user requesting CMEM services.

Figure 357 OWNER Parameter Format

Mandatory. The OWNER parameter must be 1 through 8 characters.

General Information
The OWNER parameter is primarily used by the internal security mechanism of
CMEM to determine, together with an external security product, such as TOP
SECRET, RACF or ACF2, those operations each user is authorized to perform.

Chapter 4 CONTROL-M Event Manager (CMEM) 749

OWNER: General Parameter

Example
The INCONTROL administrator is authorized to use the rule used to monitor the
arrival of backup jobs.

Figure 358 OWNER Parameter Example

RL: BKP* LIB CTM.PROD.RULES TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON JOBARRIV = BKP* JTYPE SMFID SYSTEM And/Or/Not
OWNER ADMIN GROUP BACKUP MODE PROD RUNTSEC
THRESHOLD
DESCRIPTION MONITOR STARTUP OF BACKUP JOBS
DESCRIPTION
===========================================================================
/* TELL CONTROL-M TO MONITOR THIS JOB
/*
DO FORCEJOB = TABLE BACKUP JOB DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
/*
DO
===========================================================================
======= >>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 21.00.36

750 Control-M for z/OS User Guide

 RUNTSEC: General Parameter

RUNTSEC: General Parameter

Specifies the runtime security environment for the rule.

Figure 359 RUNTSEC Parameter Format

Optional. The abbreviation, that is, the first letter, of the desired value can be entered.
Valid values are:

Table 242 Valid RUNTSEC Values

Value Description
NONE Runtime security checks are not performed for this rule.
OWNER Runtime security checks are performed using the user ID entered in
the OWNER field of the rule.
TRIGGER Runtime security checks are performed using the user ID associated
with the started task, TSO user, or batch job that invoked the rule.
‘ ‘ (Blank) If CONTROL-O is not active, the default is OWNER.
If CONTROL-O is active, performance of runtime security checks
depend on the value of the Global parameter RUNTDFT (NONE,
OWNER, or TRIGGER) in the CTOPARM member as entered at time
of CONTROL-O installation.

NOTE
Value TRIGGER applies only to ON DSNEVENT, ON STEP, or ON JOBEND event rules. If
the value TRIGGER is entered for an ON JOBARRIV event rule, the value is treated as
OWNER.

Chapter 4 CONTROL-M Event Manager (CMEM) 751

RUNTSEC: General Parameter

General Information
The RUNTSEC parameter is used by the CMEM security interface for interaction with
external security products, such as CA-RACF, CA-TOP SECRET, and CA-ACF2. For
more information see the INCONTROL for z/OS Security Guide.

CMEM security checks are carried out in two stages: at order time and at runtime.

At order time, security checks are carried out to ascertain whether the owner of the
rule, as specified in the OWNER subparameter, is authorized to code each one of the
rule statements.

At runtime, additional security checks are carried out to determine whether the user
who owns the rule (RUNTSEC=OWNER) or the user who triggered the rule
(RUNTSEC=TRIGGER) is authorized to execute a DO COND or DO FORCEJOB
statement defined in the rule.

Example
Perform a backup using the security ID of the job that triggered the rule.

Figure 360 RUNTSEC Parameter Example

RL: PRDJ0003 LIB CTM.PROD.RULES TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+----------------------------------------------------------------------------+
ON DSNEVENT = PRDJ0003 JTYPE SMFID SYSTEM
DSN PROD.* DISP CATLG
PROCSTEP PGMSTEP STEPRC OK And/Or/Not
OWNER ADMIN GROUP BACKUP MODE PROD RUNTSEC TRIGGER
THRESHOLD
DESCRIPTION NEW DATASET CREATED - TRIGGER A BACKUP JOB
DESCRIPTION
===========================================================================
/* SCHEDULE A CONTROL-M JOB TO HANDLE THE BACKUP
/*
DO FORCEJOB = TABLE BACKUP JOB BACKUP DATE ODAT
LIBRARY CTM.PROD.SCHEDULE
/*
DO
===========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF, 21.00.36

752 Control-M for z/OS User Guide

 THRESHOLD: Runtime Scheduling Parameter

THRESHOLD: Runtime Scheduling Parameter

Limits the number of times that a rule can be triggered in one CMEM Monitor cycle.

Figure 361 THRESHOLD Parameter Format

Optional. Valid values are 1 through 999999999.

General Information
The THRESHOLD parameter is used to prevent unlimited loops within the system.
The value assigned to the parameter indicates the maximum number of times that
CMEM will trigger the rule in a single CMEM interval.

Before CMEM triggers a rule, it determines whether the rule has already been
triggered the maximum number of times in the current CMEM interval. If so, CMEM
does not trigger the rule again, but instead sets the STATUS of the rule to SUSPEND
and issues message CTO285W to the console.

If no value, or a value of 0, is entered for THRESHOLD, CMEM does not limit the
number of times that the rule can be triggered.

Chapter 4 CONTROL-M Event Manager (CMEM) 753

THRESHOLD: Runtime Scheduling Parameter

Example
Limit execution of the following rule to 10 executions. Do not allow the rule to be
triggered until it is released from SUSPEND status.

Figure 362 THRESHOLD Parameter Example

RL: PRDJOB01 LIB CTM.PROD.RULES TABLE: JOB
COMMAND ===> SCROLL===> CRSR
+-------------------------------------------------------------------------------
ON JOBARRIV = JOBNM233 JTYPE SMFID SYSTEM And/Or/Not
OWNER N18 GROUP MODE PROD RUNTSEC
THRESHOLD 000000010
DESCRIPTION
=========================================================================
DO COND = JOBNX-ARRIVED ODAT +
DO
==========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< ====

=====FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF 13.21.53

754 Control-M for z/OS User Guide

 Chapter

5
5 JCL and AutoEdit Facility
This chapter includes the following topics:

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
System variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Non-Date System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Date System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Special System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
User-Defined Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Valid Characters in User-Defined Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Global Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
JCL Setup Operation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Rules of Variable Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Order of Precedence for Multiple Value Assignments . . . . . . . . . . . . . . . . . . . . . 782
Control Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
%%GLOBAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
%%GOTO and %%LABEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
%%IF, %%ELSE, %%ENDIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
%%INCLIB and %%INCMEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
%%LIBSYM and %%MEMSYM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
%%RANGE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
%%RESOLVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
%%SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
%%$CALCDTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
%%$GREG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
%%$JULIAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
%%$LEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
%%$WCALC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
%%$WEEK# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
%%$WEEKDAY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
%%$YEARWK# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
%%CALCDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
%%SUBSTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
%%$LENGTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802

Chapter 5 JCL and AutoEdit Facility 755

 %%$TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
%%$FUNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Testing AutoEdit Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
AutoEdit Usage in the Job Scheduling Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Date Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
ODATE, RDATE and DATE Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
How to Obtain Date Formats – 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
How to Obtain Date Formats – 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
How to Obtain Date Formats – 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
How to Obtain the Previous Month’s Last Business Date . . . . . . . . . . . . . . . . . . . 813
Automatic Job Order for the Next Day. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Tape Clearance System – Stage 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Tape Clearance System – Stage 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Tape Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Dynamic Job Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Controlling the Target Computer by Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Controlling the Target Computer by System Affinity . . . . . . . . . . . . . . . . . . . . . . 818
%%BLANKn Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
%%RANGE Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
SYSIN Parameter Containing %% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
%%INCLIB and %%INCMEM Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Boolean “IF” Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821

756 Control-M for z/OS User Guide

 Overview

Overview
In the production environment, it is often necessary to manually modify JCL prior to
submission of a job, as in the following cases:

■ changing a parameter or a date card

■ supplying tape numbers in JCL procedures
■ eliminating steps under different run conditions (for example, end of month
processing versus normal daily run)

Manual modification of JCL is inconvenient at best, and it may, in fact, be error prone
and lead to serious problems.

The AutoEdit facility offers an automated alternative to manual JCL modification.

This facility permits AutoEdit terms (variables, functions, and similar terms,
described in this chapter) to be specified in the JCL in place of values that change
from job submission to job submission. At time of job submission, these terms are
resolved to their actual values.

The inclusion of AutoEdit terms in the job stream can eliminate the need to
continually change the JCL. Some AutoEdit terms can also be used in job scheduling
definitions.

AutoEdit terms are prefaced by a %% symbol, which distinguishes them from terms
that are not AutoEdit terms. For example, the term %%ODAY is recognized as an
AutoEdit term.

NOTE
AutoEdit terms must be placed within the job stream submitted by CONTROL-M, not within
a catalogued JCL procedure.

The use of AutoEdit terms within started tasks (STCs) is not supported.

The components of the AutoEdit facility are described briefly on the following pages
and in greater detail later in this chapter.

Variables

Variables are the main components of the AutoEdit facility. Variables are used to
replace manually changed values, generally within the JCL. AutoEdit variables can
be either of the following types:

■ System Variables

System variables are predefined, reserved variables that represent information

about the system.

Chapter 5 JCL and AutoEdit Facility 757

Overview

For example, System variable %%ODATE is replaced by the job’s original

scheduling date.

■ User-Defined Variables

User-defined variables are created by the user. The user must provide the value (or
the tools to derive the value) that replaces the variable at time of job submission.

For example, the user can define a variable, %%SPACE-TYPE, to represent the type
of storage unit (cylinder or track) on disk.

User-defined variables are either:

— local variables

Local variables are used only within the job stream. The value of a local variable
can be set or changed within the job stream by CONTROL-M, but the changed
value is kept only in memory for use during submission of that job stream. The
value is not passed to another job stream.

— Global variables

Global variables are user-defined variables that are placed in the IOA Global
Variable database, from which they can be accessed and updated by other
CONTROL-M jobs and CONTROL-O rules.

System variables and user-defined variables are discussed in detail below. Local
variables and Global variables are also discussed in detail, under the topic of
user-Defined variables.

■ Control Statements

AutoEdit control statements in the JCL define the environment for user-defined
variables. The AutoEdit facility supports many AutoEdit control statements, and
this is discussed in detail later. Some of the more important control statements are
described here briefly.

Table 243 AutoEdit Control Statements

Statement Description
%%GLOBAL member Identifies a member that contains a set of user-defined local variables
and their assigned values.
%%LIBSYM library / Identifies a member and library that contain a set of user-defined
%%MEMSYM member local variables and their assigned values.
%% SET %%variable = Sets a value to a user-defined variable in the JCL.
value

758 Control-M for z/OS User Guide

 Overview

Operators

AutoEdit operators modify the values of AutoEdit variables in the JCL. For example,
in the following statement, operator %%PLUS assigns a number to a scratch tape that
is one higher than the previously assigned tape number:

//* %%SET %%SCRATCH=%%SCRATCH %%PLUS 1

Functions

AutoEdit functions perform functions on specified AutoEdit variables in the JCL. For
example, in the following statement, the %%CALCDATE function sets AutoEdit
variable %%NEXTDAY to one day after the current System variable %%ODATE:

//* %%SET %%NEXTDAY=%%CALCDATE %%ODATE +1

The format of a function statement depends on the function.

AutoEdit Components in the Job Scheduling Definition

Although the most important and common use of AutoEdit components is in JCL
setup, certain AutoEdit components can also be used in the job scheduling definition.

SET VAR and DO SET job scheduling definition statements assign values to
user-defined variables. These statements perform a similar function as, and work
together with, %%SET control statements specified in the JCL.

Other job scheduling definition statements (for example, SYSOUT, SHOUT,

MEMLIB) allow specification of System variables.

JCL Setup and AutoEdit Features

The rest of this chapter contains a description of the following JCL Setup and
AutoEdit topics:

■ System variables
■ User-Defined Variables
■ JCL Setup Operation Flow
■ Rules of Variable Resolution
■ Control Statements
■ Operators
■ Functions
■ Testing AutoEdit Syntax
■ AutoEdit Usage in the Job Scheduling Definition
■ Examples

Chapter 5 JCL and AutoEdit Facility 759

System variables

System variables
CONTROL-M System variables are predefined, reserved, commonly used variables
whose values are automatically updated and maintained by CONTROL-M. The
System variable format is:

%%var

where var is the name of the System variable.

Each variable resolves to the corresponding system value. The length of the line is
changed accordingly. For example:

//EJ%%ODATE JOB (0,l5, ...

// EXEC ACCOUNTS,DAY=%%ODAY,MONTH=%%OMONTH

If the original scheduling date is June 5, 2001, the variables are resolved as follows:

//EJ000603 JOB (0,l5, ...

// EXEC ACCOUNTS,DAY=05,MONTH=06

Non-Date System Variables

The following AutoEdit System variables are supported by CONTROL-M (in both
JCL and in job scheduling definitions):

Table 244 Non-Date AutoEdit System Variables (part 1 of 3)

Variable Description
%%. Concatenation symbol.
%%APPL Application to which the job belongs.
%%BLANK Blank.

760 Control-M for z/OS User Guide

 Non-Date System Variables

Table 244 Non-Date AutoEdit System Variables (part 2 of 3)

Variable Description
%%BLANKn Resolves to n blanks, where n is a number from 1 through 80.
Note: When entering an AutoEdit variable assignment (such as
%%A = 1), any leading spaces (blanks) following the '=' are ignored
and any succeeding spaces in the character string terminate the
variable value when the variable is resolved. System variables
%%BLANK and %%BLANKn enable you to embed spaces in the
variable expression.

The variable assignment

%%A = This%%BLANKis%%BLANK1an%%BLANKexample, using
%%BLANK and %%BLANKn to create embedded spaces, resolves to
This is an example
%%BLANK and %%BLANK1 each produce the same result, a single
embedded space.

The similar variable assignment, %%A = THIS IS AN EXAMPLE,

resolves to THISISANEXAMPLE.
%%GROUP Group to which the job belongs.
%%JOBNAME Name of the submitted job as specified in the JCL job statement. If
%%JOBNAME is resolved before the job submission (for example,
%%JOBNAME is used in a SHOUT WHEN LATESUB statement,
and the job has not been submitted), its value is assigned the
%%$MEMNAME value.
%%ORDERID Unique job order ID under CONTROL-M (5 characters).
%%OWNER Owner of the job, as specified in the scheduling definition.
%%RN Run number (can exceed one for cyclic and rerun and restarted jobs).
%%TIME Current time of day, in hhmmss format. This variable receives the
current time each time it is invoked.
%%TIMEID Current time of day, in hhmmss format. This AutoEdit variable
receives the current time only when it is first resolved in a job.
Subsequent resolutions within that job do not update the variable.
%%$DATEFMT Resolves to A, W, or J, according to the DATETYP date format
parameter defined in the IOAPARM member in the IOA PARM
library.
%%$L The computer LPAR name where the job executed.
%%$MEMNAME Name of the JCL member from which the job is submitted. (This
corresponds to the value specified in the job scheduling definition.)
%%$QNAME Qname (unique identifier) of the monitor that submitted the job.
%%$SCHDLIB Name of the scheduling library that contains the job scheduling
definition of the job. This variable is resolved only after the job has
been ordered.
%%$SCHDTAB Name of the table that contains the job scheduling definition of the
job. This variable is resolved only after the job has been ordered.
%%$SCHENV Name of the scheduling environment that is specified in the job
scheduling definition.

Chapter 5 JCL and AutoEdit Facility 761

Date System Variables

Table 244 Non-Date AutoEdit System Variables (part 3 of 3)

Variable Description
%%$SIGN 1-character ID of the computer on which the job is running.
The %%$SIGN variable is commonly used when assigning system
affinity, as in the following example:
/*JOBPARM SYSAFF=CPU%%$SIGN
For more information, see “Controlling the Target Computer by
System Affinity” on page 818.
Note: The %%$SIGN variable is not resolved unless the job
scheduling definition from which the job is ordered contains a
resource name with a $ mask character used as a generic indicator.
For more information, see “RESOURCE: Runtime Scheduling
Parameter” on page 605.
%%$SYSNAME Name of the system on which the CONTROL-M monitor is running.
%%$RBC Name of the rule-based calendar by which the job was scheduled. If
the SMART Table was forced, or if the job was scheduled based on
basic scheduling criteria other than a rule-based calendar, this value
resolves to blanks.

Date System Variables

Many System variables specify dates, or parts of dates, in various formats. Therefore,
it is useful to understand the categories of dates with which CONTROL-M is
concerned.

Dates are divided into the categories listed below. For a description of these
categories, see “Date Definition Concepts” on page 65

■ Working Date

System variables that specify working dates begin %%R (%%RDATE, %%RDAY,
and so on).

■ Original Scheduling Date

System variables that specify original scheduling dates begin %%O (%%ODATE,
%%ODAY, and so on).

■ System Date

System variables that specify system dates have no special prefix other than %%
(%%DATE, %%DAY, and so on).

Although these types of dates are resolved in Gregorian format, Julian formats can
also be requested (%%JULDAY, %%OJULDAY and %%RJULDAY).

762 Control-M for z/OS User Guide

 Date System Variables

The following date AutoEdit System variables are supported by CONTROL-M in JCL
and in certain job scheduling definition parameters (for more information, see
“AutoEdit Usage in the Job Scheduling Definition” on page 808):

Table 245 Date AutoEdit System Variables

Variable Description
%%$CENT First two digits in the current year (for example, 20 in the year 2000).
%%DATE Current system date (format yymmdd).
%%DAY Current system day (format dd).
%%MONTH Current system month (format mm).
%%YEAR Current system year (format yy).
%%WEEK Current week in the year (that is, 01 through 53).
%%WDAY Current system day of the week (Example: 1=Sunday, 2=Monday and
0=Saturday).a
%%$OCENT First two digits of the year in which the job was originally scheduled.
%%ODATE Original scheduling date of the job (format yymmdd).
%%ODAY Original scheduling day of the job (format dd).
%%OMONTH Original scheduling month of the job (format mm).
%%OYEAR Original scheduling year of the job (format yy).
%%OWEEK Original scheduling week of the job (that is, 01 through 53).
%%OWDAY Original scheduling day of the week of the job (format d; Example:
1=Sunday, 2=Monday and 0=Saturday).1
%%$RCENT First two digits of the current working year.
%%RDATE Current working date (format yymmdd).
%%RDAY Current working day (format dd).
%%RMONTH Current working month (format mm).
%%RYEAR Current working year (format yy).
%%RWEEK Current working week (that is, 01 through 53).
%%RWDAY Current working day of the week (format d; Example: 1=Sunday,
2=Monday and 0=Saturday).1
%%JULDAY Current system day (Julian format jjj).
%%OJULDAY Original scheduling day of the job in the year (Julian format jjj).
%%RJULDAY Current working day of the year (Julian format jjj).
a Start of the week at a site depends upon an IOA installation parameter that specifies whether
1=Sunday or 1=Monday. Your INCONTROL administrator can tell you whether the week
begins on Sunday or Monday at your site. The above reference assumes 1=Sunday,
2=Monday, … 6=Friday, 0=Saturday.

Chapter 5 JCL and AutoEdit Facility 763

Special System Variables

The following AutoEdit System variables, prefixed %%$, resolve to dates having
4-character years:

Table 246 4 Character Year Date AutoEdit System Variables

Variable Description
%%$DATE Current system date (format yyyymmdd).
%%$YEAR Current system year (format yyyy).
%%$ODATE Original scheduling date of the job (format yyyymmdd).
%%$OYEAR Original scheduling year of the job (format yyyy).
%%$RDATE Current working date (format yyyymmdd).
%%$RYEAR Current working year (format yyyy).
%%$JULDAY Current system day (Julian format yyyyjjj).
%%$OJULDAY Original scheduling day of the job in the year (Julian format yyyyjjj).
%%$RJULDAY Current working day of the year (Julian format yyyyjjj).

Special System Variables

Special System variables are resolved during specific parts of the life cycle of jobs.

The following are the types of special System variables:

■ those that are resolved after a SMART Table is ordered but before any of the jobs in
the table are ordered

■ those that can only be resolved after the job has ended

■ those that can only be resolved after job submission

Special System variables of the latter types, that is, those that can only be resolved
after the job has ended and those that can only be resolved after job submission, can
only be used with the post-processing parameters in the job definition, such as
SHOUT and DO IF RERUN.

Special System variables resolved after a SMART Table is

ordered, but before job submission
The special System variable shown in Table 247 can only be resolved after a SMART
Table is ordered, but before job submission.

764 Control-M for z/OS User Guide

 Special System Variables

Table 247 Special AutoEdit System variable resolved after a SMART Table is ordered
but before job submission

%%$GRID ■ SMART Table Entity Order ID, primarily used within a

job scheduling definition. At job ordering time, this value
is resolved to the Order ID of the SMART Table to which
the job belongs.

■ If the job does not belong to a SMART Table, or if the job

is forced from a SMART Table, %%$GRID is resolved to
“?????”.

■ %%$GRID is resolved in condition names, in IN, OUT or

DO COND parameters.

%%$GRID is especially useful in condition names, to enable

unique identification of condition names that are added by
multiple ordering of jobs from the same SMARTtable.

Chapter 5 JCL and AutoEdit Facility 765

Special System Variables

Special System variables resolved after end of job

The special System variables in Table 248 can only be resolved after the job has
ended. These variables contain a blank value if the job ends OK or if no step in the job
was run.

Table 248 Special AutoEdit System Variables Resolved after Job End
Variable Description
%%JOBCC Job completion code that caused the job to end NOTOK. For jobs ended
OK, this variable resolves to blanks.
%%MAXRC The highest return code in the job execution from among the steps that
ended NOTOK because of high return codes. The abended step(s) and
steps that ended OK are not considered for the resolution of this variable.
For jobs ended OK, this variable resolves to blanks.
%%$NODEID The value of the node name that appears in the Active Environment
Zoom screen. This variable is only resolved for NJE jobs; for non-NJE
jobs, it resolves to a null value.
%%STEP Job program step and procedure step (if it is defined) that caused the job
to end NOTOK. This is the Job step that generated the Job Completion
Code (resolved to %%JOBCC, described above). For jobs ended OK, this
variable resolves to blanks.

Format: 8-character program step (including blanks if necessary),

followed by the procedure step name (up to eight characters).
%%$PGMSTEP Job program step (equal to the first part of the %%STEP variable).
%%$PRCSTEP Procedure step (equal to the second part of the %%STEP variable).
%%$HIGHRC The highest return code from among all the steps of the job (in the Cnnnn
format). This value includes both the steps ended NOTOK and the steps
ended OK. If any of the steps ended abnormally, the first ABEND Code
(either in Sxxx or Uxxxx format) is saved as the highest return code.
%%$HIGHST The name of the job step that generated the highest return code
(%%$HIGHRC, described above).
%%$HIGHPR The name of the job procedure step that generated the highest return
code (%%$HIGHRC, described above).
%%$HIGHMN For Smart tables only. The name of the job member that generated the
highest return code from among all the jobs of the smart table.

NOTE
The effect of an ON PGMST...DO OK statement, or of the value of the MAXCCOK parameter
may be that CONTROL-M treats a non-zero return code of a step in a job as OK. In such a
case, the non-zero return code of that step is ignored by CONTROL-M in calculating values
for the %%JOBCC and %%MAXRC AutoEdit System variables.

766 Control-M for z/OS User Guide

 User-Defined Variables

Special System variables resolved after job submission

The special System variable shown in Table 249 can only be resolved after job
submission. This variable contains a blank value if the job ends OK or if no step in the
job was run.

Table 249 Special AutoEdit System Variable Resolved after Job Submission
Variable Description
%%JOBID JES job number

User-Defined Variables
The ability to specify user-defined variables provides additional flexibility. You can
define your own variables and assign values to them. CONTROL-M automatically
edits the job stream accordingly. This facility is especially useful when it is necessary
to share parameters or other information (for example, tape numbers) among jobs.

CONTROL-M assumes that strings beginning with %% are user-defined variables,

except those beginning with %%$, which are reserved System variables.

For a list of all System variables, see “System variables” on page 760.

User-defined variables are defined as either:

■ Local variables, which are discussed in “Local Variables” on page 770

■ Global variables, which are discussed in “Global Variables” on page 773

Multiple AutoEdit variables can be joined with each other and with constants, and
periods (.) are often part of this process (for example,
JOB_%%JOBID%%._ENDED_OK). This is discussed in more detail in “Rules of
Variable Resolution” on page 780.

Backslashes (\) are used only in Global variable assignments, and differentiate Global
variables from local variables. For more information, see “Global Variable
Assignment and Syntax” on page 774.

Unlike System variables, which are predefined and which receive their values from
the system at time of job submission, two steps are performed for utilizing
user-defined variables:

■ The first step consists of specifying (defining) user-defined variables, usually

within the JCL, instead of values that require manual modification.

Chapter 5 JCL and AutoEdit Facility 767

Valid Characters in User-Defined Variables

■ The second step consists of providing values to replace the user-defined variables
at time of job submission. (Since the values are not provided by the system, the
user must specify the appropriate values.) It is permissible, however, for
user-defined variables to take their values from System variables (for example,
%%SET %%VERSION = %%ODATE).)

User defined AutoEdit variables in post-processing statements of the scheduling

definition (DO MAIL, DO SHOUT, and so on) are resolved according to the following
search order:

■ SET VAR statements in the job's definition

■ SET VAR statements in the SMART Table Entity (for jobs belonging to a SMART
Table)
■ AutoEdit definitions loaded into the CONTROL-M AutoEdit cache

Note that during post-processing, it is impossible to refer to an external library

member containing AutoEdit variable definitions (that is, through %%LIBSYM xxxxx,
%%MEMSYM yyyy, or %%GLOBAL zzzz statements). The only external method of
resolving user AutoEdit variables for post-processing is to load the member(s) into
the AutoEdit cache (see “Loading %%GLOBAL Members to Cache” on page 771.

Valid Characters in User-Defined Variables

When defining AutoEdit variables, only certain characters can be used. The validity
of characters depends on the purpose for which they are being used.

768 Control-M for z/OS User Guide

 Valid Characters in User-Defined Variables

AutoEdit Variable Names

AutoEdit variable names have a maximum of 163 characters. The following
characters can be used in AutoEdit variable names:

■ any character from A through Z, both uppercase and lowercase

■ any digits from 0 through 9
■ the following special characters:
— & (Ampersand)
— $ (Dollar)
— _ (Underscore)
— # (Octothorp)
— @ (At)
■ the following hexadecimal values:
— from x'41' through x'49'
— from x'51' through x'59'
— from x'62' through x'69'
— x'71'

NOTE
BMC Software recommends that you do not use non-display hexadecimal values.

As variable names beginning with $ are reserved for BMC use, do not use $ as the first
character of user-defined variables.

AutoEdit Variable Value Fields

Any characters can be used in AutoEdit variable value fields except the following:

■ ' ' (Blank)

■ the following hexadecimal values:
— x'00'
— x'FE'
— x'FF'

NOTE
BMC Software recommends that you do not use non-display hexadecimal values.

Chapter 5 JCL and AutoEdit Facility 769

Local Variables

AutoEdit Variables in JCL

In any JCL line that contains AutoEdit variables, do not use the following
hexadecimal values unless their processing is excluded by a %%RANGE or a
%%RESOLVE OFF statement:

— x'00'
— x'FE'
— x'FF'

Global AutoEdit Variables

The following characters have special meanings in Global AutoEdit variables:

■ . (Period)
■ \ (Backslash)

Do not use these characters in the variable name field unless you require the special
meaning assigned to them.

Local Variables
Local variables are user-defined variables that are only within the job stream. The
value of a local variable can be changed within the job stream, but the changed value
is kept only in memory for use during submission of that job stream. The value is not
passed to another job stream.

Local variables can be defined in either of two ways:

■ by means of %%SET statements in the JCL and/or SET VAR and DO SET
statements in the job scheduling definition

%%SET statements are described under “Control Statements” on page 783. SET
VAR statements are described in “SET VAR: General Job Parameter” on page 630,
and DO SET statements are described in “DO SET: Post–Processing Parameter” on
page 472.

■ by placing the variables and their values in special variable members

Variable members are members dedicated to holding user-defined AutoEdit

variables and their values. These variables and values in these members can be
used by any number of CONTROL-M jobs or CONTROL-O rules that are given
access. However, these jobs and rules cannot update these members.

770 Control-M for z/OS User Guide

 Local Variables

Members containing user-defined variables can be identified in either of two ways:

— by a %%MEMSYM control statement

This member must reside in the library specified in the %%LIBSYM statement
that must accompany the %%MEMSYM statement. (The control statements
%%LIBSYM and %%MEMSYM are described “Control Statements” on
page 783.) Any number of such variable members can be defined.

— by a %%GLOBAL control statement

This statement differs from the %%MEMSYM statement in that it does not have
an accompanying %%LIBSYM statement. Instead, the library in which the
%%GLOBAL member resides is pointed to by a DAGLOBAL DD statement.

For example, the user may specify variable %%BRANCH_TAPE in a JCL

statement:

//S001.INPUT DD VOL=SER=%%BRANCH_TAPE

and the %%MEMSYM member (or %%GLOBAL member) that assigns values
might contain the following variable definition:

%%BRANCH_TAPE=045673

%%MEMSYM, %%LIBSYM and %%GLOBAL control statements are described in

“Control Statements” on page 783.

Loading %%GLOBAL Members to Cache

%%Global members can be placed in cache memory, from where they can be accessed
as needed. If the members are placed in cache, the JCL accesses the contents from the
cache, instead of accessing the members themselves.

This can be very advantageous if many jobs access %%Global members, because each
access of the member increases I/O and processing overhead.

Only those %%GLOBAL members that are specifically requested are loaded to cache.
Requests are generally made by listing the desired %%GLOBAL members in a special
cache list member in the DAGLOBAL library. This cache list member (default name:
CACHLST) is pointed to by the AECACHL parameter in the CTMPARM member in
the IOA PARM library.

Members are listed in the cache list member in the following format:

%%GLOBAL memname

Chapter 5 JCL and AutoEdit Facility 771

Local Variables

where memname is the name of the %%GLOBAL member in the Global library.

The cache list member can optionally contain the following control statement as its
first non-comment statement:

%%RESOLVE ALLCACHE

This control statement affects AutoEdit processing only if an AutoEdit variable has
not been resolved by searching the %%GLOBAL members identified in the job. The
statement instructs CONTROL-M to continue the variable resolution process by
checking all members loaded into cache. Members in cache are searched in the same
sequence they are listed in the cache list member.

%%GLOBAL members are loaded to cache at time of CONTROL-M startup.

To reload %%GLOBAL members to cache between CONTROL-M startups or to stop

using AutoEdit cache, see “Loading %%GLOBAL Members to Cache” on page 771,
and the corresponding topic in the INCONTROL for z/OS Administrator Guide.

Format of Variable Members

A variable member (referenced by %%GLOBAL or %%MEMSYM statements) must
be a member in a partitioned data set with a record length of 80. It can contain the
following types of lines:

■ Remark line: Line starting with an asterisk (*) in column 1. Remark lines are not
processed.

■ Assignment line: Line that assigns a value to a variable. The format is:

%%varname=value

Any number of user-defined variables (and their values) can be defined in a variable
member. To designate a null value, omit the value.

772 Control-M for z/OS User Guide

 Global Variables

Example

* Last banking day in each month

*
%%LAST_BANKING_DAY_0001=010131
%%LAST_BANKING_DAY_0002=010228
%%LAST_BANKING_DAY_0003=010330
%%LAST_BANKING_DAY_0004=010430
%%LAST_BANKING_DAY_0005=010531
%%LAST_BANKING_DAY_0006=010629
%%LAST_BANKING_DAY_0007=010731
%%LAST_BANKING_DAY_0008=010831
%%LAST_BANKING_DAY_0009=010928
%%LAST_BANKING_DAY_0010=011031
%%LAST_BANKING_DAY_0011=011130
%%LAST_BANKING_DAY_0012=011231

Global Variables
A Global variable is a user-defined variable that is placed in the IOA Global Variable
database.

%%SET statements in the JCL, and SET VAR or DO SET statements in the job
scheduling definition, enable CONTROL-M jobs and SMART Table Entities to define
Global variables and place them in the IOA Global Variable database.

However, since %%SET, SET VAR and DO SET statements also define local variables,
a distinguishing factor is needed to differentiate Local Variables from Global
variables. The distinguishing factor is provided by syntax, which is described in
“Global Variable Assignment and Syntax” on page 774.

A Global variable from the IOA Global Variable database can be specified anywhere a
local variable can be specified in the JCL or the job scheduling definition (SHOUT,
DO SHOUT, SYSOUT, DO SYSOUT, MEMLIB and OVERLIB statements).

Structure of the IOA Global Variable Database

The IOA Global Variable database has a hierarchical structure consisting of several
levels. This structure mirrors the hierarchical structure of the CONTROL-M
components of which a CONTROL-M job is a part.

The levels in the IOA Global Variable database structure, starting from the lowest, are
as follows:

Chapter 5 JCL and AutoEdit Facility 773

Global Variables

Table 250 IOA Global Variable Database Structure Levels

Level Description
Variable Global variable in the IOA Global Variable database.
Job Name of the job (JCL member) that appears in the MEMNAME field
of the job scheduling definition.
Group Group to which the job belongs. The name of the group appears in
the GROUP field of the job scheduling definition.
Application Application to which the group and job and belong. The name of the
application appears in the APPL field of the job scheduling
definition.
Product M (CONTROL-M).

The importance of this structure is discussed in the topic “Global Variable

Assignment and Syntax” immediately below.

Global Variable Assignment and Syntax

Whenever a job (or SMART Table Entity) creates a Global variable and places it in the
IOA Global Variable database, it assigns an owner to the variable.

The job that creates the variable can assign itself as the owner (for example, JOBA
defines a Global variable that is assigned to JOBA), but it does not have to do this. It
can, instead, assign a different owner to the variable (for example, JOBA defines a
Global variable that it assigns to GROUP_ABC).

In fact, when a Global variable is created, it can be assigned to any component (job,
group, application, or even to CONTROL-M) in the database. It is this ability to
assign variables that makes the structure of the IOA Global Variable database so
important.

The hierarchical structure of the IOA Global Variable Database, described above, is
similar to the directory and subdirectory structure in Unix and DOS. Therefore, the
same path structure and syntax that is used to describe directories and subdirectories
is used to define and identify Global variables.

Note the following points about Global variable assignment and syntax:

■ Global variables are identified (and distinguished from Local variables) by a

backslash.

Example

— Variable %%PROBID is a Local Variable.

— Variable %%\PROBID is a Global Variable.

774 Control-M for z/OS User Guide

 Global Variables

■ In the IOA Global Variable database, the format for indicating a full path is as
follows:

%%\product\application\group\job\variablename

■ Two variables with the same name but different paths are different variables. This
is comparable to the fact that two Unix or DOS files with the same name but
different paths are different files. For example, File A under \A\B\C directory is a
different file than File A under \D\E\F directory.

Example

Due to the different paths, the following variables are all different from each other:

%%\M\APP_1\TBL_1\JOB_A\VAR_XYZ
%%\M\APP_1\TBL_1\JOB_B\VAR_XYZ
%%\M\APP_1\TBL_1\VAR_XYZ

■ If the particular path has no Group and/or no Application (for example, the job
does not belong to a group or application), CONTROL-M utilizes the keyword
values “NO_APPL” and “NO_GROUP” in the path, as needed.

■ Paths can be specified using the same rules and shortcuts that are available with
directories and subdirectories (instead of the full path):

— A job or SMART Table Entity can assign a Global variable to itself by specifying
a slash immediately following the %% symbol.

Example

If JOB1 job with TBL_A group, which belongs to application APP_1, then the
following SET VAR statement in JOB1:

SET VAR=%%\PROBID=123

creates the following variable assigned to JOB1 (with the indicated full path):

%%\M\APP_1\TBL_A\JOB1\PROBID=123

— Paired dots with a backslash (..\) indicate movement to the next level up.

Example

If JOB1 with TBL_A group, which belongs to application APP_1, then the
following SET VAR statement in JOB1:

SET VAR=%%..\PROBID=123

Chapter 5 JCL and AutoEdit Facility 775

Global Variables

creates the following variable assigned to TBL_A (with the indicated full path):

%%\M\APP_1\TBL_A\PROBID=123

— To move directly down the hierarchy, it is only necessary to indicate the levels
that are lower than the current level. (However, since only SMART Table
Entities and jobs utilize variables, only SMART Table Entities can move directly
down a level.

Example

Assume SMART Table Entity with TBL_A assigns variable %%A, with a value
equal to 7, (%%A = 7) to JOB2 job. The following statement indicates the syntax
of the %% SET statement:

//* %%SET %%\JOB2\A=7

— To move across the hierarchy (that is, to change paths), you can either:

■ Specify a full path, or

■ Move up to a component common to both paths, and then move down the
other path.

Example 1

Assume JOB1 job with TBL_A group assigns variable %%A (with a value equal
to 7) to JOB2 job in the same group (and assume the group has no application).
Any of the following statements can be specified:

//* %%SET %%..\JOB2\A=7

//* %%SET %%\M\NO_APPL\TBL_A\JOB2\A=7

Example 2

Assume JOB1 job, with TBL_A group, which is in application APP_A, assigns
variable %%A, with a value equal to 7, to JOB2 job with TBL_B group and which
does not have an application.

Either of the following %% SET statements work:

//* %%SET %%\M\NO_APPL\TBL_B\JOB2\A=7

//* %%SET %%..\..\..\NO_APPL\TBL_B\JOB2\A=7

■ If two statements assign the same Global variable to the same component, the later
assignment overwrites the earlier assignment.

776 Control-M for z/OS User Guide

 Global Variables

Example

Assume JOB1 job with TBL_A group is run before JOB2 job with the same group
(and both belong to application APP_A).

If JOB1 contains the following SET VAR statement:

SET VAR=%%..\A=7

and JOB2 contains the following SET VAR statement:

SET VAR=%%..\A=8

At the end of the job run for JOB2, the IOA Global Variable database contains the
following variable (assigned to TBL_A):

%%\M\APP_A\TBL_A\A=8

■ A job or SMART Table Entity can utilize a Global variable that has been assigned to
it by merely specifying the variable with the backslash, even if the variable was
created by a different job. (The full path is not required.)

Example

Assume JOB1 job contained the following statement that assigned the following
variable to JOB2:

DO SET VAR=%%\M\NO_APPL\TBL_A\JOB2\PROBID=123

JOB2 can then access this variable in a DO SHOUT statement without a full path
name by specifying the variable with a backslash.

DO SHOUT TO TSO-U0014 URGENCY U

=*** Problem Encountered. Problem ID=%%\PROBID ***

■ When changing paths or assigning a variable to a higher level component on the

same path, a security check can be required.

■ A job or SMART Table Entity can utilize a Global variable that has been assigned to
a different component by specifying the appropriate path. However, before the
variable could be utilized, security checks, if any, would have to be passed.

Example

If a Global variable is assigned to JOB1 job as in the following statement:

DO SET VAR=%%\M\NO_APPL\TBL_A\JOB1\PROBID=123

Chapter 5 JCL and AutoEdit Facility 777

JCL Setup Operation Flow

and JOB2 accesses the variable, it would have to specify the appropriate path name
(and pass any required security checks). For instance, JOB2 can access this variable
in a DO SHOUT statement as follows:

DO SHOUT TO TSO-U0014 URGENCY U

=**Problem Occurred. ID=%%\M\NO_APPL\TBL_A\JOB1\PROBID**

JCL Setup Operation Flow

All JCL setup operations are performed during job submission. At this time,
CONTROL-M processes the JCL of the job line by line.

CONTROL-M scans each line for AutoEdit terms (identified by the %% symbol) and
tries to resolve them (unless otherwise instructed). CONTROL-M resolves all
AutoEdit terms in a line before it moves to the next line.

All changes made during JCL processing (such as variable resolution) are retained
only until CONTROL-M has finished submission of the job.

CONTROL-M resolves System variables by taking the values from the system.

CONTROL-M resolves Global variables by taking the values from the IOA Global
Variable database.

Values for Local user-defined variables can be taken from any of several possible
sources (described below). When CONTROL-M detects a local user-defined variable
in the JCL line being processed, it checks these possible sources in a specific order
until a value is found for the variable. CONTROL-M creates a user-defined variable
environment in which it places each user-defined variable and its value.

The potential sources for local user-defined variable values are listed below in the
order in which they are generally checked:

■ System variable values

■ %%SET control statements

These statements can be specified in JCL lines, including JCL comment lines. They
assign values to variables.

■ SET VAR and DO SET statements

These statements can be specified in the job scheduling definition. They can be
used to define new variables, or to assign new values to existing variables.

778 Control-M for z/OS User Guide

 JCL Setup Operation Flow

SET VAR statements can affect all job submissions.

DO SET statements can override values specified by a SET VAR or previous DO SET
statement. However, since DO SET statements are post-processing parameters, they
only affect subsequent runs of a job (rerun and restarted jobs).

■ Local variables and values defined in members specified in %%LIBSYM /

%%MEMSYM control statements

These members define local variables and specify their values. Members are
searched in the order in which they appear in the JCL.

■ Local variables and values defined in members specified in %%GLOBAL control

statements

These members define local variables and specify their values. Members are
searched in the order they appear in the JCL.

The order in which CONTROL-M checks potential sources for possible AutoEdit
variable resolution is important because once CONTROL-M has resolved a variable,
it generally stops checking other sources. Potential values from other sources are
ignored, and resolved values are not overridden except by %%SET statements in
subsequent JCL lines.

Because JCL is processed sequentially one line at a time, the line being processed can
only be affected by external members and %%SET control statements that have
previously been processed. If a line contains an undefined variable that is only
defined in a subsequent line, the variable cannot be resolved.

By default, if CONTROL-M cannot resolve a variable, it stops submission of the job.

This default, however, can be overridden by specifying the %%RESOLVE control
statement with a value of NO or OFF (described later in this chapter).

To stop submission of a job because of an unresolved variable, CONTROL-M creates

an intentional JCL error that prevents execution of the job’s already submitted JCL.
The job ends with the status NOT SUBMITTED for reason JNSUB. The erroneous JCL
remains on the spool, but does not affect other job executions except those that
depend on the successful execution of this job.

Local variable values taken from variable members (%%MEMSYM and %%GLOBAL
members) that are changed during job submission remain in effect only until
CONTROL-M finishes submission of the job. Therefore, a change made to such a
variable (using the %%SET control statement) affects only submission of that job and
does not affect any other job submission or the value of the variable in the variable
member.

Chapter 5 JCL and AutoEdit Facility 779

Rules of Variable Resolution

Rules of Variable Resolution

By default, columns 1 through 72 of JCL lines are searched for variables which are
then analyzed and resolved. If column 72 contains an asterisk (*), the active range for
resolution is columns 1 through 71 (to support continuation lines).

Multiple AutoEdit variables (and constants) can be joined together into a complex
term. When a term contains multiple variables, those variables are resolved from
right to left.

The methods of joining multiple variables together are described below.

■ Two variables can be joined to form a single complex variable by linking them
together (such as %%A%%B).

Example 1

Given: %%A=1, %%B=2, %%A2=100

Resolve: %%A%%B
Explanation: The process of resolution is as follows:
Initial expression to resolve %%A%%B
Resolve %%B 2
Replace %%B with value 2 %%A2
(%%A%%B partially resolves to a single variable %%A2)
Resolve %%A2 100
Solution: %%A%%B resolves to 100

Example 2

Given: The day is the 3rd of the month.

Resolve: //SYSBKP DD UNIT=TAPE,VOL=SER=%%BACKUP_TAPE_%%ODAY,
Solution: This statement partially resolves to:
//SYSBKP DD UNIT=TAPE,VOL=SER=%%BACKUP_TAPE_03,
%%BACKUP_TAPE_03 is a single user-defined variable. If the value of
this variable is known to CONTROL-M as EE1022, the statement would
fully resolve to:
//SYSBKP DD UNIT=TAPE,VOL=SER=EE1022,

■ Two variables can be concatenated into two distinct but joined variables by placing
a period between them (such as %%A.%%B).

780 Control-M for z/OS User Guide

 Rules of Variable Resolution

Example 1

Given: %%A=1, %%B=2, %%A2=100

Resolve: %%A.%%B
Explanation: The process of resolution is as follows:
Initial expression to resolve %%A.%%B
Resolve %%B 2
(The partially resolved variable now reads %%A.2)
Resolve %%A 1
(The partially resolved variable now reads 1.2)
Final resolution of the two values (based on the rule 12
that two variables joined by a period resolve to a
concatenated value)
Solution: %%A.%%B resolves to 12

Example 2

On the 4th of December, %%ODAY.%%OMONTH resolves to 0412

(If the expression had been written %%ODAY%%OMONTH (without the period), it
would have partially resolved to %%ODAY12, which is a user-defined variable
requiring further resolution.)

■ Two variables can be concatenated into two distinct variables joined by a period by
placing two periods between them (such as %%A..%%B).

Example 1

Given: %%A=1, %%B=2, %%A2=100

Resolve: %%A..%%B
Explanation: The process of resolution is similar to the resolution
of two variables joined by one period:
Initial expression to resolve %%A..%%B
Resolve %%B 2
(The partially resolved variable now reads 1.2)
Resolve %%A 1
(The partially resolved variable now reads 1..2)
Final resolution of the two values (based on the rule 1.2
that two variables joined by two periods resolve to
two values joined by a period)
Solution: %%A..%%B resolves to 1.2

Chapter 5 JCL and AutoEdit Facility 781

Order of Precedence for Multiple Value Assignments

Example 2

On the 4th of December, %%ODAY..%%OMONTH resolves to 04.12

■ A constant can be appended to a variable by prefixing the constant with the

concatenation symbol %%. For example, in expression %%AA%%.UP, constant UP
is appended to variable %%AA.

Without symbol %%., the constant would be treated as part of the variable (for
example, expression %%AAUP consists of one variable).

The %%. symbol is not required if the constant precedes the variable (for example,
UNIT%%AA) since the %% prefix of the variable differentiates it from the
constant.

Example

Given: %%MODE = PROD

Resolve: CTM.%%MODE%%.01.JCL
Explanation: The process of resolution is as follows:
Initial expression to resolve CTM.%%MODE%%.01.JCL
Resolve %%MODE PROD
(The partially resolved variable now
reads CTM.PROD%%.01.JCL)
Final resolution (based on the rule that CTM.PROD01.JCL
symbol %%. joins a constant to a
variable)
Solution: CTM.%%MODE%%.01.JCL resolves to CTM.PROD01.JCL

NOTE
To separate a constant (JCL) from a variable (%%MODE) by a period, specifying the period is
sufficient. For example: CTM.%%MODE.JCL would resolve to CTM.PROD.JCL.

Order of Precedence for Multiple Value Assignments

If a particular AutoEdit variable can receive a value from more than one source, an
order of precedence is necessary to determine which of the possible values is
assigned.

The following chart indicates the order of precedence. The chart works as follows:

■ Each row in the chart represents a possible source of a value for a variable.

782 Control-M for z/OS User Guide

 Control Statements

■ In each column, a single pair of value sources (rows) are selected and compared for
precedence:

— The source that takes precedence in the pair is identified by label P.

— The other source in the pair is identified by label O.

When many sources of value assignments are available for a variable, use the chart
below to compare those sources one pair at a time, as follows:

■ From the list of available sources for the particular variable, select any two sources
and use the chart to eliminate the source of lower priority. The list now has one less
source available.

■ Repeat this process until only the source of highest priority remains.

Table 251 Chart for Determining Priorities of Value Assignment Sources

Source of Value Assignment Paired Combinations of Value Sources
SET VAR (Job Scheduling Definition) O P P
JCL SET (earlier) P P P O
JCL SET (later) P
LIBSYM O O P P
LIBSYM2 O
GLOBAL O O O P
GLOBAL2 O

NOTE
JCL SET can apply to an actual AutoEdit SET statement in the JCL or to AutoEdit SET
statements embedded within an INCLIB member referenced in the JCL.

LIBSYM represents a member specified in an earlier statement; LIBSYM2 represents a

different member specified in a later statement. The same applies to GLOBAL and GLOBAL2
respectively.

If there are multiple value assignments for the same variable in the one member, the
last assignment in that member is used for the above calculation.

Control Statements
Control statements define the AutoEdit environment and control AutoEdit
processing.

Chapter 5 JCL and AutoEdit Facility 783

%%GLOBAL

Control statements can appear anywhere in the JCL member to be submitted. When a
control statement is detected in a JCL line (for example, in a JCL remark statement),
the line containing the control statement is submitted as part of the job. If the control
statement appears in a non-JCL line (for example, a line beginning without a //
symbol), the control statement is resolved and the resolved value can be applied to
subsequent JCL lines, but the control statement is not submitted as part of the job.

Available control statements are discussed on the following pages.

%%GLOBAL
Control statement %%GLOBAL defines a member that contains a set of user-defined
variables and values. Before job submission, the CONTROL-M monitor reads this
member from the library referenced by DD statement DAGLOBAL in the
CONTROL-M procedure. The content of the member is added to the user-defined
variable environment of the job.

You can specify more than one %%GLOBAL statement for a job. Each statement is
added to the user-defined variable environment of the job.

Global members can also be placed in cache, which can significantly improve
performance if the member is used by many jobs. For more information, see “Loading
%%GLOBAL Members to Cache” on page 771, and the corresponding topic in the
INCONTROL for z/OS Administrator Guide.

If CONTROL-M fails to access the variable member (member not found, and so on),
the job is not submitted and a warning message is issued to the user who requested
the job.

The format of the %%GLOBAL control statement is:

//* %%GLOBAL memname

where memname is a valid member name of 1 through 8 characters.

Example

//* %%GLOBAL TAPES

//* %%GLOBAL CURRENCY

784 Control-M for z/OS User Guide

 %%GOTO and %%LABEL

%%GOTO and %%LABEL

%%GOTO and %%LABEL control statements provide the AutoEdit facility with “GO
TO” logic, permitting simple inclusion or exclusion of job steps, DD statements, input
date, and so on.

The format of %%GOTO and %%LABEL statements is:

%%GOTO labelname
%%LABEL labelname

The %%GOTO statement transfers control to the location in the program designated
by a matching %%LABEL statement. The search for a matching %%LABEL labelname
is only performed downward (that is, loops are not supported).

All statements between a %%GOTO statement and its matching %%LABEL statement
are not processed (that is, no statements are submitted and AutoEdit statements are
not resolved).

The AutoEdit facility performs a validity check on %%GOTO and %%LABEL control
statement pairs in JCL members. If an active %%GOTO control statement is detected
without its corresponding %%LABEL control statement, an warning message is
issued.

Using the AutoEdit facility, several %%GOTO statements in one JCL member can be
combined, so that a number of jobs defined in the member can be combined into one
job, which can be submitted by CONTROL-M.

%%GOTO and %%LABEL statements are generally used in conjunction with %%IF,
%%ELSE, and %%ENDIF control statements. Examples at the end of this chapter
demonstrate how these statements can be combined.

%%IF, %%ELSE, %%ENDIF

%%IF, %%ELSE, and %%ENDIF control statements provide the AutoEdit facility
with Boolean “IF” logic capability. These statements, in conjunction with %%GOTO
and %%LABEL control statements, permit branching based on submission time
criteria. Job steps, DD statements, and so on are easily excluded or included.

The format of %%IF, %%ELSE, %%ENDIF statements is:

%%IF conditional-expression
statements
[%%ELSE]
statements
%%ENDIF

Chapter 5 JCL and AutoEdit Facility 785

%%IF, %%ELSE, %%ENDIF

where:

■ conditional-expression is the condition that determines whether the accompanying

statements are performed. If the condition is satisfied, the statements
accompanying the %%IF statement are performed and the statements
accompanying the %%ELSE statement (if specified) are not performed. If the
condition is not satisfied, the statements accompanying the %%ELSE statement (if
specified) are performed and the statements accompanying the %%IF statement
are not performed.

The format of a conditional-expression is:

operand operator operand

where:

— operand – Any character string. It can contain AutoEdit terms.

— operator – One of the valid comparison operators listed below. Valid operators:
■ EQ – is equal to

■ NE – is not equal to

■ GT – is greater than

■ GE – is greater than or equal to

■ LT – is less than

■ LE – is less than or equal to

■ statements are any statements specified in the JCL member, including AutoEdit
statements, JCL statements and non-JCL statements.

If an operand contains AutoEdit terms, they are resolved into a character string
before the conditional expression is analyzed.

An operand must not resolve to a null value (as in CLISTs). If it is possible that an
operand resolves to a null value, place a character before the first and second
operands in a way that would not affect the comparison. For example, if %%A
and/or %%C in the statement:

%%IF %%A GT %%C

might resolve to null, use a substitute expression such as:

%%IF B%%A GT B%%C

Operands are compared as character strings from left to right. For example:

91 is greater than 1000 (because 9 is greater than 1).

786 Control-M for z/OS User Guide

 %%IF, %%ELSE, %%ENDIF

An %%IF expression must be terminated with an %%ENDIF statement. If an %%IF

expression is not terminated in this way, an %%ENDIF statement is implied as the
last statement in the member.

The %%ELSE statement is optional.

The AutoEdit facility performs a validity check on %%IF and %%ENDIF control
statement pairs in JCL members. If a %%IF control statement is detected, which is not
closed by %%ENDIF control statement, it will be automatically closed at end of
member and a warning message is issued.

When the %%IF expression is true, all JCL statements (including non-AutoEdit
statements) between the %%IF expression and its %%ELSE statement (or its matching
%%ENDIF statement when no %%ELSE statement is present) are submitted by
CONTROL-M provided that all AutoEdit variables are resolved.

When the %%IF expression is not true and an %%ELSE statement exists, only
statements between the %%ELSE statement and the matching %%ENDIF statement
are submitted.

Using the AutoEdit facility, several %%IF statements in one JCL member can be
combined, so that a number of jobs defined in the member can be combined into one
job, which can be submitted by CONTROL-M.

%%IF statements can be nested.

The following logically connected statements may be specified on one line:

■ %%IF
■ %%ELSE
■ %%ENDIF
■ %%GOTO
■ %%SET

Example

%%IF expression
%%IF expression
statements
.
[ %%ELSE ]
.
%%ENDIF
%%ELSE
%%IF expression
statements
.
[ %%ELSE ]
.
%%ENDIF
%%ENDIF

Chapter 5 JCL and AutoEdit Facility 787

%%INCLIB and %%INCMEM

Up to 100 nested %%IF statements can be specified.

%%INCLIB and %%INCMEM

%%INCLIB and %%INCMEM statements contain two elements that together describe
the member that is to be included in the current job stream, as follows:

■ The %%INCLIB part of the statement defines the location of the member as one of
the following:

— the library name

— the DD name to be associated with a library or concatenation of libraries

■ The %%INCMEM part of the statement defines the member.

These statements are useful for inserting the following types of information into the
JCL:

■ JCL statements and parameters to be passed to the JCL (for example, sysin)
■ AutoEdit control statements, including other %%INCLIB and %%INCMEM
statements

The format of the statement is:

%%INCLIB { libname | DDNAME=ddname } %%INCMEM memname

In this statement

■ libname is a valid data set name, from 1 through 44 characters in length, of a

cataloged partitioned data set (library) with a record length of 80

■ ddname is a valid DD name from 1 through 8 characters in length that points to a

cataloged library or concatenation of cataloged libraries
This DD name must be preallocated to the environment in which the %%INCLIB
statement is to be resolved, such as the CONTROL-M monitor or the IOA online
logon procedures.

■ memname is a valid member name from 1 through 8 characters in length

You can specify multiple %%INCLIB and %%INCMEM statements in a job.

More than one job may contain identical %%INCLIB and %%INCMEM statements,
permitting maintenance of common, standardized code.

788 Control-M for z/OS User Guide

 %%LIBSYM and %%MEMSYM

The %%INCMEM member is read by the CONTROL-M monitor just before job
submission, and the contents of the member are submitted as part of the current job.
As a result

■ a member created by one job in the job stream can be used by a later job in the job
stream

■ if a job in the job stream updates a member and the member is subsequently used
by a later job in the job stream, the later job accesses the updated member

If the %%INCLIB statement is resolved within the JCL, ensure that there are no
unnecessary blank lines in the %%INCMEM member.

If CONTROL-M fails to access the included member (member not found, and so on),
the job is not submitted and a warning message is issued.

%%LIBSYM and %%MEMSYM

Control statements %%LIBSYM and %%MEMSYM define a library and a member
that contain a set of user-defined variables and their assigned values. The member is
read by CONTROL-M before submission, and its content is added to the user-defined
variable environment of the job.

It is possible to specify more than one %%LIBSYM or %%MEMSYM statement for one
job. Each statement is added to or deleted from the user-defined variable
environment of the specific job.

If CONTROL-M fails to access the variable member (member not found, security
constraints, and so on), the job is not submitted and a warning message is issued to
the user who requested the job.

The format of the statement is:

%%LIBSYM libname %%MEMSYM [-]memname

where:

■ libname – Valid data set name of 1 through 44 characters. It must be a cataloged

partitioned data set (library) with a record length of 80.

■ memname – Valid member name of 1 through 8 characters.

When a minus sign (-) is specified before memname, the purpose of the
%%LIBSYM/%%MEMSYM statement is to cancel the effect of the previously
processed %%LIBSYM libname %%MEMSYM memname statement with the same
member name, thereby reverting the values of the AutoEdit variables that are defined

Chapter 5 JCL and AutoEdit Facility 789

%%RANGE

in the LIBSYM/MEMSYM member to the values that were in effect prior to the
previous %%LIBSYM libname %%MEMSYM memname statement. This, in effect,
provides the capability of creating local auto-edit variables, whose scope is restricted
to specified range(s) of the job run stream.

%%RANGE
A %%RANGE statement limits the handling of AutoEdit functions and variables to a
specified column range. The contents of all columns outside the range remain
unchanged.

This statement is useful when values must be specified in specific columns and when
not every AutoEdit statement need be resolved.

The format of the statement is:

%%RANGE fromcol tocol

where:

■ fromcol – First column in the range. Valid values are: 1 through 80. The default
(without a range statement) is 1.

■ tocol – Last column in the range. Valid values are: 1 through 80. tocol must be a
value equal to or greater than fromcol. The default (without a range statement)
is 72.

NOTE
When used in a CONTROL-M SETVAR job definition, the format of the %%RANGE
statement should be:

%%RANGE=fromcol,tocol

The %%RANGE statement can prevent the shifting of constants and variables that
appear after an AutoEdit variable in the same line. By limiting AutoEdit resolution to
a specified range, all constants and variables outside the specified range are kept in
their original positions regardless of the length of the resolved variables.

Each %%RANGE statement is valid until a new %%RANGE statement is specified.

Note, however, that the placement of the subsequent %%RANGE statement must be
within the column range of the preceding %%RANGE statement (or it is not
recognized as an AutoEdit statement).

790 Control-M for z/OS User Guide

 %%RESOLVE

NOTE
The minimum length of a %%RANGE statement with 2-digit fromcol and tocol values is 12
characters. Do not, therefore, specify a range of fewer than 12 columns, or you cannot use a
subsequent %%RANGE statement to expand the range back to the regular line length.

Example
This example shows how a %%RANGE statement affects the resolution of a line. In
the original JCL, the %%RANGE statement affects the second occurrence of the
AutoEdit variable, but not the first. In the submitted JCL, note the impact on the
positioning of constant CONSTANT.

The original JCL:

//* %%SET %%A_VERY_LONG_VARIABLE=XXX

%%A_VERY_LONG_VARIABLE CONSTANT
//* %%RANGE 1 25
%%A_VERY_LONG_VARIABLE CONSTANT

The submitted JCL:

//* %%SET %%A_VERY_LONG_VARIABLE=XXX

XXX CONSTANT
//* %%RANGE 1 25
XXX CONSTANT

%%RESOLVE
By default, CONTROL-M must resolve all AutoEdit terms in the JCL or the job is not
submitted. This default can be overridden by specifying an appropriate
%%RESOLVE statement in the JCL.

Valid %%RESOLVE statements are:

Table 252 %%RESOLVE Statements (part 1 of 2)

Statement Description
%%RESOLVE NO Try to resolve AutoEdit terms. If an AutoEdit term cannot be
resolved, submit the job with the AutoEdit term as is.
%%RESOLVE YES If YES, MUST or blank is specified and a subsequent AutoEdit
term cannot be resolved, the job is not submitted.
%%RESOLVE MUST

%%RESOLVE (blank)

Chapter 5 JCL and AutoEdit Facility 791

%%SET

Table 252 %%RESOLVE Statements (part 2 of 2)

Statement Description
%%RESOLVE OFF Do not try to resolve AutoEdit terms except for other
%%RESOLVE statements. Submit the job with AutoEdit terms as
is.
Each %%RESOLVE statement remains in effect until the next %%RESOLVE statement in the
JCL is encountered.
The following special case %%RESOLVE statement is relevant if %%GLOBAL AutoEdit
members are loaded to cache.
%%RESOLVE If an AutoEdit variable has not been resolved by searching the
ALLCACHE {OFF | ON} %%GLOBAL members identified in the job, the %%RESOLVE
ALLCACHE statement instructs CONTROL-M to continue the
variable resolution process by checking all members loaded into
cache. Members in cache are searched in the same sequence they
are listed in the cache list member.

A %%RESOLVE ALLCACHE statement without an ON or OFF

qualifier can only be specified as the first non-comment
statement in the cache list member used to load %%GLOBAL
members to cache. For more information, see “Loading
%%GLOBAL Members to Cache” on page 771.

A %%RESOLVE ALLCACHE statement with an ON or OFF

qualifier can be specified anywhere in the JCL of the job. It
overrides the most current %%RESOLVE ALLCACHE function,
as follows:

■ %%RESOLVE ALLCACHE ON – Activates the

%%RESOLVE ALLCACHE function.

■ %% RESOLVE ALLCACHE OFF – Deactivates the

%%RESOLVE ALLCACHE function.

NOTE
When used in a CONTROL-M SETVAR job definition, the format of the %%RESOLVE
statement should be:

%%RESOLVE=value

%%SET
A %%SET control statement sets the values of user-defined variables. The statement
may be placed in any part of the JCL stream.

The format of the statement is:

792 Control-M for z/OS User Guide

 Operators

%%SET %%varname=expression

where:

■ varname – a valid user-defined variable

■ expression – must resolve to a value according to the rules described in “Rules of
Variable Resolution” earlier in this chapter or submission of the job is canceled
(unless a %%RESOLVE NO control statement is specified). An expression can
consist of a:
— value (for example, 5)
— variable (for example, %%ODATE)
— a combination of values, variables, operators, functions, and so on (for example,
%%GENERATION_NUMBER %%PLUS 1).

Example 1

%%SET %%BACKUP_UNIT=TAPE

User-defined variable %%BACKUP_UNIT is assigned the value TAPE.

Example 2

%%SET %%BACKUP_UNIT_%%WDAY=EE%%OMONTH.%%ODAY

On Monday the 24th of September, user-defined variable %%BACKUP_UNIT_1 is

assigned the value EE0924.

Example 3

//* %%SET %%SCRATCH=%%SCRATCH %%PLUS 1

//SYSUT1 DD UNIT=TAPE,VOL=SER=EE%%SCRATCH,DISP=...

When the initial value of SCRATCH is 3017, the result in the submitted member is:

//* %%SET %%SCRATCH=3017 %%PLUS 1

//SYSUT1 DD UNIT=TAPE,VOL=SER=EE3018,DISP=...

Operators
AutoEdit operators are used to add or subtract values from AutoEdit variables in the
JCL. These operators can only be specified in a %%SET statement. Valid AutoEdit
operators are:

Chapter 5 JCL and AutoEdit Facility 793

Functions

Table 253 AutoEdit Operators

Operator Description
%%PLUS Adds a value to an AutoEdit variable.
%%MINUS Subtracts a value from an AutoEdit variable.

AutoEdit operators are generally used as follows:

%%SET variable=operand operator operand

where:

■ operand – Expression that resolves to a numeric value.

■ operator – %%PLUS or %%MINUS.

Only one operator can be specified in each %%SET statement.

Example
Increase the number of generations (%%GENERATION_NUMBER) by one:

// %%SET %%GENERATION_NUMBER=%%GENERATION_NUMBER %%PLUS 1

If the value of %%GENERATION_NUMBER was initially 1, it is set to 2.

Functions
AutoEdit functions perform operations on specified AutoEdit variables in the JCL.
These functions can only be specified in %%SET statements. The following AutoEdit
functions are supported by CONTROL-M:

%%$CALCDTE
The %%$CALCDTE function performs date manipulation by adding or subtracting a
specified number of days from a specified date.

NOTE
This function replaces the old %%CALCDATE function, which is still supported for backward
compatibility. BMC Software recommends that you use the %%$CALCDTE function rather
than the %%CALCDATE function, to take advantage of its increased versatility.

794 Control-M for z/OS User Guide

 %%$CALCDTE

The format of the %%$CALCDTE function is:

%%$CALCDTE date ± [quantity_type]quantity

where:

■ date – must be (or resolve to) a date in format yyyymmdd

■ quantity_type – optional 1-character description of the type of data specified as

quantity
Valid values are:
— D – days
— M – months
— Y – years
If no value is specified, the default value is D (days).

■ quantity – number (or numeric AutoEdit expression) of date units, depending on

the value specified for quantity_type to add to or subtract from the date
Valid values are: 1 through 999.

NOTE
In setting values for the quantity_type and quantity variables, ensure that the final date is not
later than the year 2054.

Example 1

//* %%SET %%A=%%$CALCDTE %%$ODATE -1

If the original scheduling date is February 1, 2001, %%A is assigned a value of

20010131.

Example 2

//* %%SET %%A=%%$CALCDTE %%$ODATE +M1

If the original scheduling date is January 30, 2002, %%A is assigned a value of
20020228.

Example 3

//* %%SET %%A=%%$CALCDTE %%$ODATE +Y1

If the original scheduling date is February 29, 2000, %%A is assigned a value of
20010228.

Chapter 5 JCL and AutoEdit Facility 795

%%$GREG

NOTE
If as a result of adding months to a date, the number of days exceeds the maximum number of
days possible in the resulting month, CONTROL-M reduces the number of days to the actual
maximum.

%%$GREG
The %%$GREG function converts a Julian date (with a 4-character year) to a
Gregorian date (with a 4-character year). The format of function %%$GREG is:

%%$GREG date

where date must be (or resolve to) a date in Julian format yyyyddd.

Example

//* %%SET %%A=%%$GREG 2001196

%%A is assigned a value of 20010714

%%$JULIAN
The %%$JULIAN function converts a Gregorian date (with a 4-character year) to a
Julian date (with a 4-character year). The format of the %%$JULIAN function is:

%%$JULIAN date

where date must be (or resolve to) a date in format yyyymmdd.

Example

//* %%SET %%A=%%$JULIAN 20010717

%%A is assigned a value of 2001197

796 Control-M for z/OS User Guide

 %%$LEAP

%%$LEAP
The %%$LEAP function determines whether a specified Gregorian date (with a
4-character year) falls in a leap year. If the date is in a leap year, the variable resolves
to 1. If the date is not in a leap year, the variable resolves to 0. The format of the
%%$LEAP function is:

%%$LEAP date

where date must be (or resolve to) a date in format yyyymmdd.

Leap years are years whose last two digits are evenly divisible by 4, excluding those
years that are divisible by 100 but not by 400. Therefore, 2000 is a leap year but the
years 2100, 2200 and 2300 are not.

Example

//* %%SET %%A=%%$LEAP %%$ODATE

%%A is assigned a value of 1 for dates in the year 2000 and 0 for dates in the year
2001.

%%$WCALC
The %%$WCALC function performs a shift from the specified date to a working date
in the specified calendar, according to indicated instructions. The format of the
%%$WCALC function is:

%%$WCALC date instruction calendar

where:

■ date – must be (or resolve to) a date in format yyyymmdd

■ instruction – shift instructions.

Chapter 5 JCL and AutoEdit Facility 797

%%$WEEK#

Valid values are:

— +n – Shift to the next nth working date in the calendar.

— –n – Shift to the previous nth working date in the calendar.

— > – If the specified date is not a current working date, shift to the next working
date in the calendar. (If the specified date is a working date, do not shift.)

— < – If the specified date is not a current working date, shift to the previous
working date in the calendar. (If the specified date is a working date, do not
shift.)

■ calendar – name of the calendar to check for working dates

Example

//* %%SET %%A=%%$WCALC 20000717 +1 EXCPTCAL

//* %%SET %%A=%%$WCALC 20000717 > EXCPTCAL

■ If calendar EXCPTCAL (for 2000) contains consecutive working dates 07/13 and
07/20, %%A resolves to 20000720 in both %%SET statements.

■ If calendar EXCPTCAL (for 2000) contains consecutive working dates 07/17 and
07/24:

— In the first %%SET statement (with the +1), %%A resolves to 20000724.
— In the second %%SET statement (with the >), %%A resolves to 20000717.

%%$WEEK#
The %%$WEEK# function calculates in which week of the year (1 through 53) a
specified date falls. The function uses the site-defined start of the week (Sunday or
Monday) as the first day of each week, and assumes that January 1st falls in the first
week.

This function ensures that every day of the year falls into a week of that year, but it
also means that the first week of the year may possibly have a majority of its days
come from December of the preceding year.

798 Control-M for z/OS User Guide

 %%$WEEKDAY

(By contrast, the %%$YEARWK# AutoEdit function, which also calculates in which
week of a year a date falls, counts the week that includes January 4th as the first week.
This ensures that the first week in the year has a majority of its days in January.
However, it also means that the first days of the year may possibly belong to the last
week of the preceding year, and the last days of the year may possibly belong to the
first week of the following year.)

The format of the %%$WEEK# function is:

%%$WEEK# date

where date is the date in format yyyymmdd (a 4-character year must be specified).

Example

//* %%SET %%A=%%$WEEK# 20010712

%%A is assigned a value of 28

%%$WEEKDAY
The %%$WEEKDAY function calculates on which day of the week a specified date
(with a 4-character year) falls. The resolved value is an integer from 1 through 6 or 0,
where 1 corresponds to the first day of the week (Sunday or Monday, depending on
the site-standard) and 0 corresponds to the last day of the week (Saturday or Sunday).

The format of the %%$WEEKDAY function is:

%%$WEEKDAY date

where date must be (or resolve to) a date in format yyyymmdd.

Example

//* %%SET %%A=%%$WEEKDAY 20000714

%%A is assigned a value of 6 (Friday)

Chapter 5 JCL and AutoEdit Facility 799

%%$YEARWK#

%%$YEARWK#
The %%$YEARWK# function calculates in which week of the year (1 through 53) a
specified date falls, and returns the year and the week number according to ISO8601
standards. In accordance with those standards, the function uses Monday as the first
day of each week (this is so even if the start of the week at your site is defined as
Sunday).

The %%$YEARWK# function assumes that the first week is the week that includes
January 4th

This function ensures that the first week in the year has a majority of its days in
January. However, it also means that the first days of the year may possibly belong to
the last week of the preceding year, and the last days of the year may possibly belong
to the first week of the following year.

By contrast, the %%$WEEK# AutoEdit function, which also calculates in which week
of a year a date falls, counts the week that includes January 1st as the first week. This
ensures that every day of the year is part of a week of that year. However, it also
means that the first week of the year may possibly have a majority of its days in
December of the preceding year.

The format of the %%$YEARWK# function is:

%%$YEARWK# date

where date is the date in format yyyymmdd (a 4-character year must be specified).

The value returned by the function is in the format:

yyyyWnn

where:

■ yyyy – year in which the week falls

■ nn – number of the week within the year

Example 1

//* %%SET %%A=%%$YEARWK# 20010214

%%A is assigned a value of 2001W06

Example 2

//* %%SET %%A=%%$YEARWK# 20050101

800 Control-M for z/OS User Guide

 %%CALCDATE

%%A is assigned a value of 2004W52

Example 3

//* %%SET %%A=%%$YEARWK# 20011231

%%A is assigned a value of 2002W01.

%%CALCDATE
The %%CALCDATE function performs date manipulation by adding or subtracting a
specified number of days from a specified date.

NOTE
The %%CALCDATE function is supported for backward compatibility. BMC Software
recommends that you use the %%$CALCDTE function instead.

The format of the %%CALCDATE function is:

%%CALCDATE date ± quantity

where:

■ date – must be (or resolve to) a date in format yymmdd

■ quantity – number (or numeric AutoEdit expression) of days (from 1 to 366) to add
to or subtract from the date

%%SUBSTR
The %%SUBSTR function extracts a substring from a string.

The format of the %%SUBSTR function is

%%SUBSTR string startpos length

where

■ string – string from which the substring is extracted

■ startpos – character position in the original string from which the extraction begins
■ length – number of characters to extract

Chapter 5 JCL and AutoEdit Facility 801

%%$LENGTH

A new string is created composed of the characters extracted from the original string.

startpos and length must be a numeric value or AutoEdit expression that is greater
than zero.

When the starting position of the substring is greater than the argument string, the
function returns a null value.

When the starting position of the substring falls within the argument string, but the
length of the substring falls outside the range of the argument string (startpos + length
– 1), the function returns a substring containing the characters from the starting
position.

If the character positions of startpos + length – 1 is greater than the string length,
submission of the member is stopped.

Example 1

//* %%SET %%A=%%$CALCDTE %%$ODATE -1

//* %%SET %%AMON=%%SUBSTR %%A 5 2

On July 1, 2001:

%%A is assigned a value of 20010630

%%AMON is assigned a value of 06

Example 2

%%SET %%A=%%SUBSTR CABLE 4 4

resolves to

%%A=LE

%%$LENGTH
The %%$LENGTH function returns the length of a character string.

The format of the %%$LENGTH function is

%%$LENGTH char_string

where char_string is, or resolves to, any character string.

802 Control-M for z/OS User Guide

 %%$TYPE

Example

//* %%SET %%A=%%$LENGTH A123

%%A is assigned a value of 4.

%%$TYPE
The %%$TYPE function returns the type attribute of a character string. Possible type
attributes are:

■ N – numeric
■ M – negative numeric
■ C – character
■ X – alphanumeric
■ 0 – undefined or 0 length

The format of the %%$TYPE function is

%%$TYPE char_string

where char_string is, or resolves to, any character string.

Example 1

//* %%SET %%A=%%$TYPE A123

%%A is assigned a value of X

Example 2

//* %%SET %%B=%%$TYPE XYZ

%%B is assigned a value of C

Example 3

//* %%SET %%C=%%$TYPE -1239

%%C is assigned a value of M

Chapter 5 JCL and AutoEdit Facility 803

%%$FUNC

%%$FUNC
%%$FUNC is an AutoEdit function that enables the creation of user-defined
functions. You can only use the %%$FUNC function as part of an AutoEdit %%SET
statement.

The syntax for such use of the %%$FUNC function is

%%SET output_char_string = %%$FUNC func_name input_char_string

In its operation, it is equivalent to using assembler language to issue the following

CALL instruction

CALL func_name,(input_char_string,output_char_string)

In this instruction

■ func_name is the name of the user-coded program module

■ input_char_string is a string consisting of two parts in the following order:
— the length of the source string
— the source string
■ output_char_string is a string consisting of two parts in the following order:
— the length of the result string
— the result string returned by func_name

The AutoEdit processor passes these parameters as variable-length strings. Each

string consists of a half-word binary length field followed by the string itself. The
func_name program must return the output string in the same format, as illustrated in
the example below.

The source string can contain AutoEdit variables. If it does, these variables are
resolved before the function is activated.

The maximum length of the source string, after resolving any AutoEdit variables, is
240 characters.

The maximum length of the result string is also 240 characters.

Neither the source string nor the result string can contain non-displayable characters.

You can use AutoEdit simulation to test your program module. For more
information, see “M2: Perform an AutoEdit Simulation” on page 338.

804 Control-M for z/OS User Guide

 %%$FUNC

NOTE
You can define your func_name program module as resident. A resident program module is
loaded once, kept in the storage, and entered by means of either the CALL instruction or a
LINK instruction. If you want to do this, the program module must comply with both the
following conditions:
■ It must be able to work in AMODE 31.
■ It must be reentrant.
To define program modules as resident, include them in the cache members list using the
following definition syntax:
%%$FUNC func_name

Example

The user has a multiply function that is performed by a module named MULT.

The user’s JCL contains the following AutoEdit statements:

%%SET %%A = 20
%%SET %%B = 30
%%SET %%C = %%$FUNC MULT %%A %%B

The last %%SET statement causes the CONTROL-M monitor to call the MULT
module as follows (using assembler notation):

CALL MULT,(PRM1,PRM2)

The PRM1 and PRM2 parameters are passed to MULT in the following format:

PRM1 DC H'5'
DC C'20 30'
PRM2 DC H'0'
DC CL240' '

The MULT program returns results by updating the value of the second parameter,
PRM2, as follows:

PRM2 DC H'3'
DC C'600'

The result is that the AutoEdit variable %%C is assigned a character value of 600.

Chapter 5 JCL and AutoEdit Facility 805

Testing AutoEdit Syntax

Testing AutoEdit Syntax

When CONTROL-M detects an AutoEdit syntax error in a JCL member during
submission, the submission is canceled by CONTROL-M. Therefore, it is essential to
check the syntax of AutoEdit statements while the member is being prepared.

Furthermore, when the syntax is correct, you may want to verify that the AutoEdit
statements return the desired results. For example, you may want to check that you
specified the correct AutoEdit date variables for a job that performs end-of-year
processing.

The CTMAESIM utility tests AutoEdit syntax and JCL setup. This utility simulates
the actions of the CONTROL-M submission mechanism, which performs AutoEdit
processing and JCL setup, and produces a printed report of the process.

CONTROL-M has a customized interface with the JOB/SCAN and PRO/JCL

products. However, this utility can be used with any JCL-checking product.

The CTMAESIM utility can operate in either JCL Library mode or Scheduling Library
mode:

■ In JCL Library mode, the utility checks the AutoEdit statements in the job’s JCL.
■ In Scheduling Library mode, the utility not only checks the AutoEdit statements in
the job’s JCL of the job, it also checks the impact that SET VAR statements in the job
scheduling definition have on the JCL of the job.

The utility enables system programmers to check the operation of CONTROL-M

submission exit CTMX002 without affecting production.

The CTMAESIM utility can be activated by a batch procedure or the Online facility,
as follows:

■ Batch procedure – using procedure CTMAESIM

■ Online facility – using option M2 in the Online Utilities menu or using CLIST
CTMCAES

The utility requires specification of various parameter statements that determine how
the simulation works, and which provide necessary information for the simulation.

Although the simulation works in much the same manner whether activated by a
batch procedure or online, the following differences depend on the method of
activation:

■ Batch activation allows specification of multiple sets of parameter statements.

Online activation allows specification of only one set of parameter statements.

806 Control-M for z/OS User Guide

 Testing AutoEdit Syntax

■ Batch activation allows inclusion or omission of parameter RDR=INTRDR

(described below). This parameter cannot be specified online.

■ Command JSCAN (available only at sites where JOB/SCAN or PRO/JCL is

installed) can only be specified if the utility is activated through the Online Utilities
menu. It cannot be specified if the utility is activated by batch or by CLIST
CTMCAES.

■ Character masking is not supported in the Online utility. In the batch utility,
character masking is supported for the member name in JCL Library mode, and for
the job name in Scheduling Library mode. Valid mask characters are:

■ * – Represents any number of characters (including no characters)

■ ? – Represents any one character

■ The SET VAR parameter, which can be specified outside the job scheduling
definition, is supported in batch mode only. However, SET VAR statements in the
job scheduling definition can be checked in both online and batch mode.

■ The CONTROL-M GLOBAL LIBRARY parameter is specified only in the Online

utility, and only one library can be specified. In batch mode, global libraries are
referenced by the DAGLOBAL DD statement (multiple libraries can be
concatenated).

In addition, depending on the command type specified in a parameter statement, the

resulting JCL lines can also be written to the output file referenced by the DASUBMIT
DD statement.

When the JCL is written to the output file referenced by the DASUBMIT
DD statement, the output file can be routed to an internal reader by specifying the
parameter RDR=INTRDR in the EXEC statement. In this case, the DASUBMIT
DD statement is allocated as SYSOUT=(class,INTRDR) and the job is submitted.

Submission of the job enables the JCL to be checked by the JCL checking mechanism
of MVS.

NOTE
A DASUBMIT DD statement can also be used by the AutoEdit Simulation facility to submit
jobs for execution in emergency situations (for example, the CONTROL-M monitor is
inoperative due to a severe technical problem).

When activated using ISPF, the functioning of the utility is similar to its functioning
when activated from batch with the parameter RDR=INTRDR specified.

The CTMAESIM utility, as activated from the Online facility, is described in

Chapter 2, “Online Facilities.” The CTMAESIM utility, as activated through a batch
procedure, is described in the INCONTROL for z/OS Utilities Guide.

Chapter 5 JCL and AutoEdit Facility 807

AutoEdit Usage in the Job Scheduling Definition

AutoEdit Usage in the Job Scheduling

Definition
Certain AutoEdit components can be used in job scheduling definitions. In job
scheduling definitions, AutoEdit components in certain statements (SET VAR and
DO SET) directly affect JCL. In other statements (SYSOUT and DO SYSOUT, SHOUT
and DO SHOUT, MEMLIB and OVERLIB) they do not affect the JCL.

WARNING
When using AutoEdit variables in job scheduling definitions, always test the definitions for
proper AutoEdit syntax with the AutoEdit simulation utility. For more information, see
“Testing AutoEdit Syntax” on page 806.

In the job scheduling definition, AutoEdit components can be specified in the

following parameters:

■ SET VAR and DO SET statements

These two job scheduling definition statements and the %%SET control statements
are used to assign values to user-defined variables in the JCL.

Example

In this example, AutoEdit statements in the job scheduling definition and the JCL
allocate space for the job. If the job abends due to insufficient space, the AutoEdit
statements adjust the allocated space and rerun or restart the job.

The following step in the job’s JCL sets the quantity of available space to five units
of whatever type (track or cylinder) is specified in the job scheduling definition.

//STEP10 EXEC PGM=MYPGM

//OUTFILE DD DSN=NEWFILE,DISP=(NEW,CATLG,DELETE),
// SPACE=(%%SPACE_TYPE,5),UNIT=SYSDA

The job scheduling definition contains the following SET VAR statement that sets
the space type to “track”:

SET VAR %%SPACE_TYPE=TRK

In this case, the second line in the above DD statement resolves to:

// SPACE=(TRK,5),UNIT=SYSDA

808 Control-M for z/OS User Guide

 AutoEdit Usage in the Job Scheduling Definition

The job scheduling definition also contains the following statements that are
activated if the job abends due of lack of space (code S*37). These statements
change the space type to “cylinder”, which provides enough space, and rerun the
job. If CONTROL-M/Restart is active, the job is restarted from the abended step.

ON STEP STEP10 CODES S*37

DO SET %%SPACE_TYPE=CYL
[DO IFRERUN FROM $ABEND] ===> If CONTROL-M/Restart is active
DO RERUN

If the job abends as above, the second line of the earlier JCL DD statement resolves
to:

// SPACE=(CYL,5),UNIT=SYSDA

when the job is submitted for rerun (or restart).

■ SYSOUT and DO SYSOUT

File names for SYSOUT and DO SYSOUT handling can be specified using
AutoEdit variables whenever SYSOUT option F (copy to file or sysout archiving) is
specified. For example:

SYSOUT OP F PRM GPL.%%JOBNAME.D%%ODATE.%%JOBID.T%%TIME

■ SHOUT, DO SHOUT, and DO MAIL

System AutoEdit variables can be used in shouted messages. For example:

MSG JCL ERROR IN JOB %%JOBID %%STEP

■ MEMLIB and OVERLIB

System AutoEdit variables and variables defined in SET VAR parameters can be
used in the MEMLIB and OVERLIB fields to specify the appropriate library.
Examples of this usage are shown on the following pages.

■ IN, OUT, and DO COND

You can use an AutoEdit variable in a condition name, provided that the AutoEdit
variable has a value that is known before the job is ordered.

Chapter 5 JCL and AutoEdit Facility 809

Examples

Examples

Date Variables
Table 254 Date Variables
Original Scheduling Current Working Computer Format
%%ODATE %%RDATE %%DATE yymmdd
%%ODAY %%RDAY %%DAY dd
%%OMONTH %%RMONTH %%MONTH mm
%%OYEAR %%RYEAR %%YEAR yy
%%OWDAY %%RWDAY %%WDAY n (0-6)
%%OJULDAY %%RJULDAY %%JULDAY jjj

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//STEP01 EXEC PDUPDATE
//SYSIN DD *
%%DATE
//

The JCL submitted on June 6, 2001:

//PDPA0001 JOB (......),BILL,CLASS=A

//STEP01 EXEC PDUPDATE
//SYSIN DD *
010606
//

ODATE, RDATE and DATE Usage

//PDPA0001 JOB (......),BILL,CLASS=A
//STEP01 EXEC PDUPDATE
//SYSIN DD *
010606
//

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

....
//STEP02 EXEC PDPRINT,BUSDATE=%%ODATE
//SYSIN DD *

810 Control-M for z/OS User Guide

 How to Obtain Date Formats – 1

EXAMPLE-RDATE=%%RDATE
EXAMPLE-DATE=%%DATE
//

On July 24th, we need to run the 22nd, 23rd, and 24th (of the same job) because of
delays. On the Active Jobs file we can find three job orders:

PDPA0001 of 010722
PDPA0001 of 010723
PDPA0001 of 010724

The job of the 22nd is submitted on July 24th at 2300. The result is:

//PDPA0001 JOB (......),BILL,CLASS=A

....
//STEP02 EXEC PDPRINT,BUSDATE=010722
//SYSIN DD *
EXAMPLE-RDATE=010724
EXAMPLE-DATE=010724
//

The job of the 23rd is submitted on July 25th at 0025. The result is:

//PDPA0001 JOB (......),BILL,CLASS=A

....
//STEP02 EXEC PDPRINT,BUSDATE=000723
//SYSIN DD *
EXAMPLE-RDATE=010724
EXAMPLE-DATE=010725
//

The job of the 24th is submitted on July 25th, 2001 at 0300. The result is:

//PDPA0001 JOB (......),BILL,CLASS=A

....
//STEP02 EXEC PDPRINT,BUSDATE=000724
//SYSIN DD *
EXAMPLE-RDATE=010724
EXAMPLE-DATE=010725
//

How to Obtain Date Formats – 1

Format ddmmyy:

%%ODAY.%%OMONTH.%%OYEAR

Let’s follow the variable substitution by stages for June 24, 2001:

%%ODAY.%%OMONTH.01
%%ODAY.06.01

Chapter 5 JCL and AutoEdit Facility 811

How to Obtain Date Formats – 2

%%ODAY.0601
24.0601
240601

Remember Variable substitution is performed from right to left.

A period (.) between two AutoEdit variables is omitted.

How to Obtain Date Formats – 2

Format dd mmm yy (where mmm is the month in character format):

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%GLOBAL CHARMON
//STEP02 EXEC PDPRT3
//SYSIN DD *
%%ODAY %%MONTH_IN_CHAR_%%OMONTH %%OYEAR
//

The CHARMON member (in the CONTROL-M Global library) contains:

*
* MONTHS IN CHAR FORMAT
*
%%MONTH_IN_CHAR_01=JAN
%%MONTH_IN_CHAR_02=FEB
%%MONTH_IN_CHAR_03=MAR
.
.
%%MONTH_IN_CHAR_12=DEC

The symbols substitution by stages:

%%ODAY %%MONTH_IN_CHAR_%%OMONTH 00
%%ODAY %%MONTH_IN_CHAR_06 00
%%ODAY JUN 00
24 JUN 00

The submitted member:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%GLOBAL CHARMON
//STEP02 EXEC PDPRT3
//SYSIN DD *
24 JUN 00
//

812 Control-M for z/OS User Guide

 How to Obtain Date Formats – 3

How to Obtain Date Formats – 3

Format ddmmmyy (where mmm is the month in character format):

According to the preceding example, we might try the following original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%GLOBAL CHARMON
//STEP02 EXEC PDPRT3
//SYSIN DD *
%%ODAY.%%MONTH_IN_CHAR_%%OMONTH.%%OYEAR
//

Variable substitution by stages would proceed as follows:

%%ODAY %%MONTH_IN_CHAR_%%OMONTH.00
%%ODAY %%MONTH_IN_CHAR_06.00
%%ODAY %%MONTH_IN_CHAR_0600

However, this results in the following error: Symbol %%MONTH_IN_CHAR_0600 is

not resolved.

This error would not have occurred had we tried the following original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%GLOBAL CHARMON
//* %%SET %%A=%%MONTH_IN_CHAR_%%OMONTH
//STEP02 EXEC PDPRT3
//SYSIN DD *
%%ODAY.%%A.%%OYEAR
//

How to Obtain the Previous Month’s Last Business Date

//PDPA0001 JOB (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM LBUSMON
//STEP02 EXEC PDPRT3
//SYSIN DD *
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_%%OMONTH.%%OYEAR
//

Chapter 5 JCL and AutoEdit Facility 813

Automatic Job Order for the Next Day

The LBUSMON member in the CTM.LIB.SYMBOLS library contains:

*
* LAST BUSINESS DATE IN THE PREVIOUS MONTH
*
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_0101=001231
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_0201=010131
.
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_0601=010531
.
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_1201=011130
.
.

Variable substitution by stages (during June 2001):

%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_%%OMONTH.01
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_06.01
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_0601
010531

NOTE
An alternate method, which avoids the need to use the MEMSYM member, requires the use of
the %%$WCALC function with the standard working day calendar. For details, see
“%%$WCALC” on page 797.

Automatic Job Order for the Next Day

In many data centers it is necessary to run certain jobs “ahead of time” on a regular
basis (such as run today with the business date of tomorrow). The %%$CALCDTE
and %%SUBSTR functions can be used to permit automatic scheduling of such jobs
on a daily basis by the CONTROL-M monitor. (The output is in mmddyy format.)

//TOMDAILY JOB (....),BILL,CLASS=A

//* %%SET %%A=%%$CALCDTE %%$ODATE +1
//* %%SET %%DD=%%SUBSTR %%A 7 2
//* %%SET %%MM=%%SUBSTR %%A 5 2
//* %%SET %%YY=%%SUBSTR %%A 3 2
//STEP01 EXEC PGM=IKJEFT01,REGION=1000K,DYNAMNBR=30
//SYSPROC DD DISP=SHR,DSN=CONTROL-M-CLIST-LIBRARY
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
CTMCJOBS SCHEDLIB(CTM.LIB.SCHEDULE) TABLE(SDP00) -
ODAT(%%MM.%%DD.%%YY)
//

The %%$CALCDTE and %%SUBSTR AutoEdit functions can be used for any date
calculation that is needed in a production environment.

814 Control-M for z/OS User Guide

 Tape Clearance System – Stage 1

If you want to use the WAIT FOR ODATE option, which is described in “WAIT FOR
ODATE” on page 158, you can use the WAITODAT(YES) parameter.

For example

CTMCJOBS SCHEDLIB(CTM.LIB.SCHEDULE) TABLE(SDP00) -

ODAT(%%M.%%D.%%Y) WAITODAT(YES)

causes the job to wait for a specific date before being processed.

Tape Clearance System – Stage 1

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM TAPES
//STEP02 EXEC PDINP3
//S001.INPUT DD VOL=SER=%%FEDERAL_BANK_TAPE
//

The member TAPES in the CTM.LIB.SYMBOLS library contains:

*
* EXTERNAL TAPES LIST
*
%%FEDERAL_BANK_TAPE=045673
%%IRS_TAPE=XXXXX
%%STOCK_EXCHANGE_TAPE=YYYYYY
.
.

The submitted JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM TAPES
//STEP02 EXEC PDINP3
//S001.INPUT DD VOL=SER=045673
//

The use of a central member for all external tapes is a very simple management tool.
The minute a tape arrives, its number is typed in the member, and the tape is sent to
the computer room. There is no need to keep the tapes “at hand” on the schedulers’
table until the job is submitted. The function of receiving tapes can be centralized,
controlled, and independent of the production process.

Chapter 5 JCL and AutoEdit Facility 815

Tape Clearance System – Stage 2

Tape Clearance System – Stage 2

The example provided on the previous page has one basic weakness. It cannot handle
delays. If a certain job does not run one day, and on the next day it must be run twice
(once for each execution day), there is a danger of overriding the tape number in the
control member. To solve this problem, let’s improve our tape clearance system.

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM TAPE%%OMONTH.%%ODAY
//STEP02 EXEC PDINP3
//S001.INPUT DD VOL=SER=%%FEDERAL_BANK_TAPE
//

The TAPE0714 member in the CTM.LIB.SYMBOLS library contains:

:
*
* EXTERNAL TAPES LIST
*
%%FEDERAL_BANK_TAPE=045673
%%IRS_TAPE=XXXXX
%%STOCK_EXCHANGE_TAPE=YYYYYY
.
.

There are other advantages:

■ The ability to roll back several dates without losing the dynamic parameters.
■ Complete documentation of a tape’s usage.

Use a CONTROL-M job to automatically create a member, TAPEmmdd, for each

scheduling date, based on a master copy. For example:

// EXEC PGM=IEBCOPY
.
//SYSIN DD *
C I=IN, O=OUT
S M=((TAPES,TAPE%%OMONTH.%%ODAY))

Tape Management System

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%LIBSYM CTM.LIB.TAPES %%MEMSYM PDTAPES
//STEP02 EXEC PDBKP3
//S001.OUTPUT DD VOL=SER=%%PDTAPE_0001_%%OWDAY
//

816 Control-M for z/OS User Guide

 Dynamic Job Name

The PDTAPES member in the CTM.LIB.TAPES library contains:

*
* TAPES OF DP APPLICATION
*
%%PDTAPE_0001_1=045673
%%PDTAPE_0001_2=045683
%%PDTAPE_0001_3=045677
%%PDTAPE_0001_4=043433
%%PDTAPE_0001_5=045543
%%PDTAPE_0001_6=045556
%%PDTAPE_0001_7=045666
*
%%PDTAPE_0010_1=046600

We have created a cycle of seven tapes to be used by this application.

Dynamic Job Name

The required format:

//PDPAddxx JOB (......),BILL,CLASS=A

where dd is the business day of the month, and xx varies according to the job in the
application.

The solution:

//PDPA%%ODAY%%.xx JOB (......),BILL,CLASS=A

Controlling the Target Computer by Class

CONTROL-M can dynamically decide to which computer to send a job. The
following examples demonstrate the relation between CONTROL-M resource
acquisition parameters and local JCL standards implementation.

NOTE
This example assumes that a $ generic resource was specified in the job scheduling definition.
For more information, see “Resource Allocation in Multi-CPU Environments” on page 607

//* %%GLOBAL CLASSES

//PDPA0001JOB(.....),BILL,CLASS=%%FAST_CLASS_OF_%%$SIGN

Chapter 5 JCL and AutoEdit Facility 817

Controlling the Target Computer by System Affinity

The CLASSES member in the CONTROL-M Global library contains:

*
* DEFINITIONS OF CLASSES IN THE COMPUTERS
*
%%FAST_CLASS_OF_1=A
%%FAST_CLASS_OF_2=D
%%FAST_CLASS_OF_3=K
%%SLOW_CLASS_OF_1=W
.
.

Controlling the Target Computer by System Affinity

NOTE
This example assumes that a $ generic resource was specified in the job scheduling definition.
For more information, see “Resource Allocation in Multi-CPU Environments” on page 607

//* %%GLOBAL SYSAFF

//PDPA0001 JOB (......),BILL,CLASS=A
/*J SYSAFF=%%NAME_OF_COMPUTER_%%$SIGN

The SYSAFF member in the CONTROL-M Global library contains:

*
* NAMES OF THE COMPUTERS
*
%%NAME_OF_COMPUTER_1=SYSA
%%NAME_OF_COMPUTER_2=SYSB
%%NAME_OF_COMPUTER_3=TEST

The submitted JCL (for CPU ID 2):

//* %%GLOBAL SYSAFF

//PDPA0001 JOB (......),BILL,CLASS=A
/*J SYSAFF=SYSB

%%BLANKn Statement
A program expects to receive the day of the week and the time of day as structured
input:

■ Day of the week in column 1

■ Time of day in column 11

818 Control-M for z/OS User Guide

 %%RANGE Statement

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM DAYTIME
....
//STEP02 EXEC PDPRT3
//SYSIN DD *
%%H%%OWDAY%%.%%TIME
//

The DAYTIME member in the CTM.LIB.SYMBOLS library contains the following

AutoEdit user symbols:

%%H1=SUNDAY%%BLANK4
%%H2=MONDAY%%BLANK4
%%H3=TUESDAY%%BLANK3
%%H4=WEDNESDAY%%BLANK1
%%H5=THURSDAY%%BLANK2
%%H6=FRIDAY%%BLANK4
%%H0=SATURDAY%%BLANK2
Variable substitution by stages:
%%H%%OWDAY%%.%%TIME
%%H%%OWDAY.085300
%%H1.085300
SUNDAY 085300
The submitted JCL:
//PDPA0001 JOB (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM DAYTIME
....
//STEP02 EXEC PDPRT3
//SYSIN DD *
SUNDAY 085300
//

%%RANGE Statement
The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM LBUSMON
//STEP02 EXEC PDPRT3
//* + + + +
//SYSIN DD *
%%LAST_BUSINESS_DATE_IN_%%OMONTH REPORT1
//

The constant REPORT must be in column 40.

Chapter 5 JCL and AutoEdit Facility 819

SYSIN Parameter Containing %%

The submitted JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM LBUSMON
//STEP02 EXEC PDPRT3
//* + + + +
//SYSIN DD *
030400 REPORT1
//

The correct solution:

//PDPA0001 JOB (......),BILL,CLASS=A

//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM LBUSMON
//STEP02 EXEC PDPRT3
//* + + + +
//* %%RANGE 1 39
//SYSIN DD *
%%LAST_BUSINESS_DATE_IN_%%OMONTH REPORT1
//

SYSIN Parameter Containing %%

Disabling AutoEdit Resolution

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//STEP02 EXEC PDPRT3
//SYSIN DD *
%%VAR Do not resolve the AutoEdit variable on this line.
// EXEC ... PARM='%%ODATE'
//

The solution:

//PDPA0001 JOB (......),BILL,CLASS=A

//STEP02 EXEC PDPRT3
//SYSIN DD *
%%RESOLVE OFF
%%VAR Do not resolve the AutoEdit variable on this line.
%%RESOLVE YES
// EXEC ... PARM='%%ODATE'
//

If %%RESOLVE=NO is specified, the line is submitted as is.

820 Control-M for z/OS User Guide

 %%INCLIB and %%INCMEM Statements

%%INCLIB and %%INCMEM Statements

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//STEP01 EXEC PDPRPT1
....
//* %%INCLIB CTM.LIB.COMJCL %%INCMEM PDPRPT2
//

The PDPRPT2 member in the CTM.LIB.COMJCL library contains:

//STEP02 EXEC PDPRPT2

//SYSIN DD *
%%DATE

The submitted JCL (on June 6, 2001):

//PDPA0001 JOB (......),BILL,CLASS=A

//STEP01 EXEC PDPRPT1
....
//* %%INCLIB CTM.LIB.COMJCL %%INCMEM PDPRPT2
//STEP02 EXEC PDPRPT2
//SYSIN DD *
010606
//

Boolean “IF” Logic

Example 1
This example illustrates CONTROL-M’s ability to perform Boolean “IF” logic.

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//*
//* %%IF %%TIME LT 120000
//* %%SET %%PGMA=MORNPGM
//* %%ELSE
//* %%SET %%PGMA=AFTPGM
//* %%ENDIF
//*
//STEP01 EXEC PGM=%%PGMA
...
//

Chapter 5 JCL and AutoEdit Facility 821

Boolean “IF” Logic

The submitted JCL at 1:00 p.m:

//PDPA0001 JOB (......),BILL,CLASS=A

//
//* %%IF %%TIME LT 120000
//* %%ELSE
//* %%SET %%PGMA=AFTPGM
//* %%ENDIF
//
//STEP01 EXEC PGM=AFTPGM
...
//

The %%IF expression is not true since it is past 12:00 noon; therefore, the statements
following %%ELSE are executed. The program executed in STEP01 is AFTPGM.

Example 2
This example illustrates the use of CONTROL-M’s conditional logic in conjunction
with CONTROL-M “INCLUDE” and “GO TO” logic.

//PDPA0001 JOB (......),BILL,CLASS=A

//*
//* %%IF %%WDAY NE 1
//* %%GOTO RUN_DAILY
//* %%ELSE
//* %%INCLIB CTM.LIB.COMJCL %%INCMEM MONTHLY
//* %%ENDIF
//*
//* %%LABEL RUN_DAILY
//STEPDAI EXEC PGM=DAILY
...
//

The MONTHLY member in the CTM.LIB.COMJCL library contains:

//STEPMON EXEC PGM=MONTHLY

...

On the first day of the month both the DAILY and MONTHLY programs run. The
submitted JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//*
//* %%IF 1 NE 1
//* %%ELSE
//* %%INCLIB CTM.LIB.COMJCL %%INCMEM MONTHLY
//STEPMON EXEC PGM=MONTHLY
...
//* %%ENDIF
//*
//* %%LABEL RUN_DAILY
//STEPDAI EXEC PGM=DAILY
...
//

822 Control-M for z/OS User Guide

 Boolean “IF” Logic

On any other day of the month, only the DAILY program runs. The submitted JCL:

//PDPA0001 JOB (......),BILL,CLASS=A

//*
//* %%IF 2 NE 1
//* %% GOTO RUN_DAILY
//* %%ELSE
//* %%ENDIF
//*
//* %%LABEL RUN_DAILY
//STEPDAI EXEC PGM=DAILY
...
//

Chapter 5 JCL and AutoEdit Facility 823

Boolean “IF” Logic

824 Control-M for z/OS User Guide

 Chapter

6
6 Selected Implementation Issues
This chapter includes the following topics:

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Job Ordering Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Job Ordering Through Quick Submit Command CTMQSB . . . . . . . . . . . . . . . . . 827
Special Purpose Job Ordering From Special Environments: CTMAJO . . . . . . . . 829
Manual Conditions File and Maybe Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Loading the Manual Conditions File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Using the Manual Conditions File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Handling Manual Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Handling Unscheduled Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Handling Maybe Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Maybe Jobs in SMART Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
MAINVIEW Batch Optimizer Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Job-Related Considerations for Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Enhanced Runtime Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
System-Related Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Parameter Prompting Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Parameter Prompting Facility – Type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Parameter Prompting Facility—Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
Maintenance Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852

Chapter 6 Selected Implementation Issues 825

Overview

Overview
This chapter provides you with concepts and hints for successful implementation of
CONTROL-M. It also provides a detailed description of the procedures required for
implementation of CONTROL-M by the user and operator. The following
implementation concepts and instructions are discussed in this chapter:

■ alternative methods of job ordering

■ Manual Conditions list and Maybe jobs
■ MAINVIEW Batch Optimizer (MVBO) considerations
■ parameter prompting facilities

For information about the INCONTROL administrator's implementation of

CONTROL-M, see the INCONTROL for z/OS Administrator Guide.

NOTE
Topics in this chapter require familiarity with background information presented in
Chapter 1, “Introduction to Control-M,” and familiarity with relevant information presented
in other chapters.

Job Ordering Methods

Under CONTROL-M, job ordering is normally performed automatically by the New
Day procedure and User Daily jobs during New Day processing, as described in
detail in the INCONTROL for z/OS Administrator Guide.

However, at times it is desirable to perform job ordering using methods other than
the New Day procedure and User Daily jobs. For example, it may be necessary to
schedule special purpose jobs, or to order jobs for a different working date.

CONTROL-M provides several alternative methods of job ordering. Some methods of

job ordering are performed online; others in batch. Some are performed
automatically, while others are performed manually.

Below is a list of facilities and functions that enable jobs to be ordered without the
New Day procedure and User Daily jobs.

826 Control-M for z/OS User Guide

 Job Ordering Through Quick Submit Command CTMQSB

Table 255 Alternative Job Ordering Methods

Method Description
Table/Job List screen Enables jobs to be ordered from Online facility screens. For more
information, see “Ordering (Scheduling) Jobs” on page 155
Job Order panel Allows job ordering through the online utility (or CLIST)
CTMJOBRQ. For more information, see “M1: Issue a Job Order” on
page 336
End User Job Order Allows job ordering through the online utility (or CLIST)
interface CTMJBINT. For more information, see “M6: End-User Job Order
Interface” on page 376
Utility CTMJOB Described in the INCONTROL for z/OS Utilities Guide.
Utility CTMBLT Described in the INCONTROL for z/OS Utilities Guide.
TSO CLIST Allows job ordering directly from the TSO environment. For more
information, see the description of the CTMJOB utility in the
CONTROL M chapter in the INCONTROL for z/OS Utilities Guide,
which includes an example of such job ordering.
Quick submit Allows job ordering through CONTROL-M submit command
command CTMQSB CTMQSB (instead the ISPF submit command). For more
information, see “Job Ordering Through Quick Submit Command
CTMQSB” on page 827.
Job ordering from Facilitates job ordering from other environments (CICS, ROSCOE,
special environments and so on). For more information, see “Special Purpose Job Ordering
From Special Environments: CTMAJO” on page 829.

Job Ordering Through Quick Submit Command CTMQSB

In many instances, the contents of the job are determined by an end user before
submission. For example, a user may maintain a member that contains the JCL and
parameters of a certain report. When someone requests the report, the user edits the
member, possibly using ISPF, changes the parameters of the report, and uses the ISPF
SUBMIT command to submit the job.

As described in the previous paragraphs, CONTROL-M can detect such jobs when
they appear on spool, and control their execution. However, there are a few
disadvantages to this method. The primary disadvantage is in handling job abends.
When an On Spool job abends, it is not clear which JCL member must be submitted to
perform a rerun. For example, in the above example, if the JCL has not been saved,
such as where the user exited ISPF EDIT using the CANCEL command, there is no
original member from which to perform the rerun.

This problem can be overcome using CONTROL-M command CTMQSB. When

submitting a job, use command CTMQSB instead of the regular ISPF SUBMIT
command. Just type it in the command line and press Enter. You may have to prefix it
by the % character to designate a CLIST.

Chapter 6 Selected Implementation Issues 827

Job Ordering Through Quick Submit Command CTMQSB

It is possible to replace the ISPF SUBMIT command with the CONTROL-M CTMQSB
command. For more information, see the description of installing ISPF support in the
CONTROL-M Installation Procedure in the INCONTROL for z/OS Installation Guide.

If the member contains JCL cards that start with //*CONTROLM then special
processing takes place, that is, the member is not submitted. The CONTROL-M
submit command looks for two //*CONTROLM cards with the following format
(order and position in the job are not important):

//*CONTROLM TABLE scheduling-tables-library table-name

//*CONTROLM JCL JCL-library

The current JCL member is written to the specified JCL library. The name of the
member is composed of the first three letters of the TSO user ID, and the
CONTROL-M order ID (5 characters). This method ensures that the name is unique.

The table is read from the specified library. The submit command assumes that the
table contains only one job scheduling definition. If the table contains definitions for
more than one job, only the first job scheduling definition is taken into account; the
remainder are ignored. The CTMQSB CONTROL-M command replaces the original
library and member names with the names of the JCL library and member where the
job has been stored, as described in the preceding section. If the WM1822 optional
wish is applied, the user ID (OWNER) of the job is replaced by the TSO user ID. The
WM1822 optional wish is in the IOADFLT member in the IOA IOAENV library.

To avoid accumulation of old members, it is advisable that a new, empty JCL library
be used each day.

CONTROL-M job order security exit CTMX001 is invoked (as under CTMJOBRQ). If
the job order is valid, it is placed on the CONTROL-M Active Jobs file. The job is then
submitted based on the regular job scheduling criteria, such as IN, CONTROL, TIME.

Tables that are referred to by //*CONTROLM statements must not be included in a

batch User Daily or in New Day processing. They must contain a skeleton of a job
order, such as reports that require IMS to be up, reports that use substantial IDMS
resources, update to certain VSAM files, and so on.

It is possible to force the use of the CONTROL-M submit facility. When the
CONTROL-M CTMQSB command is activated, the contents of the member to be
submitted are passed to CONTROL-M User Exit CTMX010. This exit can
automatically add //*CONTROLM cards to the submitted member. Use of this
technique results in a completely scheduled environment. All submitted jobs are
under CONTROL-M control.

828 Control-M for z/OS User Guide

 Special Purpose Job Ordering From Special Environments: CTMAJO

NOTE
Each member processed using the command CTMQSB must contain only one job. If one of
these members contains more than one job, all the jobs are submitted; however, a message is
produced for only the last job. If the job is ordered, CONTROL-M submits all the jobs in the
member, but controls only the first job.

CONTROL-D users: The D-CAT field of the table is ignored for jobs that are scheduled using
the CONTROL-M CTMQSB command. This means that a report decollating mission is not
automatically ordered for jobs that are scheduled by the CTMQSB command.

If CTMQSB is being used to order jobs and not simply for quick submission, then the AJF
must be allocated (via DDname DACKPT) in the TSO environment or from within the
CTMSETSB Clist. For more information, see the section about installing ISPF support in the
INCONTROL for z/OS Installation Guide.

Special Purpose Job Ordering From Special Environments:

CTMAJO
This section describes a special program, CTMAJO, that is supplied with
CONTROL-M. CTMAJO was designed to handle a situation that sometimes arises,
when the user needs to order special jobs from any of various environments, such as
CICS or ROSCOE.

WARNING
CTMAJO will not be supported in future versions of CONTROL-M. BMC recommends that
you already use the CTMBLT utility (which provides improved functionality) instead of
CTMAJO. You use the CTMBLT utility to dynamically build job scheduling definitions and to
order individual jobs when required. For more information, see the INCONTROL for z/OS
Utilities Guide.

Since program CTMAJO is not environment-dependent, the INCONTROL

administrator must develop an application that enables the program to be used with
the particular environment. One such application, CTMQSB, is supplied with
CONTROL-M. CTMQSB is for use with CTMAJO under ISPF, and is described in
“Job Ordering Through Quick Submit Command CTMQSB” on page 827.

The CTMAJO program accepts the following parameters:

■ the JCL of the job, which is already loaded into memory

■ the name of a special purpose JCL library in which to place the JCL
■ the name of a scheduling library
■ the name of a table (in the above library) containing a single, skeletal, job
scheduling definition
■ the requested scheduling date

Chapter 6 Selected Implementation Issues 829

Special Purpose Job Ordering From Special Environments: CTMAJO

To handle the special purpose request, CTMAJO performs the following:

■ takes the JCL of the job to be submitted from memory and writes it to the specified
single purpose JCL library, using a unique member name

■ takes the skeletal job scheduling definition from the table in the scheduling library,
and loads the job scheduling definition to the Active Jobs file

When placing the job order in the job scheduling definition, CONTROL-M overwrites
the MEMNAME value from the skeleton with the name of the special purpose JCL
member. It also specifies the requested scheduling date.

The job then comes under the control of the CONTROL-M monitor:

■ If runtime scheduling criteria are specified in the skeletal job scheduling definition,
the job is not submitted until those criteria are satisfied.

■ If post-processing parameters are specified, they are performed upon completion

of the job.

Using CTMAJO to order special purpose jobs under special environments is

preferable to bringing jobs under CONTROL-M control as On Spool jobs because
when CTMAJO is used, the JCL is available, if necessary, for job rerun. With On Spool
jobs, the JCL member may not be known.

For a sample call to the CTMAJO utility, see the ROSORDER member in the IOA
SAMPLE library.

830 Control-M for z/OS User Guide

 Manual Conditions File and Maybe Jobs

Manual Conditions File and Maybe Jobs

The Manual Conditions file contains a list of prerequisite conditions that are required
by jobs in the Active Jobs file but which are not available, that is, added to the IOA
Conditions file, unless there is some form of user intervention.

Loading the Manual Conditions File

Conditions are added to the Manual Conditions file through the IOALDNRS utility.
This utility is run during New Day processing, but it must also be run following the
addition of a set of jobs in the Active Jobs file.

The IOALDNRS utility checks the IN conditions required by scheduled jobs against
the conditions available in the IOA Conditions file and against the OUT conditions
that can be set by the scheduled jobs.

All IN conditions that are not in the IOA Conditions file and that are not listed as
OUT conditions in a scheduled job are added to the Manual Conditions file.

Using the Manual Conditions File

The Manual Conditions file provides the user with a list of conditions for which
manual intervention is required if the conditions are to be added to the IOA
Conditions file.

To utilize this list effectively, the user must distinguish between two types of
conditions in the list because each requires a different type of intervention. From the
user perspective, the two types of conditions are:

■ Manual Conditions

Conditions that always require manual intervention and are therefore never
automatically added by jobs as OUT or DO COND conditions.

Example

Job-X, which requires that a tape has arrived before the job is submitted, contains
IN prerequisite condition TAPE-ARRIVED.

This condition must not be automatically added to the IOA Conditions file by a
job, but must instead be manually added by the operator only after the tape has
arrived.

Chapter 6 Selected Implementation Issues 831

Handling Manual Conditions

■ Unscheduled Conditions

Conditions that can be added automatically by a job, but which appear in the
Manual Conditions list because none of the jobs scheduled that day set the
condition.

Example

Job-B requires IN condition JOB-A-ENDED-OK. This condition is added as an

OUT condition by Job-A. Job-B is scheduled on a day during which Job-A is not
scheduled.

The distinction between the two types of conditions mentioned above is important
because each type requires a different user response, as described below.

Handling Manual Conditions

The handling of Manual Conditions, as defined above, is fairly straightforward. In the
above example, the user clearly does not want the condition added automatically, nor
does the user want the condition ignored. Simply put, Job-X must not be run unless
the required tape has arrived at the site, in which case the operator adds the
condition. For this type of condition, the only desired manual intervention is the
adding of the condition at the appropriate time. This can be performed by option A
(Add) in the Manual Conditions screen.

Handling Unscheduled Conditions

The handling of Unscheduled Conditions, as defined above, is more complex because
it concerns the issue of normal dependency versus “Maybe” dependency:

■ Normal Dependency

A successor job is always dependent on the predecessor job, regardless of whether

the predecessor job is scheduled.

With this type of dependency, using the example cited above, successor Job-B must
not be submitted because predecessor Job-A was not scheduled and executed.

In this case, the dependency must not be ignored. The unscheduled prerequisite
condition is not added manually.

832 Control-M for z/OS User Guide

 Handling Maybe Dependencies

■ “Maybe” Dependency

A successor job is dependent on the predecessor job only if the predecessor job is
scheduled that day. If the predecessor job is not scheduled that day, the successor
job can still be submitted, provided that other runtime scheduling criteria are
satisfied.

In this case, the predecessor job is referred to as a Maybe job.

With this type of dependency, using the example cited above, successor job Job-B
must be submitted, provided all other runtime scheduling criteria are satisfied,
because predecessor job Job-A was not scheduled.

In this case, the dependency must be ignored or bypassed. Methods for ignoring
Maybe dependencies are described below.

Handling Maybe Dependencies

The most common method of handling Maybe job dependencies is to add the
unscheduled conditions of Maybe jobs to the IOA Conditions file.

However, examining each condition in the Manual Conditions list to determine if it is

an unscheduled condition from a Maybe job, and manually adding each Maybe job
unscheduled condition, is a difficult process. The process can be greatly simplified
and automated, by following these steps:

1. Define a Unique Prefix for Maybe Job Prerequisite Conditions

When Maybe dependencies are defined, the prerequisite IN, OUT and DO COND
conditions must all have the same unique prefix (that is, a prefix that is not used
for other prerequisite conditions).

Using a unique prefix symbol makes it easier to see unscheduled conditions of

Maybe Jobs in the Manual Conditions list.

Normally, this prefix is either symbol # or @.

NOTE
If your site utilizes MVS restarts and uses symbol @ in OUT conditions for the restart, this
symbol must not be used as a prefix for Maybe job conditions. In this case, use the # symbol
for Maybe conditions. For details, see Appendix E, “MVS Job Restart Without
CONTROL-M/Restart.”

Chapter 6 Selected Implementation Issues 833

Maybe Jobs in SMART Tables

2. Use the ADDMNCND KeyStroke Language utility to add the prerequisite

conditions. The ADDMNCND KSL utility automatically adds all conditions with a
specified prefix in the Manual Conditions file to the IOA Conditions file.

By specifying the above-defined unique prefix symbol in the utility, unscheduled

conditions from Maybe jobs are automatically added, making manual adding of
the conditions unnecessary.

After the above two steps have been implemented, the only manual intervention
required for unscheduled conditions of Maybe jobs is the executing of the
ADDMNCND KSL utility.

Maybe Jobs in SMART Tables

The above implementation for handling unscheduled conditions of Maybe jobs can
be applied to jobs and conditions.

However, an alternative method is available for conditions and jobs in SMART

Tables. Rather than add the unscheduled conditions of Maybe jobs to the IOA
Conditions file, the unscheduled conditions can be removed as runtime scheduling
criteria for the successor job orders.

The SMART Table Entity definition in SMART Tables contains an ADJUST

CONDITIONS field. If a value of Y is specified in the ADJUST CONDITIONS field,
CONTROL-M checks the scheduled jobs for unscheduled conditions.

Unscheduled conditions normally added by other jobs in the same SMART Table are
removed from the IN statements of the scheduled job orders:

■ These conditions do not appear in the Zoom screen. They are not, however, deleted
from the original job scheduling definition.

■ These conditions also do not appear in the Manual Conditions file. Therefore, there
is no real advantage to defining them with a unique prefix, unless they are used as
IN conditions for jobs in a different table.

Note the following points

■ Unscheduled conditions normally added by jobs in other tables are not removed
from the job order. They appear in the Manual Conditions file.

■ As indicated above, ADJUST CONDITIONS applies only to jobs in the same

SMART Table. By contrast, the IOALDNRS utility detects unscheduled conditions
of Maybe jobs across tables, and the ADDMNCND KSL utility adds these
conditions to the IOA Conditions file regardless of table.

834 Control-M for z/OS User Guide

 MAINVIEW Batch Optimizer Considerations

For more information, see Chapter 3, “Job Production Parameters.”

MAINVIEW Batch Optimizer Considerations

MAINVIEW Batch Optimizer (MVBO) is a batch optimization system that enables
effective parallel processing and efficient resource utilization in the mainframe
environment. The Job Optimizer Pipes component of MVBO enhances this capability
using MVS Pipe technology. If MVBO/Job Optimizer Pipes is installed at your site,
you can include the CONTROL-M PIPE parameter in a job scheduling definition in
order to use MVBO/Job Optimizer Pipes functionality.

Job-Related Considerations for Pipes

The following job-related issues must be considered when using the PIPE parameter
in a CONTROL-M job scheduling definition:

■ When using pipes for jobs submitted by CONTROL-M, the PIPE parameter must
be used if parallel submission of all pipe participants is to be ensured.

■ Normally (that is, when pipes are not used), prerequisite conditions ensure desired
flow of predecessor and successor jobs.

However, when values are specified in the PIPE parameters of interrelated job
scheduling definitions, CONTROL-M uses them to create Collections. The jobs in a
Collection are not submitted until all prerequisite conditions required by all jobs in
the Collection are satisfied. If a dependency exists between an OUT condition of
one job and an IN condition of another job in the same Collection, it prevents
submission of all the jobs in the Collection. CONTROL-M resolves this problem by
ignoring the IN condition, thus bypassing the dependency between the jobs in the
Collection and enabling the submission of the jobs. If the job is removed from the
Collection, its ignored IN conditions reappear.

■ When two jobs in the same Collection request the same Control resource, and at
least one of them requests the resource in “exclusive” mode, a “deadlock” situation
arises—the Collection jobs are not submitted. To prevent this, CONTROL-M
ignores the Control resource requests of one of the jobs, as follows: If one of the
jobs requested the resource in “shared” mode, that resource request is ignored; if
both jobs requested the resource in “exclusive” mode, the resource request of the
job with the shorter average elapsed time is ignored. If the job is removed from the
Collection, its ignored Control resources reappear.

Chapter 6 Selected Implementation Issues 835

Enhanced Runtime Scheduling Algorithm

NOTE
To allow integration between CONTROL-M and MVBO/Job Optimizer Pipes, the pipe
name specified in the CONTROL-M job scheduling definition must be identical to the pipe
name specified in the MVBO/Job Optimizer Pipes rule. Currently, this requirement is not
forced by CONTROL-M.

■ Jobs cannot be run in parallel if TIME FROM and TIME UNTIL specifications for
the jobs do not overlap.

This case must be considered individually at time of implementation.

■ When PIPE definitions are added, the Quantitative resources defined for the jobs
in the Collection must be checked to see if some of the defined resources are no
longer necessary. For example, if a pipe replaces a tape data set, the tape resource
may not be required. Such resources must be removed from the job scheduling
definition.

■ In a non-Sysplex environment, all jobs that are part of a Collection must run in the
same system. Therefore, BMC Software recommends that you avoid using
resources prefixed by a dollar sign ($) in jobs that are part of a Collection, to ensure
that all the jobs are submitted to the same system.

Enhanced Runtime Scheduling Algorithm

When jobs that are part of a Collection are scheduled, CONTROL-M treats the
Collection as one unit of work for processing runtime scheduling criteria in the
following ways:

■ CONTROL-M ensures that the required number of participants, as defined for the
pipe in the MVBO/Job Optimizer Pipes rule, access each pipe in the Collection. If a
participant is missing, the jobs in the Collection are not submitted. This ensures
that a job is not submitted when its participants are not scheduled on that day.

■ CONTROL-M analyzes all resources, such as prerequisite conditions, Quantitative

resources, and time limits, required by all jobs in the Collection as a single set. All
participants are submitted together when all the resources required by the set are
available. This ensures the parallel submission of all pipe participants.

To ensure that the jobs begin execution on time, it is recommended that initiators
be handled as Quantitative resources. This ensures that submitted jobs do not wait
for initiators and delay other jobs in the Collection.

836 Control-M for z/OS User Guide

 System-Related Considerations

■ CONTROL-M checks if the MVBO/Job Optimizer Pipes monitor is active before

submitting the jobs in the Collection. If the MVBO/Job Optimizer Pipes monitor is
not active, the jobs in the Collection are not submitted. This ensures that, when
submitted, the jobs run in parallel, using pipes.

System-Related Considerations
The following system-related issues must be considered when using the PIPE
parameter in a CONTROL-M job scheduling definition.

■ Parallel processing changes resource usage in the system. All resources required
for all the jobs in the Collection must be available when the jobs are submitted.

This means that more resources, such as initiators, tape drives, CPUs, are required
for shorter time periods; they become available after the jobs using the pipe finish
execution. Therefore, when using pipes, resource usage in the system in which the
jobs are to run must be reviewed to ensure that all required system resources are
available at the time the jobs are submitted.

■ The change in resource usage may necessitate changing the maximum quantities
defined for CONTROL-M to satisfy the changed requirements.

Parameter Prompting Facilities

It is assumed that the reader is familiar with the following CONTROL-M facilities
and concepts:

■ JCL and AutoEdit facility

■ prerequisite conditions
■ Manual Conditions (Screen 7) and the IOALDNRS utility

CONTROL-M provides two different types of Parameter Prompting facilities. The

online use of the two Parameter Prompting facilities is described in Chapter 2,
“Online Facilities.”

This chapter provides an explanation of how the Parameter Prompting facilities

work, how they differ from each other, and how to choose the facility that best suits
your operational needs. In addition, certain preparatory steps are detailed.

Chapter 6 Selected Implementation Issues 837

Parameter Prompting Facility – Type 1

Parameter Prompting Facility – Type 1

The Parameter Prompting facility – Type 1 is an ISPF table-based facility that
provides automatic prompting for AutoEdit parameter values and setting of
prerequisite conditions. It is the recommended method for operations personnel to
automate the updating of AutoEdit parameter members.

The CONTROL-M JCL and AutoEdit facility eliminates the need for frequent manual
changes to job parameters. However, there are usually a few job parameter changes
that cannot be automated, for example, tape serial numbers, which are unknown
prior to tape arrival. These types of parameters require manual modification by the
user, generally operations personnel.

Old Method

To illustrate how prior versions of CONTROL-M solved this problem, consider the
daily arrival of IRS tape number 123456.

Figure 363 Illustration 1A: How CONTROL-M Formerly Handled A New Tape

The illustration above represents the one-time definitions required to prepare

CONTROL-M for handling the IRS tape.

1. JOB A requires input of the IRS tape number before it can run. The job must be
defined in a CONTROL-M table with an IN prerequisite condition of
IRS-TAPE-ARRIVED.

2. The JCL for JOB A must include %%LIBSYM and %%MEMSYM control statements
pointing to the AutoEdit Library CTM.LIB.SYMBOLS and the AutoEdit member
TAPES.

838 Control-M for z/OS User Guide

 Parameter Prompting Facility – Type 1

3. The AutoEdit member TAPES contains several AutoEdit parameters (from various
jobs), including the parameter %%IRS_TAPE.

On a given day, the Manual Conditions file created by the IOALDNRS utility
indicates that the prerequisite condition IRS-TAPE-ARRIVED must be added
manually by the user. This serves as a reminder to the operations personnel that a job
is waiting for an IRS tape number. When the tape arrives, the user must perform two
steps, as illustrated in the following figure:

Figure 364 Illustration 1B: Steps Formerly Performed by the User

1. Access the AutoEdit member TAPES and assign value 123456 to the %%IRS_TAPE
parameter.

2. Enter Screen 7 to manually add condition IRS-TAPE-ARRIVED.

When the condition IRS-TAPE-ARRIVED has been added to the IOA Conditions file,
and assuming all other runtime conditions are met, the CONTROL-M monitor
submits the job. When the job is submitted, the value of %%IRS_TAPE in the JCL of
JOB A is updated by the value in the TAPES member. The job parameter
VOL=SER=%%IRS_TAPE resolves to VOL=SER=123456.

Chapter 6 Selected Implementation Issues 839

Parameter Prompting Facility – Type 1

New Method

In the current version, the same problem is resolved in a different way using the
Parameter Prompting facility – Type 1.

Figure 365 Illustration 2A: How CONTROL-M Now Handles A New Tape

The illustration above represents the one-time definitions required to prepare

CONTROL-M for handling the IRS tape when using Parameter Prompting facility –
Type 1.

1. JOB A requires input of the IRS tape number before it can run. The job must be
defined in a CONTROL-M table with IN prerequisite condition
IRS-TAPE-ARRIVED.

2. The JCL for JOB A includes %%LIBSYM and %%MEMSYM control statements
pointing to the CONTROL-M PROMPT prompting parameters library and the
TAPM%%OMONTH.%%ODAY daily AutoEdit member.

3. Using the first option of the Parameter Prompting facility – Type 1, groups of
AutoEdit parameters that require value assignment are defined once. These
parameters are grouped into a Master Prompting table, the Master table. Default
parameter values may be assigned. In addition, prerequisite conditions to be
associated with parameters are designated. In this example, several parameters
from various jobs have been defined in the TAP Master table, including the
%%IRS_TAPE parameter from JOB A. Prerequisite condition IRS-TAPE-ARRIVED
has been associated with this parameter.

840 Control-M for z/OS User Guide

 Parameter Prompting Facility – Type 1

When the tape arrives, the user only performs one step (illustrated below):

Figure 366 Illustration 2B: Single Step Now Performed by the User

The user selects the TAP table from a list of Master tables and is presented with Daily
Prompting table TAPT1112, an automatically created copy of the Master table for the
current date. The Daily Prompting table consists of parameter names, (optional)
descriptions, and default values. The user updates the %%IRS_TAPE parameter with
the value 123456.

The facility automatically adds condition IRS-TAPE-ARRIVED to the IOA Conditions

file and updates the daily AutoEdit member TAPM1112.

Chapter 6 Selected Implementation Issues 841

Summary

Summary
By using Parameter Prompting facility – Type 1, it is only necessary to update the
Daily table. The user no longer needs to remember which AutoEdit parameters in
which AutoEdit symbol member require changing, nor the prerequisite conditions
that require setting. The Parameter Prompting facility automatically handles
updating of the AutoEdit member, and adds any required conditions to the IOA
Conditions file.

Usage Notes

JCL Modifications
JCL members for jobs containing AutoEdit parameters defined in Master tables must
be modified as follows:

■ The %%LIBSYM control statement must point to the CONTROL-M PROMPT

library.

■ The %%MEMSYM control statement member name must be in the following

format:

@@@M%%OMONTH.%%ODAY

where @@@ is the Table Name Prefix defined in Option 1 of the facility.
%%OMONTH.%%ODAY can be replaced with any date variable or date constant
in the format mmdd.

The IOALDNRS Utility

The Parameter Prompting facility automatically adds conditions to the IOA
Conditions file after parameter update. These conditions no longer require
submission through Screen 7, and therefore do not need to appear on the Manual
Conditions file. To exclude these parameters from the file, you can use the IGNORE
IN parameter in the IOALDNRS utility, which is described in the INCONTROL for
z/OS Utilities Guide.

842 Control-M for z/OS User Guide

 Parameter Prompting Facility—Type 2

Parameter Prompting Facility—Type 2

The Parameter Prompting facility – Type 2 is a manual job scheduling facility that
provides automatic prompting for AutoEdit parameter values. On a given day, the
user selects the tables for execution. The user is then automatically prompted for
parameter values required for the execution of the jobs scheduled to run on the
specified date.

This type of prompting facility is recommended for use in a distributed environment

where user departments are responsible for manually scheduling (ordering) their
jobs, and specifying required parameters.

A sample application of this type of scheduling facility is the maintenance of

confidential salary information in a payroll department. The payroll department
usually retains control over its jobs and their input parameters.

The Parameter Prompting facility—Type 2 has three major phases:

Definition Phase
Figure 367 Parameter Prompting Facility Type 2: Definition Phase

1. Table

First, a table is defined using the CONTROL-M Online facility. The table contains
job scheduling information for all of a department’s jobs. Any number or type of
jobs with any valid date scheduling criteria can be designated. The table is placed
in a Master Scheduling Tables library.

Chapter 6 Selected Implementation Issues 843

Parameter Prompting Facility—Type 2

2. Master Prompting Plan

Next, using the first option of the Parameter Prompting facility – Type 2, a Master
Prompting Plan (MPP) is defined containing all AutoEdit variables used by all the
jobs in the table. Any default values can be assigned. Value validity checks can also
be defined. The MPP is placed in the Master Prompting Plan library.

FETCH Phase
Figure 368 Parameter Prompting Facility Type 2: Fetch Phase

The second option of the Parameter Prompting facility – Type 2, FETCH A PLAN,
allows the user to select a plan for execution by CONTROL-M on a specific day.

844 Control-M for z/OS User Guide

 Parameter Prompting Facility—Type 2

When a FETCH option is executed for a specific PLANID, or all PLANIDs with a
specific suffix, a daily table is automatically created. The Daily Scheduling table, a
subset of the Master Scheduling table, is placed in the Daily Scheduling Tables
library. The Daily Scheduling table contains the job scheduling definition of all of the
jobs in the Master Scheduling table scheduled to run on the specified date, based on
each job’s scheduling criteria.

The FETCH also creates a User Prompting Plan (UPP), a subset of the Master
Prompting Plan, which is placed in the Daily Prompting Plan library. The UPP
contains only parameters that are required by the jobs scheduled to run on the
specified date.

A Daily JCL library is also created containing JCL for today’s jobs.

EXEC Phase
The third option of this facility, EXEC A PLAN, permits the user to update or accept
the default values of all the parameters appearing in the daily UPP. A daily AutoEdit
parameters member, which is accessed at the time of job submission, is automatically
created and placed in the Daily AutoEdit Parameter library.

Figure 369 Parameter Prompting Facility Type 2: EXEC Phase

Once values have been assigned to all the parameters, the prerequisite condition
RUN-%%PLANID is added. %%PLANID is resolved to the PLANID, and suffix if
supplied, designated in the FETCH phase.

Chapter 6 Selected Implementation Issues 845

Parameter Prompting Facility—Type 2

The Daily Scheduling table is then ordered by CONTROL-M. The jobs are placed on
the Active Jobs file and run based on their scheduling parameters; that is, a job is
submitted only when all scheduling criteria, such as other prerequisite conditions,
have been met.

Tailoring to User Needs

The Parameter Prompting facility – Type 2 is usually activated from the
CONTROL-M ISPF Utilities screen. However, it is possible to activate the FETCH and
EXEC phases using the following CLISTS:

Table 256 Parameter Prompting Facility Type 2: Use of CLISTS

CLISTS Purpose
CTMFETCH For fetching a plan (FETCH phase)
CTMEXEC For executing a plan (EXEC phase)

CTMFETCH CLIST
When CLIST CTMFETCH is activated, the FETCH A PLAN screen is displayed:

Figure 370 The FETCH A PLAN Screen

---- CONTROL-M - P.P.F. ------ FETCH A PLAN ------------------------------(P.2)
COMMAND ===>

PLAN NAME ===>

PLAN NAME SUFFIX ===> (For multiple plans in the same day)

OVERRIDE DAILY PLAN ===> NO (YES / NO)

ODATE ===> 060601

Please fill in the Plan Name and press ENTER

MASTER SCHEDULING LIB ===> CTMP.PROD.SCHEDULE

DAILY SCHEDULING LIB ===> CTMP.PROD.SCHD
MASTER PLANS LIB ===> CTMP.PROD.PLANMSTR
DAILY PROMPT PLANS LIB ===> CTMP.PROD.PLAN
MASTER JCL LIB ===> CTMP.PROD.JCLPROMP
DAILY JCL LIB ===> CTMP.PROD.JCLP

ENTER END COMMAND OR PF3 TO TERMINATE

846 Control-M for z/OS User Guide

 Parameter Prompting Facility—Type 2

Table 257 The FETCH A PLAN Screen: Parameters

Parameter Description
PLAN NAME Plan name (1 through 6 characters). Mandatory.
PLAN NAME Two character suffix to be added to the PLAN NAME in daily
SUFFIX libraries. Changing the suffix permits multiple daily plans.
OVERRIDE DAILY Whether to replace an existing plan.
PLAN Valid values are:
■ YES – a duplicate fetch of a plan (with suffix, if one has been
designated) replaces an existing copy of a plan with the same
PLAN NAME (and same suffix) for that day
■ NO – multiple fetches of a plan are not permitted on the same
day (default)
ODATE Specific date for which the plan is to be fetched. Default is the current
working date. Another date can be specified, in mmddyy, ddmmyy or
yymmdd format, depending on the site standard.
MASTER Name of the Master Scheduling Tables library.
SCHEDULING LIB
DAILY Name of the Daily Scheduling Tables library. The last qualifier of the
SCHEDULING LIB library name cannot exceed 4 characters. The CLIST concatenates the
date to this daily library name.
MASTER PLANS LIB Name of the Master Prompting Plans library.
DAILY PROMPT Name of the User Daily Prompting Plans library. The last qualifier of
PLANS LIB the library name cannot exceed 4 characters. The CLIST concatenates
the date to this daily library name.
MASTER JCL LIB Name of the Master JCL library.
DAILY JCL LIB Name of the Daily JCL library. The last qualifier of the library name
cannot exceed 4 characters. The ** symbol concatenates the date to
this daily library name.

Chapter 6 Selected Implementation Issues 847

Parameter Prompting Facility—Type 2

CTMEXEC CLIST
When CLIST CTMEXEC is activated, the EXEC / ORDER A PLAN screen is
displayed:

Figure 371 The EXEC / ORDER A PLAN Screen

---- CONTROL-M - P.P.F. ---- EXEC / ORDER A PLAN -------------------------(P.3)
COMMAND ===>

PLAN NAME ===> REPTS (Blank for plan selection list)

PLAN NAME SUFFIX ===> (For multiple plans in the same day)

REMAINING PARAMETERS ===> NO (YES / NO)

ODATE ===> 080800

FORCED FROM TIME ===>

Please fill in the Plan Name (or blanks) and press ENTER

DAILY SCHEDULING LIB ===> CTM.PROD.SCHD

USER PROMPT PLANS LIB ===> CTM.PROD.PLAN
DAILY PARAMETERS LIB ===> CTM.PROD.AEDI

ENTER END COMMAND OR PF3 TO TERMINATE

Table 258 The EXEC / ORDER A PLAN Screen: Parameters

Parameter Description
PLAN NAME Plan name (1 to 6 characters). Mandatory.
PLAN NAME SUFFIX 2-character suffix used to specify a specific plan.
REMAINING PARAMETERS Continuation instructions. Valid values are:
■ Y – The user is automatically presented with
remaining (non-updated) parameters from all active
plans
■ N – After updating the current plan, the user is given
options for choosing another plan (default)
ODATE Specific date on which the plan is ordered. Default is the
current working date. Another date (in mmddyy,
ddmmyy, or yymmdd format depending on the site
standard) can be specified.
FORCED FROM TIME Specific time in format hhmm, before which the jobs
cannot run.
DAILY SCHEDULING LIB Name of the Daily Scheduling Tables library.
USER PROMPT PLANS LIB Name of the User Prompting Plans library.
DAILY PARAMETERS LIB Name of the Daily Parameters library.

848 Control-M for z/OS User Guide

 Parameter Prompting Facility—Type 2

Usage Notes
■ The PLAN NAME can be up to six characters in length. Use of the SUFFIX
parameter in the FETCH phase permits creation of multiple Daily User Prompting
Plans based on one Master Prompting Plan. This also makes it possible to duplicate
(by overriding) a fetch of the same plan by setting the OVERRIDE DAILY PLAN
parameter to YES on the FETCH A PLAN screen.

■ Each job defined in the Master Scheduling table must contain an IN prerequisite
condition in the format:

RUN-%%PLANID

This prerequisite condition is added during the EXEC phase only after all
parameters for a specific plan are assigned in the EXEC phase. %%PLANID
resolves to the PLAN NAME (and SUFFIX) designated in the FETCH phase.

Since each plan can be ordered multiple times for the same scheduling date, it is
highly recommended to distinguish between the dependencies of the jobs in the
plan based on PLAN NAME. Every prerequisite condition used for inter-plan
dependency must contain the string %%PLANID. It is automatically replaced by
the PLANID during the FETCH phase.

■ The JCL of each job must be modified as follows:

The first AutoEdit control statement must point to an AutoEdit Parameters library
and the PLANID member. The PLANID member contains the unique PLANID of
the job (automatically handled by CONTROL-M).

Example

%%LIBSYM CTM.PROD.SYMBOLS %%MEMSYM PLANID

The second AutoEdit control statement must point to the Daily AutoEdit
Parameters library and the member %%PLANID. CONTROL-M automatically
resolves %%PLANID to the PLAN NAME designated in the FETCH phase.

The Daily AutoEdit Parameter library must be suffixed by a date parameter that is
resolved by CONTROL-M. Example:

%%LIBSYM CTM.PROD.AEDI%%OMONTH.%%ODAY %%MEMSYM %%PLANID

■ The %%PLANID member of each plan (in the Daily AutoEdit Parameter library)
contains up to four configuration tables identified by AutoEdit variables.

Parameters and data that are repeatedly used in a data processing environment
can be defined in such a configuration table.

Chapter 6 Selected Implementation Issues 849

Parameter Prompting Facility—Type 2

A configuration table is a member of the GLOBAL library, which is referenced by

the DAGLOBAL DD statement. Such a member contains a set of user-defined local
variables and their assigned values that can be referenced in the JCL of individual
jobs.

An AutoEdit variable identifies such a configuration table by a statement in the

form %%CONFn=config_tablename in the %%PLANID member.

Example

%%CONF1=INDICES
%%CONF2=WEEKCHAR
%%CONF3=
%%CONF4=

To use the configuration tables parameters procedure, insert the following

AutoEdit statement in the JCL of each job:

//* %%INCLIB CTM.PROD.PARM %%INCMEM PPF2CONF

The PPF2CONF member uses the configuration table values specified in the
%%PLANID member to select the GLOBAL autoedit members to be included in
the JCL of the job. It contains the following AutoEdit code:

%%IF *%%CONF1 NE *
%%GLOBAL %%CONF1
%%ENDIF
%%IF *%%CONF2 NE *
%%GLOBAL %%CONF2
%%ENDIF
%%IF *%%CONF3 NE *
%%GLOBAL %%CONF3
%%ENDIF
%%IF *%%CONF4 NE *
%%GLOBAL %%CONF4
%%ENDIF

■ The MEMLIB parameter of each job scheduling definition in the table must point to
the Daily JCL library. The library name is suffixed by the AutoEdit date variables.

Example

CTM.PROD.JCLP%%OMONTH.%%ODAY

850 Control-M for z/OS User Guide

 Parameter Prompting Facility—Type 2

■ Occurrence numbering:

It is recommended that all AutoEdit parameter names of jobs in the same plan be
unique. In some plans, duplicate names may be unavoidable, and more than one
job may share the same AutoEdit parameter name. If the parameters are to be
assigned different values, that is, used for different purposes, each parameter must
be assigned a different OCCUR NO during definition of the Master Prompting
Plan.

A %%SET statement specifying the OCCUR NO. must be included in the JCL of the
associated jobs as follows:

%%SET %%OC# = 01

When the AutoEdit parameter member is created, each AutoEdit parameter

includes the OCCUR NO. as a suffix.

■ Using the Parameter Prompting facility – Type 2 requires customizing the

CONTROL-M submit exit (CTMX002). This exit does the following:

— It ensures that at the time when the job is submitted, the AutoEdit Parameters
library contains the PLANID member.

— It places in the PLANID member an AutoEdit variable definition in the form

%%PLANID=plan_id

in order to provide the job with a unique identity (plan_id). This is done using an
OUT condition in the job scheduling definition, as described in the source code
of the exit.

For information about modifying the exit, see the CTMX2PPF member in the IOA
SAMPEXIT library.

Chapter 6 Selected Implementation Issues 851

Maintenance Utilities

Maintenance Utilities
The following jobs are located in the CONTROL-M JCL library.

PPF2DEL
This job can be run to delete sets of daily libraries according to specified date criteria.

Figure 372 PPF2DEL Utility Screen

//PPF2DEL JOB ACCNT,CTM,CLASS=A
//*
//* THIS JOB DELETES SETS OF DAILY LIBRARIES CREATED 3,4,and 5
//* DAYS PRIOR TO THE CURRENT DATE (%%ODATE).
//*
//*************************************************************
%%SET %%DT3 = %%CALCDATE %%ODATE - 3
%%SET %%DELDATE3 = %%SUBSTR %%DT3 3 4
%%SET %%DT4 = %%CALCDATE %%ODATE - 4
%%SET %%DELDATE4 = %%SUBSTR %%DT4 3 4
%%SET %%DT5 = %%CALCDATE %%ODATE - 5
%%SET %%DELDATE5 = %%SUBSTR %%DT5 3 4
//DELLIB EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DELETE CTM.PROD.PLAN%%DELDATE3
DELETE CTM.PROD.SCHD%%DELDATE3
DELETE CTM.PROD.JCLP%%DELDATE3
DELETE CTM.PROD.AEDI%%DELDATE3
DELETE CTM.PROD.PLAN%%DELDATE4
DELETE CTM.PROD.SCHD%%DELDATE4
DELETE CTM.PROD.JCLP%%DELDATE4
DELETE CTM.PROD.AEDI%%DELDATE4
DELETE CTM.PROD.PLAN%%DELDATE5
DELETE CTM.PROD.SCHD%%DELDATE5
DELETE CTM.PROD.JCLP%%DELDATE5
DELETE CTM.PROD.AEDI%%DELDATE5
//

PPF2DAY
This job allocates the daily libraries that are to be used by the Parameter Prompting
facility – Type 2. It also copies the required jobs from the Master JCL library to the
Daily JCL library.

These are time consuming tasks normally performed as part of the FETCH and EXEC
phases of the Online facility. By scheduling this job daily under CONTROL-M, the
time required to execute the FETCH and EXEC phases is reduced.

852 Control-M for z/OS User Guide

 Chapter

7
7 Simulation and Forecasting Facility
This chapter includes the following topics:

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Simulation Procedure CTMSIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Activating the Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Preparatory Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
CONTROL-M Exits and Simulation Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
Analyzing the Simulation Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Handling Manual Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
The CTMTAPUL Tape Pull List Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
Activating the Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
DD Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
JOB/SCAN, PRO/JCL, DOCU/TEXT Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Problem Determination for Tape Pull List Reports . . . . . . . . . . . . . . . . . . . . . . . . 870
Sample Tape Pull List Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871

Chapter 7 Simulation and Forecasting Facility 853

Overview

Overview
The Simulation and Forecasting facility consists of two components.

■ Simulation procedure CTMSIM

■ Tape Pull List procedure CTMTAPUL

Simulation procedure CTMSIM tests the potential impact of proposed changes to the
configuration or production environment. It answers “What if?” questions, such as:

“What if we ...

■ add or remove four tape drives from the system?”

■ increase the CPU power by 30%?”
■ run a particular set of applications daily instead of weekly?”

The Simulation procedure can also be used to forecast production runs such as the
next 24-hour run, end-of-month run, and so on. In this way, possible irregularities in
the schedule can be foreseen.

The CTMTAPUL Tape Pull List procedure creates a report of all tapes to be mounted
for a specific period. By running the procedure on a daily basis, all tapes required for
the daily production run can be prepared in advance for the operator or the robotic
tape library.

The Tape Pull List procedure uses the output of the Simulation procedure as input.
Therefore, the Simulation procedure must be executed before the Tape Pull List
procedure can be executed. However, the Simulation procedure can be executed
without executing the Tape Pull List procedure.

Simulation Procedure CTMSIM

The Simulation procedure mirrors the CONTROL-M monitor flow for a specified
period without actual job submission and without output processing. It takes into
consideration all scheduling criteria including prerequisite conditions, time limits,
quantitative, and Control resources.

CONTROL-M and IOA files used as input to the simulation process are not updated
as a result of this process. The statuses of the files after simulation are written to
special simulation output files. The simulation assumes that each job ended execution
with a condition code of 0.

854 Control-M for z/OS User Guide

 Activating the Procedure

The following CONTROL-M and IOA files are used as input in the Simulation
procedure. These files may either be actual production files or special files created
specifically for forecasting purposes.

Table 259 Files Used as Input during Simulation

File Description
AJF Active Jobs file
RES CONTROL-M Resources file
CND IOA Conditions file
STAT CONTROL-M Statistics file

The simulation produces the following output files:

Table 260 Files Produced as Output of Simulation

File Description
SIMOAJF Simulation Output Active Jobs file
SIMORES Simulation Output Resources file
SIMOCND Simulation Output Conditions file
SIMLOG Simulation Output Log file

The Simulation procedure may contain several steps prior to the actual simulation
processing step, depending on the environment to be used as input to the simulation
run. For example

■ It may be desirable to use the production Active Jobs file as input.

■ It may be necessary to simulate the run of a specific day without relating to the
current production jobs.

■ It may be necessary to resolve manual conditions prior to the simulation run so

that all jobs are submitted.

Activating the Procedure

The procedure can be invoked directly, that is, through // EXEC CTMSIM, or
through a job generated by option M3 of the Online Utilities menu.

Option M3 is the preferred method of generating the job stream for the procedure
because the Online utility can automatically perform certain necessary preparatory
steps (mentioned above). If the Online utility is not used, the user must add these
steps, as necessary, to the JCL.

Chapter 7 Simulation and Forecasting Facility 855

Preparatory Steps

The M3 Online utility is discussed in “M3: Prepare Simulation/Tape Pull List Job” on
page 342.

Preparatory Steps
The following preparatory steps must be added, as needed, to the simulation job.

Allocate IOA Conditions File

The DACNDF DD statement references the IOA Conditions file. It may refer to either
of the following files:

■ the production IOA Conditions file

If this file is used, it only needs allocation.

■ a test file used to simulate jobs planned for a future working day
If a test file is used, an initial job step must allocate and format the simulation
Active Jobs file. A date record is then generated for the date of the simulation. A
User Daily job step then loads the required job orders into the simulation Active
Jobs file.

This preparatory step can be automatically generated through the M3 online utility.

All jobs in the Active Jobs file participate in the simulation. For jobs that are currently
executing at the time the simulation is running, it is assumed that they have already
executed half of their average elapsed time.

Allocate CONTROL-M Resources File

The DACNDF DD statement references the CONTROL-M Resources file. It may refer
to either of the following files:

■ the production CONTROL-M Resources file

If this file is used, it only needs allocation.

■ a test file, which can be used to define Quantitative resources under simulation,
using the IOACND utility

856 Control-M for z/OS User Guide

 Parameters

Parameters
There are two ways of setting parameters for the utility.

Parameters can be passed to the utility using the SIMPARM member in the
CONTROL-M PARM library. This member is referenced by the DASIMPRM
DD statement in the Simulation procedure, if it is specified in option M3 (Prepare
Simulation/Tape Pull List Job) of the Online Utilities.

Alternatively, parameters may be passed to the utility in-line, using the DASIMPRM
(or SYSIN) DD statement.

Table 261 Parameters Passed to the Utility by DASIMPRM (part 1 of 3)

Parameter Description
SIMSTART Date and time at which the simulation must start, in yymmddhhmm
format. Mandatory.
SIMEND Date and time at which the simulation must end, in yymmddhhmm
format. Mandatory.
Note: Ordinarily the interval between specified SIMSTART and
SIMEND values should not exceed a 24 hour period because there is
no mechanism to simulate New Day processing for the next day.
However, it is possible to specify a larger interval if one is required
to enable existing jobs to complete.
INTERVAL mm Simulation interval, in minutes. The simulation “clock” advances by
the interval specified. The shorter the interval, the more accurate the
simulation, but the longer the simulation takes to run. The specified
interval must not exceed one working day. Mandatory.

Chapter 7 Simulation and Forecasting Facility 857

Parameters

Table 261 Parameters Passed to the Utility by DASIMPRM (part 2 of 3)

Parameter Description
NEWJOB For a job that has no execution statistics, this statement is used to
indicate the expected execution time of the job. Optional.
If the simulation encounters a job without statistics and this
statement is not supplied, a default execution time of three minutes
is used.
The format of the NEWJOB parameter is as follows:
NEWJOB memname EXECTIME mmmm.xx [GROUP
groupname][CPUID i]
The following subparameters can be specified:
■ memname – name of the member containing the JCL of the job.
This value helps identify the job order in the Active Jobs file.
Mandatory.
■ mmmm.xx – expected execution time, where mmmm is the
number of minutes and xx is hundredths of minutes. This is the
same format used in the sysout Log message of the job.
Mandatory.
■ groupname – name of the group to which the job belongs. This
value helps identify the job order in the Active Jobs file.
Optional.
■ i – CPU ID. In a multiple CPU environment, the job can have
different execution times on different CPUs. Therefore, it is
useful to specify the expected elapsed time for each CPU on
which the job may run. i must have the same value as $SIGN,
which is described in “%%$SIGN” on page 762. Optional.
OLDJOB For a job with execution statistics, this statement can be used to
override the statistically estimated execution time. For example, a
longer execution time can be specified to test the effect of adding
more input data to the job. Optional.
Format of the OLDJOB parameter is as follows:
OLDJOB memname EXECTIME mmmm.xx [GROUP
groupname][CPUID i]
The same subparameters can be specified for the OLDJOB parameter
as those for the NEWJOB parameter (in this table).
ADD Add or delete a prerequisite condition of a specific ODATE (original
scheduling date) at a specified simulation date and time.
or The format of the ADD or DELETE parameter is as follows:
{ADD|DELETE} COND condname odate ONDAYTIME yymmddhhmm
DELETE The following subparameters can be specified:
■ ADD|DELETE – action to be performed. Mandatory.
■ condname – name of the condition to be added or deleted.
Mandatory.
■ odate – original scheduling date associated with the condition.
Mandatory.
■ yymmddhhmm – simulation date and time at which the condition
must be added or deleted. Mandatory.

858 Control-M for z/OS User Guide

 Input Files

Table 261 Parameters Passed to the Utility by DASIMPRM (part 3 of 3)

Parameter Description
CHANGE Change the quantity of a given resource at a specified simulation
RESOURCE date and time.
Format of the CHANGE RESOURCE parameter is as follows:
CHANGE RESOURCE resname quantity ONDAYTIME yymmddhhmm
The following subparameters can be specified:
■ resname – name of the resource whose quantity is to be changed.
Mandatory.
■ quantity – change in quantity for the resource. The quantity
change can be specified in any of the following formats:
— nnnn – set the quantity to the specified value
— +nnnn – add the specified quantity to the current
quantity
— -nnnn – subtract the specified quantity from the current
quantity
■ yymmddhhmm – simulation date and time at which the resource
quantity must be changed. Optional.

Input Files
The simulation procedure accepts the following input files:

■ Active Jobs file—created in the course of the preparatory steps described in

“Preparatory Steps” on page 856

■ Job Execution Statistics file—the DASTAT DD statement references the

CONTROL-M Job Execution Statistics file; this file contains job execution statistics,
including the execution elapsed time

■ IOA Conditions file—created in the course of the preparatory steps described in

“Preparatory Steps” on page 856

■ CONTROL-M Resources file—created in the course of the preparatory steps

described in “Preparatory Steps” on page 856

Chapter 7 Simulation and Forecasting Facility 859

Output Files

Output Files
The simulation run produces the following output files:

■ Simulation Messages file

The DASIMOUT DD statement references a sequential file containing a list of the

simulation parameters used, and special messages for error codes, warning
situations, and so on. In addition, it contains all the SHOUT messages to
TSO/ROSCOE users and to the computer operator.

■ SIMLOG—Simulation Log file

The DALOGOUT DD statement references a sequential output file in a format

similar to that of the IOA Log file.

At the end of the simulation process, this file contains all the log messages
describing events that occurred during the simulation run, for example, JOB
SUBMITTED, JOB ENDED OK, or COND xxxx ADDED.

This file can be used as input to all CONTROL-M reports that are normally
produced from the IOA Log file. The standard set of reports produced from the
IOA Log can be used to analyze the simulation run. Therefore, it is not necessary to
write special simulation reports.

■ SIMOAJF—Active Jobs file

The DACKPTOU DD statement references a file in the format of the Active Jobs
file. All jobs that were present in the input Active Jobs file are written to this file
with the status assigned to them during the simulation run, for example, ENDED
OK, EXECUTING, or WAIT SCHEDULE.

The file can be scanned online or in batch mode using standard CONTROL-M
facilities.

■ SIMOCND—Conditions file

The SIMOCND DD statement references a file in the format of the IOA Conditions
file. All conditions that were present at the end of the simulation run are written to
this file.

The file can be scanned online or in batch mode using standard CONTROL-M
facilities.

860 Control-M for z/OS User Guide

 CONTROL-M Exits and Simulation Processing

■ SIMORES—Resources file

The SIMORES DD statement references a file in the format of the CONTROL-M

Resources file. All Quantitative resources and Control resources that were present
at the end of the simulation run are written to this file.

The file can be scanned online or in batch mode using standard CONTROL-M
facilities.

CONTROL-M Exits and Simulation Processing

The CONTROL-M Simulation and Forecasting facility functions in much the same
way as the CONTROL-M monitor, but is activated without performing “real I/O.”
Therefore, some of the exits activated under the CONTROL-M monitor are also
activated during simulation.

Exit CTMX003 (output scanning) is invoked once for each job. The exit does not
receive any sysout. Since the simulation assumes that each job ended execution with a
condition code of 0, this exit can also be used to add events for certain jobs that end
with a nonzero condition code that influences the job flow.

Exit CTMX002 is not activated in simulation mode.

If the same exit is to be used in both the production and simulation environments, it
may be necessary to determine which environment is currently active. The
MCTSMIND field in the MCT can be checked as follows to determine whether the
exit is running under simulation:

TM MCTSMIND,MCTSIMYS ARE WE UNDER SIMULATION?

BO SKIPPROD YES, SKIP PRODUCTION LOGIC

Chapter 7 Simulation and Forecasting Facility 861

Analyzing the Simulation Run

Sample Input
Figure 373 CONTROL-M Simulation Exit Screen
// EXEC CTMSIM
//SIM.DACKPTIN DD DSN=XXX.CTM.PROD.TESTAJF,DISP=SHR
//SIM.SYSIN DD *
SIMSTART 0106060900
SIMEND 0106062200
INTERVAL 15
NEWJOB D4TRY1 EXECTIME 2.30
NEWJOB D4TRY2 EXECTIME 100.00 CPUID 1
NEWJOB D4TRY2 EXECTIME 120.00 CPUID 2
CHANGE RESOURCE TAPE -3 ONDAYTIME 0106061600
ADD COND IR-TAPE-ARRIVED 0606 ONDAYTIME 0106061800
ADD COND END-CICS 0606 ONDAYTIME 0106062100
//
. . SIM076I SIMULATION STARTED
SIMSTART 0112122100
SIMEND 0112122130
INTERVAL 55
ADD COND TAP-TEST-OK 0606 ONDAYTIME 0106062102
ADD COND TAP-TEST2-OK 0606 ONDAYTIME 0106062102
ADD COND PUL2-OK 0606 ONDAYTIME 0106062102
ADD COND PUL1-OK 0606 ONDAYTIME 0106062102
ADD COND PUL2-OK 0606 ONDAYTIME 0106062102
NEWJOB ASMMCTD EXECTIME 0001.00
NEWJOB ASMMCTM EXECTIME 0001.00
21.00.00 RUN100I CONTROL-M MONITOR STARTED
21.00.00 SIM087W MEMBER PRDJBREG LIBRARY PROD.DAILY.JOBS -
DEFAULT ELAPSED TIME USED
21.00.00 SIM087W MEMBER PRDJBDAY LIBRARY PROD.DAILY.JOBS -
DEFAULT ELAPSED TIME USED
21.02.45 CTM567I COND PUL2-OK ODATE 0606 ADDED
21.02.45 CTM567I COND PUL1-OK ODATE 0606 ADDED
21.02.45 CTM587I COND PUL2-OK ODATE 0606 ALREADY EXISTS
21.02.45 CTM567I COND TAP-TEST2-OK ODATE 0606 ADDED
21.02.45 CTM567I COND TAP-TEST-OK ODATE 0606 ADDED
21.31.10 SIM098I TASK EXECDAY DID NOT FINISH EXECUTING
21.31.10 SIM098I TASK PRDTEST DID NOT FINISH EXECUTING
21.31.10 SIM099I TASK MPMXXX STILL WAITS SCHEDULE
21.31.10 SIM099I TASK MPMTST STILL WAITS SCHEDULE
21.31.10 RUN120I CONTROL-M MONITOR SHUTTING DOWN
21.31.10 SIM078I SIMULATION ENDED

Analyzing the Simulation Run

The following tools can be used to analyze the simulation run and to diagnose
problems that may have occurred during simulation processing.

■ output of the Simulation Run

■ output of the KSL Step
■ Night Schedule Report
■ Online Simulation Environment
■ the CTMRAFL utility

862 Control-M for z/OS User Guide

 Analyzing the Simulation Run

These tools are described below.

Output of the Simulation Run

The DASIMOUT DD statement references summary information about the
simulation run. It specifies which jobs ran, which are still in WAIT SCHEDULE
status, and which are still executing when the simulation terminates. The following
tools can be used to ascertain why certain jobs remain in WAIT SCHEDULE status
when the simulation run is terminated.

Output of the KSL Step

The REP3LEFT KSL script can be executed after the simulation step. REP3LEFT
generates a report that shows the reasons why certain jobs are still in WAIT
SCHEDULE status at the end of the simulation run. This report can be requested as
an option through the M3 Online utility.

Night Schedule Report

This report provides a summary of each job that fell within the time interval of the
simulation run. This report can be requested as an option through the M3 Online
utility.

Online Simulation Environment

A special online environment can be created for the allocation of the files written by
the simulation run. The online environment must include the following allocations:

Table 262 Online Simulation Environment File Allocations

Allocation Description
DACKPT DD statement Allocated to file SIMOAJF
DACNDF DD statement Allocated to file SIMORES
DACNDF DD statement Allocated to file SIMOCND
DALOG DD statement Allocated to file SIMLOG

The online environment can be used to determine not only which jobs were
submitted, but which jobs are waiting to be scheduled and why they remained in
WAIT SCHEDULE status at the termination of the simulation run.

Chapter 7 Simulation and Forecasting Facility 863

Handling Manual Conditions

The CTMRAFL Utility

The CTMRAFL utility, which is described in the INCONTROL for z/OS Utilities Guide,
can be run on the simulation input Active Jobs file to obtain information on job
dependencies and manual conditions. The CTMRAFL utility does not check the IOA
Conditions file. Therefore, conditions listed as “manual conditions” may actually
exist in the IOA Conditions file.

Handling Manual Conditions

Perform the following steps to incorporate manual conditions into the IOA
Conditions file that is used in the simulation procedure.

1. Create a Conditions file and a Manual Conditions file to be used for simulation
only. You can use the FORMCND and FORMNRS members in the IOA INSTALL
library to do this. The file name CND can be changed to SIMCND. The file names
NRS and NSN can be changed to SIMNRS and SIMNSN respectively.

2. Using the CTMCOPRS utility, copy the contents of the production IOA Conditions
file into the simulation Conditions file created in Step 1.

3. Integrate the IOALDNRS utility into the standard CTMSIM procedure so that it
runs against the simulation Active Jobs File, which has been loaded with
simulation jobs, to load the manual conditions into the simulation NRS file
SIMNRS.

Specify the following overrides when using the IOALDNRS procedure:

Table 263 Overrides To Be Specified on IOALDNRS

DDname DSname Suffix Override Suffix
DANRES NRS SIMNRS
DANSINC NSN SIMNSN
DACNDF CND SIMCND

4. Integrate the ADDCMND job, which is in the CONTROL-M JCL library, into the
standard CTMSIM procedure to add the required manual Maybe conditions to the
simulation Conditions file.

Specify the following overrides when running ADDMNCND:

864 Control-M for z/OS User Guide

 The CTMTAPUL Tape Pull List Procedure

Table 264 Overrides To Be Specified on ADDMNCND

DDname DSname Suffix Override Suffix
DANRES NRS SIMNRS
DANSINC NSN SIMNSN

5. Specify the following override for the simulation step:

Table 265 Override To Be Specified for Simulation Step

DDname DSname Suffix Override Suffix
DACNDF CND SIMCND

The CTMTAPUL Tape Pull List Procedure

The Tape Pull List procedure creates a list of all tapes to be mounted in a specified
period. The list can be sorted and edited in various ways, such as

■ all tapes to be mounted, sorted by the expected mount time

■ all tapes to be mounted, sorted by volume serial number

NOTE
It is highly recommended that the simulation be run from the current time, that is, not from a
time in the future. Otherwise, the Tape Pull list results may be inaccurate because new tape
files may be cataloged in the time remaining before the start of the simulation run.

The procedure takes into account the expected order of job execution and the order of
creation of tape data sets.

The procedure also does the following:

■ checks the syntax of all AutoEdit statements in all jobs that are planned for the
given period

■ checks the JCL syntax

■ produces a list of data sets that are still missing for the execution.

These are usually input data sets due to arrive, but they may be JCL execution
errors

Chapter 7 Simulation and Forecasting Facility 865

The CTMTAPUL Tape Pull List Procedure

NOTE
For the Tape Pull List procedure to be executed properly, the internal reader (INTRDR) must
have authority to submit jobs.

The Tape Pull List procedure uses files from the Simulation procedure as input. In
preparation for the Tape Pull List procedure, run the Simulation procedure using the
production CONTROL-M Active Jobs file, CONTROL-M Resources file, and IOA
Conditions file.

The Tape Pull List procedure works as follows:

■ The procedure looks for “SUBMISSION” messages in the simulation output LOG
file.

— For each submission message, it looks for the appropriate job having a WAIT
SCHEDULE status on the simulation input Active Jobs file.

— If a job is found, the Tape Pull List procedure actually submits the job with the
TYPRUN=SCAN parameter specification, reads the SYSOUT of the job,
retrieves the data set information, and produces the required reports.

■ The procedure recognizes tape data sets by either the appropriate unit
specification in the JCL, such as UNIT=TAPE, or by retrieving information from
the system catalog. It is therefore not necessary to have all tape data sets cataloged
in the MVS catalog.

NOTE
A highlighted warning message appears on the operator console while the jobs are being
submitted. During this stage, the operator console may display several messages regarding
the job submission. The highlighted message disappears at the end of this stage.

The procedure can detect that a certain tape is used by more than one job, and
which job creates it, as illustrated in the following example.

Job A creates a new generation of a tape data set:

//OUTUPD DD DSN=PFX.DATA(+1),DISP=(,CATLG),...

Job B, a successor of Job A, accesses the same data set:

//INUPD DD DSN=PFX.DATA(0),DISP=SHR

The procedure detects that Job A is the creator of the data set used by Job B and
reports the same tape volser for both jobs.

■ After the job sysout has been analyzed, the sysout is deleted from spool.

866 Control-M for z/OS User Guide

 Activating the Procedure

■ The next stage of the procedure produces reports according to the requested
parameters.

Activating the Procedure

The Tape Pull List procedure is activated as follows:

// EXEC CTMTAPUL
//TAPULIN DD *
parameters

Parameters
There are two ways of setting parameters for the utility.

Parameters can be passed to the Tape Pull List utility using the TAPULPRM member
in the CONTROL-M PARM library. This member is referenced by the TAPULIN
DD statement in the Tape Pull List procedure, CTMTAPUL, if it is specified in option
M3 (Prepare Simulation/Tape Pull List Job) of the Online Utilities.

Alternatively, parameters may be passed to the utility in-line, using the TAPULIN
DD statement.

Table 266 CTMTAPUL Subparameters (part 1 of 2)

Subparameter Description
REPBYVOL Produce a report sorted by volume serial number (volser). All
tapes from the tape library are included.
REPBYTIME Produce a report sorted by the expected mount time.
REPBYJOB Produce a report sorted by job name.
REPBYDSN Produce a report sorted by data set name.

Chapter 7 Simulation and Forecasting Facility 867

Parameters

Table 266 CTMTAPUL Subparameters (part 2 of 2)

Subparameter Description
JCLFILE {YES|NO|ONLY} Whether a copy of every submitted job is written to the file
referenced by the DAJCLOUT DD statement.
Valid values are:
■ YES – A copy of every submitted job is written to the file
referenced by the DAJCLOUT DD statement.
■ NO – A copy of every submitted job is not written to the
file referenced by the DAJCLOUT DD statement. Default.
■ ONLY – A copy of every submitted job is written to the file
referenced by the DAJCLOUT DD statement, but
— the procedure does not submit the job
— the Tape Pull reports are not created
— the procedure is run to create the JCL file only
Note: When dealing with submitted jobs, the utility, for
internal processing purposes, inserts the following accounting
code into the jobcard of the job:
CTM-FORCE-TPLNM
When operating under JES3, the following statement is also
inserted:
//*NET ID=AESUSER
IGNORE DSN dsn Data set name (or prefix) that must not appear in the report. If
the last character of dsn is *, it is treated as a prefix.
IGNORE JOB jobname Job name (or prefix) that must not appear in the report. If the
last character of jobname is *, it is treated as a prefix.

The Tape Pull List job can be prepared using the (ISPF) Simulation panel (Option M3
in the IOA Online Utilities menu). A special section of the panel is designated for
Tape Pull List parameters. If you want to run the Tape Pull List procedure

1. Type Y in the TAPE PULL LIST field.

2. Type Y in the field next to the desired type of report.

The default control parameters member name appears on the screen. This member
contains IGNORE statements (procedure parameters). JOB/SCAN and PRO/JCL
parameters are discussed in “JOB/SCAN, PRO/JCL, DOCU/TEXT Interface” on
page 869.

After filling in the parameters, enter the edited JCL of a job to run the simulation and
the procedure. You can submit it, or save it for future use.

868 Control-M for z/OS User Guide

 DD Statements

DD Statements
The following DD statements are used by procedure CTMTAPUL:

Table 267 DD statements used by CTMTAPUL

DD Statement Description
DALOGIN Output Log file of the Simulation facility, which is input for the Tape
Pull List procedure.
DACKPSOU Output Active Jobs file of the Simulation facility, which is input for
the Tape Pull List procedure
DACKPTIN Active Jobs file used as input to the simulation, but remains
unmodified.
TAPULIN Procedure parameters.
DATAPNAM Member containing a list of local names used by the site to describe
tape units and cassettes or cartridges.
The TAPNAM member in the CONTROL-M PARM library contains
a sample list of local names used by the data center to describe tapes,
cassettes, cartridges and DASD units. CONTROL-M recognizes
IBM-supplied names such as 3490, which do not need to be specified.
This member is referenced by this DATAPNAM DD statement in the
Tape Pull List procedure, CTMTAPUL.
The format of each line in the list is:
■ Columns 1 through 8 – Unit name
■ Column 9 – One of the following indicators:
— T – Tape
— C – Cassette or Cartridge
— D – DASD
DAREPOUT Reports output.
TAPULOUT Messages (of the procedure).
DAJCLOUT Job stream of the jobs that is submitted during the specified period.
For more information, see the following section, “JOB/SCAN,
PRO/JCL, DOCU/TEXT Interface.”

JOB/SCAN, PRO/JCL, DOCU/TEXT Interface

When the JCLFILE parameter is specified, every job that is submitted by the
procedure for JCL scan is also written to the DAJCLOUT DD statement. At the end of
execution of the procedure, this data set (if allocated) contains all jobs that are
submitted during the execution period according to the order of submission. This file
can be used as input to JOB/SCAN, PRO/JCL, or DOCU/TEXT.

In sites using the JOB/SCAN, PRO/JCL, DOCU/TEXT Interface, the lower portion of
the M3 Online utility, which is described in “M3: Prepare Simulation/Tape Pull List
Job” on page 342, contains INVOKE JOB/SCAN parameters.

Chapter 7 Simulation and Forecasting Facility 869

Problem Determination for Tape Pull List Reports

Problem Determination for Tape Pull List Reports

The following conditions must be satisfied before the Tape Pull List procedure can
forecast tapes for a specific job:

■ The submission message must be present in the simulation output Log file.

■ The corresponding job has a WAIT SCHEDULE status in the simulation input
Active Jobs file.

Reports are not produced if one or more of the following situations exist:

■ None of the “submitted” jobs required tapes.

■ Jobs requiring tapes were not “submitted” by the simulation because their
submission criteria were not satisfied.

■ An invalid Active Jobs file was specified as an input for the Tape Pull List
procedure.

■ An invalid Log file was specified as an input for the Tape Pull List procedure.

■ JCLFILE ONLY was specified as an input parameter for the procedure.

■ No reports were requested from the procedure through the input parameters, that
is, the default was “no reports”.

■ The procedure does not recognize tape data sets. For more information, see the
description of the Tape Pull list utility in the discussion of CONTROL-M
customization in the INCONTROL for z/OS Installation Guide.

870 Control-M for z/OS User Guide

 Sample Tape Pull List Reports

Sample Tape Pull List Reports

The following pages show a series of samples of reports produced by CTMTAPUL. In
these samples, when the values M-N or M-O appear in the DISP (disposition) column,
they signify a disposition of MOD, either as a NEW (M-N) or OLD (M-O) data set.

Figure 374 Sample Tape Pull List Report 1

PRODUCED BY CONTROL-M PROD TAPE PULL LIST
BMC SOFTWARE, INC. ====================

JOBNAME USER ODATE TIME MEMNAME VOLSER LAB# TYPE DISP DSNAME PROCNAME STEPNAME DDNAME
-----------------------------------------------------------------------------------------------------------------
SMFSAVE M05 060601 09:06 SMFSAVE 110050 0001 T M-O BKP.MONTH.CONT02(+0) STEP3 TAPE1
110051 T
110048 0001 T M-O BKP.MONTH.CONT02(-1) STEP3 TAPE2
110049 T
110058 0001 T M-O BKP.MONTH.CONTO2(-2) STEP3 TAPE3
110059 T
PRDINPUT M05 060601 09:02 PRDINPUT 996713 0001 T NEW PRD.TP.FILE1(+1) ST1 DD1
S#0001 0001 C NEW PRDW.FILE.GDG.TBLM1(+1) BADSTEP BADD1
100047 0001 T M-O BKP.WEEK.CONT01(-2) ASTEP1 OUT0
PRDUPDT1 M05 060601 09:09 PRDUPDT1 114003 0001 T OLD PRDW.FILE.GDG.TBL11(+0) RES TAP1GDG0
114002 0001 T OLD PRDW.FILE.GDG.TBL11(-1) RES TAP1GDG2
S#0004 0001 T NEW BKP.MONTH.CONT01(+1) RESTORE CYCLIC DACYCT
114003 0001 T OLD PRDW.FILE.GDG.TBL11(+0) RESTORE CYCLIC TAPEGDG0
$#0005 0001 C NEW PRDO.TP.UPDT1 RESTORE CYCLIC CASSFILE
PRDRPT2C M05 060601 09:19 PRDRPT2C $#0006 0001 T NEW PRD.TP.DAILY.REPORTS ASTEP1 OUT
113492 0001 T OLD PRD.CART.RPT2C BACKUP CYCLIC DACYCT
$#0007 0001 T NEW BKP.MONTH.CONT02(+1) BACKUP CYCLIC DACYCT
PRDRPT2D M05 060601 09:22 PRDRPT2D 114003 0001 T OLD PRDW.FILE.GDG.TBL11(+0) ST1 TAPE0
T00001 0001 T NEW PRD.SNG1912.TAPE1(+1) ST1 TAPE1
T00002 0002 T NEW PRD.SNG1912.TAPE1(+2) ST1 TAPE11
994529 0001 T NEW PRDW.FILE.GDG.TBL21(+0) ST2 TAPE0
997892 0003 T NEW PRD.SNG1912.TAPE2(+1) ST2 TAPE2
S#0008 0001 T NEW &&NEWTEMP ST2 TAPETMP
996638 T NEW BKP.MONTH.CONT01(+3) ST2 TAPE8O2
PRDEXE2E M05 060601 09:25 PRDEXE2E T00002 0002 T OLD PRD.SNG1912.TAPE1(+0) STEP1 INTAPE1
T00001 0001 T OLD PRD.SNG1912.TAPE1(-1) STEP1 INTAPE11
S#0007 0001 T OLD BKP.MONTH.CONT02(+0) STEP2 TAPE5
110050 0001 T OLD BKP.MONTH.CONT02(-1) STEP2 TAPE6
110051 T
110048 0001 T OLD BKP.MONTH.CONT02(-2) STEP2 TAPE7
110049 T
110058 0001 T OLD BKP.MONTH.CONT02(-3) STEP2 TAPE8
110059 T
110056 0001 T OLD BKP.MONTH.CONT02(-4) STEP2 TAPE9
110057 T

SORTBY JOBNAME (REPBYJOB)

Chapter 7 Simulation and Forecasting Facility 871

Sample Tape Pull List Reports

Figure 375 Sample Tape Pull List Report 2

PRODUCED BY CONTROL-M PROD TAPE PULL LIST
BMC SOFTWARE, INC. ====================
DSNAME JOBNAME MEMNAME VOLSER DISP TYPE PROCNAME STEPNAME DDNAME
---------------------------------------------------------------------------------------
&&NEWTEMP PRDRPT2D PRDRPT2D S#0008 NEW T ST2 TAPETMP
BKP.MONTH.CONT01(+1) PRDUPDT1 PRDUPDT1 S#0004 NEW T RESTORE CYCLIC DACYCT
BKP.MONTH.CONT01(+3) PRDRPT2D PRDRPT2D 996638 NEW T ST2 TAPE8O2
BKP.MONTH.CONT01(+0) SMFSAVE SMFSAVE 110050 M-O T STEP3 TAPE1
110051 M-O T STEP3 TAPE1
PRDEXE2E PRDEXE2E S#0007 OLD T STEP2 TAPE5
BKP.MONTH.CONT02(+1) PRDRPT2C PRDRPT2C S#0007 NEW T BACKUP CYCLIC DACYCT
BKP.MONTH.CONT02(-1) SMFSAVE SMFSAVE 110048 M-O T STEP3 TAPE2
PRDEXE2E PRDEXE2E 110050 OLD T STEP2 TAPE6
110051 OLD T STEP2 TAPE6
BKP.MONTH.CONT02(-2) SMFSAVE SMFSAVE 110058 M-O T STEP3 TAPE3
110059 M-O T STEP3 TAPE3
PRDEXE2E PRDEXE2E 110048 OLD T STEP2 TAPE7
100049 OLD T STEP2 TAPE7
BKP.MONTH.CONT02(-3) PRDEXE2E PRDEXE2E 110058 OLD T STEP2 TAPE8
110059 OLD T STEP2 TAPE8
BKP.MONTH.CONT02(-4) PRDEXE2E PRDEXE2E 110056 OLD T STEP2 TAPE9
110057 OLD T STEP2 TAPE9
BKP.WEEK.CONT01(-2) PRDINPUT PRDINPUT 100047 M-O T ASTEP1 OUT0
PRD.SNG1912.TAPE1(+0) PRDEXE2E PRDEXE2E T00002 OLD T STEP1 INTAPE1
PRD.SNG1912.TAPE1(+1) PRDRPT2D PRDRPT2D T00001 NEW T ST1 TAPE1
PRD.SNG1912.TAPE1(+2) PRDRPT2D PRDRPT2D T00002 NEW T ST1 TAPE11
PRD.SNG1912.TAPE1(-1) PRDEXE2E PRDEXE2E T00001 OLD T STEP1 INTAPE11
PRD.SNG1912.TAPE2(+0) PRDEXE2E PRDEXE2E 997892 OLD T STEP2 INTAPE2
PRD.SNG1912.TAPE2(+1) PRDRPT2D PRDRPT2D 997892 NEW T ST2 TAPE2
PRD.TP.FILE1(+1) PRDINPUT PRDINPUT 996713 NEW T ST1 DD1
PRDW.FILE.GDG.TBLM1(+0) PRDINPUT PRDINPUT S#0001 OLD C BADSTEP BADD2
PRDW.FILE.GDG.TBLM1(+1) PRDINPUT PRDINPUT S#0001 NEW C BADSTEP BADD1
PRDW.FILE.GDG.TBLM8(+1) PRDINPUT PRDINPUT S#0003 NEW T ASTEP1 TAPEGDG8
PRDW.FILE.GDG.TBL11(+0) PRDINPUT PRDINPUT 114002 OLD T ASTEP1 TAPEGDG0
PRDUPDT1 PRDUPDT1 114003 OLD T RES TAP1GDG0
PRDRPT2D PRDRPT2D 114003 OLD T ST1 TAPE0
T00002 NEW T ST1 TAPE12
PRDW.FILE.GDG.TBL11(+1) PRDINPUT PRDINPUT 114003 NEW T ASTEP1 TAPEGDG2
PRDW.FILE.GDG.TBL11(-0) PRDINPUT PRDINPUT 114002 OLD T ASTEP1 TAPEGDG1
PRDUPDT1 PRDUPDT1 114003 OLD T RES TAP1GDG1
PRDRPT2D PRDRPT2D 114003 OLD T ST2 TAPE01
PRDW.FILE.GDG.TBL11(-0) PRDUPDT1 PRDUPDT1 114002 OLD T RES TAP1GDG2
SORTBY DSNAME (REPBYDSN)

872 Control-M for z/OS User Guide

 Sample Tape Pull List Reports

Figure 376 Sample Tape Pull List Report 3

PRODUCED BY CONTROL-M PROD TAPE PULL LIST
BMC SOFTWARE, INC. ====================

VOLSER TYPE JOBNAME ODATE TIME DISP LAB# DSNAME

-------------------------------------------------------------------------
S#0001 C PRDINPUT 060601 22:02 NEW 0001 PRDW.TESTFILE.GDG.TBLM1(+1)
S#0002 T PRDINPUT 060601 22:02 NEW 0001 PRD.TP.TRANS
S#0003 T PRDINPUT 060601 22:02 NEW 0001 PRDW.TESTFILE.GDG.TBLM8(+1)
S#0004 T PRDUPDT1 060601 22:09 NEW 0001 BKP.MONTH.CONT01(+1)
T00001 T PRDRPT2D 060601 22:22 NEW 0001 PRD.SNG1912.TAPE1(+1)
T00002 T PRDRPT2D 060601 22:22 NEW 0002 PRD.SNG1912.TAPE1(+2)
100000 T PRDINPUT 060601 22:02 OLD 0001 PRDW.TESTFILE.GDG.TBLM8(+0)
100047 T PRDINPUT 060601 22:02 M-O 0001 BKP.WEEK.CONT01(-2)
100048 T PRDINPUT 060601 22:02 M-O 0001 BKP.WEEK.CONT01(-2)
110048 T SMFSAVE 060601 22:06 M-O 0001 BKP.MONTH.CONT02(-1)
PRDEXE2E 060601 22:25 OLD 0001 BKP.MONTH.CONT02(-2)
110049 T SMFSAVE 060601 22:06 M-O 0001 BKP.MONTH.CONT02(-1)
PRDEXE2E 060601 22:25 OLD 0001 BKP.MONTH.CONT02(-2)
110050 T SMFSAVE 060601 22:06 M-O 0001 BKP.MONTH.CONT02(+0)
PRDEXE2E 060601 22:25 OLD 0001 BKP.MONTH.CONT02(-1)
PRDRUN2F 060601 22:28 M-O 0001 BKP.MONTH.CONT02(-2)
110051 T SMFSAVE 060601 22:06 M-O 0001 BKP.MONTH.CONT02(+0)
PRDEXE2E 060601 22:25 OLD 0001 BKP.MONTH.CONT02(-1)
PRDRUN2F 060601 22:28 M-O 0001 BKP.MONTH.CONT02(-2)
996713 T PRDINPUT 060601 22:02 NEW 0001 PRD.TP.FILE1(+1)
997892 T PRDRPT2D 060601 22:22 NEW 0003 PRD.SNG1912.TAPE2(+1)
PRDEXE2E 060601 22:25 OLD 0003 PRD.SNG1912.TAPE2(+0)

SORTBY VOLUME (REPBYVOL)

Chapter 7 Simulation and Forecasting Facility 873

Sample Tape Pull List Reports

Figure 377 Sample Tape Pull List Report 4

PRODUCED BY CONTROL-M PROD TAPE PULL LIST
BMC SOFTWARE, INC. ====================
ODATE TIME VOLSER TYPE JOBNAME DISP DSNAME
-----------------------------------------------------------------------------------------
060601 22:02 996713 T PRDINPUT NEW PRD.TP.FILE1(+1)
S#0001 C NEW PRDW.FILE.GDG.TBLM1(+1)
100047 T M-O BKP.WEEK.CONT01(-2)
S#0002 T NEW PRD.TP.TRANS
060601 22:06 110050 T SMFSAVE M-O BKP.MONTH.CONT02(+0)
110051 T
100048 T M-O BKP.MONTH.CONT02(-1)
110049 T
110058 T M-O BKP.MONTH.CONT02(-2)
110059 T
060601 22:09 114003 T PRDUPDT1 OLD PRDW.FILE.GDG.TBL11(+0)
114002 T OLD PRDW.FILE.GDG.TBL11(-1)
S#0004 T NEW BKP.MONTH.CONT01(+1)
114003 T OLD PRDW.FILW.GDG.TBL11(+0)
S#0005 C NEW PRDO.TP.UPDT1
060601 22:19 S#0006 T PRDRPT2C NEW PRD.TP.DAILY.REPORTS
113492 T OLD PRD.CART.RPT2C
S#0007 T NEW BKP.MONTH.CONT02(+1)
060601 22:22 114003 T PRDRPT2D OLD PRDW.FILE.GDG.TBL11(+0)
T00001 T NEW PRD.SNG1912.TAPE1(+1)
T00002 T NEW PRD.SNG1912.TAPE1(+2)
994529 T NEW PRDW.FILE.GDG.TBL21(+0)
997892 T NEW PRD.SNG1912.TAPE2(+1)
S#0008 T NEW &&NEWTEMP
996638 T NEW BKP.MONTH.CONT01(+3)
060601 22:25 T00002 T PRDEXE2E OLD PRD.SNG1912.TAPE1(+0)
TOOOO1 T OLD PRD.SNG1912.TAPE1(-1)
S#0007 T OLD BKP.MONTH.CONT02(+0)
110050 T OLD BKP.MONTH.CONT02(-1)
110051 T
110048 T OLD BKP.MONTH.CONT02(-2)
110049 T
110058 T OLD BKP.MONTH.CONT02(-3)
110059 T
110056 T OLD BKP.MONTH.CONT02(-4)
110057 T

SORTBY TIME (REPBYTIM)

874 Control-M for z/OS User Guide

 Appendix

A
The Control-M Application Program
A

Interface (CTMAPI)
This appendix discusses the Control-M Application Program Interface (CTMAPI),
including the following topics:

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Environment and Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
1. Order or Force Existing Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Order or Force under Batch, REXX or CLIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Order or Force Using Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Order or Force Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Order or Force Return Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Order or Force Performance Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Order or Force Security Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
2. Create, Order, or Force New Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Invoking Create, Order or Force New Tables Using Program . . . . . . . . . . . . . . . 884
Create, Order or Force Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Create, Order or Force Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Create, Order or Force Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . 885
Create, Order or Force Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
3. AJF Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
AJF Action under Batch, REXX or CLIST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
AJF Action using Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
AJF Action Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
AJF Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
AJF Action Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
AJF Action Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
4. Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Search under Batch, REXX or CLIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Invoking Search from a Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Search Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Search Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Search Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Search Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890

Appendix A The Control-M Application Program Interface (CTMAPI) 875

 5. Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Global Variables under Batch REXX or CLIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
6. Conditions and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
7. CTMAS Active Job Download Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
EMDOWNLD Action under Batch, REXX or CLIST . . . . . . . . . . . . . . . . . . . . . . . 893
EMDOWNLD Action Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
EMDOWNLD Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
EMDOWNLD Action Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . 893
EMDOWNLD Action Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Conditional Requests and Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Performance Considerations for Selection Criteria. . . . . . . . . . . . . . . . . . . . . . . . . 896
Search Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Conversational Mode using Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Input and Output Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Example – Invoking CTMAPI in BAPI mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
CTMBAPI DSECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Status Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
The Status Reply DSECT (CTMBJSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Status Allocations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Status Return Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Status Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Status Security Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Order Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Order Return Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Order Reply. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Order or Force Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Order or Force Security Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
AJF Action Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Identifying the Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Defining the Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Action AJF Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Action Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Global Variable Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Global Variable Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Quantitative Resource Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Quantitative Resource Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Quantitative Resource Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Quantitative Resource Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Create and/or Order or Force a Table (BLT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
BLT Action Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
BLT Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
BLT Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
BLT Resource Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
CTMBAPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917

876 Control-M for z/OS User Guide

 Overview

Date Format Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918

■ “Overview” on page 877
■ “Environment and Allocations” on page 878
■ “Functions”, including
— “1. Order or Force Existing Jobs” on page 881
— “2. Create, Order, or Force New Tables” on page 884
— “3. AJF Actions” on page 886
— “4. Search” on page 888
— “5. Global Variables” on page 890
— “6. Conditions and Resources” on page 892
— “7. CTMAS Active Job Download Filtering” on page 892
■ “Conditional Requests and Selection Criteria” on page 894
■ “Return Codes” on page 897
■ “Conversational Mode using Program” on page 898
■ “Input and Output Registers” on page 898
■ “CTMBAPI DSECT” on page 899
■ “Status Extension” on page 903
■ “Order Extension” on page 907
■ “AJF Action Extension” on page 910
■ “Global Variable Extension” on page 913
■ “Quantitative Resource Extension” on page 914
■ “Create and/or Order or Force a Table (BLT)” on page 915
■ “Replies” on page 917
■ “CTMBAPO” on page 917

Overview
The Control-M Application Program Interface (CTMAPI) is an open interface
between the application environment and Control-M. CTMAPI enables your
application program to interface with Control-M so that you can access services and
extract data from Control-M into your own programs.

CTMAPI is open to all application environments. It can be called from the following
programs or environments:

■ High Level Language or Assembler programs, running under various

environments, such as CICS, IMS, or the like

■ a batch job or step

■ REXX or CLIST

Appendix A The Control-M Application Program Interface (CTMAPI) 877

Environment and Allocations

However, not all functions of the API are applicable to all environments.

The API can call the CTMAPI module and pass it requests through either of the
following:

■ a function (command line) passed to CTMAPI, as

— a parameter from within a program

— a parameter using PARM=variable in a JCL Batch step
— an explicit command coded in a dedicated sequential file pointed to by the
DAAPI special DD statement. Note that only bytes 1 through 72 of the records
in DAAPI are processed.

COBOL examples:

To perform a job order (with FORCE), in the Working-Storage section code:

01 WS-CONTROLM-PARMS.
05 PARM-LENGTH PIC 9(4) COMP VALUE 80.
05 PARM-VALUE PIC X(80) VALUE
'ORDER DDNAME=ddname MEMBER=table-name JOB=job-name FORCE'.

In the Procedure division code:

CALL 'CTMAPI' USING WS-CONTROLM-PARMS.

IF RETURN-CODE IS GREATER THAN 0 THEN GO TO error-routine.

■ conversational mode (CTMBAPI mode), using an area mapped by CTMBAPI

DSECT. It passes the request from an application program to CTMAPI, and the
results are returned to the calling program

These methods, functions and conversational mode, are explained in more detail in
this appendix.

Environment and Allocations

CTMAPI is a callable Load module that resides in the IOA LOAD library. It is located
below the line (RMODE=24), works in 31 bit addressing mode (AMODE=31), and can
be called by programs running in any AMODE.

The following requirements must be satisfied before CTMAPI can be called:

■ The calling application must have access to the IOA LOAD library, either using
STEPLIB or using Linklist.

878 Control-M for z/OS User Guide

 Environment and Allocations

■ The standard IOA DD statement DAPARM must be allocated to the calling

address space before calling CTMAPI, and must correctly point to the IOA PARM
and IOA IOAENV libraries. This allocation is essential for the correct loading of
CTMPARM, IOAPARM and other required parameter members, and to provide
the ability to issue messages, dynamically allocate files, and so on.

In addition to the above allocations, each service requires specific data sets to be
allocated for successful execution of the service. For example, to successfully order
jobs to Control-M, the Active Jobs file (AJF) must be allocated.

CTMAPI relies on IOA dynamic allocation services to allocate the files appropriate to
the function, using an ALC member. This means that your program, REXX or batch
requires no knowledge of dynamic allocation.

For more information about IOA dynamic allocation and ALC members, see the
INCONTROL for z/OS Administrator Guide.

You can tailor CTMAPI to allocate the appropriate files in either of the following
ways:

■ Let the function itself dynamically allocate the default data sets based on the site
standard naming convention (using the default ALC member). Under each
function, you can find which ALC member is used to dynamically allocate the
necessary files. If you do not require any unusual allocations, this is the
recommended method.

■ If you want to use other allocations, you can prepare your own ALC member and
pass it to CTMAPI using the standard DAALOCIN DD statement pointing to your
own ALC member. If this method is chosen, it is recommended that you use the
default ALC member specified in the function as a basis for your own ALC
member.

If the caller is not allocated to DAALOCIN DD at the time CTMAPI is called, it is

assumed that the default allocations are to be performed. In this case, CTMAPI will
dynamically allocate files using the default ALC member.

If CTMAPI is called under the IOA environment, none of the above is applicable. It is
assumed that all the necessary files are already correctly allocated, so no dynamic
allocation is performed by CTMAPI.

Appendix A The Control-M Application Program Interface (CTMAPI) 879

Functions

Functions
CTMAPI supports various types of services, but not all of them are supported under
all environments. Some of the functions can be executed using existing IOA or
Control-M utilities. For example, CTMJOB can be used to order jobs. Other functions,
such as the Status request or the Action request, cannot be processed by means of any
existing program or utility.

Future enhancements will be provided first to the API rather than to the appropriate
utility. BMC Software therefore recommends that you use CTMAPI for all requests,
even functions that are supported using other utilities.

The following CTMAPI functions are available:

■ order or force existing jobs into Control-M

This function can currently also be performed using CTMJOB.

■ create and/or order or force a new table into Control-M

This function can currently also be performed using CTMBLT.

■ perform AJF actions equivalent to the following options of the Active Environment
screen (Screen 3):

— Hold
— Free
— Delete
— Undelete
— Confirm
— Rerun
— Restart
— React
— Force OK
— Kill

■ search and query the status and other details of jobs in Control-M

■ resolve, set, and checkpoint variables in the IOA Variables Database

■ control which jobs in the Active Jobs File are to be excluded from download to
Control-M/EM

These functions are described in greater detail in this appendix. Differences in calling
the service from different environments are also discussed.

880 Control-M for z/OS User Guide

 1. Order or Force Existing Jobs

IOAAPI, which is described in the INCONTROL for z/OS Administrator Guide, can be
used to perform the following functions:

■ CHECK, ADD, or DELETE conditions

■ send e-mail messages
■ extract records from the IOA Log file

1. Order or Force Existing Jobs

The Order function can be used to order or force an existing table, or selected jobs
from an existing table, to Control-M.

This service can be called from any environment, with few differences between
environments. The syntax for this service is as follows:

ORDER {DSN=schedlib|[DDNAME|DD]=dd} {MEMBER|MEM=table}

[GROUP=group|TBL=group] [JOB=jobnm] [ODATE|DATE=date] [ODATEOPT=VAL|RUN]
[FORCE] [INTOTBL=table_rba [DUP|NODUP]] [WTO=N|Y] [SETVAR=%%xxx=yyyy]
[SELRBC=rbc]… [IGNRBC=rbc]… [IF if_statement]…

NOTE
In this syntax, NODUP is the default in the expression INTOTBL=table_rba [DUP|NODUP].

Any number of SETVAR statements can be specified in one ORDER statement. The %% string
is mandatory. The equal sign between the SETVAR name and the SETVAR value must be
contiguous.

For a full description of each parameter, see the description of the CTMJOB utility in
the INCONTROL for z/OS Utilities Guide. The only change from the utility is the
syntax of the Ignore or Select RBCs and the SETVAR statements. In CTMJOB, the
Ignore and Select RBCs are coded separately from the Order statement. Under
CTMAPI, they should be coded as part of the Order statement, substituting SELRBC
for the keyword SELECT and IGNRBC for the keyword IGNORE. The SETVAR
statement can only be specified via CTMAPI. Any job scheduling definition ordered
as a result of the Order statement is treated as if it contains the SETVAR statement.

The selection_criteria and if_statement parts of the command are described under
“Conditional Requests and Selection Criteria” on page 894.

Specifying WTO=N causes suppression of writing messages to the console.

Appendix A The Control-M Application Program Interface (CTMAPI) 881

Order or Force under Batch, REXX or CLIST

Order or Force under Batch, REXX or CLIST

When called from a batch job or step or from a REXX or CLIST, the Order statement is
specified as one of the following:

■ a statement in the format

EXEC CTMAPI PARM=‘ORDER variable’

■ in a sequential file pointed to by the DAAPI DD statement

In this type of call, the SYSPRINT DD statement must be pre-allocated to the step,
and the output of CTMAPI written to this file.

A return code is returned in register R15. For a full list of valid return codes, see
“Order or Force Return Codes” on page 883.

Order or Force Using Program

When called from a program, the simplest method of requesting a job order is to pass
the Order statement to CTMAPI as a standard parameter. Alternatively, you can use
the conversational mode of interface, where the CTMBAPI area is passed as the
parameter, and fields in it identify the request. This mode, which is described in
“Conversational Mode using Program” on page 898, is most useful when the calling
program requires a reply to be returned to it, for example, to keep track of the Order
ID of ordered jobs.

The following statement is an example of the standard method of executing CTMAPI

in batch job and passing it an Order request:

//DAAPI DD *
ORDER DSN=CTM.PROD.SCHEDULE MEM=DEFSCHD1 JOB=JOBA ODATE=ODATE

Order or Force Allocations

The default ALC member used by the Order service is ALCMJOBP, which allocates
the AJF, calendars, Control-M Statistics file and the UNITDEF member. If you choose
to prepare your own ALC member, you must allocate at least all the above files.

The DATEREC file is ignored when you use CTMAPI to order jobs.

882 Control-M for z/OS User Guide

 Order or Force Return Codes

Order or Force Return Codes

Table 268 shows the return codes that can be returned to the caller (in register R15).

Table 268 Order or Force Return Codes

Return Code Explanation
0 The operation was successfully performed.
4 At least one job was not ordered, due to one of the following:

■ missing calendar
■ a problem was encountered in the table
■ a PREV or NEXT date condition was missing
■ CTMX001 cancelled the order
8 An error occurred, and the order stopped while being processed.
12 Syntax error in the command.
16 or more Severe error in CTMAPI. The order stopped while being processed.

Order or Force Performance Considerations

There are no specific performance considerations with regard to the Order itself.
However, using an IF statement can affect the overall performance. For information
regarding the impact of an IF statement on performance, see “Performance
Considerations for Selection Criteria” on page 896.

Order or Force Security Considerations

The exit called during the Order process is CTMSE01. The files that are accessed, and
the type of access, are summarized in Table 269.

Table 269 Files Accessed during the Order or Force Process

File Name Type of Access
Active Jobs File Read and Write
Calendar Read
Statistics File Read
Unit Definition Read

Appendix A The Control-M Application Program Interface (CTMAPI) 883

2. Create, Order, or Force New Tables

2. Create, Order, or Force New Tables

CTMAPI enables the user to create tables, then order or force those tables. You can
order or force a table to the Active Jobs File (AJF) even if that table is not in a
scheduling library.

This service is similar to that provided by the CTMBLT utility. It is activated by

means of appropriate CTMBLT input control statements.

Invoking Create, Order or Force New Tables Using Program

The CTMBLT control statements can be specified in a sequential file pointed to by the
DAAPI DD statement, or in an in-core table containing the control statements as 80-
byte card images. The first control statement must be the character string 'BLT',
beginning in column 1, to indicate that the statements that follow are input for
CTMBLT. The rest of the control statements must conform to the usual CTMBLT
syntax.

For a full description of the CTMBLT parameters and how to specify whether the
tables should be optionally ordered or forced, see the description of the CTMBLT
utility in the INCONTROL for z/OS Utilities Guide.

The SYSPRINT DD statement must be pre-allocated to the step. The output of

CTMAPI is written to this file. A return code is returned in register R15. A full list of
valid return codes is provided in “Order or Force Return Codes” on page 883. When
M is specified in the CTMBLT control parameter OPTION, appropriate messages
(BLT89AI) are issued to the job log for each table that is created.

Create, Order or Force Allocations

The default ALC member used by the CTMBLT service is ALCMBLT. This allocates
the Control-M AJF, IOA LOG, IOA calendars, Control-M Statistics file, and UNITDEF
member. These files are required only if the user requests the ordering or forcing of
the tables that are built.

884 Control-M for z/OS User Guide

 Create, Order or Force Return Codes

Create, Order or Force Return Codes

Table 270 shows the return codes that can be returned to the caller (in register R15).

Table 270 Create and/or Order or Force New Tables Return Codes
Return Code Explanation
0 The operation was successfully performed.
8 An error occurred. The table was not built, or not ordered.
12 Syntax error in the command.
16 or more Severe error in CTMAPI.

Create, Order or Force Performance Considerations

There are no specific performance considerations with regard to CTMBLT itself.

Create, Order or Force Security Considerations

When using the CTMBLT service to create, order, or force a new table, the security
considerations are the same as those described in “Order or Force Security
Considerations” on page 883.

Table 271 shows the files that are accessed when Order or Force is requested, and the
type of access.

Table 271 Files Accessed during the Create, Order or Force Process
File Name Type of Access
Active Jobs File Read and Write
Calendar File Read
Statistics File Read
Unit Definition File Read

Appendix A The Control-M Application Program Interface (CTMAPI) 885

3. AJF Actions

3. AJF Actions
Using this type of call to CTMAPI, various actions can be performed against jobs
residing in the Active Jobs file (AJF). This service can be called from any environment,
with few differences between environments. The full syntax for this service is as
follows:

AJF{HOLD|FREE|DELETE|UNDELETE|CONFIRM|RERUN|REACT|FORCEOK|KILL}
{selection_criteria} [selection_criteria]…
[IF if_statement]

The selection_criteria and if_statement parts of the command are described in

“Conditional Requests and Selection Criteria” on page 894, and the selection criteria
are detailed in Table 276 on page 895.

AJF Action under Batch, REXX or CLIST

When called from a batch job or step or from a REXX or CLIST, the AJF statement is
specified as one of the following:

■ a statement in the format

EXEC CTMAPI PARM=‘AJF variable’

■ in a sequential file pointed to by a DAAPI DD statement

In this type of call, only a return code is returned in register R15. A full list of valid
return codes is provided in “AJF Action Return Codes” on page 887.

If multiple commands are entered in a DAAPI DD statement, the final return code is
the highest return code from any of the commands.

AJF Action using Program

When called from a program, the simplest method of requesting the appropriate
action against a job is to pass the above statement to CTMAPI as a standard
parameter. Alternatively, you can use the conversational mode of the interface, where
CTMBAPI area is passed as the parameter, and fields in it identify the request. This
mode is described in “Conversational Mode using Program” on page 898.

886 Control-M for z/OS User Guide

 AJF Action Allocations

The following statement is an example of the standard method of executing CTMAPI

in batch job and passing it a HOLD request:

//DAAPI DD *
AJF HOLD MEM=DEFSCHD1 JOB=JOBA OID=0AS45 ODATE=090601 IF STATE=FREE

NOTE
The HOLD command for the job is issued only if its prior STATE was FREE.

AJF Action Allocations

The default ALC member used by the AJF Action service is ALCMAJF, which
dynamically allocates the AJF only. If you choose to prepare your own ALC member,
you must ensure that you allocate at least the above file.

AJF Action Return Codes

Table 272 shows the return codes that can be returned to the caller (in register R15).

Table 272 AJF Action Return Codes

Return Code Explanation
0 The operation was successfully performed.
4 The operation was not performed. The selection criteria or IF statement
were not matched.
8 The operation could not be performed.
12 Syntax error in the command.
16 or higher Severe error in CTMAPI.

AJF Action Performance Considerations

There are no specific performance considerations with regard to the Action itself.
However, the Selection Criteria or IF statement can significantly affect the overall
performance. For information regarding the impact of Selection Criteria and/or IF
statements on performance, see “Performance Considerations for Selection Criteria”
on page 896.

Appendix A The Control-M Application Program Interface (CTMAPI) 887

AJF Action Security Considerations

AJF Action Security Considerations

The exit that is called during execution of the action is CTMSE08.

Table 273 shows the files that are accessed, and the type of access.

Table 273 Files Accessed during the AJF Action Process

File Name Type of Access
Active Jobs File Read and write.

4. Search
The Search function can be used to check the existence of a job in the AJF. It can be
called from any environment. However, the AJF entry of the job can only be returned
to the caller by using the CTMBAPI mode. Under all other environments, only the
return code is returned to the caller, indicating whether or not the job exists in the
AJF.

This function should only be used when you want to execute your own process based
on the result of this search. If you want to execute one of the other CTMAPI functions
based on the Search result, it is recommended that you use the conditional form of
that function instead.

The full syntax for the Search call is as follows:

SEARCH selection_criteria [selection_criteria]…

The various valid selection_criteria are described in “Conditional Requests and

Selection Criteria” on page 894 and Table 276 on page 895.

Search under Batch, REXX or CLIST

When called from a batch job or step or from a REXX or CLIST, the Order statement is
specified as one of the following:

■ a statement in the format

EXEC CTMAPI PARM=‘SEARCH variable’

■ in a sequential file pointed to by DD statement DAAPI

888 Control-M for z/OS User Guide

 Invoking Search from a Program

In this type of call, only a return code is returned in register R15. A full list of valid
return codes is provided below.

If multiple commands are entered in DAAPI, the final return code is the highest
return code from any of the specified commands.

Invoking Search from a Program

When called from a program, the simplest method of searching for a job is to pass the
Search call statement to CTMAPI as a standard parameter. Alternatively, you can use
the conversational mode of the interface, where the CTMBAPI area is passed as the
parameter, and fields in it identify the requested job. This mode is described in
“Conversational Mode using Program” on page 898. As mentioned earlier, the
advantage of using the CTMBAPI mode is that your program gets back from
CTMAPI the entry of the job, mapped by CTMBJSE DSECT, as described in “The
Status Reply DSECT (CTMBJSE)” on page 905.

The following statement is an example of the standard method of executing CTMAPI

in batch job and passing it a SEARCH request:

//DAAPI DD *
SEARCH MEM=DEFSCHD1 JOB=JOBA OID=0AS45 ODATE=090601

Search Allocations
The default ALC member used by the Search service is ALCMAJF, which
dynamically allocates the AJF only. If you choose to prepare your own ALC member,
you must ensure that you allocate at least the above file.

Search Return Codes

Table 274 shows the return codes that can be returned to the caller (in register R15).

Table 274 Search Action Return Codes (part 1 of 2)

Return Code Explanation
0 The job exists.
4 The job was not found.
8 The operation could not be performed.

Appendix A The Control-M Application Program Interface (CTMAPI) 889

Search Performance Considerations

Table 274 Search Action Return Codes (part 2 of 2)

Return Code Explanation
12 Syntax error in the command.
16 and higher Severe error in CTMAPI.

Search Performance Considerations

There are no specific performance considerations with regard to the Search itself.
However, the Selection Criteria can significantly affect the overall performance. For
information regarding the impact of Selection Criteria on performance, see
“Performance Considerations for Selection Criteria” on page 896.

Search Security Considerations

This function does not call any security exit during the Search process.

Table 274 shows the files that are accessed, and the type of access.

Table 275 Files Accessed during the AJF Action Process

File Name Type of Access
Active Jobs File Read

5. Global Variables
You can use CTMAPI to Set and Checkpoint variables in the IOA Variable Database.

■ The SET command readies the global variables to be written to the IOA Variable
Database, but does not actually write them there.

■ The CKP (CHECKPOINT) command writes all variables which have been SET to
the IOA Global Database.

■ The SETCKP command combines the action of both the SET and the CKP
commands.

When readying many variables to be written, for performance reasons it is

recommended that they first be SET, and only afterwards should the CKP command
be issued. When only a single variable is to updated, the SETCKP command may be
issued, instead of issuing the SET followed by the CKP command.

890 Control-M for z/OS User Guide

 Global Variables under Batch REXX or CLIST

The resolve option is available only when CTMAPI is called in Conversation mode.

The full syntax for this CTMAPI service is

GLOBAL {SET | SETCKP | CHECKPOINT | CKP}

{PRODUCT=x APPL=xxx GROUP=xxx MEMBER=xxx VAR=%%\xxx VALUE=xxx}

NOTE
Separate the parameters in GLOBAL commands with blanks, not commas.

If the action to be performed is SET or SETCKP, the name of the variable must be
supplied. The keyword parameters are used to define the variable name.

For more information on the actions and components of the variable name, see the
IOA administration chapter in the INCONTROL for z/OS Administrator Guide.

Global Variables under Batch REXX or CLIST

If you are calling this function from a batch job, REXX, or CLIST, the GLOBAL
statement can be specified in one of the following:

■ a statement with the following syntax

EXEC CTMAPI PARM='GLOBAL action | varname'

where:

— action has one of the following values:

■ SET
■ SETCKP
■ CHECKPOINT
■ CKP

— varname is the name of a global variable

■ a sequential file pointed to by the DAAPI DD statement

If you use a DAAPI file, you can insert multiple commands.

Appendix A The Control-M Application Program Interface (CTMAPI) 891

6. Conditions and Resources

6. Conditions and Resources

You can use CTMAPI to add, delete, change, or query for conditions or quantitative
and control resources. In this case, CTMAPI actually calls the IOACND utility. The
syntax is the same as the syntax for the IOACND utility, prefixed with the command
word COND or RES.

COND {ADD | DELETE | CHECK} COND cond-name ODATE

RES {ADD | DELETE} CONTROL control-name {EXCLUSIVE | SHARE}
RES ADD RESOURCE res-name quantity
RES DELETE RESOURCE res-name
RES CHANGE RESOURCE res-name [-|+]quantity

For more information on the syntax of the IOACND utility and its characteristics, see
the IOACND section in the INCONTROL for z/OS Utilities Guide.

7. CTMAS Active Job Download Filtering

You can use the CTMAPI EMDOWNLD service to control which job in the Active Job
File will be downloaded to Control-M/EM during download processing of the
Control-M Application Server (CTMAS).

■ The EXCLUDE command excludes the job(s) specified from being downloaded to
Control-M/EM

■ The ACCEPT command indicates to CTMAPI to no longer exclude the job(s)

specified from being downloaded to Control-M/EM

The full syntax for this service is as follows:

EMDOWNLD{EXCLUDE|ACCEPT}
{selection_criteria} [selection_criteria]…
[IF if_statement]

The selection_criteria and if_statement parts of the command are described in

“Conditional Requests and Selection Criteria” on page 894. The selection criteria are
detailed in Table 276 on page 895.

NOTE
If the EXCLUDE or ACCEPT action is requested for a SMART Table Entity, the action will be
performed on all jobs belonging to the SMART Table.

The EMDOWNLD service also includes the following specific syntax commands:

892 Control-M for z/OS User Guide

 EMDOWNLD Action under Batch, REXX or CLIST

■ EXCLUDE LIST – List all jobs currently excluded from download to

Control-M/EM

■ ACCEPT ALL – Include all currently excluded jobs in the next download to
Control-M/EM

EMDOWNLD Action under Batch, REXX or CLIST

The EMDOWNLD service can be called from a batch job or step or from a REXX or
CLIST, in one of the following ways:

■ a statement in the format

EXEC CTMAPI PARM=‘EMDOWNLD variable’

■ in a sequential file pointed to by DD statement DAAPI

In this type of call, only a return code is returned in register R15. A full list of valid
return codes is provided in “AJF Action Return Codes” on page 887.

If multiple commands are entered in DAAPI, the final return code is the highest
return code from any of the specified commands.

EMDOWNLD Action Allocations

For information on EMDOWNLD action allocations, see “AJF Action Allocations” on
page 887.

EMDOWNLD Action Return Codes

For information on EMDOWNLD action return codes, see “AJF Action Return
Codes” on page 887.

EMDOWNLD Action Performance Considerations

For information on EMDOWNLD action performance considerations, see “AJF
Action Performance Considerations” on page 887.

Appendix A The Control-M Application Program Interface (CTMAPI) 893

EMDOWNLD Action Security Considerations

EMDOWNLD Action Security Considerations

For information on EMDOWNLD action performance considerations, see “AJF
Action Performance Considerations” on page 887.

Examples

Example 1
Prevent download of job: Orderid 000DB

//S1 EXEC PGM=CTMAPI,PARM='EMDOWNLD EXCLUDE OID=000DB’

Example 2
Allow download of job: Member name BR14

//S1 EXEC PGM=CTMAPI,PARM='EMDOWNLD ACCEPT MEMBER=BR14’

Example 3
List all jobs currently excluded from download to Control-M/EM

//S1 EXEC PGM=CTMAPI,PARM='EMDOWNLD EXCLUDE LIST’

Conditional Requests and Selection Criteria

Many services can be conditionally executed based on various terms and conditions.
This topic describes in more detail the various criteria that can be used.

Poor usage of selection criteria can dramatically impact the overall performance.
Before using such selection criteria, read “Performance Considerations for Selection
Criteria” on page 896.

Character fields marked with an * (Asterisk) to the right of the field are used as a
prefix for the specified selection criteria. No masking is allowed in any other field.

For example, if you specify MEM=ABC*, all jobs with the MEMNAME prefix "ABC"
will be selected.

894 Control-M for z/OS User Guide

 Conditional Requests and Selection Criteria

The full syntax for the selection criteria is as follows:

IF {[MEM=memname*] | [GROUP|TBL=group_name*] |
[JOB=job_name*] | [JOBID=jes_job_number]
[OWNER=owner*] | [OID=orderid] | [ODATE={ODAT|date}] |
[STATUS={WAIT_SCH
WAIT_CONF
WAIT_PIPE
WAIT_ORD
EXEC_ERR
EXEC_WSUB
EXEC_INQ
EXEC_NJE
END_OK
END_OK_FOK
END_NOK_ABND
END_NOK_JCLE
END_NOK_UNKW
END_NOK_CC
END_NOK_NSUB
END_NOK_DISA
EXIST
NOTEXIST
NOT_DELETED
DEL} ]
| [STATE={HOLD|FREE}]}
[{AND|OR} selection2 }]...

Table 276 shows the meanings of the parameters in that statement.

Table 276 Selection Criteria Parameters

Parameter Description
MEM Member name of the job
GROUP (or TBL) Group name of the job
JOB Job name of the job (valid only after the job was submitted)
JOBID JES job number (valid only after the job was submitted)
OWNER Owner of the job
OID The Control-M Order ID of the job
ODATE The ODATE of the job. Valid values are:
■ ODATE – The current Control-M ODATE
■ DATE - Same as ODATE
■ date – The full date, in the format YYMMDD, MMDDYY, or
DDMMYY, depending on your site format
STATUS For an explanation of these statuses, see Table 282 on page 905.
STATE Whether the job is held or free. Valid values are:
■ HOLD – The job is held.
■ FREE – The job is free.

selection2 Any of the above parameters.

Appendix A The Control-M Application Program Interface (CTMAPI) 895

Performance Considerations for Selection Criteria

Multiple IF statements can be specified, connected to each other using regular

Boolean logic, including expressions inside parentheses.

Performance Considerations for Selection Criteria

The overall performance of each call to CTMAPI is largely dependent on the selection
criteria. These must be carefully considered.

An important factor affecting overall performance is the uniqueness of the selection

criteria. If very few jobs in the Active Jobs file conform to your selection criteria, then
very few job records will have to be handled. For example, if you search for a specific
Order ID, the result will be the reading of only a few index records and only one job
record. On the other hand, if you search for all jobs with a member name starting with
ABC, the API must read many job records as well as the index records.

You can greatly improve overall performance by using indexed fields in the selection
criteria. This results in a faster and more efficient search. The use of non-indexed
fields causes a sequential search through the Active Jobs file, which is very slow and
inefficient.

Table 277 shows the attributes of each selection criteria parameter.

Table 277 Selection Criteria Parameter Attributes

Parameter Indexed Unique Notes
MEM Yes No
GROUP Yes No
JOB Yes No Valid only after job submission
JOBID No No Valid only after job submission
OWNER Yes No
OID Yes Yes
ODATE No No
STATUS Yes No EXIST and NONEXIST statuses are not
indexed.
STATE Yes No

As Table 277 shows, OID is the best choice for selection criteria, since it is both
indexed and unique. On the other hand, ODATE and JOBID are the worst choices for
selection criteria, since they are neither indexed nor unique. If you must use one of
the non-indexed search criteria, BMC Software recommends using it in a combination
with other indexed criteria.

896 Control-M for z/OS User Guide

 Search Security Considerations

Another factor affecting overall performance is the complexity of any AND or OR

statements that qualify the selection criteria. Statements included in an AND or OR
section of the selection criteria are each handled separately, one by one, as if each is a
fully qualified selection criteria, and the whole Boolean sentence is verified only after
each such statement is checked.

Search Security Considerations

This function does not call any security exit during the Search process.

Table 278 shows the files that are accessed, and the type of access.

Table 278 Files Accessed during the AJF Action Process

File Name Type of Access
Active Jobs File Read

Return Codes
CTMAPI return codes are returned in register R15. They are also returned in the
following fields:

■ BAPIRC
■ BAPIRSN
■ BAPIURC

The following are the types of failure of CTMAPI:

■ CTMAPI itself encountered a problem that prevented it from calling a service.

In this case

— register R15 has a value higher than 8

— the reason code is returned in the BAPIRSN field

■ The service was activated, but failed to perform the desired action.

In this case

— register R15 has a value of 8

— the return code from the service is returned in the BAPIURC field

Appendix A The Control-M Application Program Interface (CTMAPI) 897

Conversational Mode using Program

Conversational Mode using Program

This type of call is intended for use by programs. It enables the program to pass
requests, accept replies, respond on the basis of the reply, and maintain
communication between the program and the API.

The basic communication area, which is passed back and forth between the calling
program and the API, is mapped by the Assembler DSECT CTMBAPI, which can be
found in the IOA MAC library. Different fields in this DSECT identify the request,
specify the selection criteria, and pass the address of the area in which replies to the
caller are to be returned.

Input and Output Registers

On input to any CTMAPI service, the contents of the general-purpose registers
should be as shown in Table 279.

Table 279 Contents of Registers on Input to CTMAPI

Register Contents
R0 Irrelevant
R1 Address of parameter list, where the first (and only) parameter has
its high-order bit turned on (the VL parameter of the CALL macro).
This parameter points to a 2-byte field containing the length of the
CTMAPI DSECT. The 2-byte length field must be followed by the
double word aligned CTMAPI DSECT.
R2 through R12 Irrelevant
R13 SAVE AREA address of caller
R14 Return address
R15 CTMAPI entry point address

On return, all registers are restored by CTMAPI, and a return code is returned in
register R15. In this appendix, the return codes and their meanings are explained
under each service.

898 Control-M for z/OS User Guide

 Example – Invoking CTMAPI in BAPI mode

Example – Invoking CTMAPI in BAPI mode

The following example may be used to invoke CTMAPI in BAPI mode:

LOAD EP=CTMAPI
LR R15,R0
OI BAPIADR,X'80'
LA R1,BAPIADR POINT TO BAPI AREA ADDRESS
BALR R14,R15 CALL CTMAPI
....
BAPIADR DC A(BAPIDSLN) BAPI DSECT + HALFW LEN
DS 0D DOUBLEWORD ALIGNMENT
DS CL6 6 BYTE FILLER
BAPIDSLN DC Y(BAPILEN) HALFWORD LENGTH FROM CTMBAPI DSECT
CTMBAPI DSECT=NO

CTMBAPI DSECT
This section describes in more detail

■ how to use the CTMBAPI DSECT

■ what fields the caller should set
■ what fields are used to return the result

The explanation assumes the use of Assembler language. However, you can use other
high level languages to implement most of the services, provided the language you
use conforms to the standard calling conventions in Table 279.

The type of service is identified in one or both of the following ways

■ as a command within a buffer

The start address of the buffer is passed to the API using the BAPICMDA field. The
command length is passed using the BAPICMDL field.

■ using the BAPICMD field, which identifies the type of service

If both are specified, the command takes precedence.

CTMBAPI is composed of

■ a fixed part
This is used to identify the requested service, together with other necessary fields.

■ a variable (extension) part

This is in variable format, where each service uses a different extension.

Appendix A The Control-M Application Program Interface (CTMAPI) 899

CTMBAPI DSECT

For each service, the format of each extension is documented in the following sections
of this appendix, for example in “Status Extension” on page 903, “Order Extension”
on page 907,“AJF Action Extension” on page 910, and so on.

The fields in the fixed (header) part are summarized in Table 280. The values in the
columns in Table 280 have the following significance:

■ In the column headed “Optional or Mandatory”

— M means mandatory
— O means Optional

■ In the column headed “In or Out”

— I means Input
— O means Output

■ In the column headed “Type”

— CLnn means a character field nn characters in length, padded with blanks to the
right.
If omitted, it must be set to blanks.

— an * (Asterisk) to the right of the CLnn entry means that the characters in the
field are used as a prefix for the specified selection criteria.
For example, if you specify MEMNAME ABC*, all jobs with a MEMNAME
prefix of "ABC" will be selected.

— A means Address, a 4-byte fullword field pointing to an area.

If omitted, it must be set to binary zero.

— F means Fullword, a 4-byte fullword field containing a binary number.

If omitted, it must be set to binary zero.

— H means Halfword, a 2-byte halfword field containing a binary number.

If omitted, it must be set to binary zero.

— Flag means a Flag Byte, where each bit has a separate significance.

Table 280 Fixed Part Values (part 1 of 3)

Optional or In or
Field Name Mandatory Out Type Usage
BAPICMD O I CL1 One byte identifier of the requested
service
Note: If the BAPICMDA field is set
to a value other than zero, it takes
precedence over the BAPICMD field.

900 Control-M for z/OS User Guide

 CTMBAPI DSECT

Table 280 Fixed Part Values (part 2 of 3)

Optional or In or
Field Name Mandatory Out Type Usage
BAPICMDA O I A Address of command buffer. The
command syntax should be identical
with the syntax of the individual
CTMAPI functions described in this
appendix. If set to zero, the
requested service must be specified
in the BAPICMD field.
BAPICMDL O I F Length of the command in the
command buffer. Ignored if the
value in BAPICMDA is zero.
BAPIFLG1 O I Flag General purpose flag.

BAPIF1CN (X’80’) – Do not release

the working area on return.

Applicable for programs that call the

API several times. It is the
responsibility of the caller to call the
API with the function BAPI_TERM
to allow the API to free storage, close
files, and so on. Failure to do so may
cause unpredictable results, such as
storage accumulation.
BAPIMCT M I or O A Address of IOA MCT used by the
API. The caller must set this field to
zero on the first call, and leave it
untouched between multiple calls.
BAPIRC Not applicable O H Return code returned to the caller.
Identical with register R15.
BAPIRPL# O O F Number of reply slots returned by
the API. The size of each slot
depends on the service requested.
BAPIRPLC O O F Address of the first free byte in the
reply area. Serves to indicate the end
of that area.

Appendix A The Control-M Application Program Interface (CTMAPI) 901

CTMBAPI DSECT

Table 280 Fixed Part Values (part 3 of 3)

Optional or In or
Field Name Mandatory Out Type Usage
BAPIRPLE O I A End address of the reply buffer.

If BAPIRPLS (in this Table) is set to

zero, this field is ignored.

This field informs API of the size of

the reply buffer. In some services,
such as STATUS, if the reply buffer
space is exhausted, a special return
code indicating this is returned to the
caller. The caller can then again call
the API to obtain the rest of the
reply.
BAPIRPLS O I A Start address of the reply buffer.
■ If set to zero, no reply is
returned.
■ If set to a value other than zero,
the API returns its replies into
this buffer.

The reply that the API can return is

explained in relation to each service.
BAPIRSN Not applicable O H Reason code returned to the caller.

Valid reason codes are documented

internally in the CTMBAPI macro.
BAPISIGN M I CL4 DSECT eye-catcher ‘BAPI’
BAPIURC Not applicable O H Return code returned to CTMAPI
from the invoked utility if that utility
failed. This return code is set only if
CTMAPI ended with return code 8.
Otherwise, the CTMAPI return code
itself identifies the problem.
BAPIVERS M I CL1 DSECT Version. The current version
is 1.
BAPIWORK M I or O A Address of the API work area. This
field is used by the API to hold
information between calls when
more replies must be returned. The
caller must set this field to zero and
leave it untouched between multiple
calls.

902 Control-M for z/OS User Guide

 Status Extension

Status Extension
The value of 2 (BAPI_M_STATUS) should be set in the BAPICMD field for the Status
function.

The Status function can be used to retrieve information about jobs in the Active Jobs
file. This service can be called from any environment, but only by using the
CTMBAPI mode, that is, using a program, and not by means of a batch statement,
REXX or CLIST.

On return, the status of and other information about the job is returned to the caller.

If you only requested one job, for example, Status using OID, the result is returned in
the Status extension itself. If more than one job may conform to the selection criteria,
for example, the status of MEMNAME ABC, a reply buffer must be supplied into
which the API can return a result for each and every job that conforms. If no such
buffer is supplied, no reply other than an appropriate return code is returned.

The Status extension fields are summarized in Table 281. If the caller filled in a field, it
is used as Search argument, and only jobs that conform to that field are returned. On
return from the API, if no reply area has been supplied, and if only one job conforms
to the selection criteria, the API will fill in all these fields with actual information
about this job. For example, if you specify ABC in BAPISMEM, and there is only one
job in the AJF with a matching MEMNAME, such as ABCXYZ, on return from the
API this field will hold the value ABCXYZ.

The values in the columns in Table 281 have the same significance as those in
Table 280.

Table 281 Status Extension Fields (part 1 of 2)

In or
Field Name Optional Out Type Usage
BAPISGRN O I or O CL20* Group name.
BAPISHLD O I or O CL1 Hold state. Valid values are:

■ H (Hold)

■ F (Free)
BAPISJID O I or O CL5 JES job ID (job number).
BAPISJNM O I or O CL8* Job name. Valid only after job
submission.
BAPISLIB O I or O CL44* Scheduling library from which the job
was ordered.
BAPISMEM O I or O CL8* MEMNAME.
BAPISODT O I or O CL6 ODATE of the job. This must be fully
specified. Prefixing is not supported.

Appendix A The Control-M Application Program Interface (CTMAPI) 903

Status Extension

Table 281 Status Extension Fields (part 2 of 2)

In or
Field Name Optional Out Type Usage
BAPISOID O I or O CL5 Order ID. If a value is entered, it must
include all five characters of the Order
ID.

Prefixing is not supported.

BAPISOWN O I or O CL8* Owner of the job.
BAPISRBA Not O CL6 RBA of the job, in hexadecimal
applicable format.
BAPISRBB Not O CL3 RBA of the job, in binary format.
applicable
BAPISRNM Not O H Run number of the job.
applicable
BAPISSTT O I or O CL15* Status of job. For a list of valid values,
see Table 282 on page 905.

The masking character “*” can be

used in any status value which
includes an underscore character “_”.
However, the “*” must follow
immediately after the “_”.
BAPISTAB O I or O CL8* Table from which the job was
ordered.
BAPISRBC O I CL20 (Only for jobs that are part of a group)
The name of the rule-based calendar
that made the job eligible for
execution.
BAPISTYP O I or O CL3 Task type. Valid values are:
■ JOB
■ TBL
■ STC
■ CYC
■ EMR
■ CST
■ ECJ
■ EST
■ ECS
■ WRN

Except for TBL, each of these is

explained in “TASKTYPE: General
Job Parameter” on page 666. TBL is
explained in Table 54 on page 177.

904 Control-M for z/OS User Guide

 The Status Reply DSECT (CTMBJSE)

The Status Reply DSECT (CTMBJSE)

The DSECT that formats reply area entries is CTMBJSE. Each entry is 240 bytes long.
For REXX parsing, fields in this DSECT are separated by a blank.

You must always allocate an area of 12,000 bytes and code its address in the
BAPIRPLS field.

The search criteria can fit multiple jobs on the AJF, up to a maximum of 50 jobs. For
example, if you want to process 25 jobs, prepare an area of 12,000 bytes and code its
address in the BAPIRPLS field. After returning from the API, the area will contain the
details of the 25 jobs. Each job line is detailed in the CTMBJSE DSECT and contains
relevant information about the located job.

The number of lines is returned in the BAPIRPL# field. When this field points to the
maximum, 50, it is possible that there are more lines that can be returned. In that case,
the value of the Utility Return Code field BAPIURC will be 4, and the Reason Code
field BAPIRSN will have the value "BAPI_HAVE_MORE_LINES." In such a case, the
user program can set bit BAPISPF8 in byte BAPISF1 and call CTMAPI again. This call
will retrieve the next 50 lines of output that match the search criteria. When multiple
lines are returned, the lines are in the order from the end (the most recent job) to the
beginning. There is an option for the calling program to receive only one line of
output, by specifying as the value in the BAPISF1 flag byte either BAPIS1ST (first
line) or BAPISLST (last line).

Except for field JSESTAT, the meanings of the fields are as described (internally) in
the macro CTMBJSE, which is in the IOA MAC library. The JSESTAT field returns the
status of the job in the AJF. The CTMAPI status function does not return all the
statuses detailed in the Control-M for z/OS User Guide. A list of the statuses that can be
returned appears in Table 282.

Table 282 Statuses Returnable under the Status Function (part 1 of 2)

Status Description
DEL The job was deleted.
END_NOK_ABND The job ended NOTOK because of an abend.
END_NOK_CC The job ended NOTOK because of the Condition Code of the job.
END_NOK_DISA The job ended NOTOK. It disappeared.
END_NOK_JCLE The job ended NOTOK because of a JCL error.
END_NOK_NSUB The job ended NOTOK. It was not submitted by JES.
END_NOK_UNKW The job ended NOTOK for an unknown reason.
END_OK The job ended OK.
END_OK_FOK The job was ForcedOK.
EXEC Job is executing.
EXEC_ERR Relevant only to SMART Table Entities. Several of the jobs in the
group are still executing, but at least one of them has ended NOTOK.

Appendix A The Control-M Application Program Interface (CTMAPI) 905

Status Allocations

Table 282 Statuses Returnable under the Status Function (part 2 of 2)

Status Description
EXEC_INQ The job was submitted to JES, but is not yet processing.
EXEC_NJE The job is being executed at a remote NJE node.
EXEC_WSUB Wait submission. The job was selected, but it is still waiting for
Control-M to submit it to JES.
NOT_DELETED The job was not deleted.
WAIT_CONF Wait for confirmation.
WAIT_ORD The ordering of a group is not yet complete. The group is still in the
order process.
WAIT_PIPE Waiting for all members of the pipe to be ready for submission.
WAIT_SCH Wait Schedule.
EXIST The job exists on the Active Jobs file.
NOTEXIST The job does not exist on the Active Jobs file.

Status Allocations
The ALC member used by the Status service as the default is ALCMAJF, which
dynamically allocates the AJF only. If you choose to prepare your own ALC member,
you must ensure that you allocate at least the above file.

Status Return Codes

Table 283 shows the return codes that can be returned to the caller (in register R15).

Table 283 Status Return Codes

Return Code Explanation
0 The operation was completed OK.

If a reply buffer was supplied, but was exhausted, meaning that not
all the statuses could be returned into the supplied buffer, a special
reason code, 286, is returned in the BAPIRSN field to indicate that
there are more replies.
4 The job was not found.
8 The operation could not be performed.
12 Syntax error in the command.
16 and higher Severe error in CTMAPI.

906 Control-M for z/OS User Guide

 Status Performance Considerations

Status Performance Considerations

The Status function searches the AJF for the requested jobs. More than one job may
conform to the selection criteria specified in the CTMBAPI DSECT. In that case, a Job
Status Element (JSE) entry is returned to the caller for each job.

The Selection Criteria can significantly affect overall performance.

■ The more specific the request, the fewer the jobs that must be read and returned to
the caller. For example, if you request status information for all jobs starting with
the letter A, the function must read a large part of the AJF, degrading its
performance.

■ Pay special attention to whether your search criteria are indexed. If you ask for
status information about jobs with a selection criteria that is not indexed, for
example, from a specific ODATE, without any indexed selection criteria, the whole
AJF must probably be read.

The impact of Selection Criteria on overall performance is described in “Performance

Considerations for Selection Criteria” on page 896.

Status Security Considerations

This function does not call any security exit during the Status process.

The files that are accessed, and the type of access are summarized in the following
table:

Table 284 Files Accessed during the AJF Action Process

File Name Type of Access
Active Jobs File Read

Order Extension
The value that should be set in the BAPICMD field for this function is 1
(BAPI_M_ORDER).

You can use the Order function to order jobs to the AJF. You can call this function
from any environment, but only by using the CTMBAPI mode. The function uses the
usual Control-M order process to put the requested job on the AJF. The return code
will appear in the BAPIURC (Utility Return Code) field.

Appendix A The Control-M Application Program Interface (CTMAPI) 907

Order Extension

If CTMAPI fails to invoke the order process, register R15 will contain a value of 8 or
higher, and the reason code will appear in the BAPIRSN field.

You can request a detailed reply from the order process, using the following
procedure:

1 Prepare a memory area.

2 Pass the start address in the BAPIRPLS field.

3 Pass the address of the last byte of this area in the BAPIRPLE field.

After returning from the order process, the BAPIRPLC field will point to the last
byte replied. The BAPIRPL# field will contain the number of reply lines. For each
job processed by the order process, a reply line will be returned detailing the job
identifiers and the RC of the order for this specific job. This is in contrast to the
usual output lines of the order process that are issued only for jobs that have
actually been ordered. Details of the reply line are specified in the CTMBAPO
DSECT.

Table 285 contains a summary of the CTMBAPI Order input fields. You must
ensure that all fields whose type is CL are initialized with BLANKS, and those with
type X are initialized to binary zeros.

Table 285 Order Fields (part 1 of 2)

In or
Field Name Optional Out Type Usage
BAPIODSN N I CL44 Table DS name. Mutually exclusive
with BAPIODD.
BAPIOMEM N I CL8 Member name
BAPIODD O I CL8 Table DD name. Mutually exclusive
with BAPIODSN.
BAPIOJOB O I CL8 Job name. Enter ‘ ‘ (Blank) to order all
jobs in the table.
BAPIODAT O I CL6 ODATE. Default is the current Odate.
BAPIORBA O I CL6 RBA of the SMART Table Entity when
a Dynamic SMART Table Insert is
performed.

908 Control-M for z/OS User Guide

 Order Return Codes

Table 285 Order Fields (part 2 of 2)

In or
Field Name Optional Out Type Usage
BAPIOF1 O I XL1 Flags byte. Valid values are:
■ X’80’ – Force the table
■ X’40’ – Insert the job into a
SMART Table Entity that already
exists on the AJF
■ X’20’ – Allow duplicate jobs in the
group when dynamically
inserting a job into the group
■ From X’10’ through X’01’ – These
bits are reserved for internal use
BAPIRBC# O I XL2 Number of rule-based calendar
statements that follow this field.

This field is for users who want to

implement the IGNORE and/or
SELECT RBC logic that is discussed
on connection with the utility
CTMJOB in the Control-M chapter of
the INCONTROL for z/OS Utilities
Guide.

After this field, you should code the

matching number of BAPITGNM
statements that define the rule-based
calendars themselves.
BAPITGIN O I CL1 Ignore or Select indicator. Valid
values are:
■ I – Ignore
■ S – Select

BAPITGNM O I CL20 RBC name

Order Return Codes

Table 286 shows the return codes that can be returned to the caller (in register R15).

Table 286 Order Return Codes (part 1 of 2)

Return Code Explanation
0 Order completed OK. If a reply buffer is specified in the BAPIRPLS
field, a reply line is returned for each job.
4 Order completed OK, but the order process issued a warning. This
usually occurs when one of the specified calendars was not found.
8 The operation could not be performed. The Order process
encountered a severe error.

Appendix A The Control-M Application Program Interface (CTMAPI) 909

Order Reply

Table 286 Order Return Codes (part 2 of 2)

Return Code Explanation
12 Syntax error.
16 Severe error in CTMAPI, such as a failure to get memory or a failure
to open a file.

Order Reply
The conversational mode (BAPI) order process can return a reply line for each job
processed. The reply line is mapped by DSECT CTMBAPO, which is described in
more detail in “CTMBAPO” on page 917.

Order or Force Allocations

For full information, see “1. Order or Force Existing Jobs” on page 881.

Order or Force Security Consideration

For full information, see “1. Order or Force Existing Jobs” on page 881.

AJF Action Extension

The AJF Action function can be used to perform basic Active Environment screen
(Screen 3) actions upon jobs in the AJF. Using the BAPI interface, a user program is
able to perform actions such as holding, freeing, deleting jobs in the AJF in much the
same manner as the user can from Screen 3.

For this function, set the value in the BAPICMD field to 3 (BAPI_M_ACT).

The Action function can be called from any environment. The input contains the
following types of input:

■ to identify the job

■ to define the Action upon the job

These are described in the following sections.

910 Control-M for z/OS User Guide

 Identifying the Job

Identifying the Job

The first type of input identifies the job, using the field names in Table 287.

Table 287 AJF Action Parameters

In or
Field Name Optional Out Type Usage
BAPIAMEM O I CL8 Member name in table.
BAPIAJNM O I CL8 Job name, in JCL.
BAPIAOWN O I CL8 Owner ID of the job.
BAPIAJID O I CL5 JOBID as returned by JES.
BAPIAOID O I CL5 Control-M ORDERID.
BAPIAGRN O I CL20 Group name.
BAPIRBAN O I XL3 RBA in binary format.
BAPIRBAC O I CL6 RBA of the job in characters, with
each character representing a
hexadecimal digit.

CTMAPI uses this variable to find the job in the same way it does a search. For
information concerning performance and security, see “Create, Order or Force
Performance Considerations” on page 885.

Defining the Action

To define the Action, you must set a 1-byte field called BAPIAACT with one of the
values in Table 288

Table 288 AJF Action BAPIAACT Field Values

Value Explanation
BAPIAHLD Hold
BAPIAFRE Free
BAPIADEL Delete
BAPIAKIL Kill
BAPIAUND Undelete
BAPIARER Rerun
BAPIARCT React
BAPIAFOK Force OK
BAPIACON Confirm

Appendix A The Control-M Application Program Interface (CTMAPI) 911

Action Return Codes

Action Return Codes

The CTMAPI Action return code is returned in register R15. There are basically two
types of failure:

■ The CTMAPI program itself encountered a problem which prevented it from

calling the service. In this case

— register R15 has a value higher than 8

— the reason code is returned in the BAPIRSN field

■ The service was activated but failed to perform the desired action. In this case

— register R15 has a value of 8

— the return code from the service is returned in the BAPIURC field

Table 289 shows in more detail the return codes that can be returned to the caller (in
register R15).

Table 289 CTMAPI Action Return Codes

Return Code Explanation
0 The action was successfully performed.
8 The action was not successfully performed.

The field BAPIURC contains a return code indicating the fault.

12 Syntax error.
16 Severe error, such as failure to get memory, or failure to open a file.

Action AJF Allocations

For information on AJF Actions, see “3. AJF Actions” on page 886.

Action Security Considerations

For information on AJF Action security considerations, see “3. AJF Actions” on
page 886.

912 Control-M for z/OS User Guide

 Global Variable Extension

Global Variable Extension

The Global Variable Extension is used to resolve, set, or checkpoint variables in the
IOA Variable Database. For more information on this facility, see the IOA
administration chapter in the INCONTROL for z/OS Administrator Guide.

The value for this function in the BAPICMD field is 6. For more information on the
BAPICMD field, see “BAPICMD” on page 900.

Table 290 contains a summary of the CTMBAPI Global Variable Extension input
fields. You must ensure that all fields whose type is CL are initialized with BLANKS,
and those with type X are initialized to binary zeros.

Table 290 Global Variable Fields

Field Name Optional In or Out Type Usage
BAPIGOPT N I XL1 Option byte.

Valid values are:

■ X'00' – Resolve
Obtain the value of a variable
from the database.

■ X'80' – Set
Set the value of a variable
from the database.

■ X'40' – Checkpoint
Force all changed variables to
be written to the database.
BAPIGIOA O I CL8 QNAME

Default: MCTQNAME
BAPIGAPL O I CL20 Application name.

Default: NO_APPL
BAPIGTBL O I CL20 Group name.

Default: NO_GROUP
BAPIGMEM O I CL20 Member name.

Default: NO_MEM
BAPIGVAR N I CL256 Variable name.
BAPIGVAL N I/O CL256 Variable value.
BAPIGPRC O I CL1 INCONTROL product.

Default: 'M'

Appendix A The Control-M Application Program Interface (CTMAPI) 913

Global Variable Return Codes

Global Variable Return Codes

Table 291 shows in more detail the Global Variable return codes that can be returned
to the caller (in register R15).

Table 291 Global Variable Return Codes

Return Code Explanation
0 The action was successfully performed.
8 The action was not successfully performed.

The field BAPIURC contains a return code indicating the fault.

12 Syntax error.
16 Severe error, such as failure to get memory, or failure to open a file.

Quantitative Resource Extension

The Quantitative Resource Extension function is used to query the status of a
quantitative resource in the Control-M Resources file. It can be called from any
environment by means of the CTMBAPI mode.

Use BAPI_M_RES to set the value for this function in the BAPICMD field to 4.

Table 292 CTMAPI Quantitative Resource Fields

In or
Field Name Optional Out Type Usage
BAPIRESN N I CL20 Name of the resource. This serves as
the sole key to the search.
BAPIRESX O XL2 Maximum quantity defined for this
resource.
BAPIRESQ O XL2 Quantity currently held by jobs in the
AJF.
BAPIRESP O XL1 If the resource is reserved for a critical
path job, this field will contain the
priority of this job, which will be from
1 through 9.

914 Control-M for z/OS User Guide

 Quantitative Resource Return Codes

Quantitative Resource Return Codes

The result is returned directly to the BAPI DSECT as specified below.

Table 293 CTMAPI Quantitative Resource Return Codes

Return Code Explanation
0 The operation completed OK. The output fields in the BAPI DSECT
are updated.
4 The resource was not found in the file.
16 Severe error encountered, such as failure to get memory or error in
accessing the file.

Quantitative Resource Security Considerations

The security exit called is IOASE07.

Quantitative Resource Allocations

The files that are accessed, and the type of access, are summarized in Table 294.

Table 294 CTMAPI Quantitative Resource File Allocation

File Name Type of Access
RES Read

Create and/or Order or Force a Table (BLT)

The BLT function invokes the CTMBLT utility to create, save, and optionally order a
table on the fly.

Unlike the other functions implemented through BAPI extension, this feature does
not contain a separate extension where you define the input parameters. Instead

1 Set the BAPICMD field to the value BAPI_M_BLT.

2 Prepare the input to the API in memory as a regular CTMBLT input stream, as
described in the INCONTROL for z/OS Utilities Guide, pointed to by the
CTMCMDA field.

Appendix A The Control-M Application Program Interface (CTMAPI) 915

BLT Action Return Codes

3 Set the length of the input, in bytes, in the BAPICMDL field. Each control input
statement must be an 80-byte card image.

4 Set the reply fields.

When requesting reply fields in this function, through the BAPI interface, you
receive reply lines from both the CTMBLT function and CTMJOB. For more
information on the reply input and output fields, see “CTMBAPO” on page 917.

BLT Action Return Codes

Table 295 BLT Action Return Codes
Return Code Explanation
0 The action was successfully performed.
8 The utility did not perform the action.

The field BAPIURC contains a return code indicating the fault.

12 Syntax error.

BLT Reply
The conversational mode (BAPI) BLT function can return a reply line for

■ each Table that was saved

■ each job that was processed

The reply line is mapped by the CTMBAPO DSECT, which is described in more detail
in “CTMBAPO” on page 917.

BLT Security Considerations

When creating and saving tables, no IOA security exits are invoked to check the
authority of the user to access the table. If the table must also be ordered, CTMSE01
will be called to verify that the user has the authority to order the table.

916 Control-M for z/OS User Guide

 BLT Resource Allocations

BLT Resource Allocations

Table 296 shows the files that are accessed, and the type of access.

Table 296 CTMAPI Quantitative Resource File Allocation

File Name Type of Access
Active Jobs File Read and Write
Calendar File Read
Statistics File Read
Unit Definition File Read

Replies
The BAPI feature returns output to the customer in the following ways:

■ a return code

■ setting output fields in the BAPI DSECT

These fields were individually described in “CTMBAPI DSECT” on page 899.

■ an output buffer returned by the Status service and described by the CTMBJSE
DSECT

■ the replies returned by the Order and BLT functions, as described in “CTMBAPO”
on page 917

CTMBAPO
When in CTMBAPI mode, CTMAPI serves as an interface between a user program
and a Control-M service. Some CTMAPI services have been modified to enable them
to return lines of replies into customer-supplied memory to detail their activity.
Currently this facility can be provided by

■ the BLT process

■ the Order process

For example, if the proper instructions are given, the Order process will return a reply
line for each job which it processes. This contrasts with normal processing, where a
line of output is not written until a job is actually placed on the AJF or a severe error
has occurred. You can then act upon and/or process the reply lines.

Appendix A The Control-M Application Program Interface (CTMAPI) 917

Date Format Considerations

To use this facility, you must supply the API with the pointers required to trigger the
reply mechanism. These are supplied through the calling program. Table 297 shows
the pointers and the fields in which they are supplied.

Table 297 CTMAPI Reply Mechanism Trigger Pointers

Field Information Required
BAPIRPLS The starting address of the reply buffer.
BAPIRPLE The address of the last byte in the reply buffer.

When BAPI returns, the BAPIRPLC field will point to the last byte actually written to
the reply buffer, and the BAPIRPL# field will contain the number of lines put there.
The API ensures that the value in the BAPIRPLC field never exceeds that set by the
BAPIRPLE field. Each line added to the reply buffer will start with the current
BAPIRPLC and will update it. BMC Software recommends that this field be
initialized to zero. If this field is not zero, API treats the value as the starting address
of the next reply line. This can be used by an application to accumulate reply lines
across several invocations of CTMAPI.

Each line in the buffer is mapped by the CTMBAPO DSECT. Each line starts with a
half-word that contains its length (BAPOLEN), and another two bytes that identify
the service that produced the reply line (BAPOID). The identification of each reply
line is mandatory, since a called service can call other Control-M services which, in
turn, will place their reply lines in the buffer. By using the identification of each reply
line together with the contents of the BAPIRPLC field and the BAPIRPL# field, you
can code a routine to scan and filter reply lines.

Date Format Considerations

The format of all the date fields, both input and output, depends on your site
standard. It follows that when you prepare the input to CTMAPI, you must know
your site standard.

918 Control-M for z/OS User Guide

 Appendix

B
CONTROL-M for z/OS Unix System
B

Services (USS)
This Appendix discusses the implementation of CONTROL-M in the IBM OS/390 or
z/OS Unix Systems Services (USS) environment.

Implementation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919

OS/390-Oriented Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Unix Oriented Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Integrating SAP R/3 running on USS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
CONTROL-M Support for SAP in the USS Environment . . . . . . . . . . . . . . . . . . . 923

In this appendix, the term “MVS” includes MVS, S/390, OS/390, and z/OS.

Implementation Options
The use of USS with CONTROL-M for z/OS can be implemented in different ways,
depending on your system and the way in which you use it.

Choose one of the following implementation options:

■ Use MVS to run USS applications.

■ Have MVS support USS in the same manner as it supports other Unix platforms,
such as CONTROL-M/Enterprise Manager, CONTROL-M/Server, and
CONTROL-M/Agent.

■ Integrate the architecture of SAP R/3 running on USS with the MVS platform.

These options are discussed individually in this Appendix.

Appendix B CONTROL-M for z/OS Unix System Services (USS) 919

OS/390-Oriented Implementation

OS/390-Oriented Implementation
CONTROL-M for z/OS fully supports the USS environment without any need for
modifications.

CONTROL-M for z/OS manages all USS batch processes and integrates them with
batch activities on

■ the local MVS system

■ all other platforms across the network

For CONTROL-M to submit and control all USS executions, all that is required is the
definition of a single JCL member. This member contains a USS shell activation
program that is supported by the MVS operating system. AutoEdit variables are used
to define all elements of the USS task, such as the name of the script, the script
parameters, the job name and the script location. When CONTROL-M submits the
JCL, all the AutoEdit values are resolved and the JCL is submitted with its
corresponding values. The JCL then submits the appropriate script under USS.
CONTROL-M reads the return code of the script execution from the JCL sysout, and
proceeds accordingly.

A sample JCL member is shown in Figure 378.

Figure 378 JCL for USS Execution

//jobname JOB (account_info),REGION=5000K
//STEPNAME EXEC PGM=BPXBATCH
// PARM='sh /u/usr_id/%%MYSCRPT'
//STDOUT DD PATH='/u/usr_id/stdout.f',PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=SIRWXU
//STDERR DD PATH='/u/usr_id/stderr.f',PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=SIRWXU

In the CONTROL-M job definition that submits the JCL, use the SET VAR parameter
to assign a value to the %%MYSCRPT AutoEdit variable, as follows:

SET VAR %%MYSCRIPT=uss_script_name

920 Control-M for z/OS User Guide

 Unix Oriented Implementation

Unix Oriented Implementation

To enable Unix operators to use their expert skills, CONTROL-M provides a Unix-
oriented MVS implementation for USS jobs.

CONTROL-M incorporates 3-tier architecture that includes CONTROL-M/Enterprise

Manager, CONTROL-M/Server, and CONTROL-M/Agent platforms. CONTROL-M
treats USS as an additional supported platform, just like any other supported Unix
platform.

This architecture is illustrated in Figure 379.

Figure 379 CONTROL-M Architecture for Unix-Oriented MVS Implementation

Appendix B CONTROL-M for z/OS Unix System Services (USS) 921

Integrating SAP R/3 running on USS

If you have a CONTROL-M/Agent installed on several Unix computers, you can also
install it on a USS computer, using the same architecture. You can then implement
CONTROL-M in USS through a CONTROL-M/Agent that allows Unix operators to
use the tools with which they are familiar.

Integrating SAP R/3 running on USS

In many data centers, the heaviest batch application running on USS is SAP R/3.

The architecture of SAP is shown in Figure 380.

Figure 380 Architecture of SAP R/3

922 Control-M for z/OS User Guide

 CONTROL-M Support for SAP in the USS Environment

You can integrate this 3-tier architecture with the CONTROL-M MVS platform in the
following ways:

■ You can use DB/2 as the SAP database, with MVS running the entire SAP database
layer. Many users of SAP employ this configuration.

■ You can install both of the following in USS:

— the database layer, using DB/2 running under MVS

— the application layer

This configuration is popular among organizations that require the stability,

scalability, and security of the MVS platform.

CONTROL-M Support for SAP in the USS Environment

CONTROL-M support for the USS environment ensures complete automation and
integration of business processes both inside and outside the SAP application
environment.

CONTROL-M/Enterprise Management for distributed systems supports SAP R/3 by

means of the CONTROL-M Option for SAP R/3. This product is certified by SAP in
accordance with the SAP Complementary Software Program.

The combination of CONTROL-M with the CONTROL-M Option for SAP R/3
enables all jobs and tasks to be managed in the same way, regardless of whether the
task is

■ MVS JCL
■ a Unix script
■ an SAP task

The SAP R/3 standard Business Application Program Interface (BAPI) enables you to
define jobs through either the R/3 or CONTROL-M job definition process.

Once installed on a Windows NT or Unix platform, CONTROL-M Option for R/3

communicates with the R/3 Application layer. The database location is totally
transparent to CONTROL-M.

The Application layer can be in either

■ SAP R/3
■ USS

Appendix B CONTROL-M for z/OS Unix System Services (USS) 923

CONTROL-M Support for SAP in the USS Environment

SAP R/3 Application Layer

If the Application layer is in SAP R/3 in a Unix computer, the communication process
between CONTROL-M Option for SAP R/3 and the R/3 Application layer is as
shown in Figure 381. In this figure, the database is an MVS (DB/2) database.

Figure 381 Communication with the R/3 Application Layer - DB/2 Database

USS Application Layer

If the Application layer is in USS, use the same Windows NT or Unix CONTROL-M
Option for SAP R/3.

CONTROL-M Option for SAP R/3 communicates with the R/3 Application layer in
the same way that the product communicates with other platforms. The
communication process is shown in Figure 382.

924 Control-M for z/OS User Guide

 CONTROL-M Support for SAP in the USS Environment

Figure 382 Communication with the R/3 Application - SAP/R3 Database

Appendix B CONTROL-M for z/OS Unix System Services (USS) 925

CONTROL-M Support for SAP in the USS Environment

926 Control-M for z/OS User Guide

 Appendix

C
Editing Job Scheduling Definitions in
C

the Edit Environment

Job scheduling definition parameters can be edited, moved, copied, deleted, or
repeated, by performing IOA Line Editing commands, similar to standard ISPF line
commands, from within the Edit environment.

Line Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929

Maintaining Valid Job Scheduling Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931

The Edit environment in the Job Scheduling Definition screen is accessed by typing
EDIT in the COMMAND field and pressing Enter.

Figure 383 The Edit Environment in The Job Scheduling Definition Screen
JOB: BACKP02 LIB CTM.PROD.SCHEDULE TABLE: BACKUP
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ MEMNAME BACKP02 MEMLIB CTM.PROD.JOBLIB
__ OWNER M44 TASKTYPE JOB PREVENT-NCT2 Y DFLT N
__ APPL APPL-L GROUP BKP-PROD-L
__ DESC DAILY BACKUP OF SPECIAL FILES FROM APPL-L
__ OVERLIB CTM.OVER.JOBLIB STAT CAL
__ SCHENV SYSTEM ID NJE NODE
__ SET VAR
__ CTB STEP AT NAME TYPE
__ DOCMEM BACKP02 DOCLIB CTM.PROD.DOC
__ ===========================================================================
__ DAYS DCAL
__ AND/OR
__ WDAYS WCAL
__ MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
__ DATES
__ CONFCAL WORKDAYS SHIFT RETRO N MAXWAIT 00 D-CAT
__ MINIMUM PDS
__ DEFINITION ACTIVE FROM UNTIL
__ ===========================================================================
__ IN START-DAILY-BACKUP ODAT
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 16.44.31

Appendix C Editing Job Scheduling Definitions in the Edit Environment 927

 A 2-character Line Editing command field, marked by underscores, is displayed for
each line on the screen.

Editing commands are typed directly onto these underscores.

NOTE
Edit commands cannot be applied to the first line of an IN block or an OUT block.

Incorrectly specified Line Editing commands can be corrected by typing over them
correctly. Line Editing commands can be deleted by blanking them out or by
specifying the RESET command in the COMMAND field.

The Line Editing commands you enter are processed when Enter is pressed.

CONTROL-M performs Automatic Syntax Checking to ensure that the job scheduling
definition is still syntactically correct after editing. If an edit may invalidate the job
scheduling definition, a message is displayed at the top of the screen and the edit is
not performed. For recommendations for editing job scheduling definitions, see
“Maintaining Valid Job Scheduling Definitions” on page 931.

All operations available in the Job Scheduling Definition screen can be performed
while in the Edit environment. For example, parameter values can be changed, and
the job scheduling definition can be saved and exited.

To exit the Edit environment, retype EDIT in the COMMAND field and press Enter.
Line Editing command fields are removed from the display.

Line Editing commands can be performed on the following:

Table 298 Subjects of Line Editing Commands (part 1 of 2)

Subject Description
Single Lines One single line on the screen.

Examples:
■ Additional lines of the IN parameter.
■ Single-lined DO statement (such as DO COND).

Logical Lines All parameter lines for a specific parameter, including its
subparameters.

Examples:
■ A DO SHOUT statement, whose subparameters are distributed
over more than one line.
■ A single-lined DO statement, such as DO COND.

928 Control-M for z/OS User Guide

 Line Editing Commands

Table 298 Subjects of Line Editing Commands (part 2 of 2)

Subject Description
Logical Blocks Functional group of parameter lines. Job scheduling definitions
consist of at least one logical block – an ON block.

Example:
ON block, which consists of its respective parameter lines and the
DO statement lines.
Multiple Lines User-specified group of parameter lines.

Example:
A series of DO statements.

Line Editing Commands

The following types of line editing commands exist in the Edit environment.

Table 299 Line Editing Commands - Delete Commands

Command Description
DS Delete a single line.
DL Delete a logical line.
DB Delete a logical block or sub-block.
DD Delete lines between two DD specifications.
D Delete a line. CONTROL-M determines whether to delete a single or
logical line based on the line type.

Table 300 Line Editing Commands - Copy Commands

Command Description
CS Copy a single line.
CL Copy a logical line.
CB Copy a logical block or sub-block.
CC Copy lines between two CC specifications.
C Copy a line. CONTROL-M determines whether to copy a single or
logical line based on the line type.
Copy commands are used in conjunction with Location commands. The lines and blocks are
placed at the position indicated by Location command A or B (described below).

Appendix C Editing Job Scheduling Definitions in the Edit Environment 929

Line Editing Commands

Table 301 Line Editing Commands - Move Commands

Command Description
MS Move a single line.
ML Move a logical line.
MB Move a logical block or sub-block.
MM Move lines between two MM specifications.
M Moves a line. CONTROL-M determines whether to move a single or
logical line based on line type.
Move commands are used in conjunction with Location commands. The lines and blocks are
placed at the position indicated by Location command A or B, which are described in
Table 304 on page 930.

Table 302 Line Editing Commands - Repeat Commands

Command Description
RS Repeat a single line.
RL Repeat a logical line.
RB Repeat a logical block or sub-block.
RR Repeat lines between two RR specifications.
R Repeat a line. CONTROL-M determines whether to repeat a single or
logical line based on line type.
The repeated lines and blocks are placed immediately after the lines and blocks marked with
the command.

Table 303 Line Editing Commands - Insert Command

Command Description
I Inserts a new logical line or block after the logical line or block marked
with an I.

Table 304 Line Editing Commands - Location Commands

Command Description
Indication of the position where lines or blocks must be placed.
A (After) Indicates that lines or blocks must be placed after the line marked with
an A.
B (Before) Indicates that lines or blocks must be placed before the line marked with
a B.
Location commands A and B are used in conjunction with Copy (C, CS, CL, CC, CB), and
Move (M, MS, ML, MM, MB) commands.

930 Control-M for z/OS User Guide

 Maintaining Valid Job Scheduling Definitions

Maintaining Valid Job Scheduling Definitions

Since job scheduling definitions must be syntactically correct at all times, the user
must consider the following issues when specifying Line Editing commands:

■ The result of a Line Editing command is dependent on the line on which the
command is specified. For example, command D deletes either a single or a logical
line based on the line type.

■ Logical lines form a unit and cannot be separated.

When a logical command is specified within a logical line, that is, on a

subparameter line or an additional parameter line, the specified operation is
performed on the entire logical line.

■ Block commands must be specified on the main lines of the block. For example, to
delete an ON block, specify command DB (Delete Block) on the ON line.

■ Blank parameter lines are added automatically by CONTROL-M, to allow the user
to specify additional parameters, and cannot be deleted.

■ BMC Software recommends that, wherever possible, you use commands D, C, R,

and M for editing, instead of DS, DL, CS, CL, RS, RL, MS, and ML, because these
commands automatically retain the logical structure of the job scheduling
definition.

Appendix C Editing Job Scheduling Definitions in the Edit Environment 931

Maintaining Valid Job Scheduling Definitions

Example 1
Before: Insert additional DO statements within a DO block using command I (Insert).

Figure 384 Example - Inserting A DO Statement - Before

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ SYSOUT OP (C,D,F,N,R) FROM
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ MAXRERUN 3 RERUNMEM INTERVAL FROM
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
__ CODES
I_ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO RERUN
__ DO
__ ON PGMST PROCST CODES A/O
__ DO
__ SHOUT WHEN TIME + DAYS TO URGN
__ MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 16.44.31

After

Figure 385 Example - Inserting A DO Statement - After

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ SYSOUT OP (C,D,F,N,R) FROM
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ MAXRERUN 3 RERUNMEM INTERVAL FROM
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
__ CODES
__ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO
__ DO RERUN
__ DO
__ ON PGMST PROCST CODES A/O
__ DO
__ SHOUT WHEN TIME + DAYS TO URGN
__ MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 14.49.42

932 Control-M for z/OS User Guide

 Maintaining Valid Job Scheduling Definitions

Example 2
Before: Delete an ON PGMST block. Use of the DB (Delete Block) command is the
preferred method. The DB command removes all parameters, comments,
continuation lines, and separator lines of the specified block. DB must be specified on
a main line of the block, that is, ON PGMST. In this example, the ON PGMST block is
deleted.

Figure 386 Example - Deleting A Block - Before

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ ==========================================================================
__ OUT
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ SYSOUT OP (C,D,F,N,R) FROM
__ MAXRERUN 3 RERUNMEM INTERVAL. FROM
__ STEP RANGE FR (PGM.PROC) . TO
DB ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
__ CODES
__ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO RERUN
__ DO
__ ON PGMST PROCST CODES A/O
__ DO
__ SHOUT WHEN TIME + DAYS TO URGN
__ MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 14.52.02

Appendix C Editing Job Scheduling Definitions in the Edit Environment 933

Maintaining Valid Job Scheduling Definitions

After: The ON PGMST ANYSTEP block has been deleted.

Figure 387 Example - Deleting A Block - After

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ ==========================================================================
__ OUT
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ SYSOUT OP (C,D,F,N,R) FROM
__ MAXRERUN 3 RERUNMEM INTERVAL. FROM
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST PROCST CODES A/O
__ DO
__ SHOUT WHEN TIME + DAYS TO URGN
__ MS
======= >>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< =====

COMMANDS: EDIT, DOC, PLAN, JOBSTAT 14.53.58

934 Control-M for z/OS User Guide

 Maintaining Valid Job Scheduling Definitions

Example 3
Before: Move multiple DO statements from one sub-block to another. Command MM
(Multiple Move) is specified at the beginning and end of the DO statements that are
moved. Command A (After) specifies the location after which these lines are placed.

Figure 388 Example - Moving Statements - Before

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ OUT
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ SYSOUT OP (C,D,F,N,R) FROM
__ MAXRERUN 3 RERUNMEM INTERVAL. FROM
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
__ CODES
__ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO RERUN
MM DO COND STEP5_DONE ODAT +
__ DO SHOUT TO TSO-M22 URGENCY R
MM = STEP STEP05 PROCESSED
__ DO
__ ON PGMST STEP05 PROCST CODES S*** A/O
A_ DO IFRERUN FROM $ABEND . TO . CONFIRM N
__ DO
__ ON PGMST PROCST CODES A/O
__ DO
__ SHOUT WHEN TIME + DAYS TO URGN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.03.25

Appendix C Editing Job Scheduling Definitions in the Edit Environment 935

Maintaining Valid Job Scheduling Definitions

After: The two specified DO statements have been moved to the specified location.

Figure 389 Example - Moving Statements - After

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ OUT
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ SYSOUT OP (C,D,F,N,R) FROM
__ MAXRERUN 3 RERUNMEM INTERVAL. FROM
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
__ CODES
__ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO RERUN
__ DO
__ ON PGMST STEP05 PROCST CODES S*** A/O
__ DO IFRERUN FROM $ABEND . TO . CONFIRM N
__ DO COND STEP5_DONE ODAT +
__ DO SHOUT TO TSO-M22 URGENCY R
__ = STEP STEP05 PROCESSED
__ DO
__ ON PGMST PROCST CODES A/O
__ DO
__ SHOUT WHEN TIME + DAYS TO URGN
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 5.06.09

936 Control-M for z/OS User Guide

 Maintaining Valid Job Scheduling Definitions

Example 4
Before: Copy ON PGMST and some of its DO statements to another ON PGMST
block. Command CC (Multiple Copy) is specified at the beginning and the end of the
parameters that is copied. Command B (Before) specifies the location before which
these lines are placed.

Figure 390 Example - Copying Statements - Before

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ SYSOUT OP (C,D,F,N,R) FROM
__ MAXRERUN 3 RERUNMEM INTERVAL. FROM
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
__ CODES
__ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO RERUN
__ DO
CC ON PGMST STEP05 PROCST CODES S*** A/O
__ DO IFRERUN FROM $ABEND . TO . CONFIRM N
CC DO COND STEP5_DONE ODAT +
__ DO SHOUT TO TSO-M22 URGENCY R
__ = STEP STEP05 PROCESSED
__ DO
B ON PGMST PROCST CODES A/O
__ DO
__ SHOUT WHEN TIME + DAYS TO URGN
__ MS
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 14.32.29

After: The specified ON PGMST and DO statements have been copied.

Appendix C Editing Job Scheduling Definitions in the Edit Environment 937

Maintaining Valid Job Scheduling Definitions

Figure 391 Example - Copying Statements - After

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ MAXRERUN 3 RERUNMEM INTERVAL. FROM
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 ***** A/O
__ CODES
__ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO RERUN
__ DO
__ ON PGMST STEP05 PROCST CODES S*** A/O
__ DO IFRERUN FROM $ABEND . TO . CONFIRM N
__ DO COND STEP5_DONE ODAT +
__ DO SHOUT TO TSO-M22 URGENCY R
__ = STEP STEP05 PROCESSED
__ DO
__ ON PGMST STEP05 PROCST CODES S*** A/O
__ DO IFRERUN FROM $ABEND . TO . CONFIRM N
__ DO COND STEP5_DONE ODAT +
__ DO
__ ON PGMST PROCST CODES A/O
__ DO
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.19.53

Example 5
Before: Insert a continuation line between existing continuation lines. It is
recommended that command RS (Repeat Single) or R (Repeat) be used to repeat the
previous line.

Figure 392 Example - Inserting A Line - Before

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ TIME ZONE:
__ ===========================================================================
__ OUT
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ SYSOUT OP (C,D,F,N,R) FROM
__ MAXRERUN 3 RERUNMEM INTERVAL. FROM
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 C3000 A/O A
RS CODES C4000 C5000 C6000 C7000
__ CODES C1200
__ ON PGMST STEP04 PROCST CODES ***** A/O
__ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO RERUN
__ DO
__ ON PGMST STEP05 PROCST CODES S*** A/O
__ DO IFRERUN FROM $ABEND . TO . CONFIRM N
__ DO COND STEP5_DONE ODAT +
__ DO SHOUT TO TSO-M22 URGENCY R
__ = STEP STEP05 PROCESSED
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.22.46

938 Control-M for z/OS User Guide

 Maintaining Valid Job Scheduling Definitions

After: The continuation line has been repeated. The repeated line can be modified as
necessary.

Figure 393 Example - Inserting A Line - After

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE TABLE: PRODKPL
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ TIME ZONE:
__ ==========================================================================
__ OUT
__ AUTO-ARCHIVE Y SYSDB Y MAXDAYS MAXRUNS
__ RETENTION: # OF DAYS TO KEEP 030 # OF GENERATIONS TO KEEP
__ SYSOUT OP (C,D,F,N,R) FROM
__ MAXRERUN 3 RERUNMEM INTERVAL. FROM
__ STEP RANGE FR (PGM.PROC) . TO .
__ ON PGMST ANYSTEP PROCST CODES S*** U**** C2000 C3000 A/O A
__ CODES C4000 C5000 C6000 C7000
__ CODES C4000 C5000 C6000 C7000
__ CODES C1200
__ ON PGMST STEP04 PROCST CODES ***** A/O
__ DO IFRERUN FROM $ABEND . TO . CONFIRM Y
__ DO RERUN
__ DO
__ ON PGMST STEP05 PROCST CODES S*** A/O
__ DO IFRERUN FROM $ABEND . TO . CONFIRM N
__ DO COND STEP5_DONE ODAT +
__ DO SHOUT TO TSO-M22 URGENCY R
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 15.23.46

Appendix C Editing Job Scheduling Definitions in the Edit Environment 939

Maintaining Valid Job Scheduling Definitions

940 Control-M for z/OS User Guide

 Appendix

D
Editing CMEM Rule Definitions in the
D

Edit Environment
CMEM rule definition parameters can be edited (moved, copied, deleted, repeated)
by performing IOA Line Editing commands, similar to standard ISPF line commands,
from within the IOA Edit environment.

Line Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942

Maintaining Valid Rule Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944

The Edit environment in a Rule Definition screen is accessed by typing EDIT in the
COMMAND field and pressing Enter.

Figure 394 The Edit Environment in The Rule Definition Screen

RL: JOBNAM1 LIB CTM.PROD.RULES TABLE: CMEMRULE
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ ON JOBARRIV = JOBNAM1 JTYPE SMFID SYSTEM And/Or/Not
__ OWNER CTMCTLM GROUP MODE PROD RUNTSEC NONE
__ DESCRIPTION CONVERSION: ON JOB JOBNAM1 ARRIVAL FORCEJOB
__ DESCRIPTION
__ ==========================================================================
__ DO FORCEJOB = TABLE TABLE1 JOB DATE ODAT
__ LIBRARY CTM.PROD.SCHEDULE
__ DO
__ ==========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF, 20.10.46

Appendix D Editing CMEM Rule Definitions in the Edit Environment 941

Line Editing Commands

A 2-character Line Editing command field, marked by underscores, is displayed for

each line on the Rule Definition screen.

Editing commands are typed directly onto these underscores.

Incorrectly specified Line Editing commands can be corrected by typing over them
correctly. Line Editing commands can be deleted by blanking them out or by
specifying the RESET command in the COMMAND field.

The Line Editing commands you enter are processed when Enter is pressed.

The CMEM facility performs Automatic Syntax Checking to ensure that the rule
definition is still syntactically correct after editing. If an edit may invalidate the rule
definition, a message is displayed at the top of the screen and the edit is not
performed. For guidelines and recommendations for editing rule definitions, see
“Maintaining Valid Rule Definitions” on page 944.

All operations available in the Rule Definition screen can be performed while in the
Edit environment. For example, parameter values can be changed, and the Rule
Definition screen can be saved and exited.

To exit the Edit environment, re-type EDIT in the COMMAND field and press Enter.
Line Editing command fields are removed from the display.

Line Editing commands can be performed on any single ON or DO statement or on a

block of ON or DO statements.

All lines of a single statement, for example, the two lines of a DO FORCEJOB
statement, constitute a logical line.

Line Editing Commands

The following types of line editing commands exist in the Edit environment.

Table 305 Line Editing Commands - Delete Commands

Command Description
DS Delete a single line.
DL Delete a logical line.
DB Delete a logical block or sub-block.
DD Delete lines between two DD specifications.
D Delete a line. CONTROL-M determines whether to delete a single or
logical line based on the line type.

942 Control-M for z/OS User Guide

 Line Editing Commands

Table 306 Line Editing Commands - Copy Commands

Command Description
CS Copy a single line.
CL Copy a logical line.
CB Copy a logical block or sub-block.
CC Copy lines between two CC specifications.
C Copy a line. CONTROL-M determines whether to copy a single or
logical line based on the line type.
Copy commands are used in conjunction with Location commands. The lines and blocks are
placed at the position indicated by Location command A or B (described below).

Table 307 Line Editing Commands - Move Commands

Command Description
MS Move a single line.
ML Move a logical line.
MB Move a logical block or sub-block.
MM Move lines between two MM specifications.
M Moves a line. CONTROL-M determines whether to move a single or
logical line based on line type.
Move commands are used in conjunction with Location commands. The lines and blocks are
placed at the position indicated by Location command A or B, described in Table 310 on
page 944.

Table 308 Line Editing Commands - Repeat Commands

Command Description
RS Repeat a single line.
RL Repeat a logical line.
RB Repeat a logical block or sub-block.
RR Repeat lines between two RR specifications.
R Repeat a line. CONTROL-M determines whether to repeat a single or
logical line based on line type.
The repeated lines and blocks are placed immediately after the lines and blocks marked with
the command.

Table 309 Line Editing Commands - Insert Command

Command Description
I Inserts a new logical line or block after the logical line or block marked
with an I.

Appendix D Editing CMEM Rule Definitions in the Edit Environment 943

Maintaining Valid Rule Definitions

Table 310 Line Editing Commands - Location Commands

Command Description
Indication of the position where lines or blocks must be placed.
A (After) Indicates that lines or blocks must be placed after the line marked with
an A.
B (Before) Indicates that lines or blocks must be placed before the line marked with
a B.
Location commands A and B are used in conjunction with Copy (C, CS, CL, CC), and Move
(M, MS, ML, MM) commands.

Maintaining Valid Rule Definitions

Since rule definitions must be syntactically correct at all times, you must consider the
following issues when specifying Line Editing commands:

■ The result of a Line Editing command is dependent on the line on which the
command is specified. For example, command D deletes either a single or a logical
line based on the line type.

■ Logical lines function as a unit and cannot be separated.

When a logical command is specified within a logical line, that is, on a

subparameter line, or a continuation line, the specified operation is performed on
the entire logical line.

■ Block commands must be specified on the main lines of the block. For example, to
delete an ON block, specify command DB (Delete Block) on the ON line.

■ Blank parameter lines added automatically by CMEM, to allow the user to specify
additional parameters, cannot be deleted.

■ BMC Software recommends that, wherever possible, you use commands D, C, R,

and M for editing, instead of DS, DL, CS, CL, RS, RL, MS, and ML, because these
commands automatically retain the logical structure of the rule definition.

944 Control-M for z/OS User Guide

 Maintaining Valid Rule Definitions

Example
Before: Repeat a DO block in the Rule Definition screen.

Figure 395 Example - Repeating A DO Block - Before

RL: JOBNAM1 LIB CTM.PROD.RULES TABLE: CMEMRULE
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ ON JOBARRIV = JOBNAM1 JTYPE SMFID SYSTEM And/Or/Not
__ OWNER CTMCTLM GROUP MODE PROD RUNTSEC NONE
__ DESCRIPTION CONVERSION: ON JOB JOBNAM1 ARRIVAL FORCEJOB
__ DESCRIPTION
__ ==========================================================================
R_ DO FORCEJOB = TABLE TABLE1 JOB DATE ODAT
__ LIBRARY CTM.PROD.SCHEDULE
__ DO
__ ==========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF, 20.10.46

After: The DO block has been repeated.

Figure 396 Example - Repeating A DO Block - After

RL: JOBNAM1 LIB CTM.PROD.RULES TABLE: CMEMRULE
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
__ ON JOBARRIV = JOBNAM1 JTYPE SMFID SYSTEM And/Or/Not
__ OWNER CTMCTLM GROUP MODE PROD RUNTSEC NONE
__ DESCRIPTION CONVERSION: ON JOB JOBNAM1 ARRIVAL FORCEJOB
__ DESCRIPTION
__ ==========================================================================
__ DO FORCEJOB = TABLE TABLE1 JOB DATE ODAT
__ LIBRARY CTM.PROD.SCHEDULE
__ DO FORCEJOB = TABLE TABLE1 JOB DATE ODAT
__ LIBRARY CTM.PROD.SCHEDULE
__ DO
__ ==========================================================================
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====

FILL IN RULE DEFINITION. CMDS: CAPS, EDIT, SHPF, 20.32.47

Appendix D Editing CMEM Rule Definitions in the Edit Environment 945

Maintaining Valid Rule Definitions

946 Control-M for z/OS User Guide

 Appendix

E
MVS Job Restart Without
E

CONTROL-M/Restart
For sites in which CONTROL-M/Restart is not installed, CONTROL-M provides a
mechanism for automatic implementation of MVS restarts in certain situations. The
mechanism, however, requires definition before the original submission of the job.
Therefore, it is only useful for jobs in which automatic restart is always desirable
(when necessary).

NOTE
MVS restart is not recommended and must be used with caution. MVS restart does not
perform automatic File catalog adjustment, GDG (Generation Dataset Group) adjustment,
condition code recapture, abend code recapture, or data set scratching. Unless these functions
are manually handled without error, the results of an MVS restart may be unpredictable or
damaging.

The mechanism for automatic implementation of MVS restart is the definition of a

special OUT condition in the job scheduling definition. The value of the condition is:

@#- ODAT -

where:

■ @# – =condition
■ ODAT =date
■ – =option

NOTE
§Restart§ Do not define this type of restart (that is, this OUT condition) if a
CONTROL-M/Restart restart is used for the job, or the results may be unpredictable.
§Restart§

Appendix E MVS Job Restart Without CONTROL-M/Restart 947

 This restart is implemented in the following situations if the CONTROL-M monitor
ended the job NOT OK (that is, a DO OK did not impact the final status):

■ The job abended.

■ The job failed due to JCL error.
■ One of the steps ended with a condition code of C2000 (abend of a PL/1 program).

When the special OUT condition is defined in the job scheduling definition and the
job ends as described above, the CONTROL-M monitor automatically appends the
name of the failing step to the OUT condition of the job order. The OUT condition in
the job order, that is, as seen in the Zoom screen, therefore appears as follows:

@#-procstep.pgmstep

Before a job is submitted, the CONTROL-M monitor checks the job order for an OUT
condition beginning @# –. When the monitor detects condition @# -procstep.pgmstep, it
automatically inserts an MVS step in the JCL of the job, so that the job begins from the
indicated procstep.pgmstep.

For the job to be restarted from procstep.pgmstep, the job must be rerun. This can be the
result of a rerun, manual or automatic, or the result of a cyclic job run.

The @# – procstep.pgmstep value appearing in the Zoom screen can be deleted, in

which case restart is not performed, or changed to a different procstep.pgmstep, so that
restart begins from a different step.

Even if a special OUT condition (name or prefix @# – ) is not defined in the job
scheduling definition, an MVS restart can be implemented by specifying OUT
condition @# – procstep.pgmstep (for the desired restart step) in the Zoom screen.

NOTE
It is also possible to specify OUT condition @# – procstep.pgmstep in the job scheduling
definition, but this is not recommended. If @# – procstep.pgmstep is specified in the job
scheduling definition, the job always begins at the specified step, never at the first step, even
on the initial run.

When using MVS job restart, every step in the job must have a unique
procstep.pgmstep name. CONTROL-M does not check for duplicate stepnames.

948 Control-M for z/OS User Guide

Example

The following is an example of a job set for Automatic Restart, using CONTROL-M
only, in case of abend.

NOTE
§Restart§ Do not use this type of restart when CONTROL-M/Restart restart is used for the
job, or results may be unpredictable.

Figure 397 Example - Automatic Restart - CONTROL-M Only

JOB: EBDUPDT2 LIB CTM.PROD.SCHEDULE TABLE: EBDPROD
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME EBDUPDT2 MEMLIB GENERAL
OWNER SYS1 TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL EBD GROUP EBD-PRODUCTION
DESC EBD PRODUCTION UPDATE OF DEPOSITS
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM EBDUPDT2 DOCLIB CTM.PROD.DOC
===========================================================================
DAYS DCAL
AND/OR
WDAYS 2,3,4,5,6 WCAL
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL SHIFT RETRO Y MAXWAIT 08 D-CAT
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
===========================================================================
IN DEPOSITS PREV
CONTROL
RESOURCE
PIPE
FROM TIME + DAYS UNTIL TIME + DAYS
DUE OUT TIME + DAYS PRIORITY SAC CONFIRM
TIME ZONE:
===========================================================================
OUT DEPOSITS ODAT + @#- ODAT -
COMMANDS: EDIT, DOC, PLAN, JOBSTAT 11.17.00

Appendix E MVS Job Restart Without CONTROL-M/Restart 949

950 Control-M for z/OS User Guide
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Index
Symbols
! Character DOIFRERUN 454
CTMQSB Command 827 $FIRST.$CLEANUP
Hex Value 86 DO IFREFUN Statement 454
Character % (Simulation) Option
Prerequisite Condition 571 Active Environment Screen 189
# Character % Symbol
Maybe Job Prefix 833 Job Graph 212
User-Defined Variable 767 SHOUT Parameter 638
# OF DAYS TO KEEP %%
RETENTION Parameter 612, 614 Concatenation Symbol 782
# OF GENERATIONS TO KEEP %% Prefix
RETENTION Parameter 612, 614 User Defined Variable 767
# JNFRT Parameter, CTMPARM 224 %% Symbol
#WSC Field, Global View Screen 208 AutoEdit Term 46, 757
$ Character Calendar Date 762
Hex Value 86 Concatenation 760, 782
Job Graph 212 %%$ARGS
RESOURCE Parameter 608 CONTROL-O System Variable 720
User-Defined Variable 767 %%$CALCDTE Function
$$$$ Date Reference Comparison with %%CALCDATE 794
IN Parameter 508 Description 794
OUT Parameter 572 Example 814
$$ACTDOC Member %%$CENT
Customization 85 First Two Digits of the Year 763
Customizing Active Environment Screen 175 %%$COMMSYS Reserved Variable
$ABEND DO SHOUT Statement 723
DO IFRERUN Statement 454, 456 %%$DATEFMT
Restart Confirmation Window 235 Date Format 761
$CLEANUP Value %%$Dn
Rerun/Restart Window 235 CMEM AutoEdit Variable 694, 713
$D MEMBER Command %%$DSN
Machine ID Under JES2 479, 642, 725 CMEM AutoEdit Variable 694
$DEFAULT %%$DSNDISP
Step Adjustment 234 CMEM AutoEdit Variable 695
$DEFAULT Member %%$GREG Function
Restart Window 233 Julian to Gregorian Conversion 796
$EXERR %%$GRID
DO IFRERUN Statement 454, 456 Resolution 765
Restart Confirmation Window 235 Special AutoEdit System Variable 765
$FIRST %%$JNAME
DO IFRERUN Statement 454, 456 CMEM AutoEdit Variable 695, 713
Restart Confirmation Window 235 %%$JULIAN Function
$FIRST Value Gregorian to Julian Conversion 796
Rerun/Restart Window 235 %%$L
$FIRST.$ABEND LPAR name 761
%%$LEAP Function

Index 951
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Leap Year Analysis 797 System Date 763, 764

%%$LENGTH Function %%DAY
Length Extraction 802 System Day 763
%%$MEMNAME %%ELSE Control Statement
System Variable 761 Example 821
%%$OCENT JCL Setup 785
System Variable 763 %%ENDIF Control Statement
%%$ORDERID Example 821
AutoEdit Simulation 339 JCL Setup 785
%%$QNAME %%GLOBAL
Monitor Identifier 761 AutoEdit Statement 341, 758
%%$RBC JCL Setup 779, 784
AutoEdit Simulation 339 Member Format 772
Rule-based calendar name 762 %%GLOBAL Control Statement
%%$RCENT Local Variable 771
System Variable 763 %%GLOBAL Members
%%$RJULDAY Cache 771
Julian Working Day 764 %%GOTO Control Statement
%%$SABEND Example 822
CMEM AutoEdit Variable 695 JCL Setup 785
%%$SCHDLIB %%GROUP
System Variable 761 Job Group 761
%%$SCHDTAB %%IF Control Statement
System Variable 761 Example 821
%%$SIGN JCL Setup 785
Quantitative Resource 762 Nesting 787
%%$STEPCC %%INCLIB Control Statement
CMEM AutoEdit Variable 695 Example 821
%%$SYSNAME JCL Setup 788
System Variable 762 %%INCMEM Control Statement
%%$UABEND Example 821
CMEM AutoEdit Variable 695 JCL Setup 788
%%$WCALC Function %%JOBCC
Working Date Shift 797 Force OK 766
%%$WEEK# Function Job completion code 766
Week of Year 798 %%JOBID
%%$WEEKDAY Function JES Job Number 767
Day of Week Analysis 799 %%JOBNAM Variable
%%$YEARWK# Function SHOUT Statement 368, 375
Week of Year 800 %%JOBNAME
%%A.%%B 780 AutoEdit Symbol 492
%%APPL %%JOBNAME Variable
Application 760 SHOUT Statement 368
%%BLANK Submitted Job Name 761
Blank 760 %%JULDAY
Compared with %%BLANKn 761 Julian Day 763, 764
%%BLANKn %%LABEL Control Statement
Compared with %%BLANK 761 Example 822
n Blanks 761 JCL Setup 785
SET VAR Parameter 630 %%LIBSYM Control Statement 840
%%CALCDATE AutoEdit Statement 758
Comparison with %%$CALCDTE 801 JCL Setup 779, 789
%%CALCDATE Function Local Variable 771
AutoEdit Function 759 PROMPT Library 842
Description 801 %%MAXRC
%%DATE Force OK 766
Example 810 Highest Return Code 766

952 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

%%MEMNAME %%RDAY
AutoEdit Symbol 492 Working Day 763
%%MEMSYM %%RESOLVE
Member Format 772 ALLCACHE 772
%%MEMSYM Control Statement 840 %%RESOLVE Control Statement
AutoEdit Statement 758 Example 820
JCL Setup 779, 789 JCL Setup 779, 791
Local Variable 771 %%RESOLVE NO Control Statement
Table Name Prefix 842 AutoEdit Logic 791
%%MINUS Operator JCL Setup 793
AutoEdit 794 %%RESOLVE YES Control Statement
%%MM.%%DD.%%YY Example 820
Example 814 %%RJULDAY
%%MONTH Julian Working Day 763
Month of the Job 763 %%RMONTH
System Month 763 Working Month 763
%%O %%RN
ODATE 762 Run Number 761
%%ODATE %%RWDAY
Date of the Job 763, 764 Working Day of the Week 763
Example 810 %%RWEEK
%%ODAY Working Week 763
Day of the Job 763 %%RYEAR
Example 811 Working Year 763, 764
%%ODAY.%%A.%%OYEAR %%SET %%variable
Example 813 AutoEdit Control Statement 758
%%OJULDAY %%SET Control Statement
Julian Day of the Job 763, 764 Global Variable 773
%%OMONTH JCL Setup 778, 779, 792
Example 811 Local Variable 770
%%ORDERID OCCUR NO 851
Job Order ID 761 User-Defined Variable 768
%%OWDAY Variable Members 779
Day of the Week of the Job 763 %%SIGN
Example 816 System Variable 608
%%OWDAY.%%TIME %%STEP
Example 819 Job Program Step 766
%%OWEEK %%SUBSTR Function
Week of the Job 763 Example 814
%%OWNER String Extraction 801
Job Owner 761 %%TIME
%%OYEAR Example 819, 821, 822
Example 811 Time of Day 761
Year of the Job 763, 764 %%WDAY
%%PLANID Day of the Week 763
Inter-plan Dependency 849 %%WEEK
%%PLUS Operator Week of the Year 763
AutoEdit 759, 794 %%YEAR
%%R System Year 763, 764
Installation Working Date 762 ' Character
%%RANGE Control Statement FIND Command 101
Example 819 ( Character
JCL Setup 790 Hex Value 86
Minimum Length 790 () Characters
%%RDATE DO COND 443
Example 811 IN Parameter 512
Working Date 763, 764 Prerequisite Condition 571

Index 953
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

* Character +EVERY Step 558

CONFCAL Calendar 427, 682 + (Group Next)
D-CAT Parameter 422 SAC Parameter 619
DO SYSOUT Statement 487 + Sign
JCL 780 Change Resource Window 296
Job Graph 212 DO COND Statement 444
Masking 87 Job Dependency Network 249
MEMNAME Value 717 Job Graph 212
ON PGMST Statement 653 OUT Parameter, OPT Subparameter 572
ON Statement 556 SHOUT Parameter 638
ON Statement Codes 560 +EVERY
PRIORITY Parameter 597 ON Statement 552, 553
Quick Schedule Definition 374 PGMST Parameter 552
SHOUT Parameter 637 PROCST Parameter 553
SYSOUT Parameter 655, 658 +EVERY Step Value
* in DCAL Parameter ON Statement 557
CONFCAL Calendar 427 +nnn Variable
* in WCAL Parameter Schedule Date 443, 508, 572
CONFCAL Calendar 682 - (Group Previous)
* Symbol SAC Parameter 619
SCHEDULE RBC Parameter 508 - Sign
*$EJ Code Change Resource Window 296
ON Statement Codes 560 DO COND Statement 444
**** Date Reference Job Dependency Network 249
IN Parameter 508 OUT Parameter, OPT Subparameter 572
OUT Parameter 572 Quick Schedule Definition 374
Schedule Date 443 SHOUT Parameter 638
***** Code -nnn Variable
+EVERY Step 558 Schedule Date 443, 508, 572
ON Statement Codes 560 . Character
*.taskid AutoEdit Variable 780
MEMLIB Parameter 533 .. Character
*FLUSH Code AutoEdit Variable 781
ON Statement Codes 561 /* Symbol
*in-condition DO Statement Command 269
Quick Schedule Definition 374 //*CONTROL-M
*NCT2 Code Quick Submit Command 828
ON Statement Codes 560 //OUTPUT Statement
*P Field SYSDATA Output Class 70
Conditions/Resources 290, 297 < Character
*rangename ON Statement CODES 564
ON Statement 552 SHOUT Parameter 638
PGMST Parameter 552 =6 Command
*REC0 Code PF06/PF18 97, 113
ON Statement Codes 560 =X Command
*SNRUN Code Fast Exit 95
ON Statement Codes 562 Online Facility Exit 95
*T Command > Character
JES Name 477, 639 DO Statement 441
JES3 533 ON Statement 555
*TERM Code ON Statement CODES 564
ON Statement Codes 560 SHOUT Parameter 638
*UKNW Code TIME Parameter 671
ON Statement Codes 560 ? Character
*UKNW Status Masking 87
ON Statement 557 ? Option
*xxxx Code Active Environment Screen 186, 212

954 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

? Symbol ABENDED Status

Confirm Rerun Window 233 Show Screen Filter 202
Restart Window 240 ABORT
@ Character Screen Command 99
Hex Value 86 ACF2 586
Maybe Job Prefix 833 Action Keyword
OS/390 Restarts 833, 947 DO Statement 440
User-Defined Variable 767 ACTIVATE Option
@ Symbol Active Environment Screen 187
Maybe Jobs 833 Active Environment Screen
@# -procstep.pgmstep Commands 180
OS/390 Restart 948 Display Type 175
OUT Condition 948 Fields 177, 179
@#– Filtering 196
OS/390 Restart 947 Format 176
| Character Functions 172
DO COND Statement 443 Job Deleting 186
Hex Value 86 Job Statuses 191, 192
Prerequisite Condition 571 Options 186
¬ Character RBA 181
Prerequisite Condition 571 Active Environment screen 182, 223, 469
ACTIVE FROM Parameter
Scheduling Logic 388
Numerics ACTIVE IN ERROR Status
Active Environment Screen 195
1 Command Active Jobs File
IOA Primary Option Menu 91, 92 Daily Subsystem 385
35-Day Default Description 45
Periodic Calendar 324 Display 61
4 Option DO FORCEJOB Statement 716
Primary Option Menu 90 Dynamic Insert Facility 71
5 Option MAXWAIT Parameter 505, 528
Primary Option Menu 90 New Day Processing 46
6 Option PRIORITY Parameter 597
Primary Option Menu 90 Restoration 51
8 Option SYSDATA Deletion 405
Primary Option Menu 90 TASKTYPE Parameter 668
Active Missions File
D-CAT Parameter 422
A ACTIVE Status
Active Environment Screen 192, 195
A Option SMART Table Entity 575
Active Environment Screen 187 ACTIVE UNTIL Parameter
Manual Conditions 301, 832 Scheduling Logic 388
Parameter Prompting 353 ADD Command
A/O Parameter Conditions and/or Resources 292
ON Statement 553 ADD COND Command
ABEND Conditions and/or Resources 293
FLUSH 562 ADD COND Parameter
SNRUN 563 Simulation 858
Abend Capturing Option Add Condition Option
DUMP Command 185 Why Screen 215
Abend Code ADD CONTROL Command
ON Statement 559 Conditions and/or Resources 293
S*37 633 ADD Option
Abend Code Recapture Manual Conditions 301, 832
Rerun Confirmation 233 Parameter Prompting 353, 362

Index 955
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

ADD RESOURCE Command CMEM Rule Definition 266

Conditions and/or Resources 293 ANYSTEP
ADDED Field FORCE OK 254
Manual Conditions 299 ON Statement 552
Adding PGMST Parameter 552
Conditions and/or Resources 292 ANYSTEP Value
Manual Condition 299 PGMST Parameter 557
Adding Variables APPL FORM Parameter
Variable Database Facility 284 Description 401
Addition Operator APPL Parameter
%%PLUS Operator 794 Description 399
ADDMNCND Utility Example 399
Maybe Jobs 834 APPL TYPE Parameter
ADJUST CONDITIONS Description 402
Parameter 395 APPL VER Parameter
ADJUST CONDITIONS Parameter Description 403
Description 395 Application Name
SMART Table Entity 116, 145, 383, 834 APPL Parameter 399
AECACHL Parameter APPL TYPE Parameter 402
CTMPARM 771 APPLICATION NAME Parameter
AELIBNM Parameter AutoEdit Simulation 340
CTMEXEC CLIST 848 Application Program Interface, CONTROL-M 877
AJF Application Version
Functions Performed by CTMAPI 880 APPL VER Parameter 403
AJF Action BAPIAACT Field Values 911 Archiving
AJF Action Input Parameters 911 SYSDATA 404
AJF Action Return Codes Sysout 491
CTMAPI 912 ARG Parameter
AJF Actions DO CTBRULE Statement 448
CTMAPI Calling 886 ARGUMENTS Parameter
ALCMAJF Member 906 CTB STEP Parameter 419
Use with CTMAPI 887 ARROW Command
ALL Argument Change Color 169
REFRESH Command 182, 252 ASK FOR EACH ONE Field
All Info Display Type CMEM Rule Order Window 275
Active Environment Screen 178 Conditions/Resources Confirmation 295
All Runs Manual Conditions Confirmation 302
ON Statement 555 Scheduling Confirmation 160
STEP RANGE Parameter 654 Why Screen Confirmation 217
ALLCACHE Value Assignment of Variable
%%RESOLVE Control Statement 792 Definition 776
ALLRUNS Parameter AT Parameter
CTRPARM Member 555, 654 CTB STEP Parameter 419
ALLRUNS=YES ATTN Key
FLUSH Code 562 AutoRefresh Mode 104
SNRUN Code 563 AUTO Command
AND/OR Parameter AutoRefresh Mode 104, 182
DAYS/WDAYS Parameter 387, 427, 682 AUTO-ARCHIVE parameter 406
And/Or/Not Logic AUTO-ARCHIVE parameter and 406
CMEM ON Statement 734 AutoEdit Expression
And/Or/Not Parameter DO RULE Statement 719
CMEM ON Statement 733 AutoEdit Facility
ON DSNEVENT Statement 738 Boolean Logic 785
ON JOBARRIV Statement 741 Control Statement 783, 849
ON JOBEND Statement 743 JCL Modification 757
ON STEP Statement 746 JCL Setup 46
And/Or/Not Subparameter Job Scheduling 759, 808

956 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Setting Variable Values 793 Precedence 782

Syntax Checking 338, 806 Resolution 780
AutoEdit Function SET VAR Parameter 631
%%$CALCDTE 794 Setting a Value 472, 630, 782
%%$GREG 796 System Variable 760
%%$JULIAN 796 Value Assignment 782
%%$LEAP 797 AutoEdit variable
%%$LENGTH 802 in condition name 301, 443, 507, 571, 809
%%$WCALC 797 Automatic Restart
%%$WEEK 798 Restart ... 454
%%$WEEKDAY 799 Automatic Tape Adjustment
%%$YEARWK# 800 Description 56
%%CALCDATE 801 RESOURCE Parameter 606
%%SUBSTR 801 WM2744 Wish 56
AutoEdit Variables 759 Automatic Tape Adjustment Facility
JCL Setup 801, 802 Statistics Screen 248
AutoEdit Operator Automation Log
%%MINUS 794 MODE Parameter 732
%%PLUS 759, 794 Automation Log Screen
Boolean Logic 786 SHOW Command 305
AutoEdit Parameter AUTOMATION OPTIONS
OCCUR NO Suffix 849 IOA Menu 93
Parameter Prompting 347, 352, 355, 360, 365, 838, 843 AutoRefresh
AutoEdit Resolution PA1 Key 99
Rerun/Restart Window 235 AutoRefresh Mode
AutoEdit SET Statement Active Environment Screen 174
JCL SET 783 Screen Updating 104
AUTOEDIT SIMUL Option View Graph Screen 208
Online Utilities Menu 333 AutoSave Documentation 151
AutoEdit Simulation AUTOTAPE Parameter
CTMAESIM Utility 338 CTMPARM 248, 607
AutoEdit Statement AUTOARCHIVE Parameter
CTMEXEC CLIST 849 Description 404
Syntax Checking 865 Example 406
AutoEdit Symbol Average Statistics Line
%%JOBNAME 492 Statistics Screen 246
%%MEMNAME 492
DO SYSOUT Statement 492
AutoEdit Syntax
Checking 338, 806
B
CTMAESIM Utility 806 B Option
CTMSCIM Utility 343 Table List Screen 126
Testing 338, 806 Backslash Character
AutoEdit Variable Global Variable 767
%%SIGN 608 Balancing Specifications
CMEM 713 DO CTBRULE Statement 448
Concatenation 780 BALANCING STATUS Option
Description 757 Primary Option Menu 93
DO MAIL Statement 460 BAPIACON Value
DO REMEDY 468 CTMBAPI AJF Action 911
DO SET Statement 472, 473, 808 BAPIACRT Value
DO SHOUT Statement 478, 640 CTMBAPI AJF Action 911
DO Statement 440 BAPIADEL Value
Linking 780 CTMBAPI AJF Action 911
MEMLIB Parameter 533, 809 BAPIAFOK Value
Multiple 780 CTMBAPI AJF Action 911
OVERLIB Parameter 581, 809 BAPIAFRE Value

Index 957
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

CTMBAPI AJF Action 911 CTMBAPI Field 903

BAPIAHLD Value BAPISIGN Field
CTMBAPI AJF Action 911 CTMAPI 902
BAPIAJID Field BAPISJID Field
CTMBAPI 911 CTMBAPI 903
BAPIAMEM Field BAPISJNM Field
CTMBAPI 911 CTMBAPI 903
BAPIAOID Field BAPISLIB Field
CTMBAPI 911 CTMBAPI 903
BAPIARER Value BAPISMEM Field
CTMBAPI AJF Action 911 CTMBAPI 903
BAPIAUND Value BAPISODT Field
CTMBAPI AJF Action 911 CTMBAPI 903
BAPICMD Field 913 BAPISOID Field
CTMAPI 915 CTMBAPI 904
CTMBAPI 900 BAPISOWN Field
BAPICMDA Field CTMBAPI 904
CTMAPI 901 BAPISRBA Field 904
BAPICMDL Field BAPISRBB Field
CTMAPI 916 CTMBAPI 904
CTMBAPI 901 BAPISRNM Field
BAPIFLG1 Field CTMBAPI 904
CTMBAPI 901 BAPISSTT Field
BAPIMCT Field CTMBAPI 904
CTMBAPI 901 BAPISTAB Field
BAPIOWN Field CTMBAPI 904
CTMBAPI 911 BAPISTAG Field
BAPIRBAC Field CTMBAPI 904
CTMBAPI 911 BAPISTYP Field
BAPIRBAN Field CTMBAPI 904
CTMBAPI 911 BAPIURC Field
BAPIRC Field CTMAPI Return Codes 897
CTMAPI 901 CTMBAPI 902
CTMAPI Return Codes 897 BAPIVERS Field
BAPIRESP Quantitative Resource Input Field, CTMAPI CTMAPI 902
914 BAPIWORK Field
BAPIRESQ Quantitative Resource Input Field, CTMAPI CTMBAPI 902
914 Basic
BAPIRESX Quantitative Resource Input Field CTMAPI STAT CAL Parameter 650
914 Basic Scheduling Parameters
BAPIRESX Quantitative Resource Input Field, CTMAPI Scheduling Definition 136
914 SMART Table Entity 145
BAPIRPL# Field Summary 385
CTMAPI 901 Batch Job
BAPIRPLC Field TASKTYPE Parameter 666
CTMBAPI 901 Batch Procedure
Initial Setting 918 CTMAESIM 338
BAPIRPLE Field BLANK Value
CTMAPI 902 Parameter Prompting 361
BAPIRPLS Field BLT Function
CTMAPI 902 CTMAPI, Setting Reply Fields 916
BAPIRSN Field Reply Codes 916
CTMAPI Return Codes 897 BLT Function Replies
CTMBAPI 902 CTMAPI 916
BAPISGRN Field BLT Function, CTMAPI
CTMBAPI 903 Procedure 915
BAPISHLD BMC Software, contacting 2

958 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Boolean Logic Inserting a New Year 320

Example 821 Overview 63
JCL Setup 785 Periodic Calendar 323
BOTTOM Command Scheduling Jobs 54
Scrolling 100 CALENDAR Field
Bottom Line Calendar Facility Entry Panel 316
Primary/Alternate 175 CALENDAR LIBRARY Parameter 338
Branching Calendar List Screen 316, 327
%%GOTO Control Statement 785, 821 Exiting 333
Browse Mode Calendar Name
CMEM Rules 258 DCAL Parameter 427
DOCU/TEXT 149 Calendar Periodic
DOCU/TEXT Library 495, 497 Description 323
Job List Screen 127 CANCEL Command
Zoom Screen 222 Calendar Definition Screen 331
BROWSE Option CMEM Rule Definition 271
Calendar List Screen 317 Description 102
CMEM Table List 262 Scheduling Definition 153
Table List Screen 119, 126 Scheduling Definition Entry Panel 123
BUT NOT FOUND n TIMES Zoom Screen 228
Active Environment Screen 192 CAPS Command
BYPASS Option CMEM Rule Definition 269
Active Environment Screen 190 Variable Zoom screen 287
Default Settings 190 CAPS OFF
Fields 190 Command 269
Bypassing CAPS ON
Table List Screen 271 Command 269
CATEGORY Command
Log Screen 305
C CATEGORY Field
Job Scheduling Table 828
C Option CATEGORY Parameter 386
Active Environment Screen 188 CCTMJOB
Job List Screen 130, 264 Replacement by CTMAPI 880
Year List Screen 319 CHANGE Command
Cache Scheduling Definition 147
%%GLOBAL Members 771 CHANGE Option
Calendar Conditions/Resources 294, 295
DATES Parameter 424 CHANGE RESOURCE Parameter Simulation 859
DAYS Parameter 428 Character
Example 430, 685 Global Variable 767
Job Scheduling Plan 171 Gregorian Date Format 68
Periodic 54, 315 Hex Value 86
Regular 54, 315 Character Masking 87
WDAYS Parameter 682 CHECK IN EXT VOL Option
Calendar Date Primary Option Menu 93
System Variable 762 CICS 85
CALENDAR DEF Option CMEM On Spool Job 695
Primary Option Menu 90 Environment 586
Calendar Definition Screen 318, 322 OWNER Parameter 586
Exiting 331 PF06/PF18 97
Calendar Facility CICS Environment 85
Accessing 314 Class
Deleting a Calendar 326, 330 Allocation 817, 818
Entry Panel 315 DO SYSOUT Statement 484
Exiting 331 Sysout 486, 657
General 313 SYSOUT Parameter 655

Index 959
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

CLEANUP Option Rule Management 694

Online Utilities Menu 333 CMEM Message Type
CLEANUP Status IOA Log Show Screen Window 310
Active Environment Screen 192 CMEM Monitor
CLIST Variable Database Facility 278
Activation 113 CMEM On Spool Job
TSO Environment 827 On Spool Job 717
CLIST CTMCAES CMEM Option
AutoEdit Syntax Testing 338 Primary Option Menu 257, 259
CLIST CTMCAMNU CMEM Rule
Parameter Prompting 358 And/Or/Not Logic 734
CLIST CTMCDOCU Browsing 258
DOCU/TEXT Product 378 Comments 269
CLIST CTMCFMNU Components 696
Parameter Prompting 350 CONTROL-O Rule 707
CLIST CTMCSIM Creation 258
Simulation/Tape Pull 342 Dataset Event 692, 736
CLIST CTMEXEC Definition 705
Parameter Prompting 846, 848 DESCRIPTION Parameter 709
CLIST CTMFETCH DO COND Statement 693, 712
Parameter Prompting 846 DO FORCEJOB Statement 693, 715
CLIST CTMJBINT DO RULE Statement 719
End User Job Order 376 DO SHOUT Statement 722
Job Ordering 827 DO Statement 693, 707, 711
CLIST CTMJOBRQ DO STOPJOB Statement 693, 727
Job Ordering 336, 827 Editing 259
CLIST CTMPROMPT GROUP Parameter 729
Quick Schedule Definition 367 Job Arrival 741
CLIST CTMQUICK Job Scheduling Definition 697
Quick Schedule Definition 368 Management 693
CLIST IOAUTIL MODE Parameter 731
Online Utilities 333 ON DSNEVENT Statement 692, 694, 696, 733, 736
CM VER Parameter ON JOBARRIV Statement 692, 696, 733, 741
Description 407 ON JOBEND Statement 692, 733, 743
CM Version On Spool Job 695
CM VER Parameter 407 ON Statement 733
CMEM ON STEP Statement 692, 696, 733, 745
FTP products 703 OWNER Parameter 749
Generation Data Sets 703 Parameters 705
IBM FTP 704 Prerequisite Condition 693, 712
SMS Support 703 Screen 705, 709, 726, 728, 732, 740, 742, 744, 752
CMEM DEFINITION Option Simulation 731
IOA Primary Option Menu 91 CMEM Rule Definition
CMEM Entry Panel Commands 268
Exiting 273 Description 265
CMEM Facility Editing 270
Actions 693 Entry Panel 260
AutoEdit Variables 713 Exiting 271
CICS Job 695 CMEM Rule Facility
CONTROL-O 53 Description 256
Description 692 Exiting 271
DO FORCEJOB Statement 716 ISPF PACK Option 257
Event Types 53, 692 Screens 257
External Events 53 TEST Mode 731
Forced Job 698, 716 CMEM Rule List
On Spool Job 53, 695 Browse Mode 262
Overview 61 Exiting 271

960 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Options 264 AUTO 104, 182

Screen 261, 709 BOTTOM 100
CMEM Rule Table CANCEL 103, 123, 153, 228, 271
Creation 257 Change Color 169
Deletion 273 CMEM Rule Definition 268
List 261 Conditions/Resources Screen 293
Ordering 274, 694 Copy 929, 943
CMEM Security CPUID 184
RUNTSEC Parameter 752 CTMQSB 827
CMEM support CTMTTRA 113
ON STEP Statement 700 DATA 129
CMEM Table Delete 929, 942
Ordering 259 DESC 129, 184, 263, 319
CMEM Table List DISPLAY 175, 180
Exiting 273 DOC 149
Options 261 DOWN 97
Statistics 261 DUMP 185
Cnnnn Code EDIT 148, 269, 270, 927
+EVERY Step 558 END 97, 153, 207, 271, 313
Code ***** Exit Online Facility 95
FLUSH Code 563 FIND 97, 100, 168
SNRUN Code 563 GROUP 185, 305
CODE Criteria HELP 97, 103
IOA Log Show Screen Window 310 HISTORY 181
Screen Filter 310 Insert 930, 943
CODE Field IOA Primary Option Menu 90
Log Screen 304 ISPF 105
CODES Parameter JCL 119
ON Statement 553, 559 JES HOLD 192
Collection Job Dependency 251
MAINVIEW Batch Optimizer (MVBO) Job Dependency Network 251
Implementation 836 JOBSTART 247
Color Support JOBSTAT 147, 182
Active Environment Screen 174 KEYS 105, 245
Box Color 169 L Parameter Prefix 105, 352, 355, 361, 366
Graphic Jobflow 168 Line Editing 929, 942
Job Graph 210 LOCATE 100, 241
Online Facility 86 Location 930, 944
View Graph Screen 209 Log Screen 304
Column Range Move 930, 943
%%RANGE Control Statement 790 NEW COND 300
COM-PLETE 85 NEW LCOND 300
Combinatorial Logic NOTE 183
CMEM ON Statement 734 OIDL 185
Command 1 Online Facility 97
IOA Primary Option Menu 91, 92 OPT 180
Command Line ORDERID 186
Online Facility 96 PRINT 105
Command line commands Quick Submit 827
IOA Editor 108 RBAL 181
Commands REFRESH 104, 182, 207, 249, 251
=6 97, 113 Repeat 930, 943
Active Environment Screen 180 RESET 97, 102, 103, 155, 206, 272, 313, 375, 928
ADD COND 293 RETRIEVE 98
ADD CONTROL 293 Rule Editing 941
ADD RESOURCE 293 SAVE 226, 228
ADD Resources 292 Scheduling Definition 146

Index 961
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Scrolling 99 condition name

SELECT 117 AutoEdit variable in 301, 443, 507, 571, 809
SET 109 CONDITION NAME Field
SHOW 97, 181, 197, 307 Prerequisite Condition Utility 335
SHPF 98 Condition Names
SORT 129 Long 442, 509, 574
SPLIT 105 Condition Parameter
STAT 129, 264, 319 DO COND Statement 712
SWAP 105 CONDITION/RESOURCE Field
Sysout Viewing 244 Conditions/Resources 290
TABLE 183 Conditional Processing
Table List Screen 126 DO Statement 392
TOP 100 IF, THEN, ELSE 785, 822
TSO 112 ON Statement 392
TSO CTMTTRA 113 Conditions
UP 97, 99 Forecasting 854
Utilities Transfer 97 Simulation 854
VG 186, 208 Conditions File 64
VIEW 186, 206 Conditions/Resources
VIEW GRAPH 186, 208 Add/Check/Delete Utility 334
VIEWALL 243 Delete Option 294
Comment Fields 289, 297
CMEM Rule Definition 269 Handling 49, 76
Comparison Operators IOALDNRS Utility 831
AutoEdit Logic 786 Manual Conditions 301
Components Options 294
CONTROL-M 44 Restoration 50
Compression Job condopt Parameter
CONTROL Parameter 416 DO COND Statement 713
Computer Allocation CONFCAL Calendar
Example 818 Schedule Validation 387
Computer ID Scheduling Logic 388
Started Task 535 CONFCAL Parameter
COMPLETE 85 Description 408
PF06/PF18 97 MINIMUM Parameter 540
Concatenation PDS Parameter 588
%% Symbol 760, 782 Periodic Calendar 410
AutoEdit Variable 780 Configuration Table
Logic 780 AutoEdit Statement 850
COND Field CONFIRM Field
Conditions/Resources 291 CMEM Rule Table Order 275
COND-NAME Subparameter Conditions/Resources 295
DO COND Parameter 443 Manual Conditions 302
IN Parameter 507 Restart Confirmation Window 232
OUT Parameter 571 Scheduling Confirmation 158
COND/RES Option Zoom Screen 223
Primary Option Menu 90 CONFIRM Option
Condition Code Active Environment Screen 188
ON Statement 559 CONFIRM Parameter
Condition Code Recapture Description 412
Restart Confirmation 233 DO IFRERUN Statement 455
CONDITION DATE Field Example 413
Prerequisite Condition Utility 336 Confirm Rerun Window
CONDITION Field Active Environment Screen 229, 230
Parameter Prompting 352 Confirm Restart Window
CONDITION Name Active Environment Screen 231
Manual Conditions 299 Confirm Scheduling Window

962 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Active Environment Screen 229 Restart under, Job Status 195

Confirmation Window CONTROL-O
CMEM Rule Table 275 Product Description 43
DO IFRERUN Statement 456 SHOUT Facility 53
Force OK 254 CONTROL-O Monitor
Manual Conditions 301 Variable Database Facility 278
Manual Scheduling 156 CONTROL-O/COSMOS
Why Screen 215, 216 Product Description 43
Zoom Screen 228 CONTROL-D/Image
CONNECT DIRECT Product Description 43
File Transfer 714 CONTROL-M
CONTROL Field Concepts 63
Conditions/Resources 291 Overview 43
CONTROL Parameter Product Description 42
Description 414 CONTROL-M Repository 63
Example 416 CONTROL-O
Logic 416 %%$ARGS System Variable 720
CONTROL Resource Automation Log 731
Adding 292 CMEM Facility 53
Critical Path Priority 598 CMEM Rule 693
Definition 76 MODE Parameter 731
Manual Addition 293 Shout Facility 707
Runtime Criteria 49 CONTROL-O Rule
Show Screen Filter 204 DO RULE Statement 719
CONTROL Resources CONTROL-V
CONTROL-M Resources File 288 Product Description 43
IOA Conditions/Resources Screen 288 CONTROL-D
CONTROL Statements D-CAT Parameter 422
AutoEdit 783 Product Description 43
CONTROL-M CONTROL-D/Page On Demand
Application Program Interface 877 Product Description 43
Implementation 826 CONTROL-M Monitor
Parameter Prompting 350 Description 45
SIMPARM DD Statement 857 Postprocessing 51
CONTROL-M Monitor CONTROL-M Status Field
Multiple Monitors 57 Active Environment Screen 177
New functions 581 CONTROL-M/Tape
Simulation Facility 343 Product Description 43
CONTROL-M Resources CONTROL-M/Restart
File 288 DO IFRERUN Statement 453
CONTROL-M Resources File 64, 289 Product Description 42
CONTROL-M/Analyzer Restart under 195, 453
CTB STEP Parameter 419 Restart Window 231
DO CTBRULE Statement 448 SNRUN Code on Restart 563
Product Description 43 CONTROL-O
CONTROL-M/Enterprise Manager CMEM Rule 707
APPL Parameter 399 DO SHOUT Statement 722
DO SHOUT Destination 478, 723 Rule Invocation 693
GROUP Parameter 503 Shout Facility 707
SHOUT Parameter 638 Conventions Used in This Guide 34
CONTROL-M/Restart SIMUL Option Conversational Mode
Online Utilities Menu 333 CTMAPI 898
CONTROL-M/Restart COPMEM2O Parameter 581
FLUSH Code on Restart 562 Copy Commands
History Jobs File 50 Edit Environment 929, 943
Rerun Confirmation 232 COPY Option
Restart under 69 Job List Screen 119

Index 963
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Year List 319 AJF Action, BAPIAFOK Value 911

Copy Option AJF Action, BAPIAFRE Value 911
Job List Screen 130, 264 AJF Action, BAPIAHLD Value 911
Copying AJF Action, BAPIAKIL Value 911
Jobs 163 AJF Action, BAPIARCT Value 911
Sysout 485, 489, 657, 660 AJF Action, BAPIARER Value 911
Copying Jobs 162 AJF Action, BAPIAUND Value 911
Copying Rules 276 Allocations 878
COSMOS Status Option Available Functions 880
Primary Option Menu 93 BAPICMD Field 900, 915
COUNT Parameter BAPICMT Field 901
Change Resource Window 296 BAPIGOPT Global Variable Input Field 913
CPU Field BAPIRC Field 901
Active Environment Screen 178 BAPIRESN Quantitative Resource Input Field 914
CPU ID BAPIRESP Quantitative Resource Input Field 914
Version Information Window 94 BAPIRESQ Quantitative Resource Input Field 914
CPU Time Field BAPIRESX Quantitative Resource Input Field 914
Statistics Screen 247 BAPIRPL Field 901
CPU Time, SMART Table BAPIRPL# Field 918
Statistics Screen 247 BAPIRPLC Field 918
cpuid BAPIRPLC Field, Initial Setting 918
MEMLIB Parameter 533 BAPIRPLE Field 902, 918
CPUID Command BAPIRSN Field 902
Active Environment Screen 184 BAPISIGN Field 902
CPUID Field BAPIURC Field 902
Zoom Screen 224 BAPIVERS Field 902
CREATE Field BLT Function 915
Exit Option Window 155 BLT Function Reply Codes 916
Criteria 47 BLT Function, procedure 915
Critical Path BLT Function, Setting Reply Fields 916
Deleting a Job 218 Calling 878
Job Dependency 77 Calling AJF Actions 886
PRIORITY Parameter 597 Causes of failure 897
Resource Allocation 77 CLIST and 877
Cross Memory Interface Conditional Requests 894
Online Monitor 85 Conditional Selection Criteria 894
CRSR Contents of Input and Output Registers 898
Scrolling Amount 100 Conversational Mode 878, 898
CST Task Type Create New Tables 884
IOA Log Show Screen Window 311 CTMBAPI Mode 917
Show Screen Filter 203 CTMBLT Replacement 884
CTB STEP Parameter DAAPI DD Statement 878
Description 419 Date Field Format 918
Example 420 Environment 878
CTGFORC Parameter Environments 877
CTMPARM 423 Fields in the Fixed (Header) Part 900
CTMAESIM Utility Fixed Part Values 900
AutoEdit Syntax 338, 806 Force Jobs Using 881
CTMAJO Force New Tables 884
Replaced by CTMBLT Utility 829 Force Return Codes 883
CTMAJO Program Forcing Allocations 882
Job Ordering 829 Forcing under CLIST 882
Work Flow 830 Forcing under REXX 882
CTMAPI Forcing Using a Program 882
AJF Action Return Codes 912 Generally 877
AJF Action, BAPIACON Value 911 Global Variable Return Codes 914
AJF Action, BAPIADEL Value 911 Invoking Search from a Program 889

964 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

IOA Variables Database and 880 BAPIRPLS Field 902

Masking in Character Fields 894 BAPISGRN Field 903
Multiple IF Statements 896 BAPISHLD Field 903
Order Extension 907 BAPISJID Field 903
Order Jobs Using 881 BAPISJNM Field 903
Order New Tables 884 BAPISLIB Field 903
Order Return Codes 883 BAPISMEM Field 903
Ordering Allocations 882 BAPISODT Field 903
Ordering under CLIST 882 BAPISOID Field 904
Ordering under REXX 882 BAPISOWN Field 904
Ordering using a Program 882 BAPISRBA Field 904
Pre-allocating SYSPRINT 882 BAPISRBB Field 904
Quantitative Resource Extension Function 914 BAPISRNM Field 904
Quantitative Resource Input Fields 914 BAPISSTT Field 904
Quantitative Resource Return Codes 915 BAPISTAB Field 904
Reply Mechanism Trigger Pointers 918 BAPISTAG Field 904
Requirements before Calling 878 BAPISTYP Field 904
REXX and 877 BAPIWORK Field 902
Scanning and Filtering Reply Lines 918 Components 899
Search Call Syntax 888 DSECT 899
Search Function 888 Replies 917
Security Exit IOASE07 915 Status Extension Fields 903
Selection Criteria and Performance 896 Status Reply DSECT 905
Selection Criteria Parameter Attributes 896 Statuses Returned 905
Status Function 903 CTMBAPI DESCT 878
Syntax for executing 882, 887 CTMBJSE
Syntax Forcing Jobs 881 DESCT 905
Syntax of AJF Action under 886 CTMBLT
Syntax of Search Call 888 Parameters 884
Syntax Ordering Jobs 881 Replacement by CTMAPI 880, 884
Tailoring 879 CTMBLT Utility
Under IOA Environment 879 Assembler Macro 383
Use to checkpoint variables 880 CTMAPI BLT Function and 915
Use to resolve variables 880 Job Ordering 827
Use to Search and Query Job Details 880 Replacing CTMAJO 829
Use to Search and Query Job Status 880 CTMCAES CLIST
Use to set variables 880 CTMAESIM Utility 806
CTMAPI DSECT 899 TSO Command 338
CTMAPI Replies CTMCAES Option
Reply Mechanism Trigger Pointers 918 CTMAESIM Utility 806
CTMAPI Return Codes CTMCAES Utility
BAPIRC Field 897 AutoEdit Simulation 334
BAPIRSN Field 897 CTMCAJF Utility
BAPIURC Field 897 AUTOARCHIVE Parameter 405
Generally 897 CTMCAMNU Option
CTMBAPI Parameter Prompting Entry Panel 347
BAPIAGRN Field 911 CTMCFMNU Option
BAPIAMEM Field 911 Parameter Prompting Entry Panel 347
BAPICMDA Field 901 CTMCSIM CLIST
BAPICMDL Field 901 TSO Command 342
BAPIFLG1 Field 901 CTMEXEC CLIST
BAPIJID Field 911 Example 849
BAPIJNM Field 911 Parameter Prompting 846
BAPIOWN Field 911 CTMEXEC Option
BAPIRBAC Field 911 Parameter Planning 363
BAPIRBAN Field 911 Parameter Printing 358
BAPIRPLC Field 901 CTMFETCH CLIST

Index 965
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Parameter Prompting 846 CTMQSB Command 828

CTMFETCH Option CTMX002 Exit
Parameter Prompting 358, 362 CTMAESIM Utility 806
CTMJBINT CLIST MEMLIB Parameter 534
TSO Command 376 Parameter Prompting 851
CTMJBINT Utility RESOURCE Parameter 608
End User Job Order 376 Simulation 861
Job Order Interface 334 CTMX003 Exit
Job Ordering 827 Simulation 861
CTMJOB Utility CTMX004 Exit
Job Ordering 826, 827 RESOURCE Parameter 608
TSO environment 827 Scheduling Algorithm 610
CTMJOBRQ CLIST CTMX010 User Exit
TSO Command 336 CTMQSB Command 828
CTMJOBRQ Utility 334 CTMX013 Exit
Job Order Request 336 Statistics Screen 247
Job Ordering 827 CTMX015C Exit
CTMJSA Utility Functions 581
Statistics File Update 245 CTMX015O Exit
CTMPARM Functions 581
# JNFRT Parameter 224 CTMX2PPF Member
AECACHL Parameter 771 IOA SAMPEXIT Library 851
AUTOTAPE Parameter 248, 607 CTO147I message 704
CTGFORC Parameter 423 CTO282I Subparameter
DUEINCHK Parameter 500 DO SHOUT Statement 723
FRCOKOPT Parameter 254, 562 CTO403I pseudo-message 704
MAXCCOK Parameter 561, 562 CTO782I message 704
OVERJCLM Parameter 545, 663 CTO783I message 704
OVERJCLM parameter 628 customer support 3
TAGMAXWT Parameter 529 Customization
TBLRECHK Parameter 116 IOA 84
CTMPLEX Customizing
Minus-One Support 57 Options 59
CTMPROMP Utility 334 CYC Task Type
CTMQSB Command IOA Log Show Screen Window 311
CTMX010 Exit 828 Show Screen Filter 203
Job Ordering 827 Cyclic Job
CTMQSC Application AUTOARCHIVE Parameter 405
CTMAJO Program 829 CONFIRM Parameter 412
CTMQUICK CLIST INTERVAL Parameter 520
TSO Command 367 TASKTYPE Parameter 666
CTMQUICK Option Cyclic Jobs
Online Utilities Menu 368 Force OK 254
CTMQUICK Utility Cyclic Jobs Stopping 482
Example 375 Cyclic Started Task
Quick Schedule Definition 367 TASKTYPE Parameter 666
Schedule Definition 334
Tables 117
CTMRSTR Utility
Restoration 51
D
CTMSIM Procedure D JOB Message Type
Simulation Procedure 854 IOA Log Show Screen Window 310
CTMTAPUL Procedure D Option
Tape Pull List 854, 865, 867 Active Environment Screen 187
CTMWORK Value Job List Screen 129
SYSOPT Variable 449 Parameter Prompting 353
CTMX001 Exit Table List Screen 126

966 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

D-CAT Field DASIMPRM DD Statement

Ignored by CTMQSB Command 828 Simulation Parameter 857
D-CAT Parameter DASTAT DD Statement
Category E 386 Simulation Statistics 859
Description 422 DASUBMIT DD Statement
Example 423 AutoEdit Simulation 341
D-INT Message Type CTMAESIM Utility 807
IOA Log Show Screen Window 310 Emergency Execution 807
DAACTLOG DD Statement Data Area of Screen
MODE Parameter 731 Online Facility 96
DACKPTIN DD Statement DATA Command
Simulation Active Jobs File 856 Job List Screen 129
Tape Pull List 868 DATA Format
DACKPTOU DD Statement Job List Screen 128
Simulation Active Jobs File 860 Database Facility 278
DACNDF DD Statement Database List Screen
CONTROL-M Resources Simulation 856 Variable Database Facility 280
Simulation 864 Database Update
DAGLBLST DD IN Parameter 515
Variable Database Facility 280 DATAPNAM DD Statement
DAGLOBAL Statement 771 Tape Pull List 869
%%GLOBAL Control Statement 784 dataset cleanup 594
PARAMETER LIBRARY Parameter 807 Dataset Disposition
Daily AutoEdit Member ON DSNEVENT Statement 736
Parameter Prompting 845 DATASET Event
Daily JCL Library CMEM 692
Allocation 852 DO FORCEJOB Statement 716
Deletion 852 Dataset Event
Parameter Prompting 845 ON DSNEVENT 692, 694, 733
Daily Plan ON DSNEVENT Statement 737
Parameter Prompting 364, 845 Dataset Name
Daily Prompting Table CMEM 694
Daily Table 354 Date Calculation
Daily Scheduling Table %%$CALCDTE Function 814
Parameter Prompting 844 Date Definition
Daily Subsystem Overview 65
D-CAT Parameter 422 DATE Field
DCAL Calendar 427 Conditions/Resources 291
Daily Table Job Order Execution History 243
Table Selection Screen 354, 841 Log Screen 304
DAJCLOUT DD Statement 868 Simulation/Tape Pull 344
JOB/SCAN DOCU/TEXT 869 Date Field
Tape Pull List 868, 869 Why Screen Confirmation 217
DALIB DD Statement Date Field Format
MEMLIB Parameter 532 CTMAPI 918
DALOGIN DD Statement DATE Parameter
Tape Pull List 868 CTMEXEC CLIST 848
DALOGOUT DD Statement CTMFETCH CLIST 847
Simulation Log File 860 DO FORCEJOB Statement 715
DANRES DD Statement DATE Range
Simulation 864, 865 Job Scheduling Plan Screen 172
DANSINC DD Statement Log Screen 304
Simulation 864, 865 Manual Conditions 300
DAREPOUT DD Statement Date Range
Tape Pull List 869 Log Screen 304
DASIMOUT DD Statement DATE Reference
Simulation Messages 860 Manual Conditions 299

Index 967
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Date Reference Primary Option Menu 93

DO COND Statement 443, 712 DB/2 database
Generic 515 use with SAP/R3 923
IN Parameter 508, 517 DCAL Parameter
January 1st 74, 712 Calendar Name 427
OUT Parameter 572, 579 Calendar Type 429
Prerequisite Condition 74 DATES Parameter 424
STAT 74, 443, 712 DAYS Parameter 387
Zoom Screen 225 MAXWAIT Example 531
Date Updated Field Non-periodic Calendar 428
Parameter Prompting 356 DCAL parameter
Date Variable Periodic Calendar 429
Example 810 DD Statement
JCL Setup 762 DAACTLOG 731
DATEMEM Calendar DACKPTIN 856, 869
WCAL Parameter 682 DACKPTOU 860
dateref Parameter DACNDF 856
DO COND Statement 712 DAGLBLST 280
DATEREF Subparameter DAGLOBAL 771
DO COND Parameter 443 DAJCLOUT 869
IN Parameter 508 DALIB 532
OUT Parameter 572 DALOGIN 869
DATES Parameter DALOGOUT 860
DAYS Parameter 430 DAREPOUT 869
Description 424 DASIMOUT 860
Example 425 DASIMPRM 857
MINIMUM Parameter 540 DASTAT 859
MONTHS Parameter 424, 542 DASUBMIT 342, 807
PDS Parameter 588 DATAPNAM 869
DATES Range Field TAPULIN 867, 869
Conditions/Resources 292 TAPULOUT 869
DATETYP Parameter 436, 625 Deadline Adjustment
Day of the Week Job Flow 78
First 681 DEADLINE Argument
WDAYS Parameter 681 REFRESH Command 252
DAYJCLB Parameter Decollating Mission
CTMFETCH CLIST 847 D-CAT Parameter 422
DAYS Parameter Default Display Type
DATES Parameter 424 Active Environment Screen 176
DCAL Field 387 Job Dependency Network 250
Description 426, 671 Job Order Execution History 242
Example 430 DEFAULT Field
Format 426, 427 Parameter Prompting 361
FROM DAYS 671 DEFAULT Filter
Logic 429 Active Environment Screen 181
MINIMUM Parameter 540 Default Filter
Negative Value 429 Active Environment Screen 196
PDS Parameter 588 Log Screen 306
Runtime 671 DEFAULT STATUS Field
Scheduling Logic 388 Parameter Prompting 366
UNTIL DAYS 671 Define Parameters and Conditions
DAYTBLB Parameter Exiting 353
CTMEXEC CLIST 848 Fields 352
CTMFETCH CLIST 847 Options 353
DAYTIMEM Parameter Screen 352
ODATE 66 Type 1 Option 1 351
DB VARIABLE DEF Option Define Parameters in Master Plan

968 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Fields 360 Active Environment Screen 184

Options 362 Job List Screen 129
Screen 360 Rule List Screen 263
DEFINITION ACTIVE Parameter Year List Screen 319
Description 436 DESC Field
Forced Jobs 436 Active Environment Screen 178
Format 436 IOA Log Show Screen Window 309
FROM 137, 329, 436 Parameter Prompting 352
UNTIL 137, 329, 436 Show Screen Filter Window 199
DEL Option DESC Format
Active Environment Screen 187 Job List Screen 128
DEL Status DESC Parameter
CTMAPI 905 Description 438
Delete Commands Example 439
Edit Environment 929, 942 Description
DELETE COND Parameter THRESHOLD Parameter 753
Simulation Parameter 858 DESCRIPTION Field
Delete Confirmation Window Quick Schedule Definition 374
Active Environment Screen 218 Rule List Screen 262
Table List Screen 164 Description Field
Delete NOT-COND Option Parameter Prompting 356
Why Screen 215 DESCRIPTION Parameter
DELETE Option CMEM Rule 709
Calendar List Screen 317, 328 Example 709
CMEM Rule List 264 Scheduling Definition 130
CMEM Table List 262, 273 Destination
Conditions/Resources 294 DO MAIL Statement 458
Job List Screen 119, 130 DO SHOUT Statement 479, 480, 642, 722, 725
Parameter Prompting 353, 362 DO SYSOUT Statement 484
Table List Screen 119, 126 SYSOUT Parameter 655
Year List Screen 319 Devices
Delete Option Tape Usage 248
Table List Screen 164 DEVICES USED Field
DELETED Status Statistics Screen 248
Active Environment Screen 192 DISAPPEARED Status
Deleting Activate Option 187
Calendars 326, 330 Active Environment Screen 192
CMEM Table 273 Show Screen Filter 202
DO Statement 441 Zoom Screen 224
Manual Conditions 301 DISP Field
MSGCLASS Sysout 491 WHY Option 297
ON Statements 555 DISP Parameter
Prerequisite Condition 75, 444 ON DSNEVENT Statement 737
Sysout 486, 489, 657, 660 DISPLAY Command
Table in Table List 273 IOA Log Screen 305
Deleting a Job Job Order Execution History Screen 242
SMART Table Entity 218 Status Command 180
WAIT SCHEDULE jobs 217 Variable Zoom screen 286
DELOVRER Parameter 581 Display Command
DELOVRUN Parameter 581 Active Environment Screen 175
Dependency Display Filters Window
Maybe Job 833 Fields 308
DEPENDS ON Field Options 198, 308
Quick Schedule Definition 374 Display Filters window
DESC Fields 198
DO REMEDY parameter 467 Display Type
DESC Command Active Environment Screen 175

Index 969
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Display Type A DO Statement Action 440

Active Environment Screen 178 DO REMEDY
Display Type D sending e-mail to Remedy Helpdesk 468
Active Environment Screen 176 DO REMEDY Statement
Display Type Field DO Statement Action 440
Active Environment Screen 177 DO RERUN
Display Type Indicator Description 469
Job Dependency Network 250 DO RERUN Statement
Displaying CMEM On Spool Job 699
Job Statistics 120 DO Statement Action 440
Jobflow 120 RERUNMEM Parameter 602
Statistics 147 DO RULE Calls
DO Action Nesting 720
DO Statement 140 DO RULE Statement
DO COND Parameter AutoEdit 719
COND-NAME Subparameter 443 CONTROL-O Rule 693, 719
DATEREF Subparameter 443 Example 721
Long Condition Names 442, 445 DO SET
OPT Subparameter 444 Global Variables 278
DO COND Statement DO SET Statement
CMEM Rule 693, 712 AutoEdit Statement 808
Conflicts 445 Description 472
Definition 442 DO Statement Action 440
DO Statement Action 440 Example 475
Example 447, 713 Global Variable 773
Logic 444 JCL Setup 778
OUT Parameter 446, 575 Local Variable 770
Prerequisite Condition 72, 508, 713 SET VAR Parameter 474, 632
DO CTBRULE Statement User-Defined Variables 759
Description 448 DO SHOUT Statement
DO Statement Action 440 CMEM CONTROL-O 693
Example 449 CMEM Rule 722
DO FORCEJOB Statement CONTROL-O 722
Active Jobs File 716 CTO282I Subparameter 723
CICS Job 718 DO Statement Action 440
CMEM On Spool Job 698 Example 481, 646, 726
CMEM Rule 693, 715 JES 723
Dataset Event 716 Route Codes 724
Description 450, 715 Shout Facility 476
DO Statement Action 440 DO Statement
Example 452, 717 CMEM Rule 693, 707, 711
Logic 716 CMEM Rule Definition 267
RERUNMEM Parameter 602 Description 440
DO IFRERUN Statement Logic 441
Description 453 Post-Processing Parameters 140
DO Statement Action 440 Summary 393
Example 457 DO STOPCYCL
Job Rerun 233 Description 482
RERUNMEM Parameter 602 DO STOPCYCL Statement
Scheduling Definition 225 DO Statement Action 441
DO MAIL Statement DO STOPJOB Statement
Description 458, 467 CMEM Rule 693, 727
DO Statement Action 440 Description 727
DO NOTOK Statement Example 728
DO Statement Action 440 DO SYSOUT Statement
DO OK Statement Archiving Facility 491
Description 464 Description 484

970 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Diagram 488 SHOUT Parameter 637

DO Statement Action 441 DUEIN Field
Example 490 Job Dependency Network 251
Logic 487 DUEINCHK Parameter
Merging 488 CTMPARM 500
SYSOUT Parameter 490, 656, 661 DUEOUT Field
DOC Command Job Dependency Network 251
Scheduling Definition 146, 149, 226 Dummy Class
DOC Lines DO SYSOUT Statement 487
Scheduling Definition 150, 497 SYSOUT Parameter 658
Status Zoom Screen 497 DUMMY Job
DOCLIB Field Status 395, 396
Scheduling Definition 150 DUMMY Jobs
DOCLIB Parameter MEMBLIB Parameter 396
Description 495 DUMMY Library
Example 496 MEMLIB Parameter 532
DOCMEM Field OVERLIB Parameter 580
Scheduling Definition 150 DUMP Command
DOCMEM Member Active Environment Screen 185
DOCLIB Library 495 duplicate dataset prevention 594
DOCMEM Parameter DUPLICATE Field
Description 497 Scheduling Confirmation 159
Example 498 Dynamic Destination Table
DOCU/TEXT 495, 497 DO SHOUT Statement 479, 642, 725
Browse Mode 149 Dynamic Group Insert Facility 71
Interface 334, 378, 869 Dynamic insert job into group Field
INVOKE JOBSCAN Parameters 869 Scheduling Confirmation 159, 160
JCL Documentation 378
Online Utilities Menu 333
Option 333
Option U1 334
E
Simulation/Tape Pull 343 E Option
Tape Pull List 869 Active Environment Screen 188
Utility 334 Display Filters Window 308
Documentation Job List Screen 127
AUTO-SAVE Field 125 Manual Conditions 301
AUTOSAVE Field 151 ECJ Task Type
DESC Parameter 438 IOA Log Show Screen Window 311
Editing 150 Show Screen Filter 203
Saving 151 ECS Task Type
Scheduling Definitions 149 IOA Log Show Screen Window 311
Double Confirmation Window 161 Show Screen Filter 203
DOWN Command EDIT Command
PF08/PF20 97, 99 CMEM Rule Definition 269
DSN Parameter Job Scheduling Definition 927
ON DSNEVENT Statement 737 Scheduling Definition 146
DSNEVENT criteria Edit Entry Panel
STEPRC field 701 IOA Editor 106
DSNEVENT Statement 266 Edit Environment 927
DUE IN Time CMEM Rules 270
DUE OUT Parameter 500 Description 927
DUE OUT Parameter Example 932
Description 499 Line Editing Commands 148
Example 500 EDIT Option 188
Job Flow 77 Active Environment Screen 188
DUE OUT Time Display Filters Window 308
REFRESH Command 252 Display Filters window 198

Index 971
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Editing Job Ordering 827

CMEM Rule Definition 270 Utility CTMJBINT 376
CMEM Rules 258 END_NOK_ABND Status
Documentation 150 CTMAPI 905
Example 932 END_NOK_CC Status
Job JCL 129, 188 CTMAPI 905
Rule Definitions 941 END_NOK_DISA Status
Scheduling Definition 148, 927 CTMAPI 905
EDMEM command END_NOK_JCLE Status
IOA Editor 106 CTMAPI 905
ELAPS Field END_NOK_NSUB Status 905
Job Dependency Network 251 END_NOK_UNKW Status
ELAPSE Field CTMAPI 905
Zoom Screen 223 END_OK Status
ELAPSE TIME CTMAPI 905
Job Flow 78 END_OK_FOK Status
Elapse Time CTMAPI 905
DUE OUT Parameter 500 ENDED NOT OK – ABENDED Status
ELAPSED Field Active Environment Screen 192
Job Order Execution History 243 ENDED NOT OK – DUE TO CC Status
ELAPSED Run Time Field Active Environment Screen 192
Statistics Screen 247 ENDED NOT OK – JCL ERROR Status
ELAPSED Time, SMART Table Active Environment Screen 192
Statistics Screen 247 ENDED NOT OK – RERUN WAS NEEDED Status
Emergency Execution Active Environment Screen 192
DASUBMIT DD Statement 807 ENDED NOT OK – TERM ON NCT2 Status
Emergency Job Active Environment Screen 192
MAXWAIT Parameter 529 ENDED NOT OK Status
TASKTYPE Parameter 666 Active Environment Screen 192
EMR Task Type TERMINATE Option 254
IOA Log Show Screen Window 311 ENDED NOTOK Status
Show Screen Filter 203 DO STOPJOB Statement 727
End Code ENDED NOTOOK Status
ON Statement 559 Active Environment Screen 195
END Command ENDED OK FORCED OK Status
Calendar Definition Screen 331 Active Environment Screen 192
CMEM Rule Definition 271 ENDED OK Status
IOA Log Show Screen Window 313 Active Environment Screen 192, 195
PF03/PF15 97 Job Graph 212
Scheduling Definition 153 Show Screen Filter 202
Show Screen Filter 206 TERMINATE Option 254
END NOT OK Status ENDED Status
END NOTOK Status 172 Show Screen Filter 202
END NOTOK Field ENTER Key
Global View Screen 207, 209, 211 AutoRefresh Mode 104
END NOTOK Status Enter YES Field
Job Graph 210, 212 Simulation/Tape Pull 347
END OK Field ENTER YES TO CONTINUE Parameter
Global View Screen 207, 209, 211 Description 338
Job Graph 210 Prerequisite Condition Utility 336
END OK Status Entry Panel
ENDED OK Status 145 AutoSave Documentation 151
END TIME Field Calendar Facility 315
Statistics Screen 247 CMEM Rule Definition 260
End TRACE level CMEM Rule Facility 259
SET Command Panel 110, 111 Exiting 155
End User Job Order Interface IOA 88

972 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Parameter Prompting 347 Statistics Screen 245

Scheduling Facility 118, 121, 155 Execution Time
Table Creation 116 DUE OUT Parameter 500
Environment EXERR Code
Online Facility 85 ON Statement Codes 561
Environment Specification EXERR Status
SET VAR Parameter 633 Description 392
EQ Operator ON Statement 557
AutoEdit Facility 786 Exit
ERASE Option CTMX001 828
Manual Conditions 301 CTMX002 534, 608, 806, 851, 861
Errors Only Field CTMX003 861
Simulation/Tape Pull 347 CTMX004 608
EST Task Type CTMX013 247
IOA Log Show Screen Window 311 CTMX014 534
Show Screen Filter 203 Exit Command
Event Selection Parameter Online Facility 95
CMEM Rule 266, 706 EXIT Option
Exclusive Control Online Utilities Menu 333
CONTROL Parameter 414 Parameter Prompting Entry Panel 347
Exclusive Resource Primary Option Menu 91
WAIT SCHEDULE Status 293 Exit Window
EXEC A PLAN Option Job List Screen 154
Parameter Prompting 845 Rule List Screen 271
EXEC Phase Exiting
Parameter Prompting 361 CMEM Entry Panel 273
EXEC Status CMEM Rule Facility 271
CTMAPI 905 CMEM Rule List 271
Exec/Order a Plan CMEM Table List 273
Parameter Prompting 363, 367 Define Parameters in Master Plan 362
EXEC_ERR Status IOA Log Show Screen Window 312
CTMAPI 905 Job List 155
EXEC_INQ Status Job Scheduling 153
CTMAPI 906 Quick Schedule Definition 375
EXEC_NJE Status Scheduling Definition 153
CTMAPI 906 Show Screen Filter 205
EXEC_WSUB Status Exits
CTMAPI 906 CTMX015C 581
EXECTIME Limit CTMX015O 581
SHOUT Parameter 638 External Tape
Execute a Plan Example 815
CTMEXEC CLIST 846
EXECUTING (SYSOUT IN HOLD STATUS)
Active Environment Screen 192
EXECUTING Field
F
Global View Screen 207, 209, 211 F Option
EXECUTING Status Active Environment Screen 187
Job Graph 210, 212 Job List Screen 130
Show Screen Filter 202 Table List Screen 120, 126, 156
Execution Delay FAILED REASON UNKNOWN Status
MAXWAIT Parameter 528 Activate Option 187
Execution Error Fast Exit
ON Statement 559 Online Facility 95
Execution Information Fetch a Plan
Job Order Execution History 241 CTMFETCH CLIST 846
Statistics Facility 55 Parameter Prompting 362
Execution Statistics FETCH A PLAN Option

Index 973
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Parameter Prompting 844 FORCED SCHEDULING Parameter 338

Field-Sensitive Help Forcing Jobs
Online Facility 103 Overview 68
File Name Forecasting
DO SYSOUT Statement 484 Overview 55, 56
SYSOUT Parameter 655 Simulation 55
File Prefix Form Type
Parameter Prompting 350 APPL FORM Parameter 401
File Transfer FR Parameter
Example 714 STEP RANGE Parameter 652
File Transfer to PC FRCOKOPT Parameter
PC PACKET STATUS Option 714 CTMPARM 254, 562
Filter FREE Option
Job Dependency Network 249, 250 Active Environment Screen 187
FILTER Field Free Tracks
Active Environment Screen 177 MINIMUM Parameter 540
IOA Log Show Screen Window 309 PDS Parameter 588
Show Screen Filter 199, 309 FRM Parameter
Filtering DO SYSOUT Parameter 484
Active Environment Screen 196 FROM Class
Log Screen 306 DO SYSOUT Statement 484, 487
FIND Command SYSOUT Parameter 655, 658
Description 100 FROM DATE Field
Graphic Jobflow Screen 168 Date Range Window 170
PF05/PF17 97, 169 FROM DAYS
FLUSH Code TIME + DAYS Parameter 671
+EVERY Step 558 FROM Field
ON Parameter 562 Zoom Screen 223
FLUSH Value FROM STEP Field
PREVENT-NCT2 Parameter 593 Restart Confirmation Window 233
FORCE Code Restart Step List Window 241
ON Statement 557 From Step/Proc $FIRST/$CLEANUP
ONStatement Codes 561 Rerun/Restart Window 235
Force Job FROM subparameter
CMEM 693 INTERVAL Parameter 521
FORCE OK FROM TIME
ANYSTEP 254 TIME + DAYS Parameter 671
Force OK FROM Time
%%JOBCC 766 TIME Parameter 671, 673
%%MAXRC 766 fromcol Parameter
Cyclic Jobs 254 FIND Command 101
SMART Table Entity 254 FROMJOB Field
FORCE OK Confirmation Window Quick Schedule Definition 371
Active Environment Screen 255 FTP products
Description 254 CMEM 703
FORCE OK Option FUNCTION Field
Active Environment Screen 255 Prerequisite Condition Utility 335
FORCE Option FUNCTION Parameter
CMEM Table List 262, 274, 694 AutoEdit Simulation 341
DO FORCEJOB Statement 450 Functions
Job List Screen 120, 130 IOA Primary Option Menu 90
Manual Scheduling 156
Table List Screen 120, 126, 156
FORCE# RT Installation Parameter 451, 717
FORCE# WI Installation Parameter 451, 717
G
FORCED FROM TIME Field G Option
Parameter Prompting 364 Table List Screen 126

974 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

GDG Adjustment 594 Number of Characters 68

GE Operator Gregorian Date Standards
AutoEdit Facility 786 Overview 67
General Job Parameter GROUP Command
Scheduling Definition 134 Active Environment Screen 185
GENERAL Library Log Screen 305
DALIB DD Statement 534 GROUP Criteria
MEMLIB Parameter 532 IOA Log Show Screen Window 311
OVERLIB Parameter 581 GROUP Field
GENERAL Message Type Active Environment Screen 178
IOA Log Show Screen Window 310 Global View Screen 208
General Parameters Group 145
CMEM Rule 706 Quick Schedule Definition 371
CMEM Rule Definition 267 Show Screen Filter 201
Summary 384 Group Handled Jobs 116
General Profile Group Name
Active Environment Screen Filter 196, 306 GROUP Parameter 502
Generation Data Sets JOBSTART Command 147
CMEM 703 GROUP NAME Field
Generation Dataset (GDG) Adjustment 594 View Graph Screen 210
Generic Resource GROUP NAME Parameter
Example 817 AutoEdit Simulation 340
GLOBAL Control Statement GROUP Parameter
%%GLOBAL 784 CMEM Rule 729
Global Profile Description 502
Customizing 85 Emergency Jobs 668
Global Variable Example 504
AutoEdit 758 MAXWAIT Parameter 529
Backslash Character 767 SMART Table Entity 145
Distinguishing 774 Group Scheduling
JCL Setup 773 Job List Screen 127
Resolution 778 Logic 388
Syntax 774 MAXWAIT Parameter 529
Global Variable Database Option O 156
Structure 773 Group Statistics
Global Variable Extension 913 Global View Screen 206
Global Variable Return Codes View Graph Screen 208
CTMAPI 914 Group Status
Global Variables Global View Screen 208
Variable Database Facility 278 Group-Handled Jobs 116
Global View Screen Groupname Argument
#END Field 208 JOBSTART Command 182
# EXC Field 208 GRP MAXWAIT parameter 506
Active Environment Screen 186 GRP Task Type
Fields 207 IOA Log Show Screen Window 311
Group Statistics 206 GT Operator
GOING TO START Status AutoEdit Facility 786
Active Environment Screen 192
Graphic Display
Job Status 186
GRAPHIC FLOW Option
H
Table List Screen 126, 168 H Option
Graphic Jobflow Active Environment Screen 186
Display Width 168 HALF Page
Screen 168 Scrolling Amount 99
Gregorian Date Format HELD Class
Definition 67 DO SYSOUT Statement 485

Index 975
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Held Class ON DSNEVENT Statement 738, 747

SYSOUT Parameter 656 IEFPROC Stepname
HELD Status ON DSNEVENT Statement 737
Active Environment Screen 193 ON STEP Statement 746
CMEM On Spool Job 698 IF Logic
Job Deletion 218, 255 Example 821
Help IGD101I message 703
Line Sensitive 103 IGD104I message 703
Online Help 104 IGD105I message 703
HELP Command IGD107I message 703
PF01/PF13 97, 103 IGD108I message 703
Hexadecimal Value IGD17101 message 703
Special Characters 86 IGNORE DSN Parameter
HIST Installation Parameter Tape Pull List 868
CONTROL-M/Restart 50 IGNORE IN Parameter
HISTORY Command IOALDNRS Utility 842
Active Environment Screen 181 IGNORE JOB Parameter
History Environment Screen 252 Tape Pull List 868
Options 253 Implementation
RESTORE Option 254 Job Scheduling 826
History Jobs File Manual Conditions 831
# OF DAYS TO KEEP 612 Parameter Prompting 837
# OF GENERATIONS TO KEEP 614 IMS/DC 85
Description 50 PF06/PF18 97
History Jobs file 406 IMSACTIVE
History Jobs file and 406 Prerequisite Condition 578
HLDCLAS Installation Parameter IN Condition
DO SYSOUT Statement 485 Erased Automatically 396
SYSOUT Parameter 656 IOALDNRS Utility 831
HOLD Field Job Dependency 249
Scheduling Confirmation 159 IN Field
HOLD Option Zoom Screen 223
Active Environment Screen 186 IN Parameter
Host Node COND-NAME Subparameter 507
NJE Network 52 DATEREF Subparameter 508
Description 507
Example 513
I Logic 510, 516
Long Condition Names 507, 509
I Option Quick Schedule Definition 368
Job List Screen 130 IN PROCESS Status
Parameter Prompting 353 Show Screen Filter 202
I1 ISPF Utility IN Statement
Add Prerequisite Condition 334 Manual Conditions 298
Check Prerequisite Condition 334 Prerequisite Condition 72
Delete Prerequisite Condition 334 INCLIB Control Statement
I1 Option %%INCLIB 788
Online Utilities Menu 335 INCONTROL
IBM Core Description 64
3720 Terminals 86 INFO Command
IBM FTP Primary Option Menu 91
CMEM 704 Information about Job
IDMS/DC 85 DESC Parameter 438
PF06/PF18 97 Input Files
IEF125I Message Simulation 855
ON DSNEVENT Statement 738, 747 Input Registers
IEF403I Message CTMAPI 898

976 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

INQ/UPD MEDIA DB Option Description 64

Primary Option Menu 93 IOA Editor 106
INSERT BY WEEK DAYS Option Command line commands 108
Year List Screen 319 Edit Entry Panel 106
Insert Command EDMEM command 106
Edit Environment 930, 943 PFKey functions 107
INSERT Option Row commands 108
CMEM Rule List 264 IOA Editor screen 107
Job List Screen 118, 130 IOA Entry Panel 88
Parameter Prompting 353, 362 IOA Global Variable Database
Year List Screen 319 AutoEdit 758
Inserting Structure 773
Relevant Screen or specific item to insert 320 IOA Log Facility 303
Inserting Additional Job 71 Description 51
Installation Working Date Post-processing 51
Working Date 762 IOA Log Screen
INSTREAM JCL Parameter DISPLAY Command 305
Description 518 Messages 312
Interval IOA Log Show Screen Window
Periodic Calendar 324 Activating 307, 308
INTERVAL Parameter Activating Filters 307
Description 520 Active Environment Screen 308
Example 522 DESC 309
FROM Subparameter 521 Exiting 312
INTERVAL Subparameter 520, 521, 523 Fields 309
RERUNMEM Parameter 603 Message Types 312
Simulation 857 IOA Manual Conditions 62
Simulation/Tape Pull 345 IOA Manual Conditions Screen
TASKTYPE Parameter 667 Manually Releasing Jobs 396
INTERVAL Subparameter IOA Primary Option Menu 89
INTERVAL Parameter 520, 521, 523 Option 6 333
INTRDR Internal Reader Option 7 298
Submit Authority 343 Option F 93
Tape Pull List 866 Option S 303
INVOKE JOB/SCAN PC PACKET STATUS 93
Simulation/Tape Pull 346 IOA SAMPEXIT Library
Tape Pull List 869 SAMPEXIT Library 534
IOA IOA SET 109
Conditions File 64 IOA Variable Database 913
Customization 84 IOA Variable Database Facility 278
Display Format Members 85 Entry Panel 279
Log File 64 IOA Variables Database
Manual Conditions File 64 CTMAPI and 880
Primary Option Menu 89 IOA Variables Facility
Under ISPF 105 Entry Panel 279
IOA Calendar Facility IOA125I message 701, 702
Calendar Facility 313 IOA283I message 702
IOA Conditions IOA285I message 702
File 288 IOA287I message 702
IOA Conditions File 289 IOA403I message 701, 702
IOA Conditions/Resources IOAAPI Functions 881
Screen 288 IOADFLT Parameter
IOA Conditions/Resources File 289 IOAENV Library 429
IOA Conditions/Resources Screen IOADLD Utility
Description 288 Variable Database Facility 285
Manually Releasing Jobs 396 IOADUL Utility
IOA Core Variable Database Facility 285

Index 977
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

IOAID Field JCL ERROR Status

Conditions/Resources 290 Show Screen Filter 202
IOALDNRS Utility 298 JCL Expanded
Manual Conditions 831, 839 SYSDATA 70
Parameter Prompting 842 JCL Library
IOALog Screen 62 CTMQSB Command 828
IOANOTE Utility OVERLIB Parameter 580
Tasktype WRN 668 PPF2DAY Job 852
IOASE07 Security Exit 915 PPF2DEL Job 852
IOAUTIL CLIST JCL Library Mode
Online Utilities 333 AutoEdit Syntax Testing 339, 806
IOAVAR Parameters 340, 741
Variable Database Facility 278 JCL LIBRARY Parameter
IOAVARLD Job AutoEdit Simulation 340
Variable Database Facility 285 JCL Management
IOAVARUL Job CMEM On Spool Job 699
Variable Database Facility 285 JCL Member
ISPF 99 OVERLIB Library 580
AutoRefresh Mode 105 OVERLIB Parameter 341
PACK Option 314 RERUNMEM Parameter 602
ISPF Commands JCL Modification
Priority 105 OVERLIB Parameter 580
ISPF PACK Option 537 JCL Option
Scheduling Definition 114 Active Environment Screen 188
ISPF SPLIT Command Job List Screen 130
PF02/PF14 97 JCL SET
ISPF/PDF Facilities AutoEdit SET Statement 783
Online Facility 112 JCL Setup
ISPF/PDF Primary Option Menu %%ELSE Control Statement 785
ISPF KEYS Command 105 %%ENDIF Control Statement 785
ISPSTART Command %%GLOBAL Control Statement 784
ISPF Keys 105 %%GOTO Control Statement 785
IV Option %%IF Control Statement 785
IOA Primary Option Menu 279 %%INCLIB Control Statement 788
%%INCMEM Control Statement 788
%%LABEL Control Statement 785
J %%LIBSYM Control Statement 789
%%MEMSYM Control Statement 789
J Option %%RANGE Control Statement 790
Active Environment Screen 188 %%RESOLVE Control Statement 791
Job List Screen 130 %%SET Control Statement 792
JCL AutoEdit 46, 794
Editing 188 Control Statement 783
in job definition 518 CTMAESIM Utility 806
instream 518 Date Variable 762, 810
JCL Check Field DO SET Statement 779
Simulation/Tape Pull 347 Global Variable 773
JCL Command Local Variable 770
Job List Screen 119 Modification 580, 757
JCL Documentation Nested Expressions 787
DOCU/TEXT Product 378 Operators 786
JCL Edit Syntax Checking 806, 865
Active Environment Screen 188 Sysout Archiving 809
Job List Screen 130 System Variable 760
JCL Error User-Defined Variable 767
Intentional 779 Variable Resolution 780
ON Statement 559 Work Flow 778

978 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

JCL Statement Job Arrival Event

MEMNAME Parameter 537 CMEM 692, 741
Syntax Checking 806, 865 DO FORCEJOB Statement 716
JCL statement Job Arrival Rules
limitations 518 CMEM On Spool Job 699
JCL Syntax Job Chain
Checking 806, 865 DO COND Statement 447
CTMSCIM Utility 343 IN Parameter 515
JCLFILE Parameter Job Copying 162
DAJCLOUT DD Statement 869 Job Deletion
Tape Pull List 868 Active Environment Screen 218, 255
JES HOLD Command Undeleting 188
Job Status 192 Job Dependency
JES Initialization %%PLANID 848
SYSDATA Output Class 70 Critical Path 77
JES Instruction Job Flow 78
DO SYSOUT Statement 487 Maybe Job 833
SYSOUT Parameter 658 Predecessor/Successor Job 77
JES Spool Prerequisite Condition 73, 508
ON JOBARRIV Statement 741 REFRESH Command 182
JES2 Job Dependency Network
cpuid 533 Commands 251
DO SHOUT Statement 477, 723 Description 249
DO SYSOUT Statement 485 NET Option 187
SHOUT Parameter 639 Quick Schedule Definition 372
SYSOUT Parameter 656 Job Documentation
JES3 DESC Parameter 438
cpuid 533 Documentation 149, 150
DO SHOUT Statement 477, 723 Job End Event
DO SYSOUT Statement 485 CMEM 692, 733
SHOUT Parameter 639 Job Execution Time
SYSOUT Parameter 656 DUE OUT Parameter 500
JESDS Subparameter Job Filter
SYSDATA Output Class 70 Log Screen 220
JESYSMSG 700, 702 Job Flow
JFAIL Code Adjustment 60, 77
ON Statement Codes 561 ELAPSE Time 78
JFAIL Status Manual Modification 79
Description 392 Job Flow Report
JLOST Code Prerequisite Condition 77
ON Statement Codes 561 Job Forcing
JLOST Status CMEM On Spool Job 699
ON Statement 557 Definition 68
JNRUN Status Logic 699
Description 392 Job Graph
ON Statement 557 ENDED OK Status 254
JNSUB Code JOB GRAPH Line
ON Statement Codes 561 View Graph Screen 210, 211
JNSUB Reason Job Interdependency
NOT SUBMITTED Status 779 Job Dependency 372
JNSUB Status Job List Exit Window
ONStatement 557 Table Creation 117
Job Job List Screen
Displaying Jobflow 120 Commands 129
Displaying Statistics 120 COPY Option 119
Job Activation Option Copying Jobs 162
Active Environment Screen 187 Delete Job 127

Index 979
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Description 127 AutoEdit Simulation 342

Edit JCL 130 JOB SCHEDULE DEF Option
Exiting 154 IOA Primary Option Menu 91
Fields 373 Job Scheduling 155
Format 128 Alternative Methods 826
Job Ordering 827 AutoEdit Facility 759, 808
Manual Job Scheduling 155 CTMAJO Program 829
Options 119, 129, 374 CTMJOB 826
Quick Schedule Definition 372 CTMQSB Command 827
Scheduling Definition 117 Implementation 827
Job Log Screen 131
SYSDATA 70 Special Purpose Job 826
Job Name Table List Screen 827
Example 817 Job Scheduling Definition
Job Scheduling Plan Screen 172 Calendar Facility 54
MEMNAME Matching 699 CMEM Rule 697
JOB NAME Parameter Commands 146
AutoEdit Simulation 341 Group-Handled Jobs 116
Description 337 New Day Processing 46
ON JOBARRIV Statement 741 Parameters 44
ON JOBEND Statement 743 Storing 44
Parameter Prompting 361 job scheduling definition
Job On Spool DOC Lines 497
On Spool Job 696 Job Scheduling Plan
Job Order Execution History Screen Calendar Format 170
Active Environment Screen View Option 187 Screen 171, 172
Description 241 Job Status
Fields 242 Active Environment Screen 191, 192
JOB ORDER ISSUE Option Description 391
Online Utilities Menu 333 JOB STATUS Field
Job Ordering 155 Global View Screen 208
Definition 68 JOB STATUS Option
End User Job Order 376 IOA Primary Option Menu 91
Example 814 Job Submission
Job Order Panel 827 Manual Confirmation 412, 455
Order ID 70 Scheduling Criteria 47
Quick Submit Command 827 Job Sysout
Special Purpose Job 829 Sysout... 70
Utility 336 JOB Task Type
JOB Parameter IOA Log Show Screen Window 311
DO FORCEJOB Statement 450, 715 Show Screen Filter 203
ON STEP Statement 745 Job Task Type
Job Parameters TASKTYPE Parameter 666
Scheduling Definition 134 Job Termination
Job Priority DO STOPJOB Statement 727
Priority... 77 ON JOBEND Statement 743
Job Production JOB TYPE Parameter
Scheduling 383 ON JOBARRIV Statement 741
Job Reactivate Option Job Type Parameter
Active Environment Screen 187 ON JOBEND Statement 743
Job Request Utility Screen Parameters 337 Job Undeleting 188
Job Rerun 69 JOB WAIT FOR PIPES COLLECTION
MAXRERUN Parameter 525 Why Screen 213
Job Restart 69 JOB/SCAN
Job Run Statistics INVOKE JOBSCAN Parameters 869
Statistics Screen 245 Simulation/Tape Pull 343
JOB SCAN Tape Pull List 869

980 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

JOB/SCAN Product
AutoEdit Simulation 342 K
JOBARRIV Statement 266 Keyboard Character
JOBEND Statement 266 Hexadecimal Value 86
Jobflow KEYS Command
Graphic Display 168 ISPF/PDF Primary Option Menu 105
JOBID Field KILL option 191
Active Environment Screen 177 KOA Recorder Option
Statistics Screen 246 Primary Option Menu 93
Zoom Screen 222 KSL ADDMNCND Utility
JOBID, SMART Table Entity Maybe Jobs 834
Statistics Screen 247
JOBNAME Criteria
IOA Log Show Screen Window 311
JOBNAME Field
L
Active Environment Screen 177 L Command
Job Order Execution History 243 Parameter Prompting 352, 355, 361
Statistics Screen 246 L Option
Zoom Screen 222 Active Environment Screen 186, 219
JOBNAME Parameter LABEL Control Statement
ON DSNEVENT Statement 736 %%LABEL 822
JOBNAME, SMART Table Entity Last Working Date
Statistics Screen 247 Example 813, 819
Jobs Left Field LATE EXECUTION Status
Simulation/Tape Pull 346 Active Environment Screen 193
JOBSTAT Command LATE Field
Active Environment Screen 182 Job Dependency Network 251
Job Scheduling Definition Screen 147 Show Screen Filter 198
JODID Field LATE Status
Job Order Execution History 243 Active Environment Screen 193
Joining LATE SUBMISSION Status
Concatenation 781 Active Environment Screen 193
Journal File LATESUB Value
Overview 64 SHOUT Parameter 637
Journaling LE Operator
Description 50 AutoEdit Facility 786
JRNL Installation Parameter Leap Year
Journaling 51 Definition 797
JSECU LEFT Command
ON Statement Codes 561 PF10/PF22 97
JSECU Status LEVEL Field
ON Statement 557 Job Dependency Network 251
JTYPE Parameter LIBRARIAN 534, 581
ON DSNEVENT Statement 736 Job Documentation 150
ON JOBARRIV Statement 741 Library
ON JOBEND Statement 743 Maintenance 540, 588
ON STEP Statement 745 LIBRARY Field
Julian Date Calendar Facility Entry Panel 316, 327
JCL Setup 762 CMEM Entry Panel 260
Julian Date Format CMEM Rule Exit Option 272
Definition 68 Exit Option Window 154
Julian Date Standards Parameter Prompting 351, 359
Overview 68 Quick Schedule Definition 369
LIBRARY Parameter
DO FORCEJOB Statement 450, 715
DO RULE Statement 719
Save Documentation Window 152

Index 981
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Line Editing
Edit Environment 927, 929, 941, 942 M
Example 932 M JOB Message Type
Job List Screen 374 IOA Log Show Screen Window 310
Line Editing Commands 929, 942 M-INT Message Type
Line Number Field IOA Log Show Screen Window 310
Quick Schedule Definition 373 M1 Option
Linking Online Utilities Menu 336
Concatenation 780 M2 Option
LIST Function Online Utilities Menu 338
AutoEdit Simulation 341 M3 Option
LIST Value Online Utilities Menu 342, 868
PREVENT-NCT2 Parameter 593 M4 Option
LOADGLOBAL Operator Command Online Utilities Menu 347
Variable Database Facility 288 M5 Option
Loading to Cache Online Utilities Menu 367
%%GLOBAL Members 771 M6 Option
Local Variable Online Utilities Menu 376
AutoEdit 758 Mail Prefix Value
Distinguishing 774 DO SHOUT Destination 478, 723
JCL Setup 770 MAILDEST 479, 642
LOCATE Command MAILDEST table 479, 642
Description 100 Main Menu
Location Commands IOA Primary Option Menu 89
Edit Environment 930, 944 Maintenance
Log File 64 Libraries 540, 588
CONTROL-M Log Screen 219 MAINVIEW Batch Optimizer (MVBO)
IOA Log Screen 303 CONTROL-M Support 58
LOG Mode Implementation 835
CMEM Rule Simulation 731 PIPE Parameter 590
LOG Option System-Related Considerations 837
Active Environment Screen 186, 219 MAINVIEW Batch Optimizer (MVBO) Option
Primary Option Menu 90 Active Environment Screen 191
Log Screen Manual Conditions
CATEGORY Command 305 Add Condition 300
Commands 304 Description 298
CONTROL-M Log Screen 219 Fields 299
Description 303 Loading 831
Example 96 Maybe Job 831
Fields 304 Options 301
Filtering 306 Overview 62
GROUP Command 305 Unscheduled Condition 831
IOA Log Screen 303 Manual Conditions File 64
Job Messages 303 Manual Intervention 831
MESSAGE TYPE Codes 310 Unscheduled Conditions 832
Overview 62 Manual Confirmation
Stacking Multiple Jobs 220 CONFIRM Parameter 412
Long Condition Names DO IFRERUN Statement 455
DO COND Parameter 442, 445 Rerun Confirmation 229
IN Parameter 507, 509 Restart Confirmation 231
OUT Parameter 571, 574 Manual Intervention
Long Prerequisite Condition IN Parameter 509
Adding 292 OUT Parameter 573
LPAR Field Prerequisite Condition 62, 75
Zoom Screen 224 Manual Job Ordering 155
LT Operator Manual Job Release 396
AutoEdit Facility 786 Manual Job Scheduling 155

982 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Manual Rerun WHY Option 297

MAXRERUN Parameter 526 MEMBER NAME Parameter
Manual Reruns AutoEdit Simulation 340
Rerun Confirmation 229 MEMBER Parameter
Restart Confirmation 231 Save Documentation Window 152
Masking Member Specification
Description 87 %%GLOBAL Control Statement 784
ON Statement 735 MEMBLIB Parameter
ON Statement CODES 564 PSEUDO Jobs 396
Master Console MEMLIB Library
SHOUT Parameter 638 COPMEM2O Parameter 581
Master Plan JCL Member 188
Parameter Prompting 358, 843 MEMLIB Parameter
Master Plan PREFIX AutoEdit Variable 809
Parameter Prompting 363 Daily JCL Library 850
Master Scheduling Table Description 532
Parameter Prompting 843 DUMMY Jobs 396
Master Table Creation Example 535
Parameter Prompting 350 Job 532
MAX OVERLIB Parameter 580
Scrolling Amount 100 Started Task 533, 535
MAX Field System Variables 759
Conditions/Resources 290 MEMNAME Criteria
MAX RC Field Active Environment Screen Filter 200
Job Order Execution History 243 IOA Log Show Screen Window 311
MAXCCOK Parameter MEMNAME Field
CTMPARM 561, 562 CMEM Rule 697
MAXDAYS Parameter Global View Active Environment Screen 208
AUTOARCHIVE Parameter 405 Job Name Matching 699
MAXRERUN Limit Job Order Execution History 242
Manual Job Rerun 229 Quick Schedule Definition 373
MAXRERUN Parameter Show Screen Filter 200
Description 525 SMART Table Entity 145
RERUNMEM Parameter 603 MEMNAME Parameter
MAXRUNS Parameter D-CAT Parameter 422
AUTOARCHIVE Parameter 405 Description 537
MAXWAIT Parameter 530 Example 538
Basic Scheduling Criteria 389 MAXRERUN Parameter 526
Description 528 OVERLIB Library 580
Example 530 Scheduling Definition 130
Maybe Dependency SMART Table Entity 145
Maybe Job 75 MEMNAME Value
Unscheduled Condition 833 CMEM On Spool Job 697
Maybe Job DOCMEM Default 497
@ OUT Conditions 833 Job Scheduling 830
ADDMNCND Utility 834 Simulation 858
Job Dependency 75 MEMSYM Control Statement
Manual Conditions 831 %%MEMSYM 789
Prerequisite Condition Prefix 833 Message Content
SMART Table 834 Group Name 503
MCT MESSAGE Field
Simulation 861 Log Screen 304
MCTSMIND Parameter Prompting 361, 366
Simulation 861 Message File
MEM/MIS Criteria Simulation 860
IOA Log Show Screen Window 311 Message Generation
MEMBER Field DO SHOUT Statement 476

Index 983
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

DO Statement 440 MS Parameter

SHOUT Parameter 636 SHOUT Parameter 640
Message Handling MSG Library
Log File 62, 303 Help Member 104
Shout Facility 50 MSG STATISTICS Option
Message Line IOA Menu 93
Online Facility 96 MSGCLASS Parameter
MESSAGE Parameter SYSDATA Output Class 70
DO SHOUT Statement 724 MSGCLASS Sysout
Message Type CMEM On Spool Job 696
IOA Log Show Screen Window 312 DO SYSOUT Statement 487
Message Type Criteria SYSOUT Parameter 655, 658
IOA Log Show Screen Window 310 MSGLEVEL=1,1
MESSAGE TYPE Field ON DSNEVENT Statement 738, 747
Screen Filter 310 MSTJCLB Parameter
Messages CTMFETCH CLIST 847
Log File 312 Multi-Screen Control
MINIMUM Parameter Transfer Command 94
CONFCAL Parameter 410 MVS MODIFY Command
DATES Parameter 424 protecting 276
DAYS Parameter 430 MVS MODIFY command
Description 540 Order or Force request 276
Example 541
MONTHS Parameter 542
PDS Parameter 588
WDAYS Parameter 685
N
MINUS Operator N Option
%%MINUS 794 Active Environment Screen 187
Minus-One N Qualifier
Multiple CONTROL-M Monitors 57 DO Statement 564
Minus-One Support NAME Field
CTMPLEX 57 Active Environment Screen 177
Sysplex 57 AutoEdit variable in 301
MISSION DEF Option Change Resource Window 296
Primary Option Menu 92 Job Dependency Network 251
MISSION STATUS Option Manual Conditions Window 301
Primary Option Menu 92 NAME Parameter
Mission, CONTROLM/Analyzer CTB STEP Parameter 419
CTB STEP Parameter 419 NE Operator
MODE Parameter AutoEdit Facility 786
CMEM Rule 731 Nested Expressions
Example 732 JCL Setup 787
Monochrome Terminal NET Argument
Color Support 86 REFRESH Command 182, 252
Graphic Jobflow Screen 169 NET Option
Month Field Active Environment Screen 187, 249
Job Scheduling Plan Screen 172 NEW COND Command
MONTHS Parameter Manual Conditions 300
DATES Parameter 424, 542 New Day Procedure
Description 542 "Shifted" for SHOUT purposes 641
MINIMUM Parameter 540 ODATE 66
PDS Parameter 588 SHOUT jobs 641
Periodic Value 430 SHOUT WHEN LATE Message 641
Move Commands SHOUT WHEN LATESUB Message 641
Edit Environment 930, 943 New Day Processing
MPP Description 45
Master Prompting Plan 843 NEW LCOND Command

984 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Manual Conditions 300 NOTE

NEW PASSWORD Field Zoom Screen 223
IOA Entry Panel 89 NOTE Command
NEWJOB Parameter Active Environment Screen 183
Simulation 858 Zoom Screen 227
Next NOTE Field
SAC Parameter 619 Active Environment Screen 178
NEXT Command NOTE Status
Job Scheduling Plan 171 Active Environment Screen 193
PF11/PF23 97 NOTOK
Scheduling Definition 147, 154 Description 462
NEXT Value NOTOK Status
Schedule Date 443, 572 Description 392
NEXTYEAR (PF11/PF23) Command ON Statement 557
Calendar Definition Screen 331 SMART Table Entity 143, 146
Night Schedule Field NOTOK Value
Simulation/Tape Pull 346 ON Statement Codes 561
NJE Enhanced Tracking Support 700 SHOUT Parameter 637
NJE Field NR Field
Zoom Screen 224 Quick Schedule Definition 373
NJE Job NXT RUN Field
CMEM On Spool Job 695 Zoom Screen 224
NJE JOB Status
Active Environment Screen 193
NJE Network
CONTROL-M Monitor 52
O
NJE NODE Parameter O Option
Format 544 Active Environment Screen 254
Under JES2 544 Job List Screen 130
Under JES3 545 Table List Screen 156
node ID OBJECTS Option
JES2 533 IOA Primary Option Menu 93
NODE NAME Field OCCUR NO Suffix
Zoom Screen 224 AutoEdit Parameter 851
Non-Color Display OCCUR NO. Field
Monochrome Terminal 86 Parameter Prompting 360, 366
Non-periodic Calendar ODAT
DCAL Parameter 428 IN Parameter 508
WCAL Parameter 682 Prerequisite Condition 74
Non-periodic Scheduling Schedule Date 443, 572
Format 682 ODATE
NOT CATLGD 2 Assignment 66
CMEM 692 DAYTIMEM Parameter 66
DO STOPJOB Statement 728 Definition 65
Job Status 192 DO FORCEJOB Statement 450
NOT CATLGD2 error prevention 594 Example 810
NOT FOUND Status GRP MAXWAIT Parameter 505
Active Environment Screen 193 Job Eligibility 66
NOT OK Status MAXWAIT Parameter 528
Show Screen Filter 202 Meaning 66
NOT STARTED Status New Day Procedure 66
Active Environment Screen 193 RUN Attribute 67
NOT SUBMITTED Status System Variable 762
Active Environment Screen 193 VALUE Attribute 67
JNSUB Reason 779 ODATE Field
NOT_DELETED Status Active Environment Screen 177
CTMAPI 906 Global View Screen 208

Index 985
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Job Order Execution History 242 DO CTBRULE Statement 448

Log Screen 304 ON Statement 551
Parameter Prompting 364 ON PGMST Parameter
Scheduling Confirmation 158 ON Statement 546, 551
Show Screen Filter 204 ON PGMST Statement
Zoom Screen 222 Combinatorial Logic 225
ODATE Parameter Step Range 652
AutoEdit Simulation 341 ON PGMST trigger
OF Field Zoom Screen 225
Parameter Prompting 355 On Spool Job
OIDL Command CMEM Facility 53
Active Environment Screen 185 CMEM Rule 693
OK Status Components 696
Description 392 DO FORCEJOB Statement 717
ON Statement 557 Forcing Logic 698
Post-Processing Parameters 392 Job Flow 697
SMART Table Entity 143, 146 NJE Job 695
OK Value ON JOBARRIV Statement 742
ON Statement Codes 561, 562 Status 195
SHOUT Parameter 637 TYPERUN=HOLD 696, 700
OLDJOB Parameter ON Statement
Simulation 858 * Character 556
ON Block +EVERY 553
ON Statement 554 CMEM Parameters 706
ON CODE Parameter CMEM Rule 733
ON Statement 546, 551 CMEM Rule Definition 266
ON DSNEVENT Statement Codes 559
And/Or/Not Parameter 738 CODES Parameter 553
CMEM Parameters 706 Combinatorial Logic 734
CMEM Rule 692, 694, 733, 736 Conditional Processing 392
CMEM Rule Definition 266 Description 546, 551
CMEM support 700 Example 556, 565
Dataset Event 736 Logic 553, 564
Example 740 Masking 735
MSGLEVEL=1,1 738, 747 Multiple 554
RUNTSEC=TRIGGER 751 PGMST Parameter 552
ON JOBARRIV Rule PROCST Parameter 553
CMEM Rule 695 Specified Step 556
DO FORCEJOB Statement 717 ON Statement Codes
ON JOBARRIV Statement ***** Code 560
CMEM Parameters 706 FORCE Code 561
CMEM Rule 692, 696, 733, 741 ON STEP Statement
CMEM Rule Definition 266 CMEM Parameters 706
Example 742 CMEM Rule 692, 745
Job Arrival 692 CMEM Rule Definition 266
ON JOBEND Statement CMEM support 700
CMEM Parameters 706 ON SYSOUT Parameter
CMEM Rule 692, 733, 743 Description 568
CMEM Rule Definition 266 ON TABLE END Parameter
Example 744 Definition 548
Job End 692 ON TABLE-END Parameter
RUNTSEC=TRIGGER 751 SMART Entity 383
ON OUTPUT Q Status SMART Table Entity 146
Show Screen Filter 202 Online Facility
ON OUTPUT QUEUE Status Active Environment Screen 172
Active Environment Screen 194 Documentation 149
ON PGMST ANYSTEP Exiting 95

986 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Help Screen 103 Manual Conditions 301, 832

Overview 59, 84 Parameter Prompting 353, 362
Tracking and Control 60 Primary Option Menu 92
TSO Application 113 Why Screen 215
Under ISPF 105 Option B
Online Utilities Menu CMEM Table List 262
Utility Screen 63, 333 Job List Screen 375
OP Parameter Table List Screen 126
SYSOUT Parameter 655 Option BA
OPER Value Primary Option Menu 93
DO SHOUT Destination 477 Option BB
SHOUT Parameter 638 Primary Option Menu 93
OPER2 Value Option BM
DO SHOUT Destination 477 Primary Option Menu 93
OPT Command Option BR
Active Environment Screen 180 Primary Option Menu 93
OPT Field Option BV
Conditions/Resources 290 Primary Option Menu 93
Manual Conditions 299 Option C
Rule List Screen 262 Active Environment Screen 188
OPT Parameter IOA Primary Option Menu 91
DO SYSOUT Statement 484 Job List Screen 130, 264, 375
opt Parameter Primary Option Menu 61, 257, 259
DO COND Statement 444 Option Code
OPT Subparameter DO SYSOUT Statement 484
DO COND Parameter 444 SYSOUT Parameter 655
OUT Parameter 572 Option D
Option ? Active Environment Screen 187, 254
Active Environment Screen 186, 212 CMEM Rule List 264
Option 1 CMEM Table List 262, 273
Parameter Prompting Entry Panel 347 Conditions/Resources 294
Parameter Prompting Type 1 Menu 349 Job List Screen 130, 374
Parameter Prompting Type 2 Menu 358 Parameter Prompting 353, 362
Option 2 Table List Screen 126, 164
IOA Primary Option Menu 91 Why Screen 215
Parameter Prompting Entry Panel 347, 358 Option E
Parameter Prompting Type 1 Menu 349, 353 Active Environment Screen 188
Parameter Prompting Type 2 Menu 358, 362 Display Filters window 198
Primary Option Menu 60, 115, 121 Manual Conditions 301
Option 3 Option F
IOA Primary Option Menu 91 Active Environment Screen 187
Parameter Prompting Type 2 Menu 358, 363 AutoEdit Variable 809
Primary Option Menu 60, 172 CMEM Table List 262, 274
Option 4 IOA Primary Option Menu 93
Primary Option Menu 90 Job List Screen 130
Option 5 Manual Scheduling 156
Primary Option Menu 62, 90, 303 Primary Option Menu 92
Option 6 Restart Step List Window 241
Online Utilities 106 Table List Screen 119, 126
Primary Option Menu 63, 90, 333 Option Field
Option 7 Active Environment Screen 177
Primary Option Menu 62, 90, 298 Job Dependency Network 250
Option 8 Quick Schedule Definition 373
Primary Option Menu 63, 90 Option G
Option A Table List Screen 126, 168
Active Environment Screen 187 Option H
Job List Screen 374 Active Environment Screen 186

Index 987
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Option I Option R1
CMEM Rule List 264 Online Utilities Menu 333
Job List Screen 130, 374 Option R2
Parameter Prompting 353, 362 Online Utilities Menu 333
Option I1 Option S
Online Utilities Menu 333, 335 Active Environment Screen 187
Option IV CMEM Rule List 264
IOA Primary Option Menu 91 CMEM Table List 262
Option J Display Filters window 198
Active Environment Screen 188 End User Job Order 377
Job List Screen 130 Job List Screen 130
Option L Job Order Execution History 243
Active Environment Screen 186, 219 Table List Screen 126
Option M Option T
Job List Screen 375 Active Environment Screen 188
Primary Option Menu 92 Job List Screen 130
Option M1 Primary Option Menu 92
Online Utilities Menu 333, 336 Restart Step List Window 241
Option M2 Option TC
Online Utilities Menu 333, 338 Primary Option Menu 93
Option M3 Option TI
Online Utilities Menu 333, 342, 868 Primary Option Menu 93
Option M4 Option TP
Online Utilities Menu 333, 347 Primary Option Menu 93
Option M5 Option TR
Online Utilities Menu 333, 367 Primary Option Menu 93
Option M6 Option TV
Online Utilities Menu 333, 376 Primary Option Menu 93
Option N Option U
Active Environment Screen 187, 249 Active Environment Screen 188
Option O Primary Option Menu 92
Active Environment Screen 187 Option U1
Group Scheduling 156 Online Utilities Menu 333, 378
Job List Screen 130 Option V
Manual Scheduling 156 Active Environment Screen 187, 241
Restart Step List Window 241 Option W
Option OA Active Environment Screen 191
IOA Menu 93 Option X
Option OC Online Utilities Menu 333
Primary Option Menu 93 Primary Option Menu 91
Option OK Option Z
Primary Option Menu 93 Active Environment Screen 186
Option OL Options
IOA Menu 93 Activate 187
Option OM Active Environment Screen 186
IOA Menu 93 AUTOMATION LOG 93
Option OR AUTOMATION OPTION 93
IOA Menu 93 BALANCING DEF 93
Option OS BALANCING STATUS 93
IOA Menu 93 CHANGE 294, 295
Option P CLEANUP 333
Job List Screen 130, 170, 374 CMEM 257, 259
Option R CMEM DEFINITION 91
Active Environment Screen 187, 229, 232 CMEM Rule List 264
Job List Screen 374 CMEM Table List 261
Parameter Prompting 353, 362 CONFIRM 188
Primary Option Menu 92 COSMOS Status 93

988 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Cross Memory 97 TERMINATE 187

CTMEXEC 358, 363 UNDELETE 188
CTMFETCH 358, 362 UPDATE 353, 362
CTMQUICK 368 USER INTERFACE 333
DB VARIABLE DEF 93 VARIABLE DATABASE 91
Define Parameters and Conditions 351, 353 VIEW 187, 241
Define Parameters in Master Plan 362 WHY 186
DEL 187 Year List Screen 319
DELETE 119, 126, 130, 164, 262, 264, 273, 294, 353, 362 ZOOM 186
Delete Condition/Resource 294 Order a Job
Display Filters window 198 DO FORCEJOB Statement 450
DOCU/TEXT 333 DO Statement Action 440
EDIT 130, 188, 198 Next Day 814
EXIT 333 Order Daily Jobs Field
FORCE 120, 126, 130, 156, 274 Simulation/Tape Pull 345
FORCE OK 255 Order Extension
FREE 187 CTMAPI 907
GRAPHIC FLOW 126, 168 Order ID
HOLD 186 Multiple Orders 70
INSERT 118, 130, 264, 353, 362 ORDER Option
IOA Primary Option 90 CMEM Table List 262
ISPF PACK 114 Job List Screen 120, 130
ISPF Primary Option Menu 106 Manual Scheduling 156
JCL 130, 188 Table List Screen 120
Job Activation 187 ORDERID Command
Job List 119, 129, 374 Active Environment Screen 186
JOB ORDER ISSUE 333 ORDERID Field
Job Reactivate 187 Active Environment Screen 178
JOB SCHED DEF 91 IOA Log Show Screen 311
JOB STATUS 91 Job Order Execution History 242
JOB/PIPE ACTIVITY 92 WHY Option 297
KOA Recorder 93 Zoom Screen 222
LOG 186, 219 Ordering Jobs 155
M4 on Online Utilities Menu 347 End User Job Order 376
M6 on Online Utilities Menu 376 Job List Screen 130
MAINVIEW Batch Optimizer (MVBO) 191 Job Ordering Utility 336
MANUAL COND 90 Next Day 814
Manual Conditions 301 Overview 68
Master Plan 358 Ordering Rules
Master Table Creation 350 CMEM Rule Table 274
MSG STATISTICS 93 ORDERING Status
NET 187 Active Environment Screen 196
ORDER 120, 130, 156, 262 Original Scheduling Date
PACK 114 ODATE 65, 762
Parameter Definition 350 ORIGLIB Field
Parameter Prompting 333, 350, 353 Zoom Screen 222
Parameter Updating 350 OS/390 Restart
PLAN 130, 170 @ Character 833
Prerequisite Condition 333, 350 OUT Parameter 947
QUICK SCHEDULE 333 procstep.pgmstep 948
Reactivate 187 OUT Condition
RERUN 187, 229 @#-procstep.pgmstep 948
RULE ACTIVITY 93 IOALDNRS Utility 831
RULE DEFINITION 93 Job Dependency 249
RULE STATUS 92, 93 SMART Table Entity 575
Table 188 OUT Parameter
Table List Screen 126 DATEREF Subparameter 572

Index 989
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Description 571 PAGE

DO COND Statement 446, 575 Scrolling Amount 99
Example 576 PAGES Field
Job Chain 578 Job Order Execution History 243
Logic 574 PANVALET
Long Condition Names 571, 574 Job Documentation 150
OPT Subparameter 572 PANVALET Product
OS/390 Restart 947 CONTROL-M 534, 581
Prerequisite Condition 508 PARAM PROMPTING Option
Quick Schedule Definition 368 Online Utilities Menu 333
OUT Statement Parameter
Prerequisite Condition 72 #JNFRT 224
Output Class AECACHL 771
SYSDATA 70 AUTOTAPE 248, 607
Sysout 657 CTGFORC 423
Output Files DUEINCHK 500
Simulation 855 FRCOKOPT 254, 562
Output Registers IOADFLT 429
CTMAPI 898 MAXCCOK 561, 562
OVERJCLM Parameter 545 TAGMAXWT 529
OVERLIB Library TBLRECHK 116
COPMEM2O Parameter 581 Parameter Definition
Deleting JCL Member 581 Parameter Prompting 350, 352, 360
JCL Member 188, 580 PARAMETER LIBRARY Parameter
MEMNAME Parameter 581 AutoEdit Simulation 341
OVERLIB Parameter Parameter Passing
AutoEdit Variable 809 MEMLIB Parameter 535
Description 580 Parameter Prompting
Example 585 AutoEdit Parameter 352, 355
JCL Member Name 341 Daily Prompting Tables 354
OVERRIDE DAILY PLAN Field Daily Scheduling Table 845
Parameter Prompting 363 Daily Table 353, 842
OVERRIDE DAILY PLAN Options Define Parameters Option 351
FETCH A PLAN Screen 849 Definition Phase 843
Overwrite Confirmation EXEC Phase 845
Quick Schedule Definition 371 FETCH Phase 844
OWNER Field File Prefix 349
Active Environment Screen 177 IRS Tape Example 838
Job Order Execution History 242 Master Plan 359
Quick Schedule Definition 369 Master Table 350
Show Screen Filter 204 New Method 840
OWNER Parameter Old Method 838
AutoEdit Simulation 329, 340 Scheduling Table 843
CMEM Rule 749 Type 1 349, 838
Description 586 Type 2 358, 843
DO RULE Statement 719 Parameter Update
Example 587 Parameter Prompting 350
Parameters
Basic Scheduling 136
P CMEM Rule Facility 266
Description 394, 708
P Option General Job 134
Job List Screen 130 Job Scheduling 44
PA1 Key 99 Multiple Occurrences 133
AutoRefresh Mode 105 Postprocessing 139
AutoRefresh Mode 105 Runtime Scheduling 138
PA2 Key 99 Scheduling Definition 133

990 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

SMARTTable 144 Active Environment Screen 186, 206

Summary 383 Box Color 169
Tape Pull List 867 CMEM Rule Exit Option 272
PARM Field Global View Screen 207
Parameter Prompting 352 Job List Exit Window 155
PARM NAME Field REFRESH Command 207
Parameter Prompting 360, 366 RESET Command 97
PARM PREFIX Field PF05/PF17
Parameter Prompting 352, 356, 361, 366 FIND Command 97, 101, 168
Update Parameter Values 366 PF06/PF18
Passing Arguments =6 Command 97, 113
ARGUMENTS Parameter 419 PF07/PF19
DO CTBRULE Statement 448 Filtering 313
Password Show Screen Filter 206
Online Facility 89 UP Command 97
PC PACKET STATUS Option PF08/PF20
Primary Option Menu 92 DOWN Command 97
PDS Parameter Filtering 313
CONFCAL Parameter 410 Show Screen Filter 206
DATES Parameter 424 PF09/PF21
DAYS Parameter 430 SWAP Command 105
Description 588 PF10/PF22
MINIMUM Parameter 540 IOA Log Show Screen Window 313
MONTHS Parameter 542 LEFT Command 97
WDAYS Parameter 685 PREV Command 97
PDSE Library 588 Scheduling Definition 154
PDSE-type Library Show Screen Filter 206
MINIMUM Parameter 540 PF11/PF23
PDSMAN Active Environment Screen 185
$$$SPACE Member 165, 274, 327 NEXT Command 97
PENDING Conditions RIGHT Command 97
Manual Conditions 299 Scheduling Definition 154
Periodic Calendar 323, 325 PF12
DCAL Parameter 429 RETRIEVE Command 98
Example 430, 685 PF24
Overlapping 325 SHPF Command 98
WCAL Parameter 684 PFKey Definition
WDAYS Parameter 430, 685 Online Facility 97
periodic calendar PRINT Command 105
STAT CAL parameter 650 TSO CTMTTRA 113
STAT CAL PERIOD parameter 651 PFKey Display
statistics 650, 651 SHPF Command 98
Periodic Scheduling PFKey functions
Format 429, 683 IOA Editor 107
PF01/PF13 PFKeys
HELP Command 97, 103 DOWN 99
PF02/PF14 UP 99
ISPF SPLIT Command 97 PGMST Parameter
SHOW Command 97 ON Statement 552
SPLIT Command 105 Step Range 556
PF03/PF15 PGMSTEP Parameter
CMEM Rule Definition 271 ON DSNEVENT Statement 737
END Command 97 ON STEP Statement 746
IOA Log Show Screen Window 313 pgmstep.procstep
Scheduling Definition 153 DO IFRERUN Statement 454
Show Screen Filter 206 Pipe
PF04/PF16 Job Scheduling Definition 58

Index 991
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Job-Related Considerations 835 Predecessor Job

MAINVIEW Batch Optimizer (MVBO) 58 Job Dependency 77, 249
PIPE Field REFRESH Command 252
Show Screen Filter 204 Prefix
PIPE Parameter Maybe Job Prerequisite Condition 833
Description 590 PREFIX Field
MAINVIEW Batch Optimizer (MVBO) 381, 391 Manual Conditions 291, 299
MAINVIEW Batch Optimizer (MVBO) Prefixing
Implementation 835 Description 87
Summary 138 PREREQ CONDITION Option
Pipe Participant Online Utilities Menu 333
Definition 59 Prerequisite Condition
PIPE Statement Add/Check/Delete Utility 334
Deleted Through Zoom Screen 835 Adding 292, 300, 572
PLAN Command CMEM Rule 693
Scheduling Definition 146 CONTROL-M Files Prefix 350
Plan Description Date Reference 74
Parameter Prompting 359 Deleting 75, 294, 301, 573
PLAN NAME Description 72
Master Prompting Plan PREFIX 364 DO COND Statement 442, 713
Parameter Prompting 363, 366 DO Statement 440
PLAN NAME Prefix Erasing 294, 301
Parameter Prompting 359 Example 73, 513, 577
PLAN Option Format 368
Job List Screen 130, 170 IMSACTIVE 578
PLAN ORDERED ALREADY Field IN Parameter 507
Parameter Prompting 364, 365 IOALDNRS Utility 831
Plan Selection Screen IRSTAPEARRIVED 838
Parameter Prompting 364, 367 Job Dependency 73, 77
PLANID Parameter Manual Conditions 62, 298
CTMEXEC CLIST 848 Manual Intervention 75, 509, 573
CTMFETCH CLIST 847 Maybe Job 833
Daily Scheduling Table 845 OUT Parameter 571
PLANID Suffix Parameter Prompting 350, 352
CTMFETCH CLIST 847 Quick Schedule Definition 370, 372
POOL DEFINITION Option Runtime Criteria 49
Primary Option Menu 93 RUN%%PLANID 845, 849
Post-Processing Show Screen Filter 204
System Variable 767 SMART Table Entity 74, 575
post-processing STAT 74
statistics 650 Unscheduled Condition 833
Post-Processing Parameter Why Screen 215
System Variable 766 Prerequisite Conditions
Post-Processing Parameters IOA Conditions File 288
CONTROL-M Monitor 51 IOA Conditions/Resources Screen 288
DO SET Statement 474, 632 PREV Command
Scheduling Definition 139 Job Scheduling Plan 171
SMART Table Entity 146 PF10/PF22 97
Summary 391 Scheduling Definition 147, 154
Post-processing Statement PREV Value
Error 392 FIND Command 101
PPF2DAY Job IN Parameter 508
JCL Library 852 Schedule Date 443, 572
PPF2DEL Job prevent NOT CATLGD2 errors 594
JCL Library 852 PREVENT-NCT2 Parameter
Precedence Description 593
AutoEdit Variable Assignment 782 PREVENTNCT2 Parameter

992 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Example 596 CONTROLM/Analyzer 43

Previous product support 3
SAC Parameter 619 Production Delay
PREVYEAR Command MAXWAIT Parameter 528
Calendar Definition Screen 331 Productivity Tools
Print a Copy of the Screen 99 Option OA 93
PRINT Command Profile Variable
PFKey Definition 105 SACTMOD 174
Print Screen 99 Programmer Information
Printing SHOUT Parameter 638
Sysout 486, 657, 660 PROMPT IND Field
PRIOR RUN Status Parameter Prompting 361
Active Environment Screen 194 PROMPT Library
Priority %%LIBSYM Statement 842
Conditions/Resources 290, 297 Prompting Plan
Overview 77 AutoEdit Variables 838, 844
Runtime Criteria 47 PROPAGATE Argument
SYSOUT Operations 488 REFRESH Command 252
Sysout Operations 660 PRTDBG
User-Defined Variable 778 DD Statement 99
PRIORITY Field PRTY Field
Show Screen Filter 204 Job Dependency Network 251
Priority Field PSEUDO Job
WHY Option 297 Status 395
PRIORITY Parameter PSEUDO Jobs
Description 597 MEMBLIB Parameter 396
Example 598
Job Flow 77
Logic 598
PRM Parameter
Q
DO SYSOUT Statement 484 Quantitative Resource
PRMTBLB Parameter Adding 292
CTMFETCH CLIST 847 Changing 295
PRO/JCL Critical Path Priority 598
INVOKE JOBSCAN Parameters 869 Definition 76
Simulation/Tape Pull 343 Deleting 294
Tape Pull List 869 MAINVIEW Batch Optimizer (MVBO)
PROBLEMS READING SYSOUT Status Implementation 836
Active Environment Screen 194 RESOURCE Parameter 605
PROCST Parameter Runtime Criteria 49
+EVERY 553 Show Screen Filter 204
ON Statement 553 Quantitative Resource Return Codes, CTMAPI 915
PROCSTEP Parameter Quantitative Resources
ON DSNEVENT Statement 737 IOA Conditions/Resources Screen 288
ON STEP Statement 745 QUANTITY Field
PROD Mode Conditions/Resources 290
CMEM Rule Simulation 731 WHY Option 297
Product Description Quick Schedule Definition
CONTROL-M/Restart 42 CTMQUICK Utility 367
CONTROL-M/Tape 43 Example 375
CONTROL-O 43 Exiting 375
CONTROL-O/COSMOS 43 Overwrite Confirmation Window 371
CONTROL-D 43 Screen 368
CONTROL-D/Image 43 QUICK SCHEDULE Option
CONTROL-D/Page On Demand 43 Online Utilities Menu 333
CONTROL-M 42 Quick Submit Command
CONTROL-V 43 Job Ordering 827

Index 993
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

QUICKDEF Utility opening 467

ISPF Online Utility 383 Remote Node
NJE Network 52
REMOVE UNSCHED CONDITIONS
R SMART Table Entity 834
REP3LEFT Report
R Option Simulation/Tape Pull 346
Active Environment Screen 187, 229 REPBYDSN Parameter
Parameter Prompting 353 Tape Pull List 867
RACF REPBYJOB Parameter
Security Product 586 Tape Pull List 867
RANGE Control Statement REPBYTIME Parameter
%%RANGE 790 Tape Pull List 867
RBA 181 REPBYVOL Parameter
RBA Field Tape Pull List 867
Active Environment Screen 181 Repeat Commands
Conditions/Resources 181, 291 Edit Environment 930, 943
WHY Option 297 REPEAT Option
RBAL Command Parameter Prompting 353, 362
Active Environment Screen 181, 291 REPLACE Parameter
Job Dependency Network 249 CTMFETCH CLIST 847
RDR=INTRDR Parameter REPLACE YES Option
CTMAESIM Utility 807 CTMFETCH CLIST 849
Reactivate Option Replies
Active Environment Screen 187 CTMBAPI 917
RECAPTURE ABEND CODE REPORT BY DSN Field
ON Statement 555 Simulation/Tape Pull 346
STEP RANGE Parameter 654 REPORT BY JOB Field
RECAPTURE CONDITION CODE Simulation/Tape Pull 346
ON Statement 555 REPORT BY TIME Field
STEP RANGE Parameter 654 Simulation/Tape Pull 346
RECAPTURE CONDITION CODES Field REPORT BY VOLSER Field
Restart Confirmation Window 233 Simulation/Tape Pull 346
RECIPIENT TREE Option Report Decollating
Primary Option Menu 92 D-CAT Parameter 422
Record Selection Criteria REPORT DEF Option
Active Environment Screen 196 Primary Option Menu 92
REFRESH Command Reporting Facility
Active Environment Screen 182 Overview 56
Global View Screen 207 REPORTS Field
Job Dependency Network 249, 251 Simulation/Tape Pull 346
RELATIONSHIP Field Repository
SMART Table 381 Description 64
RELATIONSHIP Parameter REQUESTED CHANGE HELD Status
Description 131, 600 Zoom Screen 229
Group Scheduling Logic 389 REQUESTED CHANGE Status
SMART Table 385 Active Environment Screen 194
RELEASED Status REQUESTED DELETE
Active Environment Screen 194 Active Environment Screen 196
REMAIN Parameter REQUESTED FORCE OK Status
CTMEXEC CLIST 848 Active Environment Screen 194
REMAINING PARAMETERS Field REQUESTED FREE Status
Parameter Prompting 364 Active Environment Screen 194
Update Parameter Values 366 FREE Option 187
Remedy Helpdesk closing 468 REQUESTED HELD Status
Remedy problem ticket Active Environment Screen 194
closing ticket 468 HOLD Option 186

994 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

REQUESTED REACT Status Resource Control

Active Environment Screen 194 CONTROL Parameter 414
REQUESTED RERUN Status RESOURCE Parameter
Active Environment Screen 194 Automatic Tape Adjustment Facility 248
Rerun Description 605
Definition 69 Example 609
DO STOPCYCL 482 Logic 607
Rerun Confirmation Window RESOURCE TYPE Field
CONTROL-M/Restart 232 Show Screen Filter 204
Manual Job Rerun 229 Resource Utilization
Rerun Interval Critical Path 77, 597
INTERVAL Parameter 520 Priority 597
Rerun Job Tape Devices 248
Example 808 Resource Window
RERUN NEEDED Status Conditions/Resources 295
MAXRERUN Parameter 525 Resources
RERUNMEM Parameter 602 Forecasting 854
RERUN Option Simulation 854
Active Environment Screen 187, 229 Resources File 64
TASKTYPE Parameter 667 RESTART
RERUN Parameter ON Statement 555
Example 526 STEP RANGE Parameter 654
Rerun Request Restart
DO Statement 440 CONTROL-M/Restart 69
RERUN Status Definition 69
Show Screen Filter 202 DO IFRERUN Statement 453
RERUN Value DO STOPCYCL 482
SHOUT Parameter 637 RESTART DECISION Field
Rerun/Restart Window Zoom Screen 223, 225
$FIRST/$CLEANUP Values 235 Restart Job
Active Environment Screen 231 DO IFRERUN Statement 453
RERUNMEM Parameter OUT Parameter 949
Description 602 Restart OS/390
MAXRERUN Parameter 526 OUT Parameter 947, 949
RES Field RESTART Parameter
Conditions/Resources 292 DO Statement 440
Job Dependency Network 251 Restart Step
RES NAME Field List Window 240
Show Screen Filter 204 OUT Parameter 948
RESET Command RESTARTED Status
CMEM Rule Exit Option 272 Active Environment Screen 194
Description 102 Restoration
Edit Environment 928 Active Jobs File 50
Exit Option 155 Conditions/Resources 50
IOA Log Show Screen Window 313 RESTORE Option
PF04/PF16 97, 102 History Environment Screen 254
Quick Schedule Definition 375 RESTORED Status
Scheduling Facility Exit Option 155 Active Environment Screen 194
Show Screen Filter 206 RETENTION Parameter 612
RESOLVE Control Statement # OF DAYS TO KEEP 612, 614
%%RESOLVE 792 # OF GENERATIONS TO KEEP 612, 614
Resource History Jobs File 381
Conditions/Resources 181 Retention Period
Resource Allocation SYSDATA 405
Critical Path 77 Retrieval Criteria
Resource Contention Selection Criteria 291
Critical Path Priority 598 RETRIEVE Command

Index 995
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

PF12 98 Runtime Scheduling Parameters

RETRO Parameter Scheduling Definition 138
Description 616 Summary 391
MAXWAIT Parameter 529 RUNTSEC Parameter
MINIMUM Parameter 540 Example 752
PDS Parameter 588 Security Check 752
Return Codes RUN%%PLANID
CTMAPI Forcing Jobs 883 Prerequisite Condition 845, 849
CTMAPI Ordering Jobs 883
RIGHT Command
PF11/PF23 97
ROSCOE
S
DO SHOUT Statement 724 S Option
ROSCOE/ETSO Active Environment Screen 187
Address Space 85 Display Filters Window 308
PF06/PF18 97 End User Job Order 377
Row commands Job List Screen 130
IOA Editor 108 Table List Screen 126
Row Numbering S*37 Abend Code
Variable Database Facility 284 SET VAR Parameter 633
RULE ACTIVITY Option SAC Parameter
Primary Option Menu 93 + (Group Next) 619
Rule Copying 276 - (Group Previous) 619
Rule Definition Next 619
Editing 941 Previous 619
Maintaining Validity 944 SAMPEXIT Library
RULE DEFINITION Option CTMX002 Exit 534
Primary Option Menu 93 SAP/R3
RULE Field architecture 922
CMEM Entry Panel 260 BAPI 923
Rule List Screen running on USS 922
Commands 263 Unix and the SAP/R3 Application Layer 924
Copying Rules 276 with DB/2 database 923
RULE STATUS Option SAVE (Y/N) Field
IOA Menu 93 IOA Log Show Screen 309
Rule Table Show Screen Filter 199
Automatic Creation 368 SAVE Command
CMEM 257 Zoom Screen 226, 228
Rule, CONTROL-M/Analyzer SAVE DOCUMENTATION Parameter
CTB STEP Parameter 419 Save Documentation Window 152
RULENAME Parameter Save Documentation Window
DO RULE Statement 719 Scheduling Definition 151
RUN Attribute SAVE Field
ODATE 67 Exit Option Window 155
RUN n Status IOA Log Show Screen Window 309
Active Environment Screen 194 Scale Line
RUN SIMULATION Field View Graph Screen 210, 211
Simulation/Tape Pull 344 SCATMOD Profile Variable 174
Run Statistics SCHDLIB Field
Statistics Screen 245 Zoom Screen 222
Runtime Criteria SCHDTAB Field
Job Submission 47 Zoom Screen 222
Runtime Scheduling Schedule Date
MAINVIEW Batch Optimizer (MVBO) 836 Job Scheduling Plan Screen 172
Pipe Algorithm 59 OUT Parameter 572
Runtime Scheduling Parameter SCHEDULE PREVIOUS DAY Parameter
THRESHOLD 753 Description 619

996 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

SCHEDULE RBC ACTIVE Parameter Scheduling Definition Screen

Description 625 SMART Table Entity 143
Format 625 Scheduling Information
FROM 137, 625 Job Scheduling Plan Screen 171
SCHEDULE RBCs, Conflicting 627 Scheduling Jobs 155
UNTIL 137, 625 Scheduling Library
SCHEDULE RBC Field DO FORCEJOB Statement 450
SMART Table 381 Job Scheduling 44
SCHEDULE RBC Parameter Scheduling Library Mode
Description 621 AutoEdit Syntax Testing 339, 806
Group Scheduled Job 508 Parameter 341
SMART Table 385 SCHEDULING LIBRARY Parameter
SMART Table Entity 115, 145 AutoEdit Simulation 341
SMART Table Scheduling 136 Description 337
SCHEDULE-PREV-DAY Value Scheduling Logic
DESC Parameter 438 DAYS Parameter 427
SCHEDULE-PREV-ONLY Value Description 388
DESC Parameter 438 Scheduling Parameters
SCHEDULED RUN DATE Parameter 337 Display 122
Scheduling Scheduling Table
Basic Parameters 385 DO FORCEJOB Statement 450
Calendar Facility 313, 322 Parameter Prompting 843
Description 381 SCHENV parameter
DO FORCEJOB Statement 450, 451 format 628
DO MAIL Statement 458 SCHTBLB Parameter
DO REMEDY Statement 467 CTMFETCH CLIST 847
Example 381 Screen
General Parameters 383 Printing 99
Logic 388, 427 Screen Control
Non-periodic 682 Online Facility 113
Periodic 429, 683 Screen Description Line
Runtime Parameters 391 Online Facility 96
TASKTYPE Parameter 666 Screen Exit
Scheduling Criteria CANCEL Command 103
Job Submission 47 Screen Help
SMART Table Entity 115 Line Sensitive 103
Scheduling Definition Online Facility 103
Commands 146 Screen Layout
Creation 118 Online Facility 96
Deletion 119, 164 Screen Printing
Description 114 ISPF LIST File 105
Documentation 149 Screen Transfer
Editing 148, 927 TSO CTMTTRA Command 113
Entry Panel 121 Screens
Exiting 153 Active Environment 173
Graphic Jobflow 168 AutoEdit Simulation 339
Group-Handled Jobs 116 Calendar Definition 322
Job List 127 Calendar Facility 314
Job Plan 170 Calendar Facility Entry Panel 316, 327
Job Scheduling 381 Calendar List 316, 327
Ordering Jobs 156 CMEM Online Entry Panel 259
Overview 60 CMEM RULE Definition 721
Parameters 133 CMEM Rule Definition 265, 270, 705, 709, 726, 728,
Screen 114, 131 732, 740, 742, 744, 752, 941
Search Window 123 CMEM Rule Facility 257
SMART Table Entity 142 CMEM Rule List 262
Table List 125 CMEM Table List 261

Index 997
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Conditions/Resources 293, 294 Tape Pull List 342, 869

CONTROL-M Simulation 342 TSO Command Processor 112
Database List Screen 280 Update Parameters 355, 365
Define or Update a Master Plan 359 Variable List Screen 281
Define Parameters and Conditions 351, 352 Variable Zoom Screen 285
Define Parameters in Master Plan 360 View Graph 209
Edit Environment 148, 270, 927, 941 Why 212
Entry Panel 121 Year List 317
Exec/Order a Plan 363 Zoom 222
Fetch a Plan 362 SCROLL Field
Forecasting Facility 342 Screen Header 99
Global View 206 Scrolling
Graphic Jobflow 168 Commands 99
History Environment 252 SEARCH COUNTER Field
IOA Entry Panel 88 DISAPPEARED Status 224
IOA Help 103 Zoom Screen 224
IOA Log 98, 303 Search Function
IOA Log Show Screen Window 308, 311 CTMAPI 888
IOA Primary Option Menu 89, 91 Searching
IOA TSO Command Processor 112 FIND Command 100
IOA Variables Facility 279 LOCATE Command 100
Issue a Job Request 336 Security
Job Dependency Network 250 CMEM Rule 749
Job List 127, 156, 170, 372, 376 OWNER Parameter 586
Job Log 219 RUNTSEC Parameter 751
Job Order Execution History 241 Security Exit IOASE07 915
Job Scheduling Definition 131, 149, 171, 375, 927 SELECT Command
job scheduling definition 381, 399, 406, 413, 416, 423, Table Creation 117
425, 439, 449, 452, 457, 475, 481, 490, 496, 498, 500, SELECT Option
504, 506, 513, 522, 527, 530, 536, 539, 541, 565, 576, Calendar List Screen 317, 328
585, 587, 589, 596, 609, 634, 645, 646, 654, 662, 669 CMEM Rule List 264
Job scheduling definition for SMART Table 142 CMEM Table List 262
Job scheduling definition for SMART Table Entities Display Filters Window 308
142 Display Filters window 198
Jobflow 168 Job List 130
Manual Conditions 298, 300, 301 Table List 119, 126
Master Plan Definition 359 Year List Screen 319
Master Table Definition 351 Select Option
Online Utilities 333 Job Order Execution History 243
Online Utilities Menu 333 Selection Criteria
Parameter Prompting Facility 351 Active Environment Screen 196
Parameter Prompting Type 1 Menu 349 CMEM Actions 266
Parameter Prompting Type 2 Menu 358 Conditions/Resources 291
PFKey Window 98 Display Filters window 198
Plan Selection 364 Parameter Prompting 352
Prerequisite Condition Utility 335 Show Screen Filter 199
Quick Schedule Definition 368 SELECTION FIELD
Rule Definition Entry Panel 122 Parameter Prompting 366
Scheduling Analysis 212 SET
Scheduling Definition 114 Global Variables 278
Set Conditions 355 SET command 109
Simulation, AutoEdit 338 SET Command Panel
Simulation, CONTROL-M 342 End TRACE level 110, 111
Statistics 245 Set Dollar Sign Representation 111
Sysout Viewing 243 Set TRACE level 110, 111
Table List 125, 164 Set Conditions
Table Selection 353 Screen 352

998 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

SET Control Statement Active Environment Screen 181, 197, 307

%%SET 793 IOA Log Screen 305
Set Dollar Sign Representation Log Screen 220, 306
SET Command Panel 111 PF02/PF14 97
SET Statement SHOW JOB DOCUMENTATION Field
JCL SET 783 Entry Panel 149
Set TRACE level SHOW LIMIT ON Field
SET Command Panel 110, 111 Log Screen 304
SET VAR Show Option Window 196
Global Variables 278 Show Screen Filter
SET VAR Parameter Activating 197, 198
AutoEdit Variable 473, 631 Active Environment Screen 197, 198
Description 630 Displaying available filters 197
DO SET Statement 474, 632 Exiting 205
Example 632 Fields 199
SET VAR Statement Show Screen Filter Window Field
AutoEdit Statement 808 DESC 199
Global Variable 773 SHPF
JCL Setup 778 Command 269
Local Variable 770 SHPF Command
User-Defined Variables 759 CMEM Rule Definition 269
SETOGLB PF24 98
Global Variables 278 Show PFKey 98
Setting Variable Values SIMEND Parameter
AutoEdit 792 Simulation 857
Shared Control SIMLOG Output File
CONTROL Parameter 414 Simulation 860
Shared Resource SIMOAJF Output File
WAIT SCHEDULE Status 293 Simulation 860
SHIFT Parameter SIMOCND Output File
CONFCAL Calendar 387 Simulation 860
CONFCAL Parameter 409 SIMORES Output File
SHOUT Facility Simulation 861
CONTROL -O 53 SIMPARM DD statement
Shout Facility CONTROL-M 857
DO SHOUT Statement 476 SIMSTART Parameter
Problem Notification 50 Simulation 857
SHOUT Message SIMUL/TAPE PULL Option
AutoEdit Variable 809 Online Utilities Menu 333
IOA Log Show Screen Window 310 Simulation
SHOUT Parameter Active Jobs File 854, 859
Description 636 Analyzing the Run 862
DO SHOUT Statement 480, 644 AutoEdit Statement 806
Job Statistics File 640 CMEM Rules 731
System Variables 759 CTMAESIM Utility 806
SHOUT Statement CTMCSIM CLIST 342
%%JOBNAM/%%JOBNAME Variables 368 CTMX002 861
Post-Processing Parameters 140 Description 854
SHOUT WHEN EXECTIME Message Input Files 855, 859
Job Dependency Network 251 INVOKE JOBSCAN 342
SHOUT WHEN LATE Message Manual Conditions 864
Job Dependency Network 251 Message File 860
New Day Procedure 641 MODE Parameter 731
SHOUT WHEN LATESUB Message Output Files 860
Job Dependency Network 251 Overview 56
New Day Procedure 641 Parameters 857
SHOW Command Screens 342

Index 999
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Tape Pull List 865 Special Catalog

Simulation Facility Tape Pull List 866
CTMCSIM Utility 342 Special Purpose Job
Simulation Option Job Ordering 829
Active Environment Screen 189 Job Scheduling 826
SIMULATION Parameter SPLIT Command
Simulation/Tape Pull 345 PF02/PF14 97, 105
Simulation/Tape Pull Utility Split Screen Mode
CLIST CTMCSIM 342 Online Facility 105
SKELETON Field SRB Time Field
Quick Schedule Definition 369 Statistics Screen 247
Skeleton Job SRB Time, SMART Table
Quick Schedule Definition 367 Statistics Screen 247
SMART Table SSCHTBO Parameter 161
Maybe Jobs 834 START Command
Parameters 144 TASKTYPE Parameter 667
REMOVE UNSCHED CONDITIONS Field 834 START Field
SMART Table Entity 382 Job Order Execution History 243
SMART Table Entity START TIME Field
Deleting a Job 218 Statistics Screen 247
Display 188 STARTED Status
Group-Handled Jobs 116 Active Environment Screen 195
ON TABLE-END Parameter 548 Started Task
OUT Conditions 575 AUTOARCHIVE Parameter 405
Parameters 144 MEMLIB Parameter 533, 536
Prerequisite Condition 74 MEMNAME Parameter 537
Scheduling Definition 142 OVERLIB Parameter 581
Scheduling Definition Screen 143 Show Screen Filter 203
SMART Table 382 TASKTYPE Parameter 666
SMART-Handled Jobs 70 STAT CAL Parameter
Statistics Screen 247 Description 650
Task Type 203 STAT CAL PERIOD Field
Undeleting 188 Zoom Screen 222
Zoom Screen 225 STAT CAL PERIOD parameter
SMART Table Scheduling description 651
SMART Table Entity 71, 142 STAT Command
SMART-Handled Jobs Job List Screen 129, 319
Description 70 Rule List Screen 264
SMFID Parameter STAT Date Reference
ON DSNEVENT Statement 736 DO COND Parameter, DATEREF Subparameter 443
ON JOBARRIV Statement 741 DO COND Statement 712
ON JOBEND Statement 743 IN Parameter 508
ON STEP Statement 745 OUT Parameter, DATEREF Subparameter 572
SMS Support Prerequisite Condition 74
CMEM 703 STAT Field
SNRUN Conditions/Resources 292
ANYSTEP 563 Global view Screen 208
SNRUN Code Manual Conditions 300
+EVERY Step 558 STAT Message Type
ON Parameter 563 IOA Log Show Screen Window 310
SORT Command STAT Option
Job List Screen 129 Active Environment Screen 187
Space Allocation Job List Screen 130
SET VAR Parameter 632 State (Mode of Control)
Space Report Field CONTROL Parameter 414
Simulation/Tape Pull 347 STATE Status
SPD Statement 619 Show Screen Filter 203

1000 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Statement Example 567

DO SET Statement 778 ON Statement 552
Error PGMST Parameter 552, 556
Post-processing 392 STEP RANGE Parameter
Statistical Information Description 652
Global View Screen 206 Example 654
Job Status 182 pgmstep.procstep 652
View Graph Screen 208 STEP Statement 266
Statistics STEPRC field
Execution Information 55 DSNEVENT criteria 701
JOBSTAT Command 147 STEPRC Parameter
SMART Table Entity 247 ON DSNEVENT Statement 738, 739
Tape Device 248 ON STEP Statement 746
statistics String Search
STAT CAL parameter 650 LOCATE Command 100
STAT CAL PERIOD parameter 651 SUBMIT Command
utility 650 From ISPF 827
Statistics File ISPF 827
SHOUT Parameter 640 Quick Submit 827
Statistics Screen 245 SUBMIT Function
Active Environment Screen 182 AutoEdit Simulation 341
Fields 246 SUBMITTED Status
JOBSTAT Command 182 Active Environment Screen 195
STATUS Field Show Screen Filter 202
Active Environment Screen 178 SUBSCAN Function
Job Dependency Network 251 AutoEdit Simulation 341
Job Order Execution History 243 Subtraction Operation
Show Screen Filter 201 %%MINUS 794
Status Reply DSECT Successor Job
CTMBAPI 905 Job Dependency 77, 249
Status Return Codes 906 SUFFIX Field
Status Returned Quick Schedule Definition 371
CTMBAPI 905 SUFFIX Parameter
Status Screen 172 CTMEXEC CLIST 848
Functions 60 CTMFETCH CLIST 847
Manual Confirmation 455 SUM Field
WAIT CONFIRMATION Status 412 View Graph Screen 210
Status screen 469 SUMM
Status Zoom Screen DO REMEDY parameter 467
DOC Lines 497 support, customer 3
Status, CONTROL-M SWAP Command
Job Dependency Network 250 PF09/PF21 105
STATUS, SMART Table Sxxx Code
Statistics Screen 247 +EVERY Step 558
STC Syntax Checking
Started Task 532 AutoEdit Statement 806, 865
STC Task Type CTMSCIM Utility 343
IOA Log Show Screen Window 311 Edit Environment 928
Show Screen Filter 203 JCL Statements 865
STEP ADJUSTMENT Field SYSDATA
Restart Confirmation Window 234 Definition 70
Step Event SYSDATA Archiving
CMEM 692 AUTOARCHIVE Parameter 404
DO FORCEJOB Statement 716 SYSDATA Deletion
Step List Window Active Jobs File 405
Restart Window 240 SYSDATA Viewing
Step Range AUTOARCHIVE Parameter 404

Index 1001
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

SYSDB Parameter Under JES3 664

AUTOARCHIVE Parameter 404 System Messages
SYSIN DD Statement SYSDATA 70
%% Parameter 820 SYSTEM Parameter
SYSOPT = CTMWORK ON DSNEVENT Statement 736
CONTROL-M/Analyzer System Variable 449 ON JOBARRIV Statement 741
SYSOUT Archiving ON JOBEND Statement 743
Option F 809 ON STEP Statement 745
SYSOUT Dataset SYSTEM Subparameter
SYSDATA 70 DO SHOUT Statement 723
Sysout Destination System Variable
DO SYSOUT Statement 487 AutoEdit 757, 760
Sysout destination Date Variable 762
SYSOUT Parameter 658 JCL Setup 760
SYSOUT Operations MEMLIB Parameter 809
Copying 657 Post-Processing 766, 767
SYSOUT Parameter 656 Resolution 778
SYSOUT operations SET VAR Parameter 473, 631
Priority 488 SHOUT Parameter 759
Sysout Operations SYSOPT = CTMWORK 449
Archiving Facility 491 SYSOUT Parameter 759
Class Change 486, 658
Copying 485, 489, 660
Displaying 243
DO SYSOUT Statement 485
T
Merging 488, 659 T Option
Moving 487, 658 Active Environment Screen 187
Multiple 487, 658 Job List Screen 130
Printing 486, 658, 660 Table
Priority 660 Browse Mode 119
Releasing 486, 657 Creation 116, 257
SYSDATA Definition 70 Deletion 119, 164
Viewing Screen 243 Job Scheduling 45
Sysout Option Code TABLE Command
DO SYSOUT Statement 484 Active Environment Screen 183
SYSOUT Parameter 655 Table Description
SYSOUT Option F Parameter Prompting 351
AutoEdit Variable 809 TABLE Field
SYSOUT Parameter Active Environment Screen 178
Description 655 CMEM Entry Panel 260
DO SYSOUT Statement 490, 661 Quick Schedule Definition 369
Example 662 Scheduling Facility Exit Option 154
Logic 658 Table Information
System Variables 759 Quick Schedule Definition 368
SYSPLEX Table Library
Variable Database Facility 278 Parameter Prompting 351
Sysplex Table List
Minus-One Support 57 CMEM Table List 125
System Abend Code Options 126
ON Statement 559 Statistical Information 125
System Date Table List Screen
Definition 65 CMEM Rule Facility 261
DO FORCEJOB Statement 450 Commands 126
JCL Setup 762 Delete Confirmation 164
SYSTEM ID Parameter Description 125
Format 663 Exiting 155
Under JES2 664 Job Ordering 827

1002 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Manual Job Scheduling 155 Description 666

New Table 155 Example 669
Options 118 MEMLIB Parameter 533
TABLE NAME Parameter MEMNAME Parameter 538
AutoEdit Simulation 341 Tasktype WRN
Description 337 Warning Message 668
Entry Panel 119 TBL Entry
Table Name Prefix Active Environment Screen 188
Parameter Prompting 351, 842 TBL HELD Status
TABLE Option Active Environment Screen 193
Active Environment Screen 188 TBL MAXWAIT Parameter
TABLE Parameter Description 505
DO FORCEJOB Statement 450, 715 SMART Table Entity 145
DO RULE Statement 719 TBL Task Type
TABLE PREFIX Field Show Screen Filter 203
Table Selection Screen 355 TBLRECHK Parameter
Table Selection Screen CTMPARM 116
Parameter Prompting 353 technical support 3
TAGMAXWT Parameter Terminal Support
CTMPARM 529 Online Facility 86
Tape Adjustment 56 TERMINATE Option
Tape Devices Active Environment Screen 187
Statistics 248 TEST Mode
Tape Drive CMEM Rule Simulation 731
RESOURCE Parameter 609 Testing
Tape Pull List AutoEdit Syntax 806
Catalogs 866 THRESHOLD Parameter
CTMCSIM Utility 342 Description 753
DD Statements 869 THRESHOLD Runtime Scheduling Parameter 753
JOB/SCAN, PRO/JCL, DOCU/TEXT 869 Time
Parameters 867 Runtime Criteria 47
Problem Determination 870 TIME + DAYS Parameter
Recommendations 865 Description 671
Sample Report 871 FROM DAYS 671
Simulation 865 FROM TIME 671
Work Flow 865 Runtime 671
TAPE PULL LIST Field UNTIL DAYS 671
Simulation/Tape Pull 346 UNTIL TIME 671
TAPE PULL LIST Parameter Time and day limits
Simulation 868 TIME + DAYS Parameter 671
Tape Pull List Parameters 867 TIME Field
TAPULIN DD Statement Log Screen 304
Simulation Parameter 867 TIME Parameter
Tape Pull List 869 CTMEXEC CLIST 848
TAPULOUT DD Statement Description 671
Tape Pull List 869 Runtime 671
TAPULPRM Member TO DATE Field
CONTROL-M 867 Date Range Window 170
Target Computer TO Destination
Example 817, 818 DO SHOUT Statement 477, 478
TASK TYPE Criteria SHOUT Parameter 638
IOA Log Show Screen Window 311 TO Field
TASK TYPE Field Zoom Screen 223
Show Screen Filter 203 TO Parameter
taskid Format DO SHOUT Statement 722
MEMLIB Parameter 533 STEP RANGE Parameter 652
TASKTYPE Parameter TO Step

Index 1003
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

DO IFRERUN Statement 455 Environment 85, 130, 187

Restart Step List Window 241 TYP Field
TO STEP Field Active Environment Screen 178
Restart Confirmation Window 233 TYPE 1
TO=OPER Value Parameter Prompting 348
DO SHOUT Destination 478, 479, 641, 642 TYPE 2
TO=TSO-ID Value Parameter Prompting 348
DO SHOUT Destination 479, 642, 725 TYPE Field
TO=USERID Value Conditions/Resources 290
DO SHOUT Destination 478, 641 Manual Conditions 299
Tocol Parameter Parameter Prompting 361
FIND Command 101 Rule List Screen 262
TOP Command Type of Task
Scrolling 100 TASKTYPE Parameter 666
TOP SECRET 586 TYPE Parameter
Totals Line CTB STEP Parameter 419
Global View Screen 207, 209, 211 TYPRUN Parameter
Tracking and Control Tape Pull List 868
Description 60 TYPRUN=HOLD
Tracking and Control Facility CMEM On Spool Job 696, 700
Online Facility 172 TYPRUN=SCAN Parameter
Transfer Command AutoEdit Simulation 341
Multi-Screen Control 94 Tape Pull List 866
Transfer of Control
TSO/Online Facility 97, 113
Transfer to TSO/Utilities
PF06/PF18 97
U
TSO U-M 479, 642
AutoRefresh Mode 104, 182 U1 Option
Command Processor Screen 112 Online Utilities Menu 378
Commands 112 UNDELETE Option
Control 97, 113 Active Environment Screen 188
Screen 112 UNEXPECTED CC Status
TSO Application Show Screen Filter 202
Online Facility 113 UNITDEF Member
TSO CLIST facility 827 IOA PARM Library 248
TSO Cross Memory Option Unix system services 919
PF06/PF18 97 Unnnn Code
TSO CTMTTRA Command +EVERY Step 558
Transfer to IOA 113 Unscheduled Condition
TSO Environment Manual Conditions 832
OWNER Parameter 586 UNTIL DAYS
TSO Job TIME + DAYS Parameter 671
CMEM On Spool Job 695 UNTIL TIME
DO STOPJOB Statement 727 TIME + DAYS Parameter 671
TSO Option UNTIL Time
Primary Option Menu 90 TIME Parameter 671
TSO SEND Command Unused Tracks
DO SHOUT Statement 477, 723 MINIMUM Parameter 540
SHOUT Parameter 639 PDS Parameter 588
TSO Transfer Command UP Command
PF06/PF18 97 PF07/PF19 97, 99
TSO User ID UPDATE Option
Quick Schedule Definition 369 Parameter Prompting 353, 362
TSO-id Value Update Parameters
DO SHOUT Destination 477 Fields 355, 366
TSO/ISPF Screen 355, 365

1004 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Type 1 Option 1 353 AutoEdit 758

Updating Variables DO SET Statement 472, 759
Variable Zoom Screen 285 SET VAR Parameter 473, 631
UPP Source Priority 778
User Prompting Plan 845 USS
UPPTBLB Parameter CONTROL-M implementation 919
CTMEXEC CLIST 848 USS services 919
CTMFETCH CLIST 847 USS, CONTROL-M and
URGENCY architecture for Unix-oriented implementation 921
DO REMEDY parameter 467 CONTROL-M Option for SAP/R3 923
URGENCY Field in the USS environment 923
IOA Log Show Screen Window 310 JCL for OS/390 orientation 920
URGENCY Parameter OS/390 oriented 920
DO SHOUT Statement 478, 480 SAP R/3 on USS 922
URGENCY Subparameter SAP/R3 Application Layer 924
DO SHOUT Statement 723 Unix oriented implementation 921
URGN Parameter Utilities
SHOUT Parameter 640 CLIST IOAUTIL 333
SHOUT Statement 643 Conditions/Resources File 335
Usage Line CTMAESIM 338, 806
Screen Layout 96 CTMJBINT 376
USE Field CTMJOBRQ 336, 827
Conditions/Resources 290 CTMJSA 245
WHY Option 297 CTMQUICK 367
User Abend Code CTMSIM 854
ON Statement 559 CTMTAPUL 854
USER DATA Field Fast Transfer 334
Statistics Screen 247 IOALDNRS 298, 827, 831, 839, 842
USER DATA, SMART Table Job Order 336
Statistics Screen 247 Prerequisite Condition 335
User ID Under ISPF 333
IOA Log Show Screen Window 311 Utilities Transfer Command
Online Facility 89 PF06/PF18 97
USER ID Parameter 135
USER INTERFACE Option
Online Utilities Menu 333
USER Message Type
V
IOA Log Show Screen Window 310 V Option
User Plan Active Environment Screen 187, 241
User Prompting Plan 363 VALUE Attribute
User Profile ODATE 67
Active Environment Screen Filter 196 VALUE Field
Customizing 85 Parameter Prompting 352, 355, 366
User Prompting Plan Variable Assignment
Parameter Prompting 362, 845 Definition 776
USER REPORTS Option Variable Database
Primary Option Menu 92 Updating 288
User-Defined Variable 767 Variable Database Facility 278
USER=Library Adding Variables 284
MEMLIB Parameter 532 Database List Screen 280
OVERLIB Parameter 581 Row Numbering 284
USERID Field Variable List Screen 281
Log Screen 304 Variable Zoom Screen 285
USERID Value VARIABLE DATABASE Option
DO SHOUT Destination 477 IOA Primary Option Menu 91
SHOUT Parameter 638 Variable Database Option
UserDefined Variable Primary Option Menu 91

Index 1005
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Variable Database, IOA 913 Zoom Screen 223

Variable List Screen WAIT FOR ODATE Parameter 337
Variable Database Facility 281 WAIT RELEASE Status
Variable Member Active Environment Screen 195
Format 772 WAIT SCHEDULE (PIPE) Status
Variable Resolution Active Environment Screen 195
Concatenation 780 WAIT SCHEDULE (WITH RESTART) Status
Logic 780 Job Rerun 233
Variable Zoom Screen WAIT SCHEDULE Field
Variable Database Facility 285 Global View Screen 207, 209, 211
Variables WAIT SCHEDULE ON SPOOL Status
AutoEdit, Date, Global, KSL, Local, System, User- Active Environment Screen 195
Defined 760 CMEM Forced Job 698
VAULT DEFINITION Option WAIT SCHEDULE Status
Primary Option Menu 93 Cause or Reason 213
Version Information CONTROL Resources 293
Primary Option Menu 94 Job Deletion 218, 255
VG Command Job Graph 210, 212
Active Environment Screen 186, 208 Job Rerun 233
VIEW Command Screen Status 195
Active Environment Screen 186, 206 Show Screen Filter 202
VIEW GRAPH Command SMART Table Entity 575
Active Environment Screen 186, 208 TERMINATE Option 254
View Graph Screen WAIT SUB Status
Color Terminals 209 Show Screen Filter 202
Fields 209, 211 WAIT SUBMISSION Status
Format 209 Active Environment Screen 195
Group Statistics 208 WAIT_CONF Status
Non-color Terminals 211 CTMAPI 906
TOTAL Field 209, 211 WAIT_ORD Status
VIEW Option CTMAPI 906
Active Environment Screen 187, 241 WAIT_PIPE Status
VIEWALL Command CTMAPI 906
Job Order Execution History 243 WAIT_SCH Status
VOL=SER=%%VOLSER CTMAPI 906
Example 816 Warning Message
VTAM 85 MEMNAME Parameter 537
Environment 99 TASKTYPE Parameter 666
PF06/PF18 97 WCAL Field
WDAYS Parameter 387
WCAL Parameter
W Calendar Name 682
Calendar Type 684
WAIT CONFIRM Status Non-periodic Calendar 682
Show Screen Filter 202 Periodic Calendar 684
WAIT CONFIRMATION (FOR SCHEDULE) Status WDATE Parameter
Active Environment Screen 195 AutoEdit Simulation 341
WAIT CONFIRMATION (WITH RESTART) Status WDAYS Parameter
Active Environment Screen 195 Description 681
WAIT CONFIRMATION Status Example 685
CONFIRM Parameter 412 Format 682
WAIT EXEC Status Logic 682, 684
Show Screen Filter 202 MINIMUM Parameter 540
WAIT EXECUTION Status Negative Value 684
Active Environment Screen 195 PDS Parameter 588
WAIT FOR ODATE Field Scheduling Logic 388
Scheduling Confirmation 158 WCAL Field 387

1006 Control-M for z/OS User Guide

 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

WHEN Parameter Primary Option Menu 91

SHOUT Parameter 637, 640
WHY Option
Active Environment Screen 186, 212
Why Screen
Y
Adding Conditions 215 YEAR Field
Deleting Negative Conditions 215 Calendar Definition 322
Deleting NOT-CONDs 215 Calendar Facility Entry Panel 316
Example 212 Job Scheduling Plan Screen 171
Reasons 213 Year List Screen 317
WAIT SCHEDULE Status 212 Commands 318
Window Exit Exiting 332
RESET Command 103 Inserting New Year 320
Windows Year List Screen, IOA Calendar Facility
Active Environment Screen Delete 218 Format 318
ADD Conditions 293
CMEM Rule Exit Option 271
CMEM Rule Table Order 274
CMEM Table Deletion 273
Z
Conditions/Resources Delete 294 Z Option
CONTROL-M/Restart Active Environment Screen 186, 222
Rerun Confirmation 232 ZOOM Option
Delete Conditions/Resources 294 Active Environment Screen 186
IOA Log Show Screen Window 308, 311 Zoom Screen
Manual Condition Add 300 Deleting PIPE Statements 835
Manual Condition Delete 301 Exiting 228
Overwrite Confirmation 371 Fields 222
Quick Schedule Definition Exit 375 Job Order Information 222
Rerun Confirmation 229 MAXRERUN Parameter 525
Resource Quantity 295 SHOUT Parameter 641
Save Documentation 152
Scheduling Facility Exit Option 154
Show Screen Filter 198
Why Screen Confirmation 216
Zoom Screen Confirmation 228
Wish WO0945 276
WITH RESTART Field
Restart Confirmation Window 233
WITH RESTART Status
Active Environment Screen 195
WO0943
APPLY=YES 276
Working Date
Definition 65
System Variable 762
Working Days
WDAYS Parameter 681
WRN Task Type
IOA Log Show Screen Window 311
Show Screen Filter 203

X
X Command
Online Facility Exit 95
X Option

Index 1007
 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

1008 Control-M for z/OS User Guide

Notes
*120055*
*120055*
*120055*
*120055*
*120055*